Kubernetes Security: 10 Best Practices From the Industry and Community

Kubernetes requires extensive configuration, and keeping container security at the right level is always challenging. One of the best ways to tighten your clusters’ security is by implementing tactics that have become industry standard. Here are the 10 most important ones.

10 Best Practices for Kubernetes Security

1. Don’t Keep Secrets in an Environment Variable

It’s a good practice to have your objects use a secret in an environment variable since other parts of your system can access environment variables. That’s why it’s best to use secrets as files or take advantage of a secretKeyRef to minimize potential attacks.

2. Use Strong Kubernetes Authentication and Authorization

Integrating Kubernetes with a third-party authentication provider is smart, as it delivers extra security features like multi-factor authentication. Avoid managing users at the API server level to make access to the control plane more secure. Use Identity and Access Management (IAM) solution from the cloud service provider if you’re running a managed Kubernetes service like EKS, GKE, AKS, or similar. Go for OpenID Connect (OIDC) alongside an SSO provider you got used to if CSP IAM isn’t an option.  

3. Disable the NET_RAW Capability

If your K8s containers don’t drop the NET_RAW capability, you risk enabling a wide range of networking exploits from within the cluster. It’s best to use Policy Enforcement solutions like Open Policy Agents, Kyverno, or Kubernetes Pod Security admission controller to ensure you are following best practices. Use drop for ALL or NET_RAW capabilities in the pod’s securityContext definition to ensure that the NET_RAW capability is disabled.

4. Avoid Sharing the Host’s IPC or Network Namespace 

Check if your pods are sharing the host’s IPC or network namespace. Sharing namespaces for pod and host interprocess communication may lead to opening access to shared information. Pods should not be allowed access to the host namespaces. 

And sharing pod and host network namespaces enables network access to the host network from the pod, which breaks network isolation. That’s why you better set the hostNetwork parameter to false in PodSecurityPolicy.

5. Use Kubernetes Role-Based Access Control (RBAC)

RBAC helps to define who has access to the Kubernetes API and on what permissions. In Kubernetes 1.6 and higher, RBAC is usually enabled by default. Since Kubernetes combines authorization controllers, make sure to disable the legacy Attribute Based Access Control (ABAC) when enabling RBAC.

Pick namespace-specific permissions over cluster-wide permissions. Even when debugging, don’t grant cluster administrator privileges. Otherwise, your container security may be compromised.

6. Avoid Usage of Root File System for Container Security

Are your containers running without a read-only root file system? Using a read-only file system prevents malicious binaries from writing to a system or a system takeover by attackers. You can ensure that containers use only the read-only file system by setting readOnlyRootFilesystem to true in Pod securityContext definition. 

7. Isolate Your Kubernetes Nodes

Kubernetes nodes should never be exposed directly to public networks. Ideally, these nodes are located on a separate network and – if possible – without any direct connections to the general corporate network. 

You can achieve this by keeping Kubernetes control and data traffic isolated. Otherwise, they both flow through the same pipe. Open access to the data plane means that access is open to the control plane as well. Configure nodes with an ingress controller and set it to only allow connections from the master node via the specified port through the network access control list (ACL).

8. Avoid Running Containers in Privileged Mode

Does your deployment have containers running in privileged (root) mode? This allows the container to gain access to critical resources of the host. Avoid running containers in privileged mode or enable the podSecurityPolicy with the privileged parameter set to false. This will ensure that containers can’t run processes that require root privileges on the host.

9. Check for Unsafe /Proc Mount

Deployments with unsafe /proc mount (procMount=Unmasked) will allow bypassing the default masking behavior of the container runtime. Setting a container with an Unmasked /proc mount type can potentially expose the host information to the container and, as a result, cause a potential information leakage or container escape. Set procMount=Default to ensure the container doesn’t unsafely expose any parts of /proc.

10. Have a Rolling Update Strategy

Another smart move is developing a rolling update strategy. Rolling updates allow deployment updates to minimize your application downtime by incrementally updating pod instances with new ones. See this page in the Kubernetes docs for more details.

Achieving Kubernetes Security Is Challenging

The Kubernetes ecosystem is constantly changing – and so are its security and configuration parts. Keeping up with these changes takes time and effort, stealing away engineers from other tasks and screaming for their attention.

Another challenge teams experience around Kubernetes security is the prioritization of security issues – depending on the application’s size, prioritizing issues may become time-consuming.

But automation is here to change that.