Request a Demo
Join a 30 minute demo with a Cloudian expert.
Kubernetes is the de facto standard in container orchestration, and is used by organizations large and small to manage container workloads. However, while Kubernetes is extremely powerful, it also raises new security concerns that traditional approaches and tools cannot solve.
According to a 2020 StackRox survey, 86% of organizations running containers manage them with Kubernetes, but over 50% feel they do not invest enough in container security, and are concerned about security affecting their production schedule or resulting in damaging security breaches.
Kubernetes workloads are vulnerable to several types of security threats, including:
Read on to better understand these threats and learn key considerations on how to secure your Kubernetes clusters.
This is part of our series of articles on Kubernetes storage.
In this article, you will learn:
Here are a few key concepts you need to know as you plan your Kubernetes security strategy.
In the official Kubernetes documentation, the makers of the platform suggest an approach called 4C for cloud-native security:
At each level, security best practices should be followed. There may be different security considerations at different levels. For example:
These are just examples of security concerns that may exist at each level of the 4C model
There are three default security policies for Kubernetes pods. To properly protect your environment, you need to understand the tradeoff between availability and security.
The pod security context configures security settings at runtime. This includes aspects such as access control, whether to run in privileged mode or not, and mounting read-only file systems.
The difference between security policies and the security context is that policies define security parameters, and the context is what executes policies at runtime.
You should never put an authentication token or password in a YAML configuration file. Kubernetes provides a mechanism called secrets, for storing this type of sensitive information.
Keep in mind that Kubernetes secrets are not secured by default—you can and should enable encryption for secrets, and set RBAC rules defining who can read or write the secret.
Here are a few considerations for building a secure Kubernetes environment.
The Kubernetes platform is extremely rich in features, some activated by default and some not. You could use security benchmarks, such as those published by the Center for Internet Security (CIS) however, these checklists, while extensive, do not take into account the performance impact of some settings, or the relative importance of different security controls.
Hardening Kubernetes is an exacting process. Clusters must be configured to ensure API server access over HTTPS, the use of X.509 certificates for communication and authentication, etcd datastore encryption, and more. Every configuration change should be tested to determine its production impact.
Security automation from day one almost always reaps dividends. CI/CD pipelines should employ automated unit and functional tests, and should integrate vulnerability scanners and other automated security gates. To facilitate this, DevOps teams should enable AppDev teams to uniformly integrate monitoring, alerting, and logging services, while deploying microservice-based applications.
In addition, while adding a service mesh to a Kubernetes cluster may seem complex, it actually improves the visibility of a product’s business logic. Previously, developers needed to build the logic into their code. Now, these capabilities can be made available as part of the Kubernetes platform, paring down development activities and accelerating the delivery of microservices.
Helm Charts is an open-source tool used to automate the provisioning and configuration of Kubernetes applications. They are primarily useful for Day 1 operations. For Day 2 operations, Kubernetes Operators are the preferred option.
Operators assist in packaging, deploying, and managing complex Kubernetes applications, by encoding practical human expertise into dynamic software instructions. This lets application developers deliver Kubernetes-run services with automated lifecycle management. If required, a Kubernetes operator can contain a Helm Chart for synchronic deployment.
Operators also help maintain supported configurations for Kubernetes services, improving security by resetting an unsupported service configuration to its initial, declared configuration.
Here are some practices that improve the security of Kubernetes clusters.
Kubernetes nodes must be on a separate network and should not be exposed directly to public networks. Preferably, they should not be exposed to the broader corporate network either.
To achieve this isolation, you must separate Kubernetes control and data traffic. Otherwise, both types of data flow through the same pipe, and open access to the data plane implies open access to the control plane. Ideally, nodes should be configured to only allow connections from the master node on the specified port, managed through the network access control list (ACL).
Related content: read our guide to Kubernetes multi tenancy
Whitelisting starts by observing an application’s normal course of behavior, and drawing up a list of known good processes. This becomes a whitelist that defines which processes are allowed to run, excluding other, unexpected processes. This is challenging to do at large scale; commercial container security products can help operationalize runtime process analysis.
When replicating containerized applications—whether to increase availability, fault tolerance, or scaling—replicas should behave identically. Any significant deviation warrants examination.
When integrating Kubernetes security tools with security systems, such as Security Information and Event Management (SIEM), or collaboration tools like Slack, use deployment labels or annotations to alert the relevant teams to potential threats.
Role-Based Access Control (RBAC) regulates access and permissions to the Kubernetes API. It is enabled by default in Kubernetes as of version 1.6. Configuration settings, however, should be checked after upgrading. Legacy Attribute-Based Access Control (ABAC) should be disabled when enabling RBAC.
After enforcing RBAC, namespace-specific permissions should be favored over cluster-wide permissions. Cluster-admin privileges should only be granted on a case-by-case basis, even while debugging.
Zero trust is a new security model, which assumes there is no security perimeter—all entities both inside and outside the corporate network are considered hostile. And any user or device must be securely authenticated, authorized, and monitored.
By default, all Pods in a Kubernetes cluster can communicate with each other. Taking a zero trust approach is important to preventing a range of attacks on Kubernetes infrastructure. To ensure the security of your cluster, set network policies to prevent containers from communicating with each other, unless explicitly allowed.
Kubernetes security tools commonly used include:
Containerized applications require storage that’s agile and scalable. The Cloudian Kubernetes S3 Operator lets you access exabyte-scalable Cloudian storage from your Kubernetes-based applications. Built on the S3 API, Cloudian lets you dynamically or statically provision object storage with this lightweight Operator using S3 APIs. You get cloud-like storage access in your own data center.
Cloudian’s key features for Kubernetes storage include: