What Is Kubernetes Security?
Kubernetes is the world’s most popular container orchestrator. While it is highly useful for application development, it introduces potential security concerns. The platform is not inherently secure, and while it is possible to achieve secure configuration, this requires specialized expertise and in many cases, dedicated security tools. Organizations must consider several key aspects of Kubernetes security:
- Securing the physical infrastructure—Kubernetes worker nodes, master nodes, and underlying cloud infrastructure.
- Securing the control plane—preventing unauthorized access to the Kubernetes API server and kubectl.
- Hardening cluster configuration—there are numerous critical best practices for securely configuring a Kubernetes cluster.
- Image security—Kubernetes clusters create pods and containers based on image, and these images must be scanned for security vulnerabilities on a regular basis.
- Network security—several open source projects enable network segmentation and applying security policies to govern internal and external communication in a cluster.
Below are the most common issues affecting the security of Kubernetes containers and critical best practices you can use to secure deployments.
Kubernetes Security Issues
Let’s review some key security issues with Kubernetes in production.
Container Images and Image Registries
Organizations need strong governance policies to ensure images are securely stored and that all images used in a Kubernetes cluster are safe and free from vulnerabilities. It is important to create container images from approved security-based images and scan images at all stages of the development lifecycle. Organizations should also ensure that only images from trusted image registries are used.
Container Networking
Pods and containers communicate within Kubernetes clusters and over external networks. When a container is under attack, the ability of a cybercriminal to move laterally is directly related to the extent to which the container communicates with other pods, containers, and endpoints.
Performing network segmentation in a containerized environment can be difficult. Manual configuration of policies is not feasible in large clusters, however you can automate security policies using open source Kubernetes networking solutions.
Kubernetes Default Configurations are Not Secure
Kubernetes provides security controls that organizations can use to protect their clusters and applications. For example, Kubernetes network policies act like firewall rules that specify how pods communicate with endpoints and with each other.
However, Kubernetes does not apply secure configurations by default. For example, pods do not have a network policy by default, meaning they can communicate with any other pod in a Kubernetes cluster. This creates potential security risks, making it critical to apply secure configuration to all clusters.
Secrets Management
An additional configuration risk relates to secrets management. Secrets are sensitive information such as keys and credentials. Storing secrets in clear text in Kubernetes YAML files, container images, or within files on containers, poses a serious security risk.
Organizations should protect their credentials using the secrets mechanism provided by Kubernetes or dedicated third-party secrets management solutions. It’s important to regularly scan your environment for accidentally leaked secrets.
Compliance Challenges
Managing compliance risks in container environments is one of the key motivators of security initiatives. It is not uncommon to see compliance audit failures at later stages of the container deployment process.
To avoid such failures and prepare your environment for compliance requirements, refer to Kubernetes-specific compliance standards that apply to all organizations, such as the Docker and Kubernetes CIS benchmarks and NIST SP 800-190. There are automated tools such as kube-bench that can scan your environment and report configurations that do not match security benchmarks. Resolving these issues can help make your clusters compliant.
Kubernetes Security Best Practices
Isolate Sensitive Workloads
To mitigate the potential impact of a breach, run sensitive workloads on a dedicated set of machines. This approach reduces the risk of accessing sensitive applications through shared container runtimes or insecure applications on the host.
For example, if an attacker compromises a node, that node’s kubelet credentials will allow them to access all secrets mounted on pods running on that node. If sensitive secrets are distributed throughout many nodes in the cluster, attackers will have more opportunities to steal them.
This isolation can be achieved using several methods including node pools (on-premises or in the cloud), Kubernetes namespaces, and configuring taints and tolerations.
Enable Role-Based Access Control (RBAC)
Use role-based access control (RBAC) to control who can access the Kubernetes API and what permissions they have. RBAC is usually enabled by default in Kubernetes 1.6 and later, but double-check the settings to be sure. Due to the way the Kubernetes authentication controller is configured, you will need to enable RBAC and disable the legacy Attribute Based Access Control (ABAC).
After enabling RBAC, you need to configure it effectively. In general, use per-namespace permissions and avoid granting cluster-wide permissions. Do not give cluster administrator privileges to anyone, even for debugging. If absolutely necessary, you can allow temporary access and then immediately revoke it.
If your application requires access to the Kubernetes API, create a separate service account and grant it the minimum set of permissions required. Do not assign broad privileges to the namespace default account.
Vet and Scan Container Images
Do not use container images from public repositories. If you must, use only container images from official vendors such as Ubuntu and Microsoft. A better approach would be to use a Dockerfile definition instead, build an image, and publish it to the private image repository, enable greater control.
Creating your own images still runs the risk of vulnerable components or tampering. Make sure you include a tool in your development pipeline that scans all images and containers for potential vulnerabilities.
Leverage Kubernetes Monitoring and Security Tools
Kubernetes cannot function as a standalone solution in most production environments. Instead, it relies on third-party tools to achieve high security standards. Consider using the following categories of Kubernetes security tools:
Behavioral Analysis and Network Monitoring Tools
Every application has a behavioral pattern, and changes to deployments and configurations can deviate from this pattern. Understanding these anomalies and their causes is critical to discovering and mitigating security issues.
Logging and Monitoring Tools
In a microservices environment, logs are distributed between multiple components and services and it is difficult to get a complete picture of a transaction. Use specialized tools that can capture and store all the logs in a central location, and are able to piece together logs belonging to the same use request. There are several open source logging and monitoring solutions built for a containerized environment.
Network and Storage Tools
In Kubernetes, networking and storage is mainly handled by plugins. Depending on your distribution, there will be default options, which you can replace if necessary. In some cases, to handle complex networking requirements, you will need a service mesh solution.
Protecting Container Environments with Imperva
Defined by cloud-native applications to infrastructure as code, modern coding is created, tested, and deployed at incredible speed. While deploying modern applications has created new attack surfaces, DevOps has the daunting task of balancing the need for speed for applications and the demand for securing them.
Both Runtime Application Self-Protection (RASP) and Web Application Firewall (WAF) are great solutions to protect containers running within Kubernetes clusters. For hybrid enterprises, Imperva lets you manage thousands of containers, each with their operating system versions, system files, packages, and executables, dynamically protecting against security vulnerabilities.
Additionally, advanced API Security can be used to monitor and protect the Kubernetes API that is used to administer and interact with clusters, something that is commonly targeted by attackers. Imperva enables comprehensive API visibility for Kubernetes operators, without requiring development to add resource-intensive workflow to their CI/CD processes.
Imperva also provides comprehensive protection for applications, APIs, and microservices.
