Security is one of key challenges in Kubernetes because of its configuration complexity and vulnerability. Managed container services like Google Kubernetes Engine (GKE) provide many protection features but don't take all related responsibilities off your plate. Read on to learn more about GKE security and best practices to secure your cluster.
Basic overview of GKE security
GKE protects your workload in many layers, which include your container image, its runtime, the cluster network, and access to the cluster API server.
That's why Google recommends a layered approach to protecting your clusters and workloads. Enabling the right level of flexibility and security for your organization to deploy and maintain workloads may require different tradeoffs, as some settings may be too constraining.
The most critical aspects of GKE security involve the following:
- Authentication and authorization;
- Control plane security, including components and configuration;
- Node security;
- Network security.
These elements are also reflected in CIS Benchmarks, which help to structure work around security configurations for Kubernetes.
Why are CIS Benchmarks crucial for GKE security?
Handling K8s security configuration isn’t exactly a walk in the park.
Red Hat 2022 State of Kubernetes and Container Security1 found that almost 1 in 4 serious issues were vulnerabilities that could be remediated. Nearly 70% of incidents happened due to misconfigurations.
Since its release by the Center of Internet Security (CIS), Benchmarks have become globally recognized best practices for implementing and managing cybersecurity mechanisms.
The CIS Kubernetes Benchmark involves recommendations for K8s configuration that support a strong security posture. Written for the open-source Kubernetes distribution, it intends to be as universally applicable as possible.
CIS GKE Benchmarking in practice
With a managed service like GKE, not all items on the CIS Benchmark are under your control.
That’s why there are recommendations that you cannot audit or modify directly on your own. These involve:
- The control plane;
- The Kubernetes distribution;
- The nodes' operating system.
However, you still have to take care of upgrading the nodes that run your workloads and, of course, the workloads themselves. You need to audit and remediate any recommendations to these components.
You could do it manually or use a tool that handles CIS benchmarking. With CAST AI’s container security module, for example, you can get an overview of benchmark discrepancies within minutes of connecting your cluster.
The platform also prioritizes the issues it identifies, so you know which items require remediation first. When scanning your cluster, you also check it against the industry's best practices, so you can better assess your overall security posture and plan further GKE hardening.
Top 10 strategies to ensure GKE security
1. Apply the principle of least privilege
This basic security tenet refers to granting a user account only the privileges that are essential to perform the intended function.
It comes in CIS GKE Benchmark 6.2.12: Prefer not running GKE clusters using the Compute Engine default service account.
By default, your nodes get access to the Compute Engine service account. Its broad access makes it useful to multiple applications, but it also has more permissions than necessary to run your GKE cluster. That's why you must create and use a minimally privileged service account instead of the default one – and follow suit in other contexts, too.
2. Use RBAC to strengthen authentication and authorization
GKE supports multiple options for managing access to your clusters with role-based access control (RBAC)2.
RBAC enables more granular access to Kubernetes resources at cluster and namespace levels, but it also lets you create detailed permission policies.
CIS GKE Benchmark 6.8.4 underscores the need to give preference to RBAC over the legacy Attribute Based Access Control (ABAC).
Another CIS GKE Benchmark (6.8.3) recommends using groups to manage users as it simplifies controlling identities and permissions. It also removes the need to update the RBAC configuration whenever users are added or removed from the group.
3. Enhance your control plane’s security
Under the Shared Responsibility Model, Google manages the GKE control plane components for you. However, you remain responsible for securing your nodes, containers, and pods.
By default, the Kubernetes API server uses a public IP address. You can protect it by using authorized networks and private clusters, which enable you to assign a private IP address.
You can also enhance your control plane’s security by doing a regular credential rotation. When you initiate the process, the TLS certificates and cluster certificate authority are rotated automatically.
4. Upgrade your GKE infrastructure regularly
Kubernetes frequently releases new security features and patches, so keeping your K8s up-to-date is one of the simplest ways to improve your security posture.
GKE patches and upgrades the control planes for you automatically. Node auto-upgrade also automatically upgrades nodes in your cluster. CIS GKE Benchmark 6.5.3 recommends keeping that setting on.
If for any reason you need to disable the auto-upgrade, Google advises performing upgrades monthly and following the GKE security bulletins4 for critical patches.
5. Protect node metadata
CIS GKE Benchmarks 6.4.1 and 6.4.2 refer to two critical factors compromising your node security, which is still your responsibility.
The v0.1 and v1beta1 Compute Engine metadata server endpoints were deprecated and shut down in 2020 as they didn’t enforce metadata query headers.
Some attacks against Kubernetes rely on access to the VM's metadata server to extract credentials. You can prevent those attacks with Workload identity or Metadata Concealment.
6. Disable the Kubernetes dashboard
Some years back, the world was electrified by the news of attackers gaining access to Tesla’s cloud resources and using them to mine cryptocurrency5. The vector of attack in that case was a Kubernetes dashboard, which was exposed to the public with no authentication or elevated privileges.
Complying with CIS GKE Benchmark 6.10.1 is recommended if you want to avoid following Tesla's plight. This standard clearly outlines that you should disable Kubernetes web UI when running on GKE.
By default, GKE 1.10 and later disable the K8s dashboard. You can also use the following code:
gcloud container clusters update CLUSTER_NAME \
--update-addons=KubernetesDashboard=DISABLED7. Follow the NSA-CISA Framework
CIS Kubernetes Benchmark gives you a strong foundation for building a secure operating environment. But if you want to go further, make space for NSA-CISA Kubernetes Hardening Guidance6 in your security procedures.
The NSA-CISA report outlines vulnerabilities within a Kubernetes ecosystem and recommends best practices for configuring your cluster for security.
It presents recommendations on vulnerability scanning, identifying misconfigurations, log auditing, and authentication, helping you to ensure that you appropriately address common security challenges.
8. Improve your network security
Most workloads running in GKE need to communicate with other services running inside and outside the cluster. However, you can control the traffic allowed to flow through your clusters.
First, you can use network policies to limit pod-to-pod communication. By default, all cluster pods can be reached over the network via their pod IP address. You can lock down the connection in a namespace by defining traffic flowing through your pods and stopping it for those that don't match the configured labels.
Second, you can balance your Kubernetes pods with a network load balancer. To do so, you create a LoadBalancer service matching your pod's labels. You will have an external-facing IP mapping to ports on your Kubernetes Pods, and you’ll be able to filter authorized traffic at the node level with kube-proxy.
9. Secure pod access to Google Cloud resources
Your containers and pods might need access to other resources in Google Cloud. There are three ways to do this: with Workload Identity, Node Service Account, and Service Account JSON Key.
The simplest and most secure option to access Google Cloud resources is by using Workload Identity. This method allows your pods running on GKE to get permissions on the Google Cloud service account.
You should use application-specific Google Cloud service accounts to provide credentials so that applications have the minimal necessary permissions that you can revoke in case of a compromise.
10. Get a GKE-configured secret manager
CIS GKE Benchmark 6.3.1. recommends encrypting Kubernetes Secrets using keys managed in Cloud KMS.
Google Kubernetes Engine gives you several options for secret management. You can use Kubernetes secrets natively in GKE, but you can also protect these at an application-layer with a key you manage and application-layer secret encryption.
There are also secrets managers like Hashicorp Vault, which provide a consistent, production-ready way to manage secrets in GKE. Make sure you check your options out and pick an optimal solution.
Assess GKE security within minutes
The Kubernetes ecosystem keeps growing, but so are its security configuration challenges. If you want to stay on top of GKE container security, you need to be able to identify potential threats and track them efficiently.
CAST AI’s security report lets you scan your GKE cluster against CIS benchmark, NSA-CISA framework, and other container security best practices to identify vulnerabilities, spot misconfigurations, and prioritize them. It only takes a few minutes to get a complete overview of your cluster’s security posture.
Scan your GKE cluster now and find out how to secure it best.
Check your Kubernetes cluster against configuration and security best practices
Connect and scan your cluster in 5 min, no credit card required.
References
- [1] - RedHat
- [2]- Google Cloud
- [3] - Google Cloud
- [4] - GKE Security Bulletins
- [5] - RedHat
- [6] - National Security Agency & Cybersecurity and Infrastructure Security Agency
Top comments (0)