In recent years, Kubernetes (K8s) has become increasingly popular with many organizations and it’s the default way for them to orchestrate and scale their container-based workloads. Because of this, many cloud providers now provide dedicated Kubernetes services like Azure Kubernetes Service and Google Kubernetes Engine.
However, as is the case with many other new technologies, the question is often how organizations should secure their Kubernetes deployments. And this is a crucial question, simply because the popularity in its use has also led to the rise in cybercriminal interest in Kubernetes clusters.
In other words, as organizations deploy more applications with Kubernetes, how should they avoid becoming part of the data breach statistics. This post will look at this question in more detail and give an overview of Kubernetes security.
Why Is Kubernetes Security Important?
Before looking at this overview, it’s essential to understand why Kubernetes security is important.
At its core, the importance for Kubernetes security lies in the distributed, dynamic nature of a Kubernetes cluster. As a result of this, a Kubernetes cluster requires different security approaches for each phase of the application lifecycle: build, deploy, and runtime.
To facilitate this, Kubernetes offers developers several security advantages compared to traditional deployments. For example, containers are typically not patched or updated like other applications but are instead replaced entirely with new versions. This, ultimately, makes the application contain more secure.
However, in certain instances, Kubernetes presents IT security professionals with unique challenges. With this in mind, let’s look at an overview of Kubernetes security.
Kubernetes Security
Kubernetes security is based on the 4 C’s of cloud-native security. In other words, we can think of Kubernetes security in layers. These four layers are Cloud, Clusters, Containers, and Code, therefore the 4 C’s.
Each layer in this model builds on the next layer. So, for example, cloud security forms the base layer. Cluster security builds on that, followed by container security. Finally, code security forms the final piece of the puzzle. As a result, each layer in the model builds its security on a solid base.
For example, the code layer benefits from strong security in the cloud, cluster, and container layers. This, however, also means that it is not possible to implement proper security by addressing security only at the code level.
Considering this model, let’s look at the separate layers in more detail.
Cloud
The underlying physical infrastructure on which clusters are deployed lays the foundation of Kubernetes security. Irrespective of whether the cluster is deployed in an organization’s own datacenter or with a cloud provider, basic cloud provider best practices should be followed to ensure the best security.
So, organizations should consult their datacenter’s documentation or the documentation of the cloud provider to make sure that they follow the necessary security best practices.
Some of these best practices include:
· Network access to API server (Control plane). All access to the Kubernetes control plane should be controlled by network access control lists which are restricted to the set of IP addresses needed to administer the cluster.
· Network access to nodes. Nodes should be configured from the control plane on certain specified ports. Ideally, these nodes should not be exposed to the public Internet entirely.
· Kubernetes access to the cloud provider API. Every cloud provider should grant a different set of permissions to the Kubernetes control plane and nodes.
· Access to etcd. Access to the data store of Kubernetes should be limited to the control plane only. Also, ideally, etcd should be used over TLS.
· etcd Encryption. If at all possible, all drives should be encrypted at rest, especially etcd because it holds the state of the entire cluster.
Clusters
Securing a Kubernetes cluster is done by securing both the configurable components like the Kubernetes API and the security of all the applications that are part of the cluster. This is simply because most cloud-native applications are designed around microservices and APIs. As a result, applications are only as secure as the weakest link in the chain of services that make up the entire application.
Some specific areas that need to be looked at to secure workloads running in Kubernetes are:
· RBAC Authorization. These should be properly configured to limit access to the Kubernetes API.
· Authentication. Authentication should be properly implemented to control access to the Kubernetes API.
· Application secrets management. Secrets are useful to store and manage sensitive information, but by default, they are stored as unencrypted statements. For proper security, these should be encrypted.
· Pod Security Policies (PSP). Kubernetes PSP enables the fine-grained authorization of port creation and updates, and it controls the sensitive security aspects of the product specification.
· Quality of Service. QoS classes should be properly set up and configured.
· Network Policies. Kubernetes NetworkPolicies effectively controls the traffic flow at the IP address or port level of the cluster. They should therefore be properly configured for effective security.
· TLS For Kubernetes Ingress. Organizations can secure an Ingress by specifying a secret that contains both the TLS private key and certificate.
Containers
Best practices of container design consist of starting with the smallest codebase possible, avoiding granting unnecessary privileges to users in that container, and making sure that containers are scanned for vulnerabilities at build time.
Some general recommendations to facilitate proper security at the container layer include:
· Container Vulnerability Scanning and OS Dependency Security. As part of the build step, containers should be scanned for known vulnerabilities.
· Image Signing and Enforcement. Container images should be signed to maintain a system of trust for the content of containers. Untested code can or grant access to the content to bad actors.
· Disallow privileged users. When constructing containers, it’s essential to create users inside the containment that require the least level of operating system privilege to carry out the goal of the container.
· Use container runtime with stronger isolation. Container runtime classes can be used to provide stronger isolation at run time.
Code
Application code is one of the main attack surfaces in a Kubernetes environment. It’s also one of the places where organizations have the most control over security.
Some general recommendations to protect application code include:
· Access over TLS only. When code needs to communicate by TCP, it’s advisable to perform a TLS handshake and head of the time. Also, it’s crucial to include network traffic between services.
· Limiting the port ranges of communication. Wherever possible, only ports on the service that are strictly necessary for communication or metric gathering should be exposed.
· Third-Party Dependency Security. It’s essential to regularly scan an application’s third-party libraries for any security vulnerabilities. Most programming languages have a tool to do this check automatically.
· Static Code Analysis. Most programming languages provide the tools necessary to analyze a snippet of code for any unsafe coding practices. Where possible, these checks should be done using automated tooling that can scan codebases for common security errors.
· Dynamic Probing Attacks. There are a few tools available that can be used against a service to attempt some of the well-known service attacks.
A Kubernetes Security Checklist
With the above in mind, organizations can develop a Kubernetes security checklist that can be followed to ensure that all the best practices of Kubernetes security are adhered to.
At a high level, this checklist can include recommendations like:
· Beginning with a minimal, distro-less image and adding only what is absolutely necessary.
· Using a minimal host operating system, read-only amounts, and using SELinux for more control.
· Scaling images for vulnerabilities.
· Using namespaces and RBAC to segment the cluster and users logically.
· Implementing network segmentation before production to control access.
· Keeping privileges to a minimum and never running applications as root.
· Integrating security such as image scanning into the CI/CD pipeline. For more security, organizations should consider running CIS Kubernetes Benchmark tests.
· Securing the cluster itself by configuring RBAC to limit access to the Kubernetes API and ensuring all etcd communications are secured with TLS encryption.
· Taking advantage of built-in controls in Kubernetes, like configuring security context to limit pod access.
· Monitoring process activity, communications between services, and communications externally to the cluster.
Keep in mind, though, that these are just some recommendations. For more complete guidelines and best practices, the CIS Benchmarks Kubernetes best practices can be a base to work from. These are a set of recommendations for configuring Kubernetes to support strong security.
It’s important to remember that, although these benchmarks are universally applicable across distributions, they are tied to a specific Kubernetes release. As a result, the specific benchmarks for the specific Kubernetes release should be used.
The Bottom Line
Considering that Kubernetes automates and simplifies the process of application deployment, scaling, and management, it’s easy to see why many developers are turning to it to release their applications. In simple terms, many organizations are using it to release applications faster and more efficiently. Ultimately, this is a requirement in a competitive market where success is often measured by how quickly developers can release products.
Unfortunately, the popularity of Kubernetes has also made it a target for cybercriminals who are increasing their interest in clusters. As a result, organizations have to ensure that they implement the necessary Kubernetes security best practices to secure their deployments.
Hopefully, this post was helpful in illustrating some of these best practices.
For more information on Kubernetes and security, visit our website or contact us for more details.