Best Practises For Kubernetes Container Security

Kubernetes or K8 is an open-source tool for automating, scaling, and maintaining deployments of container applications. Google founded Kubernetes after running a production workload for 15 years. Some features of Kubernetes are automated rollouts and rollbacks, storage orchestration, and secret management.

Setting up a Kubernetes cluster from scratch is very easy. In a matter of minutes, we can set up a cluster with Minikube, Kops, Amazon EKS, Google Kubernetes engine, or Azure Kubernetes.

Kubernetes Container Security Best Practises

Considering the popularity and ease of setting up the Kubernetes cluster, many enterprise organizations are using Kubernetes to orchestrate their containerized applications.

Though, organizations need to consider and also adopt Kubernetes security best practices for the containerized workload.

Enable Kubernetes with role-based access control (RBAC)

With RBAC, we can define permissions regarding who can access the Kubernetes API and related permissions at a granular level. Kubernetes combines the authorization controllers so it is better to disable the legacy attribute based access control. It is advisable to avoid granting cluster-level permission, even during troubleshooting.

Keep Kubernetes up to date

As it is open source, Kubernetes has many contributors. Thus, it is important to stay up to date with the latest version considering the security vulnerabilities and related updates.

Integrate Kubernetes with third-party authentication

We can integrate Kubernetes with third-party tools, like GitHub, for authentication. These tools provide additional security features like multi-factor authentication, etc.

Limit direct access to the Kubernetes nodes

Limit SSH access to the Kubernetes nodes to avoid the risk of unauthorized access to the resource. We can also use Kubernetes authorized plugins to control user access to the resources.

Setup administrative boundaries 

We can create a Kubernetes namespace to partition the resources into logical groups. Resources created in one name space won’t be accessible to another namespace. We can even create policies to separate access between the namespaces.

For example,

{
    "apiVersion": "abac.authorization.kubernetes.io/v1beta1",
    "kind": "Policy",
    "spec": {
        "user": "sagar",
        "namespace": "cloud1",
        "resource": "pods",
        "readonly": true
    }
}

Enable network isolation

Running multiple applications on a Kubernetes cluster runs the risk of one application interfering with another application. Therefore, network isolation is important to ensure containers can only communicate with those that are supposed to communicate.

Enable security context for pods and containers

While designing the containers and pods, it is advised to configure the security context for the pods, containers, and volumes. We can define security context properties in the YAML format.

Source

For example, pod definition with security context parameters,

apiVersion: v1
kind: Pod
metadata:
name: first-pod-security-context
spec:
containers:
# specification of the pod’s containers
securityContext:
readOnlyRootFilesystem: true
runAsNonRoot: true

Enable Kubernetes cluster logging

Enable logging for all cluster-related activities. We can also integrate the output of cluster logs with tools like Google stackdriver logging or ElasticSearch.

Secure Secrets

Kubernetes cluster secrets contain sensitive information such as passwords, tokens, and SSH keys. Kubernetes supports encryption to ensure communication between the API server is protected with TLS/SSL.

It is also recommended to frequently rotate secrets to make it harder for attackers to gain unauthorized access to the cluster.

Protect etcd with TLS, firewalls, and encryption

etcd stores the state of the cluster and confidential information in the form of secrets. It contains all the confidential information and is the highest-value target for attackers. If unauthorized users get access to the etcd, then the entire cluster is vulnerable to security attacks.

Encryption of the etcd component is very important and it is not turned on by default. We can enable encryption using the kube-api server process.

Setup process whitelisting 

Whitelisting is an effective way of identifying unexpected running processes. For this, you first need to understand overall application behaviour over a period of time. Then, use this pattern/list to whitelist the workload to the Kubernetes cluster.

It is also difficult to do runtime analysis at the process level but there are various solutions available in the market that minimize the overhead.

Lock the kubelet

Kubelet is basically an agent that runs on each cluster node that interacts with the container runtime to launch the pods. Various configuration options are available to lock kubelet to improve the overall security of the cluster.

Disable anonymous access with --anonymous-auth=false. 

Unauthenticated requests won’t be able to access the cluster and they will get an error response.

Set --authorization mode

It is recommended to set the value for this variable to AlwaysAllow to verify that requests are authorised. 

Set --read-only-port=0

This configuration will enable read-only ports to prevent anonymous users from accessing information about running workloads. 

Conclusion

Kubernetes provides more flexibility and ease of deployment to orchestrate and containerize your enterprise workloads. Kubernetes has many in-built features to secure the deployment of the application. With the right configurations, we can prevent unauthenticated and unauthorized access to the Kubernetes cluster and underlying application.