In this fifth installment of Tenable’s “Stronger Cloud Security in Five” blog series, we offer three best practices for quickly hardening your Kubernetes environment’s security in GCP: remove wide inbound access to cluster APIs; remove root permissions from containers; and remove privileged permissions from publicly accessible groups.
Securing your Kubernetes environment is critical in order to protect your cloud application development lifecycle and your container orchestration. However, properly configuring and managing Kubernetes is complicated, and this often leads to lax security controls that put organizations at an elevated risk for a breach.
As the “Tenable Cloud Risk Report 2024” found, security weaknesses in Kubernetes environments aren’t the exception – they’re the norm:
- 78% of organizations have publicly accessible Kubernetes API servers, and 41% of those are set to allow inbound internet access.
- 44% run privileged containers, which have access to the host’s resources and kernel capabilities, making them a major risk if attackers gain access to them.
- 58% have cluster-admin role bindings, which give some users complete control over all of their organizations’ Kubernetes environments.
Here we outline three best practices that take no more than five minutes to implement and that’ll quickly boost the security of your Google Cloud Platform’s (GCP) Kubernetes environment. Read on!
Remove wide inbound access to clusters’ APIs
The Google Kubernetes Engine (GKE) API lets you query and manipulate the state of API objects in Kubernetes. Thus, you should configure its authorized networks setting so it restricts inbound internet access to specific IP addresses. Otherwise, if the authorized network setting is disabled, any public IP address can access the Kubernetes API without any restrictions, creating a significant risk for malicious users to tamper with the API.
Specifically, GKE’s wide rules allow network inbound access for an IP range of more than 65,535 addresses. If “Allow access through Google Cloud public IP addresses” is enabled, your cluster’s control plane may be exposed to network access publicly.
One way this can be mitigated is to limit the authorized networks that can access the control plane in this way:
- In the GCP Portal, open the resource page of GKE cluster.
- Under the “Networking – Control plane authorized networks” setting, click the pencil button.
- Check “Enable control plane authorized networks.”
- Edit the “Authorized Networks” to allow access only to specific IP addresses that require access to the Kubernetes API.
- Click “Save Changes” to confirm
By taking these steps, you shrink your Kubernetes clusters’ attack surface and reduce the risk that hackers will breach the control plane via brute-force attacks, API vulnerability exploitation and other attack methods.
Remove privileged permissions from containers
If attackers exploit a vulnerability in a privileged container’s application, they could control the container’s host and wreak havoc in your Kubernetes environment. For example, attackers could tamper with host devices and kernel parameters, and make malicious OS system calls, such as retrieving files and disabling security controls.
That’s why we don’t recommend running privileged containers. You should evaluate Kubernetes workloads and flag every container spec that has the securityContext.privileged flag set to “true,” as shown in the screenshot below.
(Source: Tenable)
Here’s how you remediate this:
- For each deployment where a container is provisioned with a privileged security context, set the flag for “privileged” to “false.”
- Add a Pod Security Standard policy to the namespace default.
Remove privileged permissions from publicly accessible groups
You should be aware that the groups like system:anonymous user and system:unauthenticated can be used by anyone with access to the cluster. In GKE, the system:authenticated group, though it may sound more secure, actually allows access to anyone who can identify with any Google identity (e.g., a Gmail account), making it public.
(Source: Google’s “Best practices for GKE RBAC” documentation)
Unfortunately, it’s quite common for organizations to inadvertently grant these groups privileged access, which opens the door for potentially anyone on the internet to access critical resources in your Kubernetes environment.
In addition, combining this with the first issue we discussed — unrestricted network access to the cluster’s control plane — grants permissions that can be leveraged by anyone with network access to the control plane, which in turn has network access from anywhere.
This dangerous scenario puts your organization at an elevated risk for a breach if attackers exploit a security flaw in your Kubernetes environment, such as a container pod with a critical vulnerability.
To remedy this simply remove any unnecessary role bindings from the publicly accessible groups.
Conclusion
We hope you’ve found these three Kubernetes security “quick win” tips helpful and valuable. They’re just a small sample of the comprehensive Kubernetes security best practices our cloud security experts can help you adopt and automate with our Tenable Cloud Security cloud native application protection platform (CNAPP).
With Tenable Cloud Security, you can streamline and simplify core Kubernetes security elements across multi-cloud environments, including:
- Obtaining comprehensive, continuously updated visibility into all your resources
- Controlling access to clusters and enforcing least-privilege access
- Enforcing policy and configuration control at scale
- Detecting container vulnerabilities and malware
- Automating remediation and mitigation of security issues, including misconfigurations, policy violations and overprivileged identities
Find out how you can take action to boost your Kubernetes and your overall multi-cloud security in just five minutes.