Kubernetes security is a complex topic. So complex that the National Security Agency recently issued a 59-page guidance document on Kubernetes security hardening. Yet, when you boil this advice down, you’ll find that most sources of compromise in Kubernetes environments fall into three main categories: Supply chain risks, malicious actor threats and insider threats. The key to securing Kubernetes is to address each of these categories of threat individually. This blog summarizes the NSA’s advice for managing these risks within the context of Kubernetes and gives you practical implementation tools.

Understanding sources of compromise

According to the NSA, the three types of threats described above are the most common sources of compromise for Kubernetes environments for the following reasons:

• Supply chain risks: Unauthorized access to any element making up a container system. This can include the risk from third party vendors and software that can enable attackers to compromise Kubernetes clusters on the container level or the infrastructure level, or both.
• Malicious actors: Malicious actors actively seek to exploit security vulnerabilities or insecure configurations within Kubernetes’s complex infrastructure.
• Insider threats: Admins, users and infrastructure providers who have access to Kubernetes resources can abuse their privileges, especially in the absence of rigid access controls.

Managing Kubernetes security risks

With the right tools and processes, all these security risks can be managed. This blog provides a breakdown of the NSA’s main security recommendations, and tips on how to review and remediate them using tools like SecureApp CN.

Scan containers and pods

Containers and pods deployed in Kubernetes can contain malicious code introduced during the build cycle. They could also be subject to insecure configurations such as root-level access to host resources. If deployed into production, insecure containers allow attackers to breach Kubernetes from the supply chain. Defending against this type of risk is relatively simple: You scan container images continuously before deploying pods based on them, as well as in runtime (the latter to detect any new vulnerabilities that may have been defined post your initial deployment).

Enforce least privilege for containers and pods

Running containers and pods with as few privileges as necessary ensures that if a security breach does occur, the ability of a compromised container or pod to infect other pods is minimal. The right access configuration for a given workload will vary depending on its requirements. However, teams can simplify container and pod security configuration using tools like SecureCN, which makes it possible to define different types of Pod Security Setting profiles based on workload requirements.

Use network separation

Isolating Kubernetes resources from each other on the network is another essential step for hardening Kubernetes clusters. It minimizes the ability of a breach to escalate from one resource to the rest of your environment. You can enforce isolation by following the principles of micro segmentation. Here is a great blog that delves into detail on micro segmentation for cloud native applications. Further below, we’ll show how SecureApp CN leverages Istio with the Envoy Proxy to enable micro segmentation.

Control network threats using firewalls

Micro segmentation is useful for isolating workloads at the network level within Kubernetes. However, you should also protect workloads from the public Internet unless they need to be public-facing. You can leverage firewall tools, as well as IAM frameworks in the cloud, for this purpose.

Double up on authentication and authorization

The Kubernetes API requires many requests to be authenticated and authorized by default, but this protection is often not enough. You can gain an added layer of protection by using a tool like SecureApp CN to enforce authentication and authorization policies for communication between clusters.

Use logging and auditing

Many of the components of Kubernetes generate logs, which you can use to detect suspicious activity. Kubernetes also provides audit logging capabilities for tracking requests to the API. It’s critical to make use of both of these sources of insight into potential Kubernetes security risks.

Use admission controllers to enforce security across the cluster

As the NSA guidance explains, Kubernetes admission controllers are one of the most valuable security tools that Kubernetes offers natively. As the NSA’s guidance explains, admissions controllers can be used not just to secure pods, but also for purposes such as image scanning:

Review Kubernetes configurations

Most Kubernetes clusters change over time. The RBAC policies, Pod Security Policies, network policies and other configurations that are effective for securing a cluster at one point in time may no longer suffice in the future. For that reason, it’s critical to review Kubernetes configurations frequently and identify areas that require updating. As an example, here is how RBAC is done with SecureApp CN. For RBAC, SecureApp CN provides risk analysis of users and service accounts, the permissions that are granted to them, as well as the impact of these permissions. SecureApp CN makes it easy to review and then subsequently remediate these permissions. As PSP profiles in K8s are deprecated (as of version 1.21), SecureCN instantiates its own version of PSP profiles, providing the ability to detect, block, and remediate risky host permissions. SecureApp CN provides suggested PSP profiles to make sure that workloads run with minimal host access permissions. Delving into the restricted policies, for example, one can see that policies can easily be put in place to restrict pods from running with root access. Taking it one step further with SecureApp CN, you can define Kubernetes seccomp profiles that can be included in a Pod Security Profile. Seccomp profiles list the system calls that the pod is able to execute. Deployment rules that use the Pod security profile (with the seccomp profile) will check whether the pod complies with the profile. They can also enforce the profile by modifying the pod to conform to the profile. For Network Policies connections, SecureApp CN covers a wide breadth of controls, including:

1. East-west enforcement
2. North-south
3. Seamless encryption
4. Segmentation based on logical environments
5. Segmentation based on workload vulnerabilities levels
6. Layer 7 properties policy
7. Seamless TLS inspection

In the SecureApp CN screenshot below, you can see several policies enabled, including enabling specific (layer 7) read/write communication with Kafka brokers, encryption of specific pod to pod communication, blocking of pod communications based on workload vulnerability levels, and pod segmentation (blocking) based on environments. At first glance, Kubernetes security can seem mind-bogglingly difficult. There are multiple types of risks to address and multiple frameworks within Kubernetes for handling them. However, at a high level, Kubernetes security can be summarized simply enough. The key is devising and enforcing configurations that mitigate the risks of compromise through various vectors -- supply chains, malicious actors, insider threats and beyond. SecureApp CN provides the tools teams need to address Kubernetes security threats at all levels -- from the supply chain, to pods, to service meshes and cluster-to-cluster communications. To access a free trial of SecureApp CN, click here.