Authentication and Policy Enforcement

for Docker

Josh Ellithorpe - 2015

@zquestz

About The Speaker

I am Josh Ellithorpe, a software architect at Apcera. I have been building open source projects and enterprise solutions for the past 20 years. You can see my projects at https://github.com/zquestz

About This Talk

As organizations prepare to move to production, they are looking for ways to extend Docker and employ additional security and policy controls for their deployments. This talk will cover:

• Securing access to your Docker workloads with OAuth2, LDAP, Crowd and Kerberos.
• Extending Docker deployments with policy and governance.
• Securing the network perimeter of Docker workloads while providing multiple multi-host networking options.

The Apcera Platform has always strived to be the best environment for deploying Docker workloads in production. This talk will cover our thinking around secure deployments and how we have extended Docker for our customers.

Current State of Docker Authentication

Currently within Docker, all authentication/authorization is done at the registry level. This can control who can push and pull to your registry, however there are many other concerns where you need to know "who" is doing an action so you can provide proper policy and security enforcement. For example:

• What network routes (http, tcp, udp) should be allowed?
• How many resources can this user consume?
• Where can the user deploy this application/service?
• What packages and software is this user allowed to use?
• How do a I provide an audit trail for all actions the user is attempting?

Reality of the Enterprise

Today in the enterprise, they have already rolled out complex authentication solutions. Integrating with these solutions is the first step to a sound authentication/authorization system. These include:

• LDAP (https://tools.ietf.org/html/rfc4513)                        
• Kerberos (https://tools.ietf.org/html/rfc1510)
• OAuth2 (https://tools.ietf.org/html/rfc6749​)
• Crowd (https://www.atlassian.com/software/crowd/overview/)

At Apcera we have integrated with the common enterprise authentication systems. No need to use yet another authentication system, or deal with token based auth complexity.​ Once you have logged in, then deploying docker workloads is as easy as "apc docker run" which has similar functionality to the standard "docker run" command.

Authorization and Policy

Once the user is logged in, the next step to a mature enterprise deployment fabric is tight policy controls. At Apcera we have developed a policy grammar to control every aspect of a job's lifecycle. This includes but is not limited to:

• Resource controls for network bandwidth, cpu, memory and disk.
• Scheduling policy for where a workload should run.
• Network policy to control network ingress/egress
• Routing policy to control domains you can attach to a job.
• Audit log policy, so you can control who can see audit logs in the system.
• Registry policy to control what images can be accessed, and from what docker registries.

Along with the policies listed above, there are many others we provide for native workloads, these are just the ones pertinent to Docker.

Policy Samples!

Docker Policies

Whitelisting Registries

job::/sandbox/someuser {
  { docker.allow "https://index.docker.io" }
}

Whitelisting Namespaces

job::/sandbox/someuser {
  { docker.allow "https://index.docker.io/mybin" }
}

Whitelisting Images

job::/sandbox/user {
  { docker.allow "https://index.docker.io/mybin/redis" }
}

Resource Policies

Below is a sample of how we control resource consumption within the Apcera Platform:

quota::/sandbox/someuser {
  { total.package.size 6GB }
  { total.memory 5GB }
  { total.disk 15GB }
  { total.network 1Gbps }
}

Scheduling Policies

To control where a workload runs within the Apcera Platform you can define it easily within our policy grammar. This snippet forces workloads for a developer to run within AWS.

job::/sandbox/someuser {
    { schedulingTag.hard aws }
}

Networking/Service Controls

At Apcera we take a unique approach to network security. By default jobs in the system are deployed without network access. In order to grant network access you must bind the job to network services. This could be a service that grants internet access, or just access to a particular CIDR range. You can also link jobs to each other, so that when their IP addresses change, the system can make sure that network connectivity is not interrupted. This provides many benefits:

• Jobs can only talk to the services and network ranges they are allowed to via policy.
• You can run jobs on the same hardware without worrying about if another job/service can accidentally reach it.
• Multiple environments (dev/test/staging/production) can safely run on the same hardware if needed.

Multi Host Networking

Currently Docker has support for multiple networking options, however your mileage with those solutions may vary. At Apcera we have 2 opinionated networking modes. We currently offer:

• NAT based solution using a zeroconf address in the container (non-routable) and exposing needed ports through NAT.
• A virtual layer 2 network using OVS for jobs that assume layer 2 network functionality or do not support NAT.

Between these 2 networking modes we support virtually any software running within the Apcera Platform. Both of these network modes fully support multi-cloud environments.

Final Words

Docker is an amazing tool, at Apcera we see the power of Docker and seek to provide the best possible environment to run your Docker workloads.

We encourage you to give the Apcera Platform a try and tell us what you think!

https://www.apcera.com

Thank You!