In our series on container security fundamentals, we covered how containers work and shared strategies for securing and troubleshooting containerized environments. As a follow-up to that series, we wanted to explore the world of Kubernetes security. Most organizations that use containers to run their applications will orchestrate those containers using Kubernetes—but Kubernetes security can be quite complex, with so many different configuration options and tools to consider. In this series, we'll walk through the fundamental areas that companies should think about when it comes to Kubernetes security.
Complications of talking about Kubernetes security
One challenge of talking about Kubernetes security is actually defining the scope of what you're discussing. The open source Kubernetes project has taken the deliberate policy of not including security solutions for cluster operations. Instead, it allows for integrations with third-party systems.
From a security perspective, this means that you need to use these integrations to handle key functions in the cluster, such as runtime security, vulnerability management, and log analysis. But it also means that you are required to implement third-party systems for core tasks, like user authentication and management. Kubernetes does not include a user database, and its built-in authentication methods are not suitable for production use, so users need to implement external software to handle that aspect of cluster operations.
Additionally, other security-adjacent areas of cluster operations, such as networking, storage, and container runtimes, are also delegated to third-party projects. In these cases, Kubernetes provides interface specifications (Container Network Interface, Container Storage Interface, and Container Runtime Interface respectively), and external software providers create systems that implement those specifications.
This means that when we're talking about Kubernetes security, we're not only considering Kubernetes itself, but also all of the supporting software used by a cluster.
Managed and unmanaged Kubernetes distributions
When it comes to Kubernetes security, another key consideration is the type of distribution you're using. Typically, most organizations will choose to use a certified Kubernetes distribution. At the time of writing, there are 126 options that span across platforms, installers, and hosted services.
One of the main points of difference between these options is whether they are considered managed or unmanaged. In a managed Kubernetes service, the provider controls the Kubernetes control plane components and ensures that they operate effectively. Meanwhile, the cluster owner takes care of the worker nodes and workloads deployed to the cluster. (Note: Some services, such as EKS Fargate and GKE Autopilot, do not even require the cluster operator to directly manage any nodes.)
Unmanaged distributions, on the other hand, leave the cluster operator to manage all the elements of the cluster. This increases the overhead of running the cluster, but it also provides better opportunities for customizing its configuration. This means that while unmanaged distributions require the cluster operator to put in more effort to harden their environment, they also enable organizations to potentially achieve higher levels of security.
Along those lines, in this series of blog posts, we will not only explain how various aspects of Kubernetes security are handled in vanilla Kubernetes, but also how they are implemented in three major managed distributions: Amazon Elastic Kubernetes Service (EKS), Microsoft Azure Kubernetes Service (AKS), and Google Kubernetes Engine (GKE).
Areas of discussion
Kubernetes security fundamentals is an expansive topic, but the goal of this series is to provide a solid foundation for cluster operators by exploring the following topics:
- Kubernetes component API security: Kubernetes is made up of a series of APIs. Understanding how those APIs are used and secured is an important part of Kubernetes security.
- Authentication: Looking at both user and workload authentication to the main Kubernetes API and other APIs that are part of a Kubernetes environment.
- Authorization: Understanding the options available for ensuring that only certain users should have access to specific API paths, and exploring some of the risks of privilege escalation that can occur in Kubernetes clusters.
- Admission Control: Admission control is a vital part of securing a Kubernetes cluster in production, but it can also introduce its own risks if it is not implemented correctly.
- Network security: Controlling access to and from the container network to reduce the risk of unauthorized access to applications and external services.
- Public key infrastructure (PKI): Understanding the various ways that TLS certificate and certificate authorities are used in Kubernetes—and how they should be secured.
- Secrets management: Correctly managing secrets is important for ensuring their security.
- Container image security: Hardening and patching the container images that are deployed to the cluster.
- Runtime security: Assuring the security of workloads at runtime and detecting possible attacks.
- Monitoring, logging, and auditing: Ensuring that appropriate metrics and logs are available can help you detect attacks on the cluster and its workloads.
Conclusion
Kubernetes security is a complex area to cover, with lots of variation between different distributions and configurations. Because Kubernetes does not provide built-in security solutions, operators need to implement third-party software to handle user authentication, runtime security, and other important tasks. Throughout this series, we aim to cover these fundamental challenges in detail and explain how you can address them to improve the security of your Kubernetes-based environments.
