Basic tips to secure Kubernetes workloads
Containers and container orchestration allow organizations to deliver software more quickly and efficiently. They are getting popular between organizations that want to pursue continuous integration and continuous delivery (CI/CD) as part of the modern DevOps culture.
Kubernetes is a portable, extensible, open-source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation. It has a large, rapidly growing ecosystem. Kubernetes services, support, and tools are widely available. [1]
This article aims to introduce some basic security practices that are applicable in a scenario where your container orchestration platform is Kubernetes.
Enforcing Network Policies
By default, a Kubernetes cluster won’t impose any traffic restriction between your pods. To achieve that, you need to create NetworkPolicy resources that suit the needs of your workloads. They allow you to control both ingress (inbound) and egress (outbound) traffic.
A network policy is a specification of how groups of pods are allowed to communicate with each other and other network endpoints. [2]
NetworkPolicy resources require you to have a network plugin setup that supports such resources like Calico or WeaveNet. Ensure that your cluster has a networking solution that provides support; otherwise, your NetworkPolicy resources won’t have any effect [2]. Check your cluster setup and evaluate which network plugin suits your needs. If you are using a managed solution from your cloud provider, it may already have a network plugin solution available for you. For instance, on AWS EKS, it is possible to apply Calico reasonably quick.
If you are looking forward to learning more about network policies, there is a GitHub repository where you will find some helpful examples of network policies for some of the most common use case scenarios out there.
Repository: ahmetb/kubernetes-network-policy-recipes
Image Scanning of your containers
Keeping your containers updated in terms of package versions may be hard to track, particularly when the complexity of workloads and the number of microservices increases in your architecture. Leaving containers using components that may have Common Vulnerabilities and Exposures (CVEs) can open your product to security issues. Image Scanning is an automated process that allows you to identify potential vulnerabilities. If you are using AWS ECR as your image repository, this feature just got released, leveraging an API to integrate with your CI/CD process[3].
Use Security Context for more granular control
Pods or containers should have a well-defined security context that fits the use case. Ensure that your containers don’t run in privileged mode to avoid them to have access to the host network stack and kernel. By default, a Linux container entrypoint is run as root user (uid 0), so setting a more restrictive user/group with runAsUser and runAsGroup properties might be worth considering as a hardening measure, which discards the risk of an image failing to switch to a more restrictive user. If you are above Kubernetes 1.16, you can use Pod Security Policies to enforce better security policies. Also, for 1.16 clusters, your Windows containers can use runAsUserName property to run as a specific user.
Enforce resource usage limits for workloads
Understanding how workloads behave in terms of resource usage is essential in scaling a cluster. In Kubernetes, compute resources such as CPU and memory are considered resource types. By default, there are no limits in place, so ensure that containers have assigned CPU resources and memory resources, to avoid situations where a container can exhaust the host node.
Resource Quotas allows implementing resource hard limits in a more broad-spectrum, more specifically at the namespace level. They are useful in use cases where multiple teams are working in the same cluster, imposing hard caps. Limit Ranges are helpful as a complement to resource quotas.
Keeping track of the best practices
As part of the official Kubernetes documentation, there is a section named “Securing a cluster”, that provides some insights and hints on how you can improve the overall security of your cluster. Ensure that you join the kubernetes-announce group to get emails with all news first hand.
