Containerization brings along scalability, portability, and agility. However, the distributed nature of containers makes security enablement inherently more challenging. As organizations continue to increase the number of containers in production, automation becomes a necessity. While container orchestration solutions, such as Kubernetes, solve this issue, they add yet another layer to security.
A recent report by Red Hat demonstrates that 94% of the respondents had a security-related incident in the last 12 months. Common causes were:
With misconfigurations prevailing, it is clear that setting up Kubernetes at scale might be troublesome for first-time users. The study highlighted the following configuration mistakes:
The runtime life cycle seems to be the most vulnerable as 49% of respondents faced issues at different stages, mostly at build and deploy. The exposure may also appear through an inconsistent security strategy across on-premises and hybrid, public and private, as well as multi-cloud deployments.
67% of participating companies reported having a container security strategy in place, indicating a positive trend for the industry. Some of the common approaches involve building DevSecOps teams or shifting left (incorporating security at earlier stages). Despite that, 29% of respondents have significant concerns about the maturity of the strategies existing in their companies. That being said, organizations could benefit from taking proactive measures to harden Kubernetes deployments.
The official documentation for Kubernetes contains extensive security guidelines detailing how companies can prevent unauthorized access, data leaks, and other vulnerabilities. A report by the National Security Agency (NSA) and Cybersecurity and Infrastructure Security Agency (CISA) of the USA also delivers profound insights on securing Kubernetes clusters. Listed below are some best practices to keep in mind when running apps on Kubernetes.
Ensure that image scanning is part of your routine, conducted on a regular basis. For this purpose, you can utilize the default admission controller that intercepts and processes requests to the Kubernetes API. This happens once the request is authenticated and authorized before the controller moves on with object persistence. One can also implement a custom webhook, enabling the admission controller to block the deployment of container images if they do not meet predefined security requirements.
Give containers and pods as few permissions as possible. For example, run container images as nonroot users. Setting up role-based access control to limit the actions that users, groups, and service accounts can perform in a namespace is a viable alternative.
Utilizing host and network firewalls, as well as Kubernetes network policies can significantly reduce the damage from a breach. Isolate namespaces by denying all ingress and egress, allowing only those connections that are specifically required.
Log auditing enables administrators to keep track of all the activities and get customizable alerts. When it comes to microservices-based architecture, one may consider a service mesh like Istio to gather logs from each of the components.
Routinely inspecting all Kubernetes settings, applying the latest security patches, and running vulnerability scans helps to minimize any potential risks.
To make sure that no issue is overlooked, test your Kubernetes and Docker deployments, as well as operating systems using credible benchmarks (by the Center for Internet Security, for instance).
It also makes sense to assess the maturity of your security strategy, by using professional support services from a trusted system integrator.
