Docker 1.12 – Another Piece In The Container Security Puzzle
| DevOps |
Docker has taken a welcome step toward making security easier for containerized applications. In Docker 1.12, made generally available last Friday, Docker, has been enhanced with “mutually authenticated transport layer security (TLS), providing authentication, authorization and encryption to the communications of every node participating in the swarm, out of the box.” It also automatically rotates PKI certificates for containers. All of this is enabled automatically on startup of the swarm, for secure-by-default orchestration.
The Docker 1.12 security improvements address what has been a tradeoff between deployment simplicity and risk, especially as deployments grow in complexity and scale. However, even as Docker 1.12 secures communications within and across nodes, the question of what they can do once they connect – and who within the organization can define what they can do – still needs to be resolved. These questions apply to containers, their hosts, the Docker registry, applications and services accessing the nodes, and the people responsible for managing the Docker 1.12 infrastructure.
- What permissions do containers have to access shared host resources and secrets?
- How are policies defined for client authorization to the Docker Registry?
- Can token use be logged and audited?
- Who or what gets to make changes to the Docker Engine or daemon, and how are they authenticated?
- Who gets permission to make access policy changes, and how are changes tracked?
- How are permissions defined to make changes to Docker processes (master, worker) based on organizational role – such as developer, QA or production?
- How are changes and activity logged for containerized applications and management?
These security, compliance, and governance questions are not restricted to Docker – they apply from one end of the software delivery pipeline to the other, from software repos, through build, release, orchestration, and configuration management. Therefore, the container security introduced in Docker 1.12 should be seen as a piece in a larger, role-based access management solution that secures the entire software delivery pipeline consistently.
Conjur Fit for Purpose: Container Authorization
Conjur’s role based access control, secrets management and authorization policy abstraction layer fills in many of the pieces of the puzzle needed for more secure Docker orchestration across environments.
Secrets & SSH management for the entire software delivery pipeline
Conjur manages secrets (including certificates, API keys, passwords and SSH keys) in a centralized service that is easily integrated with the Docker 1.12 environment. Conjur defines, enforces, and audits compliance with authentication and authorization policies for:
- The containers themselves,
- Human identities managing and building applications on the Docker infrastructure,
- and Docker machine identities (notably the Docker daemon).
The secrets management service releases secrets to the Docker controller based on authorization events, and ensures that they are regularly rotated and that access is strictly controlled and logged. For organizations that use SSH to control developer, administrator and application access, Conjur manages and audits the SSH access to the cluster nodes. Conjur also provides the authentication and authorization service for the Docker Registry, with all activity logged on the basis of issued tokens.
Least-privileged access to Docker & associated infrastructure
Conjur’s policy framework enables role-based permissions for developers and administrators that should have least privilege access to Docker and the cloud services that support container deployments. Centralized management of clearly defined policies and role-based access controls translates into consistent patterns as well as visibility into all changes made across the containerization tier.
More fundamentally, Conjur allows customers to ensure that authorization is a separate step from authentication, during which the login system determines if the authenticated user or container should be granted login access based on their access key, and what their access level should be. Here, Docker’s new authentication features can be leveraged for greater automation.
As containers are started and ‘Conjurized’ they have the ability to individually filter inbound traffic based on policy rules, ensuring no rogue services spin themselves up, and outbound traffic is contained. With all communication between containers appropriately tagged based on issued tokens, Conjur delivers complete audit records for all static and ephemeral services.
Protection for for hybrid application infrastructure
Most customers are still going to want to retain some flexibility on what platforms and environments their containerized applications run on – including hybrid cloud architectures. Docker has put containers on the map, but for larger enterprises the reality is that multiple container platforms and methodologies will co-exist or operate in parallel. This means that for security and consistency, authentication, access management and authorization should be abstracted from the underlying platform.