According to a 2020 survey, 86% of companies that use containers manage them with Kubernetes, but over 50% say they are not investing enough in container security and are concerned that the security will affect their production schedule or could cause harmful security breaches. Kubernetes security risks typically correspond to phases in the container lifecycle.
Therefore, the best practices and practical recommendations for Kubernetes security sometimes referred to as Kubernetes container security, relate to properly responding to threats at run time, avoiding configuration errors during the deployment and deployment phases, designing and addressing known vulnerabilities during the construction phase. These Kubernetes security best practices are essential to securing cloud-native infrastructure and applications.
Kubernetes are vulnerable to several types of security threats, including:
- Compromise on the Kubernetes control plane: Critical components such as ETCD and API servers are not sufficiently secure by default. An attacker who accesses a Kubernetes master node could take control of an entire cluster.
- Node and Pod Exposure: An attacker could gain access to a physical host running multiple Kubernetes pods or a single pod, which could exfiltrate data into the pods and move it to other parts of the cluster.
How to get started with Kubernetes Security
With so many Kubernetes security considerations, it can be difficult knowing how to get started and stay safe.
These three tips will help you keep Kubernetes secure:
- People and processes are essential
- Use a supported Kubernetes distribution service
- Workload monitoring
People and processes are essential
While the technical side of security is vital, your people and processes are just as important. Running containers and Kubernetes affects the entire IT and development chain: developers, security, infrastructure, and operations teams.
For this reason, it is best to reduce and expand your knowledge base and your key experts in all disciplines. But don’t try to do everything yourself. Leverage the large Kubernetes community, third-party tools, and experienced Kubernetes service providers in your K8 deployment. They can also offer ongoing Kubernetes security assessments and offer guarantee that you are up to date with the latest best practices.
Use a supported Kubernetes distribution service
It’s almost always better to use a supported Kubernetes distribution from a trusted provider rather than configuring it for your production environment yourself. With over 90 compliant and certified Kubernetes distributions, they offer built-in platform security for role-based access control and more.
But even the best distribution lacks some network security rules, access controllers, and pod security for workloads. Choosing the right distribution for your needs is critical to Kubernetes security, but it doesn’t eliminate the need to search for vulnerabilities or configuration errors in Kubernetes and container security.
Kubernetes security tools for monitoring workloads
Kubernetes is an orchestrator and set of APIs that can be used to create and run various workloads but cannot serve as a stand-alone solution for most production environments. Rather, it relies on third-party configurations and tools to achieve optimal security standards. Layering the tools can help complete this picture.
Kubernetes Security: Important Considerations
Here are some considerations for creating a secure Kubernetes environment:
Hardening and resilience
The Kubernetes platform is extremely feature-rich, with some enabled by default and some not. You can use security credentials published, for example, by the Center for Internet Security (CIS). While these checklists are exhaustive, they do not consider the impact of certain parameters on performance or the relative importance of various security controls.
Hardening Kubernetes is a demanding process. The clusters must be configured in such a way that access to the API server via HTTPS, the use of X.509 certificates for communication and authentication, encryption of the data store ETCD, etc. is guaranteed.
The balance between security and agility
Automating security from day one almost always pays off. CI / CD pipelines should use the automated unit and functional tests and contain vulnerability scanners and other automated security gates. To make this easier, DevOps teams should enable AppDev teams to seamlessly integrate monitoring, alerting, and logging services while delivering microservice-based applications.
Kubernetes security best practices
Here are some practices that can improve the security of Kubernetes clusters.
Isolate Kubernetes nodes
Kubernetes nodes should be on a separate network and not directly exposed to public networks. Preferably, they shouldn’t be exposed to the larger corporate network either.
To achieve this isolation, you need to separate Kubernetes controls and traffic. Otherwise, both data types pass through the same channel and open access to the data plane implies open access to the control plane. Ideally, nodes should be configured to only allow connections from the master node on the specified port, which is managed by the Network Access Control List (ACL).
Use the process whitelist
The whitelist begins by observing the normal behavior of an application and making a list of known good processes. It becomes a whitelist that defines which processes are allowed to run, excluding other unexpected processes. It is difficult to do this on a large scale; commercial container security products can help operationalize the analysis of fulfillment processes.
Compare runtime activity in similar pods
When replicating containerized applications, whether, for increased availability, fault tolerance, or scaling, replicas should behave identically. Any significant deviation deserves attention.
When integrating Kubernetes security tools with security systems like Security Information and Event Management (SIEM) or collaboration tools like Slack, use deployment labels or annotations to alert teams concerned about potential threats.
Enable role-based access control (RBAC)
Role-Based Access Control (RBAC) regulates access and authorizations to the Kubernetes API. It is enabled by default in Kubernetes 1.6 and higher. However, the configuration settings should be checked after the upgrade. Legacy Attribute-Based Access Control (ABAC) must be disabled when RBAC is enabled.
After applying RBAC, namespace-specific permissions should be preferred over cluster-wide permissions. Cluster administrator privileges should only be granted on a case-by-case basis, including during debugging.