Breaking applications into microservices for a container deployment doesn’t just change the underlying software design — it also has significant ramifications on security, particularly when deployed on the public cloud.
Traditional firewall-based network security, which delineates trusted users and systems from untrusted outsiders, is inadequate in the cloud, where there’s a high volume of both internal — between nodes in a cluster — and external — between users and systems — connections. Zero-trust security has emerged instead as a more effective model.
Google adopted a zero-trust security model that it first applied to user access control for cloud resources. The company later realized that microservices and machine-to-machine communications similarly break traditional perimeter-based network security models — including in container deployments.
While many of the zero-trust concepts described here relate to Google’s internal practices, organizations can apply them more broadly to ensure container security in the cloud.
Zero-trust principles for containers
Zero-trust security replaces implicit trust — or trust based on a device’s network location or a user’s authentication onto a trusted network — with explicit verification to access any service, device, application or data repository.
Zero-trust rewrites the old axiom of “trust, but verify” to “never trust and always verify.” It replaces implicit mutual trust with authenticated access and centralized network control over a system of edge devices with encrypted connections. This helps address the security challenges of a decentralized IT environment — and makes zero-trust an ideal model for container security in the cloud.
Organizations can build on traditional, perimeter-based network security using firewalls, and adapt zero-trust client security to machine-to-machine communication between containers and microservices. Zero-trust security in this context is built on several principles:
- There is no implicit mutual trust between containers, but rather, authenticated access to services. Such mandatory authentication thwarts a hacker’s ability to easily migrate from one compromised container or system to another in the same cluster, which limits the so-called blast radius of an attack.
- All servers in a container establish a root of trust via a local certificate installed in a server’s hardware trusted platform module (TPM). These certificates authenticate and validate administrator access and any code or configuration changes. Any system updates or applications that aren’t initiated by an authorized administrator, and don’t come from an authorized and trusted code repository, are rejected.
- All infrastructure and code changes are cryptographically hashed using the server’s local certificate and logged to provide an immutable record for troubleshooting and compliance audits.
- Containers on a shared OS are sandboxed in VMs and virtual networks.
- Inter-container or service-to-service communications are authenticated and encrypted via the local certificate and TPM. There is no implicit trust between containers based on a local IP address.
- Services such as identity and access management (IAM) and public key infrastructure (PKI) centrally manage security policies and objects, including users, user certificates, two-factor authentication integrations, role-based access controls (RBAC), and machine and code certificates.
In aggregate, these principles and associated controls enable organizations to bolster container security in the cloud. They ensure containers and microservices can only communicate with other services that are explicitly authorized.
In addition, these safeguards enable containers to run in multiple cloud environments, including across cloud regions or on hybrid clouds, with the same protections as a single-cloud deployment. Containers can rely on the underlying infrastructure to enforce security controls.
Implement zero-trust using public cloud services
These principles are easier to understand in the context of a typical situation, such as a client application requesting a container service. As an example, we’ll walk through a scenario from Google’s documentation on BeyondProd, the company’s internal zero-trust project.
The following diagram illustrates an application accessing data from a back-end storage service via a front-end web server.
- The application establishes a TLS connection to the server to make a data request (ALTS in the diagram above stands for application-layer transport security). Note that both the front- and back-end systems have valid TPM certificates that establish the TLS connections. If any of these machines is an imposter, it will not be able to establish a secure channel to the other, since the public-private key pairs won’t match.
- The front-end server parses the REST API request and routes it to the appropriate containerized service. Note that each service has an identity, or account, in the IAM system, along with cryptographic credentials, such as a public-private key pair, to prove its identity to requesting clients and establish secure, encrypted sessions.
- The front-end server authenticates the requestor via a second TLS connection to an IAM system.
- Once authenticated, the front-end server makes a second encrypted TLS connection to a back-end storage service and issues a remote procedure call (RPC) command.
- The back-end storage service validates that the front-end service is authorized to access the storage service, and that the authenticated user is authorized to access the requested data object or file share.
- If any of these checks fail, access to the data is denied. If they all pass, the data is returned to the front-end service, which then passes it along to the requesting client.
Again, although the example above uses services and capabilities inherent to Google Cloud, organizations can apply these concepts and steps to any container infrastructure that provides:
- Server TPMs and the ability to cryptographically verify the authenticity of individual systems.
- A service-traffic router that can establish authenticated TLS connections and route REST API requests to the appropriate container service.
- An IAM service to authenticate users and provide cryptographic credentials.
- Platform-enforced isolation for individual containers sharing a cluster node.
- Container-level network isolation and encrypted inter-container connections within the virtual network on a container host.
While the details will vary, organizations can configure most cloud container platforms, such as Amazon Elastic Kubernetes Service, Azure Kubernetes Service and VMware Tanzu Kubernetes Grid, in a zero-trust environment — albeit not without a lot of planning and research. There are also packaged SaaS products for zero-trust container security, such as Aporeto, that work with any standard Kubernetes nodes or VMs.
Indeed, zero-trust is especially advantageous in multi-cloud, multi-tenant environments, as it ensures all machine-to-machine transactions are authenticated and private. While zero-trust implementations in multi-cloud will use different services and features on each cloud platform, the security policies, user and group IDs, and certificates can — and should — be portable. Organizations planning for microservices applications that use cloud container services should build zero-trust security into the foundation of their architecture.
