10 Kubernetes Security Best Practices

Kubernetes security is critical throughout the life of the container due to the dynamic and distributed nature of a cluster. For a cluster to be considered effective and stable, it needs to be secure from unauthorized changes.

---

Use Kubernetes Role-Based Access Control (RBAC)

This feature has been available since Kubernetes 1.6. The RBAC plays an important role in managing Kubernetes resources by controlling the authorization feature. One of the biggest benefits of this feature is the ability to adjust permissions without having to restart the whole cluster. After you enable it, you’ll be able to give the necessary permissions to the system’s components. Users can only allow full access to components when it is completely necessary for a specific situation.

Restrict Access to the etcd

The etcd is the brain of the cluster because it keeps a record of everything happening in the cluster. If a hacker gained access to it, they would be able to view all the cluster operation details. It is very important to keep it safe and limit access to only the authorized people with the right credentials. It should be protected to keep the sensitive cluster information a secret.

There are two ways to protect the etcd:

• Set up a firewall between its cluster and the API by running it on a separate node. To configure the firewall use Calico, a firewall manager that allows one to create a zone-based architecture for the Kubernetes cluster.
• Encryption is another protective step that locks out unauthorized manipulation of the etcd. It is not activated by default so you’ll have to activate it via the Kube apiserver process.

Add SSH Access Restrictions

Being one of the most used services to access the system remotely, it is an attractive point of entry for hackers. This is why restricting access to it is very important if you want to keep the cluster secure. SSH’s two user restriction attributes, allow and deny, are enough to manage its security needs. One of the ways to secure it is by denying access to port 22 on the nodes and only allowing access to it when debugging. Even when you allow it, only given access via the organization’s VPN or bastion host. These security settings can be configured through your cloud provider.

Isolate the Kubernetes Nodes

You should place the nodes are on a separate network that is not exposed to the public network directly. This adds an extra layer of security where traffic to and from the node can be controlled. Also, avoid exposing the nodes to the corporate network so as not to mess with the security mesh’s integrity. To achieve this, you have to ensure that traffic and Kubernetes control are both isolated. Failure to isolate them will lead to both flowing on the same pipe, thereby opening access to the data plane. It is recommended that you perform the configurations using the ingress controller to comprehensively implement the isolation. With an ingress controller, you limit the master node connection to only the network access control list specified port.

Don’t run containers as the root user

Running containers in the pods as a root user is a common mistake that can lead to an involuntary configuration change. In Kubernetes, the user id is mapped onto the host of the container, meaning that the user also appears as a root on the nodes that it runs on. Although there is a Kubernetes mechanism that stops the change in privileges using this strategy, the security vulnerability that can be exploited by an experienced hacker still exist. The way to prevent running container as root is to create a user with a known id by modifying inbuilt containers’ Dockerfile.

Use minimal distroless base images

One of the most used images to run apps in Docker containers is Ubuntu, while the size of the image is not ideal to run it in a Kubernetes cluster, the image contains the OS package manager (APT) and gives users access to shell. The problem is that both features (package manager and shell) present security risks and may contain vulnerabilities.

If installing packages is necessary, the best practice in this case is removing the package manager after using it.

According to an OWASP guide: “Restricting what’s in your runtime container to precisely what’s necessary for your app is a best practice employed by Google and other tech giants that have used containers in production for many years. It improves the signal to noise of scanners (e.g. CVE) and reduces the burden of establishing provenance to just what you need.”

Install the Latest Version of Kubernetes

Ensure that you are always running the latest Kubernetes version available. This will ensure that you always have the latest security solutions available. The Kubernetes community is always creating new patches to increase the system’s security and these updates are regularly published.

Use Namespaces to Increase Control Over the Cluster

Namespaces help in organizing a cluster into virtual sub-clusters and this gives you more control of the cluster. This is very important when the cluster is acting as a multi-tenant environment.

Namespaces can add restrictions in two ways:

• You can restrict the scope of resources that are available to a user. For instance, a user can be limited to only use development resources within a cluster.
• It can also be used to limit the amount of memory and CPU allocated.

Activate Audit Logging

The audit log keeps a record of all suspicious API calls and automatically flags them. For instance, an authentication failure is flagged because it could be a sign that an attacker is trying to gain access to the cluster using stolen credentials. Over time you can be able to view the cluster’s health and stability based on the number of suspicious calls revoked.

There are four logging options that are available:

• None: this keeps no logs
• Metadata only: this will only keep a log of the metadata
• Request: this will log requests and metadata.
• RequestResponse: this logs requests, metadata, and responses.

Secure the Kubelet

If an attacker gains access to a Kubelet, they can compromise the entire cluster. Here are some of the configuration options that can be utilized in securing the Kubelet from attacks:

• Activate authorization mode: change the –authorization from AlwaysAllow to ensure that a level of authorization is required for all requests made.
• Include node restriction: adjust API server –admission-control setting to restrict Kubelet access using the NodeRestriction.
• Disable anonymous access: change the settings to –anonymous-auth=false so that unauthorized requests aren’t responded to.
• Close read-only ports: set –read-only-port=0 to close the read-only ports and prevent anonymous users from viewing the clusters’ activities.

Store the Sensitive Details Secret and Not Configmap

Avoid storing the application’s sensitive details in the configmap and instead store them in secret. The difference between the two is that while Secret stores its data in base64 format, configmap stores in plain text. Encrypting details such as username, database name and passwords adds another layer of security to containerized applications.

Aknowledge the OWASP best practices

OWASP also provides a framework that can be used to evaluate applications’ security. This comes in handy when a company wants to conduct an audit of its applications. You can use OWASP’s top 10 security risks to decide the risks that will require a higher priority.

1. Injection
2. Broken authentication
3. Sensitive data exposure
4. XML external entities
5. Broken access control
6. Security misconfiguration
7. Cross-site scripting
8. Insecure deserialization
9. Using components with known vulnerabilities
10. Insufficient logging and monitoring

The OWASP foundation maintains the The OWASP Cheat Sheet Series repose which was created to provide a concise collection of high value information on specific application security topics. This cheat sheet includes a Kubernetes related part and contains almost everything you need to know in order to secure your Kubernetes clusters and Docker containers.

Use a CI/CD solution that keeps your application safe

WildCard CI/CD solution takes a security-first approach in handling development, delivery, and deployment. Try it here for free!

Wildcard is a NoCode platform that provides a solution to help organizations, and developers, even those without DevOps experience or coding knowledge, to successfully implement and manage versioned infrastructure using NoCode CI/CD pipelines. It enables collaboration, auditing, and automation. You can use Wildcard to build, deploy, and manage applications without writing a single line of code. Start for free by singing using Github or GitLab.