Four must-haves in Kubernetes security best practices
When it comes to Kubernetes security, IT teams must look beyond their containerized workloads, and consider code and cloud infrastructure as well.
Emerging infrastructure technology always heightens IT security concerns -- after all, new software and operating models invariably introduce new sources of vulnerabilities.
The excitement around containers in Kubernetes-managed clusters has made container and cluster security a hot topic industry-wide. Organizations that have adapted tools, processes and policies to VMs are concerned about how Kubernetes -- with a collection of new service options to configure -- might jeopardize their security posture.
Fortunately for organizations that are new to Kubernetes, the basics of good security best practices don't change. The challenge is how to apply those security fundamentals to a new environment. Strong Kubernetes security starts with the timeless strategy of defense in depth. Ensure multiple defensive layers that cover different areas of the Kubernetes software and infrastructure environment, including:
- cloud and data center infrastructure, and the virtual resources that create Kubernetes environments;
- container clusters, including the component configuration of the environment and the workloads that run on a cluster;
- individual containers -- namely, the software images used to instantiate workloads; and
- source code that comprises container images.
Kubernetes documentation calls these The 4Cs of cloud-native security -- cloud, cluster, container and code -- and outlines different control points for each.
While not all four of these components are tied directly to Kubernetes itself, let's take a closer look.
Cloud infrastructure
Kubernetes clusters exist within a virtual infrastructure environment, such as the cloud, whether they are self-managed on premises or rented from an infrastructure-as-a-service (IaaS) provider. In the context of Kubernetes, cloud security translates to policies and configurations that protect the compute instances and virtual networks used to operate clusters. The implementation details vary by cloud software -- such as VMware, Microsoft and Red Hat -- or IaaS provider -- like AWS, Azure or Google Cloud. However, there are several areas of specific focus for Kubernetes security.
Establish network access controls to the infrastructure, including separate policies for each component. For instance, limit access to Kubernetes master nodes to a select set of whitelisted devices and IP addresses, and prohibit access from public internet connections. Cluster nodes should only accept administrative connections from the masters on particular ports; limit other connections to externally facing devices, such as load balancers.
In addition, limit access to the etcd Kubernetes distributed data store to the master nodes over a TLS encrypted connection. Encrypt the data of etcd, since it contains cluster state information, including secrets such as passwords and security tokens or keys.
Admins must also configure user access to the master and worker nodes, the details of which vary by cloud provider. It's best to follow the principle of least privilege for user roles and permissions.
Kubernetes clusters
Kubernetes cluster security is chiefly a matter of protection from unauthorized access, whether accidental or malicious, and maintaining policies that prevent critical workloads on the cluster from resource depletion, whether the cause is a noisy neighbor or DDoS attack. The cloud infrastructure implements most factors to achieve cluster security, which are outside the realm of Kubernetes. However, there are certain controls admins can put in place.
For example, define role-based access controls to the Kubernetes API, which specifies four access categories. Use an authentication system, such as Active Directory or AWS identity and access management, to associate RBACs with particular users and groups. Note that Kubernetes supports various authorization modes besides RBAC, as well.
Encrypt application secrets stored in etcd. Kubernetes documentation provides implementation steps, but the details of encryption key management and use vary by implementation.
Configure pod security policies for access, workload execution and quality of service, along with any other controls necessary for your organization's ecosystem. Again, follow the principle of least privilege and limit or deny access by default to uphold Kubernetes security best practices. Use Kubernetes namespaces to create administrative security boundaries around resources that are divided into logically similar security groups.
Apply restrictive network security to pods to create and enforce isolation and provide a control point to manage access between them. Separate workloads on pods by their data sensitivity and enterprise criticality.
The future of Kubernetes security
Despite some established Kubernetes security best practices, there's a lot of room for progress and growth in this space. Moving forward, enterprises will likely look for ways to drive better security policy integration between Kubernetes and other IT systems; more robust Kubernetes networking security; and streamlined security for multi-tenant environments.
That said, the Kubernetes security tool market continues to rapidly expand and offer new capabilities to IT teams.
Containers
Container security -- which aims to protect and verify the workloads that run in containers -- is independent of Kubernetes and applies to any container management system, whether Docker Swarm or Amazon Elastic Container Service.
To secure containers, scan container images for security vulnerabilities; enforce the use of signed images that are traceable to a trusted source via the Kubernetes Admission Controller and a tool such as IBM Portieris; minimize administrative permissions for containers; and deny privileged user access to the container environment.
Code
Nothing provides more security control over a container than the code that comprises it. While security guidelines apply to code regardless of the environment, some are worth highlighting for Kubernetes applications.
Use TLS to encrypt data in transit to secure transmission control protocol (TCP) network communications. Minimize the number of open TCP ports to only those used for communications or monitoring. When using any third-party code and libraries, scan them for vulnerabilities. And for internet-facing applications, use a penetration testing tool to check for common vulnerabilities, such as SQL injection attacks or cross-site scripting.
General Kubernetes security guidance
Like other infrastructure software, there are a few basic rules that can prevent problems and make those that emerge easier to diagnose. For example, always run the latest stable Kubernetes release that is compatible with your applications. Managed cloud services often automatically update the platform unless configured otherwise, but usually provide a mechanism to roll back to a previous release should problems arise. And log at both the application container and Kubernetes cluster level. Integrate logs with a central security information and event management or monitoring system.
