Full Report
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’ APIsThe 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 confirmBy 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 groupsYou 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.ConclusionWe 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 resourcesControlling access to clusters and enforcing least-privilege accessEnforcing policy and configuration control at scaleDetecting container vulnerabilities and malwareAutomating remediation and mitigation of security issues, including misconfigurations, policy violations and overprivileged identitiesFind out how you can take action to boost your Kubernetes and your overall multi-cloud security in just five minutes.Learn more:"Stronger Cloud Security in Five: The Importance of Cloud Configuration Security""Stronger Cloud Security in Five: How To Protect Your Cloud Workloads""Stronger Cloud Security in Five: Securing Your Cloud Identities"“Stronger Cloud Security in Five: How DSPM Helps You Discover, Classify and Secure All Your Data Assets”
Analysis Summary
# Best Practices: Kubernetes Security Quick Wins
## Overview
These practices address immediate, high-impact actions to significantly improve the security posture of Kubernetes environments, focusing on configuration, access control, and vulnerability management using readily available security principles.
## Key Recommendations
### Immediate Actions
1. **Review and Reduce Unnecessary Role Bindings for Publicly Accessible Groups:** Immediately audit and remove any RoleBindings associated with globally or publicly accessible groups. This minimizes the blast radius if a less-privileged identity is compromised.
2. **Remove Unnecessary Role Bindings from an Existing Insecure Container Pod:** Identify and remove any redundant or overly permissive role bindings attached to containers, especially those deployed publicly or running critical workloads, to enforce the principle of least privilege.
### Short-term Improvements (1-3 months)
1. **Obtain Comprehensive, Continuously Updated Visibility into All Kubernetes Resources:** Implement continuous scanning or inventory tools (like a CNAPP connector) to maintain a real-time mapping of all deployed resources, workloads, and configurations within your clusters.
2. **Control Access to Clusters and Enforce Least-Privilege Access:** Implement strict Role-Based Access Control (RBAC) policies across the cluster, ensuring users and service accounts only possess the permissions strictly necessary for their function.
3. **Detect Container Vulnerabilities and Malware:** Integrate automated scanning tools into the CI/CD pipeline or runtime environment to proactively identify known vulnerabilities (CVEs) and malicious code present within container images.
### Long-term Strategy (3+ months)
1. **Enforce Policy and Configuration Control at Scale:** Establish automated enforcement mechanisms (like admission controllers or policy engines) to prevent non-compliant or insecure configurations from being deployed into the cluster.
2. **Automate Remediation and Mitigation:** Develop and integrate automated workflows to swiftly address common security issues, including misconfigurations, policy violations, and instances of overprivileged identities.
3. **Adopt Cloud Native Application Protection Platform (CNAPP) Capabilities:** Standardize on a unified platform to streamline core Kubernetes security elements across multi-cloud environments, integrating visibility, access control, vulnerability management, and policy enforcement.
## Implementation Guidance
### For Small Organizations
- Focus intensely on **Immediate Actions** (reducing excessive role bindings) as these offer the highest immediate ROI on security lift with minimal tool investment.
- Implement basic **Vulnerability Scanning** (e.g., free or open-source tools) on container images before deployment.
- Standardize on **basic RBAC models** based on job function rather than broad group access.
### For Medium Organizations
- Begin implementing **continuous visibility** tools to track resource configuration drift.
- Prioritize **enforcing least-privilege access** organization-wide using RBAC best practices.
- Integrate **vulnerability detection** directly into the CI/CD pipeline (shift left).
### For Large Enterprises
- Deploy a **unified security platform (CNAPP)** to manage security posture consistently across hybrid or multi-cloud Kubernetes deployments.
- Institute **automated remediation** pipelines for policy violations and high-severity vulnerabilities.
- Utilize **security posture management** to enforce configuration standards at scale via policy-as-code.
## Configuration Examples
*The source article implies actions on RoleBindings but does not provide specific YAML configuration blocks. Below are conceptual implementation targets based on principles described:*
**Conceptual Action:** Restrict binding for a potentially broad group (e.g., `public-access-group`) in a specific namespace.
yaml
# Goal: Enforce Least Privilege by auditing/removing unnecessary RoleBindings
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: audit-public-access
namespace: sensitive-namespace
subjects:
- kind: Group
name: public-access-group # ACTION: Review if this group should have access here
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: View
name: readonly-view
apiGroup: rbac.authorization.k8s.io
## Compliance Alignment
The core recommendations align broadly with foundational security frameworks:
- **NIST CSF:** Identify (ID.RA, ID.AM), Protect (PR.AC, PR.DS)
- **CIS Benchmarks for Kubernetes:** Focuses heavily on configuration management, access control (RBAC), and securing control plane components, which are addressed by enforcing least privilege and configuration control.
- **ISO 27001:** A.6 (Organization of Information Security), A.9 (Access Control)
## Common Pitfalls to Avoid
- **Ignoring Runtime/Deployment Environment Discrepancies:** Assuming that container build-time security scans cover all runtime risks (e.g., exploitation after deployment). Full lifecycle security requires visibility into cluster configuration, not just image contents.
- **Over-reliance on Default Permissions:** Deploying applications without explicitly defining RBAC roles, which defaults to leveraging broader permissions if the deployment runs under a service account with excessive rights.
- **Stale Bindings:** Failing to regularly audit and prune role bindings after project transitions or personnel changes, leading to accumulated, unnecessary access rights.
## Resources
- Cloud Native Application Protection Platform (CNAPP) solutions for unified security management.
- Tools specializing in **Container Vulnerability Scanning** (integrated into the build pipeline).
- Kubernetes **RBAC auditing tools** to identify overprivileged identities and excessive role bindings.