Containers play a vital role in the development, deployment, and seamless management of applications. However, just like any other technology, containers also are prone to malicious attacks and breaches. That's why it's important to secure the containers with a robust security model.
When it comes down to container security, customary firewall systems won’t really do the job in the public sector. Instead, the public cloud requires a powerful security model that can detect vulnerabilities in the container images, or in the orchestration or where they are stored, or in the deployment.
Let’s have a look at the significance of container security and how it can bring trust to the public sector:
Need for container security
Open-source container technology has outperformed traditional application development technologies. Today, organizations are transforming digitally at a rapid pace, and federal IT professionals are now changing the security practices for such modern technologies as well. Zero-trust models are one of the best approaches for securing containers; however, it calls for meticulous upfront work.
Container security requires a “shift left” approach where IT developers will integrate security into the software from the beginning to the end of the development process. To do this, developers need to switch from legacy security tools and practices to modern cloud-native security models. These models aim to embed security into the application right from the start of the development pipeline.
Building applications on VMs or Kubernetes requires end-to-end security to avoid data breaches and cyber-attacks. For a container deployment in the public cloud, generally, developers need to break applications into micro-services, which again changes the software design beneath and requires security amendments.
Traditional firewalls define trusted users and restrict unauthorized users. Still, the notion is quite lacking for public clouds where there are a high number of internal (between cluster nodes) and external (between users and systems) connections. In such circumstances, “zero-trust” proves to be a better and effective security model.
Google first employed the Zero-trust model, and it assigned user access control for their cloud resources. Later, Google realized that machine-to-machine connections and microservices break old-school security models, even in container deployments.
Zero-trust model for container security
As the name suggests, zero-trust is a security model that breaks the implicit trust offered by traditional security practices, which implies trust based upon the network location of a device or user’s authentication via a trusted network. Instead, the Zero-trust model employs “explicit trust,” which verifies before accessing any device, service, database, or application.
The Zero-trust model replaces the old-style “trust and verifies” notion with the new “never trust and always verify” axiom. Instead of providing implicit mutual trust, it rather authenticates and verifies access. Further, it provides centralized network control for a system of edge devices along with end-to-end encryption. As a result, it will destroy the decentralization of IT infrastructure and address the security issues of containers in the public cloud.
Organizations can build software upon a transition network security model and employ a zero-trust security model to machine-to-machine connections (between microservices and containers).
Zero-trust security is based upon the following principles:
It eradicates traditional mutual trust between containers and instead adopts authenticated user access to container services. Such compulsory authentication mitigates the risk of cyber-attacks, as it weakens hackers’ ability to access compromised systems or containers easily.
All servers will define a root of trust within a container through a local certificate cited in a server’s TPM (Trusted Platform Module). These certificates verify and authenticate the system admin’s access and any changes to configuration or codes. Any other changes to code or system updates that the authenticated admin does not execute are hence rejected. Even when these changes do not come from an authenticated code repository, they’re declined.
Containers running on a shared operating system are all sandbagged in virtual networks and virtual machines.
Code changes and infrastructure changes are all cryptographically hashed via a server’s local certificate and carefully logged to get a permanent record for compliance audits and troubleshooting purposes.
Communications between services or within a container are authenticated via the server’s local certificate in TPM to offer end-to-end encryption. However, it does not offer implicit trust to inter-container communications based upon a local IP address.
Services such as PKI (Public Key Infrastructure) and IAM (Identity and Access Management) offer centralized management of security policies and elements, including TFA (two-factor authentication) integrations, user certificates, users, RBAC (Role-Based Access Controls), and code/machine certificates.
To summarize, all of these fundamental principles of the zero-trust security model allow organizations to embed robust security into their entire software development lifecycle in the public cloud. In addition, the model ensures microservices and containers only establish connections with services that are authenticated via explicit trust.
Moreover, these security practices allow containers to run in multi-cloud and hybrid environments with the same security as a single-cloud deployment. To enforce security controls, containers may depend upon the underneath infrastructure.
How to implement zero-trust security using public cloud services?
To understand how zero-trust works, let us consider an example of an application requesting access from the back-end container service via a web server. This scenario is taken from Google’s documentation related to their internal zero-trust project, viz. BeyondProd.
The application makes a data request by establishing a TLS connection to the server.
Now, back-end and front-end, both systems have local TPM certificates that authenticate TLS connections. If the machine requesting is a fraud, it won’t be able to establish a connection since public-private key pairs will mismatch.
The front-end server parses the REST API request and sends it to the desired container service. Each container service has its account or identity along with cryptographic hashes in the IAM system. These credentials may include public-private key pairs, which are meant to authenticate the identity of requesting clients and help them establish an encrypted, secure connection.
Once the front-end server authenticates the requesting client via a second TLS contention to the IAM system, it will form a second secure TLS connection to a back-end storage service and define an RPC (Remote Procedure Call) command.
The back-end service will authenticate the front-end service for access and also authorize the user to access the file or data object.
If any of the zero-trust security checks mismatches, the access is rejected. If the security checks pass, the data is provided to the front-end service, which is further routed towards the requesting client.
Now, this was all about Google’s internal zero-trust project. Today, IT organizations can apply the zero-trust robust security practices broadly to any of their container infrastructure that offers:
Server TPM and controls to cryptographically verify and authenticate individual devices.
Service-traffic router with the ability to form authenticated TLS communications and route REST API requests towards the desired container service.
IAM system that can authenticate users and define cryptographic credentials.
Container-level network isolation with inter-container connections that is secure and encrypted within the virtual network.
Platform-enforced isolation for each container that shares a cluster node
With some ramifications here and there, organizations can configure most cloud container platforms such as Azure Kubernetes Service, Amazon Elastic Kubernetes Service, etc., in a zero-trust environment. Or, you can also adopt SaaS solutions to employ zero-trust container security that will work with any VMs or Kubernetes nodes.
The zero-trust security model is one of the best solutions for multi-cloud environments, as it secures and encrypts all machine-to-machine communications.