One of the biggest risks with containers and Kubernetes is that both technologies’ default configurations are not secure. Reducing risk of a security incident requires proactively changing those default configurations consistently across the entire organization. Neglecting this step, through oversight, lack of knowledge, or workflows that don’t incorporate a configuration management step, will lead to workloads that are unnecessarily vulnerable.
Default settings in containers
Many default container settings, as well as common practices when building containers, can leave the containers vulnerable. Here are some things to look out for when configuring containers.
Specify a user. If a user is not specified, it will default to the root user, potentially giving the container root access to the host.
Verify images. Default settings do not enforce image verification, leading to the potential to pull compromised images unknowingly.
Set resource limits. Resource limits can be configured, but there are no default limits. Limiting the CPU and memory a container can consume helps prevent the container from consuming large amounts of resources if it becomes compromised.
Install tools and libraries selectively. The fewer tools and libraries are in the containers, the fewer tools a malicious actor has to exploit if they get access to the container. Make sure you don’t just install a standard set of tools in every container, but rather install only what’s actually needed.
Control access to the registry by whitelisting. In addition to making sure any images you use are from trusted sources, access to the registry has to be tightly controlled, ideally through whitelisting only trusted users.
Default settings in Kubernetes
Kubernetes also provides many tools for improving the organization’s security posture, but they have to be actively configured to provide security benefits. Here are some core things to check in Kubernetes.
Configure Role-Based Access Controls (RBAC). RBAC is enabled by default in Kubernetes 1.6 and later, but still needs to be configured correctly to provide benefits. Ideally, access should be provided by namespace, not clusters.
Use namespaces. The ‘default’ is to run everything in the same namespace. Actively use the separation provided by namespaces to isolate workloads from each other.
Use Kubernetes Network Policies. There are no network policies configured out-of-the-box, so organizations need to install a network plugin to control ingress and egress traffic from the application and configure policies accordingly.
Enable Audit Logging. Audit logging is not usually enabled by default, but should be turned on to get visibility into anomalous API calls and authorization failures.
Last updated: May-30-2020
- The risk of doing nothing
- 9 Kubernetes settings that maximize security
- 12 Kuberntes configuration best practices