Securing Containerized Services
Containers are increasingly becoming an important part of enterprise applications. They help to build immutable infrastructures. Immutability makes it difficult for attack vectors to access a container and modify it in such a way that a backdoor is created. Immutability also makes updating a container easy. In case a security vulnerability is identified in one container, it can be replaced and the threat can be limited to that container.
Containers have only a minimum number of software components, which reduces the surface area of attack. Also, the entry and exit points of each container are defined clearly. By following the principle of least privilege, a container’s access to various resources can be limited to those necessary for it to function.
But container security is only as good as the security practices that are followed:
Container running as root: A container running as the root user is as insecure as any application with root privilege. Container technology does not create a trust boundary. Organizations need to be aware of this when they deploy containerized applications. The practice of running containers with specific users and groups in the system should be followed.
Image provenance: Any application is only as secure as the image on top of which it is built. Image identification and trust mechanisms are important to secure container-based infrastructure. Having a private authenticated repository that makes use of certificates and digital signatures helps. Repository of trusted images are kept encrypted and audit is held on the repository to ensure compliance with security processes.
Security testing: Any image should also undergo security testing before being deployed to the environment. Ideally, the security tests should be a part of the CI/CD pipeline, and run similar to how unit tests do. Only if the built image passes the security tests should the pipeline deploy the container to your stack.
Containers vs Virtual Machines: A Security Perspective
Containers do not provide as much isolation as virtual machines. In virtual machines, the guest operating systems do not share a single kernel and the systems can have different security profiles. There is little chance of weakness in one affecting another. Containers, however, provide a powerful means of isolating applications that otherwise share the same host and security profile.
Containers ensure isolation of applications using some of the functionalities provided by the Linux kernel for process isolation. However, many aspects of the processes (such as a user namespace) are not isolated in the Linux kernel. This makes container isolation mechanism a vulnerable attack surface. An attacker who gains access to a container can exploit vulnerabilities of container runtime to affect other containers or the host.
Mandatory Access Control as Defense
Constraining an application’s ability to access or perform an operation on other resources such as a network port or file devices can be constrained through mandatory access control. In the context of containers, access control limits a container’s ability to affect the host or other containers.
Devising appropriate policies with any of the two MAC systems SELinux or AppArmor helps contain an attack even when the attacker is able to exploit the service provided by one of the containers. Depending on the level of security and flexibility needed, we help you choose the appropriate MAC tool. Linux kernel can also be used to restrict container applications in the place of MAC.
Securing the Boundary
Firewalls provide the first level of security to all Internet-connected applications and services. With the advent of cloud infrastructure, additional security hardening mechanisms like Virtual Private Cloud (VPC) are available. VPCs allow you to create a set of computing resources connected through Virtual Private Networks with only certain nodes exposed to the Internet. Network rules can be created between these nodes to prevent a breach. Quite often, the focus is on network access from the outside. It is equally important and useful to restrict outgoing traffic from each computing resource. Systematic isolation can be achieved by creating subnets in VPCs.
Securing Container Runtime and Platform
In the case of virtual machines and containers, the security of the host is also a concern. Vulnerabilities in the host platform or runtime can lead to breach across containers.
Using fully loaded systems can increase the attack surface in both cases. The isolation that virtual machines or containers provide is not on par with bare metal servers. Technologies like gVisor from Google provide an additional layer of security. All of this points to the need to devise your security strategy carefully.
All communication between machines should be cryptographically secured using Transport Level Security (TLS) protocol. To the extent possible, communication should be through a private IP. Data at rest should be encrypted using AES-256 and proper data management practices should be followed. This will help you comply with privacy policies and contractual obligations.
API Key Handling
With the rise in the microservice model of application deployment, API keys have become a source of risk. They are often handled in an insecure manner. Once a service is breached and the key to other services used by the breached service is visible to the attacker, it leads to a cascade of breaches. It is very common to find deployment script with API keys getting exposed over version control systems.