The Cloud Risk Encyclopedia is a free and public resource featuring over 1,800 cloud security risks. Security practitioners, developers and cloud engineers can use the Encyclopedia as a resource to investigate security and compliance risks found in cloud environments. In this blog, we talk about the recent updates in the CRE, and take a look at some of the most prevalent Kubernetes security risks. If you are interested in learning more, Yonatan Broder, our Kubernetes expert, will be demonstrating how the CRE can serve as a resource to improve your Kubernetes security posture, and will be answering your Kubernetes questions in our upcoming webinar.
New Q3 Cloud Risk Encyclopedia updates
This week, Orca Security published a new update to the Cloud Risk Encyclopedia (CRE), a public resource featuring cloud security and compliance risks and remediation strategies pulled directly from Orca’s cloud security platform. With this new update, the Encyclopedia now includes 1,800 cloud risks. This is an increase of over 800 new risk entries since its original launch in early 2022, and the collection is continuing to grow.
Users can search or filter on risks based on cloud platform, risk category, and risk score. For ‘featured’ risks, the encyclopedia includes more detailed descriptions, related risks, and preventive strategies.
Users can also check which risks apply to particular compliance frameworks: By filtering risks on a compliance framework or CIS benchmark, security professionals can research the relevant cloud security risks that affect compliance status. Major compliance frameworks—PCI-DSS, GDPR, HIPAA, NIST 800-53, and SOC 2, as well as leading CIS benchmarks from AWS, Azure, Google Cloud and Kubernetes—are all included.
New featured Kubernetes risks
Kubernetes is an open source container orchestration platform for the management of containerized applications. K8s is an open source project hosted by the Cloud Native Computing Foundation (CNCF).
The Cloud Risk Encyclopedia includes a collection of about 200 common Kubernetes security risks—from network and authentication misconfigurations, to lateral movement risks—helping security teams stay up to date and improve their Kubernetes security postures. In addition to including best practices recommendations from the Kubernetes CIS Benchmark and specific Kubernetes managed service risks, the Orca research pod continuously adds further risks to promote Kubernetes hardening.
Among the 15 new featured pages in this update, the following 3 Kubernetes-related lateral movement risks are included:
- Risk #1: Controller of pods with the ability to read secrets – A controller should not be able to create pods with a service account that allows reading secrets in a namespace or cluster. Kubernetes secrets are objects that contain security-critical information like passwords, tokens, or keys. If a malicious actor gains access to any pod’s container, they can extract the tokens of other service accounts and use them to steal all the secrets of the cluster.
- Risk #2: Controller creating pods with privileged Docker – Ensure that PodSecurityPolicy objects do not have the privileged attribute set to true since this allows Kubernetes controllers to run containers in privileged mode. Privileged containers have root capabilities to all the devices on the host system. If an attacker gains access to the container, they can use it to compromise the system.
- Risk #3: Controller creating containers with secrets as environment variables – A controller should not be able to create containers that use secrets mounted as environment variables. It is reasonably common for application code to log out its environment, particularly in the event of an error. This will include any secret values, passed as environment variables. Once an adversary gets access to the asset, and in turn, the application logs, they can use the exposed secrets to compromise the larger system.
You can find other Kubernetes risks in the Cloud Risk Encyclopedia.
Three common Kubernetes security concerns
Like any major cloud platform, there are security concerns around Kubernetes. A Red Hat survey of DevOps professionals found that:
- 55% delayed an application release due to security issues.
- 94% experienced at least one Kubernetes security incident in 2021.
- 59% said security is their biggest concern with regard to continued use of Kubernetes and containers.
Below we list 3 major security concerns in Kubernetes deployments:
- Kubernetes Misconfigurations
A good starting point is recognizing that while Kubernetes provides several controls that can help organizations effectively secure clusters and applications, it does not provide secure configurations out of the box, nor robust-enough default configuration rules. Kubernetes was built for speed and agility, not for security or isolating components.
For example, Kubernetes does not apply network policies to pods by default. This means that after being deployed, all pods can talk to all other pods within a Kubernetes environment. So you might find that a Kubernetes API server configuration allows http kubelet connections or that RBAC authorization is not set in the Kubernetes API server configuration file. This makes it critical to ensure all cluster resources have appropriate security policies defined.
Another concern is secret management. Secrets define how sensitive information, like keys and credentials, is accessed and stored. When managing secrets, it is critical to make sure that they are not used as environment variables, or hard coded within images. Secrets should be managed externally to containers, with careful access control to protect secrets from unauthorized parties. Risks included in the Cloud Risk Encyclopedia related to improper secrets management include Controller of pods with the ability to read secrets and Controller creating containers with secrets as environment variables.
- Insecure Transport Controls
When it comes to self-managed Kubernetes clusters, while making sure that the clusters themselves are secure, setting proper security measures for data in transport is often overlooked and could lead to exposure to malicious actors.
Transport Layer Security (TLS) can be used to help prevent potential attackers from using man-in-the-middle (MiTM) or similar attacks to eavesdrop on or manipulate network traffic. It is recommended to allow only encrypted connections over TLS, when configuring communication in the cluster between services.
Another important element to consider is etcd. Etcd is an open source distributed key-value store used to hold and manage the critical information that distributed systems need to keep running. Most notably, it manages the configuration data, state data, and metadata for Kubernetes. These objects are sensitive in nature and should be encrypted in transit.
In the Cloud Risk Encyclopedia, you can find (among others) the following related risks:
- K8S API server configuration tls communication not configured
- K8s etcd using plaintext communication
- K8s etcd is not using TLS for peer communication
- K8s etcd is using –auto-tls argument
- Kubernetes node’s kubelet –tls-cert-file and –tls-private-key-file are not set
- Lack of Visibility into Kubernetes
As we mention all the time when it comes to cloud security: visibility is critical to ensure security is maintained. However, attaining wide visibility can be challenging in complex, distributed, and containerized environments, for the following reasons:
- Container development is vast. Many containers can be scheduled, deployed, and terminated, making monitoring challenging.
- Data collection is difficult due to the distributed and dynamic nature of containerized workloads.
- Unified multi-cloud visibility is challenging, due to the fact that each cloud service provider provides its own monitoring and visibility tools.
Maintaining proper visibility into crucial cloud-native infrastructure components becomes more challenging the more containers are deployed. Even worse, because containers are typically “deploy and forget” assets, nobody may be checking them for shady activity, out-of-date apps, a lack of tooling, or other security components. Fewer people are aware of security gaps because of this lack of insight into their security posture.
Webinar: How to Support Kubernetes Security with the Cloud Risk Encyclopedia
Want to understand more about how security teams can benefit from the Kubernetes information in the Cloud Risk Encyclopedia?
Join us – Yonatan Broder, Cloud Threat Researcher at Orca Security and Jason Silberman, Senior Product Marketing Manager at Orca Security for our webinar How to Support Kubernetes Security with the Cloud Risk Encyclopedia on October 26th, 2022.
We’ll be demonstrating how security teams can stay up to date with prevalent Kubernetes and other cloud risks, and how the Cloud Risk Encyclopedia can help organizations improve Kubernetes security postures. This will also be a great chance for you to ask Yonatan, our Kubernetes expert, all your Kubernetes security questions!