As more and more organizations move away from traditional virtual machines for developing applications, containerization has become the new norm. Containers offer a more modern approach as they are generally more lightweight and fast, are OS and infrastructure agnostic and can handle larger-scale applications. That scale, however, can be challenging to manage. That’s where Kubernetes comes in.
Kubernetes has quickly risen in popularity as one of the most popular cloud technologies for many good reasons—scalability, stability, cost (in some cases) and when done right, security. Unfortunately, those benefits come with a tradeoff, adding another layer to an already complex construct.
One of the big challenges with containerization over VMs is security because they are harder to isolate. Although Kubernetes ventures to solve that with its native security features, it can also add complexity and, thus, more attack surface. In this post, we’ll go through some of the security features Kubernetes offers and its unique advantages in terms of DevSecOps through the use of infrastructure as code (IaC) for cluster management.
Cloud infrastructure has come a long way despite, or perhaps because of, the security concerns that it faces. Kubernetes includes built-in security features that, on their own, may not be sufficient to keep your entire infrastructure secure but provide a great starting point for protecting Kubernetes environments. They approach securing dynamic, complex and multi-layered Kubernetes systems by identifying Kubernetes-specific threats and providing rich context and insights. The following are some of the Kubernetes-specific security features:
RBAC (role-based access control) is a Kubernetes feature that allows you to limit access to services based on roles and identities. RBAC improves the security of a Kubernetes cluster by limiting who has access to what. It accomplishes this by controlling resource access to users and applications through authorization, such as granting access to a user, adding or revoking rights and establishing rules. To learn more on RBAC, check the official Kubernetes documentation.
PodSecurityPolicies let you control pod and container behavior, including preventing them from executing in privileged mode or requiring them to adopt a read-only file system.
The PodSecurityPolicy specifies a set of requirements that Pods must follow in order to be accepted by the cluster; if a request to create or update a Pod fails to match the PodSecurityPolicy’s requirements, the request is rejected, and an error is returned.
To utilize PodSecurityPolicy, you must first build and describe the policies that new and updated Pods must meet.
Kubernetes revealed that in 2021, the Pod Security Policy (PSP) would be deprecated, but will follow the Kubernetes deprecation policy starting from 1.21 to 1.25. The Kubernetes community identified several limitations as causes for PSP’s deprecation, including conflicts in the authorization paradigm, complexity in the API and function scope and deployment flow problems. Better solutions are emerging, such as the Kubernetes Pod Security Standards and other third-party IaC security options, such as Open Policy Agent(OPA) and Prisma Cloud.
Through the use of rules, Kubernetes network policy allows administrators and developers to control which network traffic is allowed. Kubernetes NetworkPolicies enables you to regulate traffic flow for specific applications in your cluster at the IP address and port level. They do it by defining how a pod can communicate with different network elements (endpoints and services) over the network. These are applied to a connection with the relevant pod on one or both ends. When a cluster is hosting a multi-level application, defining network policy allows you to implement in-depth security protocols.
Admission controllers in Kubernetes are plugins that govern and control the rules for the persistence of Kubernetes objects. They serve as gatekeepers, intercepting (authenticated) API requests and determining if they violate a predefined policy before rejecting or modifying them to meet policy. Admission controllers are used to provide several basic Kubernetes best practices, such as limits and requests, and ensure pods are not overly privileged. Admission controllers are thus another feature that avoids illegal activities in a Kubernetes environment. Still, they, like network and namespace segmentation, are only useful if they are configured and enforced correctly.
An Ingress is a Kubernetes object that grants access to your Kubernetes services from outside the cluster. You configure access by defining which inbound connections reach which services using a set of rules. This allows you to combine all of your routing rules into a single resource. A secret that includes a TLS (Transport Layer Security) private key and certificate can be used to secure a Kubernetes application. Only one TLS port, 443, is supported by Ingress, which assumes TLS termination. The TLS secret must have the keys named tls. crt and tls. keys, which contain the TLS certificate and private key, respectively.
Considering that Kubernetes is intended to serve as an orchestrator rather than a full-fledged security solution, it comes with built-in capabilities to create some guardrails for limiting access and control pod and container behavior. That said, most of the security issues in a Kubernetes environment, such as vulnerable container images and misconfigurations, require additional security controls.
Kubernetes enables the deployment of scalable, modular and fault-tolerant modern container applications. With Kubernetes, you declare the state that you want your environment to be in, and it works continually to keep it there, freeing engineers from manual infrastructure management responsibilities. That said, the manual provisioning of a Kubernetes cluster and its addons can be time-consuming, which is where infrastructure as code (IaC) comes in. IaC utilizes code to manage infrastructure resources such as data servers, storage and networks rather than manually managing them. In addition, IaC building blocks such as Kubernetes manifests, Helm charts and Kustomize files are machine-readable, allowing for version control and auditability as well as easier collaboration and security testing.
Enabling the embedding of Kubernetes security guardrails and testing throughout the software development lifecycle, known broadly as DevSecOps, is necessary for securing containerized, cloud-native apps. DevSecOps strives to integrate security into DevOps operations in the same way that development, testing and deployment are all automated through CI/CD pipelines, allowing for:
Infrastructure hardening with code security is an excellent solution for modern DevOps teams that want to distribute security responsibility across existing frameworks within CI/CD pipelines while delegating security ownership to individual contributors.
Kubernetes is the de facto container management platform. However, due to the complexities of deploying, managing and growing containers, Kubernetes security can easily become a liability. Therefore, despite its built-in security controls, it’s crucial to implement and follow additional Kubernetes security best practices.
As we noted above, adopting Kubernetes and prioritizing IaC provides numerous infrastructure security advantages. DevOps teams must integrate security into their workflows and use DevSecOps to shift security left while ensuring that their culture and processes become more flexible and automated. When DevSecOps is done well, each team will be able to explain its ability to help the firm fully leverage the power of cloud-native models in general and containers in particular.
Dive deeper into security best practices for cloud-native applications with our Complete Guide to Kubernetes Security.
By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement. Please look for a confirmation email from us. If you don't receive it in the next 10 minutes, please check your spam folder.