Cloud computing is all about the combination of all kinds of separate components. In that regard, Kubernetes are essential for running applications in containers and distributing hardware resources. They are therefore widely configurable, or also called “composable,” making it applicable to numerous IT infrastructures. However, OWASP (Open Worldwide Application Security Project) sees that this poses several dangers. It highlights 10 of them.
OWASP has been around since 2001 and also highlights risks around API security and cryptographic flaws, for example. The increasing popularity of cloud computing will only have made the importance of the Kubernetes top 10 more obvious. On top of that, the list of best practices regarding Kubernetes are by no means always followed. So very useful to put your finger on the sore spot. What can go wrong and how do you solve it?
Tip: Kubernetes best practices often not followed
K01: unsafe workload configurations
OWASP cites research from Red Hat that concluded nearly 53 percent of those surveyed had experienced a Kubernetes misconfiguration incident at some point in the last 12 months. For example, one may run a process within a container as the root user, allowing an attacker to gain root privileges. In addition, users should choose read-only file systems so that malicious actors cannot take actions outside a container. On top of that, it is not advisable to run a privileged container: this allows a threat actor to tap additional resources and take over a host at the kernel level. That person bypasses many built-in prevention tools against container breakouts by doing so.
K02: supply chain vulnerabilities
OWASP indicates that a single container can deal with hundreds of third-party components and dependencies, making it very difficult to trust each origin. The nonprofit cites that it is difficult to ensure the integrity of an image because there is no or too little data being logged. Therefore, it is important to verify the integrity of the software at each stage with in-toto attestations.
In addition, a container image consists of layers, where external software can ensure that the attack surface is increased. Hackers can exploit known vulnerabilities to worm their way inside a Kubernetes environment.
Due to a heavy reliance on third-party software, there may be vulnerabilities unknown in those applications, which can put an entire cluster at risk. Therefore, every organization should maintain a Software Bill of Materials (SBOM), from which security checks should take place to check for vulnerabilities or unpatched applications.
K03: too permissive RBAC configurations
RBAC (Role-based access control) ensures that a network or user has only the level of access that is strictly necessary. An error in its configuration can mean that a compromised user can lead to much more access for a malicious person than imagined. An example of OWASP is unnecessarily deploying cluster-admin to a user. Centralized policies to detect and block risky RBAC permissions can help greatly in this regard. Direct access to clusters should also be prevented as much as possible.
K04: No centralized policy enforcement
Many organizations today work with multiple cloud services simultaneously or have multiple Kubernetes distributed by region or business division, for example. It is tough to ensure all policies are operating centrally, but that is very important. Indeed, those who don’t do so can potentially allow images from untrusted registries. Combined with other common mistakes, this can lead to privilege escalation, with dire consequences.
Fortunately, Kubernetes has a built-in Admission Controller in the API to handle this.
K05: Inadequate use of logging and monitoring
With Kubernetes, it is important to log data, especially since containers tend to be alive for a short time, so evidence of a cyberattack fades quickly. It is particularly important to have a centralized location for logs, which allows you to keep visibility into potential cyberattacks. Things such as failed authentication attempts or manual deletion of Kubernetes resources should be visible. Kubernetes itself has an Audit logging functionality that saves actions taken by the API for later analysis. It is also important to properly protect the logging infrastructure, otherwise a sophisticated attacker can cover their tracks.
K06: vulnerable authentication mechanisms
Authentication can be configured in many ways within Kubernetes, but therefore can also be screwed up in many ways. For example, users should avoid using certificates to grant access through the Kubernetes API. This is because these cannot be revoked, so a compromised cluster quickly needs a re-key. OWASP calls certificates a “Break Glass” mechanism if you really have no other way to provide authentication.
As is well known, MFA (Multi-Factor Authentication) is now everywhere, but again it is a useful method of security.
K07: missing tools for network segmentation
The importance of network traffic with Kubernetes is readily apparent: the infrastructure can be up and running with all sorts of microservices and tenants. Networking is therefore “flat” by default, allowing every workload to communicate with every other workload by default. Those who don’t deviate from that can allow attackers to navigate their way through the network.
OWASP recommends multiple Kubernetes clusters when appropriate. This creates a separation between workloads so that attackers cannot get as far. Still, this can create additional complexity in your IT infrastructure. Network policies can constrain communication flows between Kubernetes pods. A service mesh such as Istio, Linkerd and HashiCorp Consul is also recommended by OWASP to segment network traffic.
K08: errors in secrets management
A Kubernetes Secret is an object that stores sensitive data, such as a password or token. OWASP recommends using these with “extreme caution.” Anyone who calls it through the API will see an unencrypted username and password. Therefore, it is crucial to provide secrets-at-rest with encryption. In addition, users should properly seal RBAC configurations, as a malicious person with access to these can determine what privileges they want. This is where logging and auditing come into play, as they can be used to see whether someone gained access to a Kubernetes secret.
K09: misconfigured cluster components
A Kubernetes cluster can be configured in many ways, which encourages errors. Consider kubelets, which ensure that containers work properly. However, it is possible not to have authentication enabled on requests to this cubelet. Also, the key-value store etcd should be kept well, as it houses config data and Kubernetes secrets.
It is also important not to run the Kubernetes API server on a public network. OWASP cites BleepingComputer, which reported 900,000 Kubernetes instances available online in 2022.
Regular CIS Benchmark scans and audits should be able to detect component misconfigurations. A strong Infrastructure-as-Code culture should ensure that security teams maintain visibility into how clusters are created and maintained.
K10: dated and vulnerable components
Finally, traditional patching and vulnerability monitoring can also cause problems. Keeping track of Kubernetes-related CVEs should be a given, as should continuously scanning for vulnerable components with OPA Gatekeeper, for example. Minimizing third-party dependencies can keep a Kubernetes cluster safe.
In short: keep an overview
For the most part, IT teams will have already identified many threats and taken the necessary steps. Still, keeping up with Kubernetes security starts with keeping an overview. For example, OWASP talks about the Software Bill of Materials, which can be used as a template for addressing one’s own IT infrastructure. Is it known what is happening in each cluster, who has access and whether all data is transparent? That’s always easier said than done.
For an overview of how Kubernetes are doing in the year 2023, we published a comprehensive article earlier this year.
Read it here: The State of Kubernetes In 2023