Tigera Logo

Guides: GKE Security

GKE Security: The Basics and 10 Critical Best Practices

What Is Google Kubernetes Engine (GKE) Security?

Google Kubernetes Engine (GKE) is a managed Kubernetes service that allows users to leverage Kubernetes for container orchestration more easily, with Google handling management of the system components and control plane. There are several features and practices that can help protect GKE clusters from unauthorized access and attacks.

GKE integrates deeply with Google Cloud’s security model, offering mechanisms for managing access control, protecting the infrastructure, and securing data in transit and at rest. This ensures that applications running on GKE are protected against common cybersecurity threats.

A key component of GKE security is encryption of data, both in transit between the user and the cluster and at rest within Google Cloud storage services. Additionally, it provides identity and access management (IAM) capabilities that allow fine-grained control over who can access specific resources within a cluster.

This is part of a series of articles about Kubernetes Security.

In this article:

Critical Aspects of GKE Security

Here are some of the most important elements involved in securing GKE clusters.

Authentication and Authorization

Authentication in GKE is primarily handled through Google Cloud IAM, which integrates with Kubernetes Role-Based Access Control (RBAC). IAM allows administrators to manage who can authenticate to the GKE cluster and what permissions they have. Users can be assigned roles that grant access to specific resources, such as viewing or modifying deployments, pods, and services.

Authorization within the cluster is controlled by Kubernetes RBAC. This system enables administrators to create roles with specific permissions and bind these roles to users or groups. For example, a developer might be granted permissions to create and manage deployments within a specific namespace, while a security team member could have broader access to audit logs and configuration settings.

Control Plane Security

The GKE control plane is managed by Google and includes the Kubernetes API server, etcd database, and other critical components. To secure the control plane, Google employs multiple layers of security, including encryption of data at rest and in transit, regular security updates, and strict access controls. These measures ensure that the control plane is protected from unauthorized access and potential vulnerabilities.

One of the key features of GKE control plane security is the use of private clusters. In a private cluster, the control plane is accessible only from within the cluster’s Virtual Private Cloud (VPC), and nodes communicate with the control plane over private IP addresses. This reduces the attack surface by limiting exposure to the internet. Google also performs regular vulnerability assessments and applies patches to the control plane components to maintain.

Node Security

GKE nodes, which run the containerized workloads, are secured through several mechanisms. By default, GKE uses Container-Optimized OS, a lightweight, hardened operating system designed for running containers securely. This OS includes built-in security features such as secure boot, automatic updates, and minimal software packages to reduce the attack surface.

Nodes can also be configured with Shielded GKE Nodes, which provide enhanced security features such as verifiable integrity and tamper protection. Shielded GKE Nodes use secure boot to ensure that the system boots only with verified software, and they employ a virtual Trusted Platform Module (vTPM) to protect cryptographic operations.

Network Security

Network security in GKE involves controlling traffic flow between pods, services, and external networks. GKE supports Kubernetes Network Policies, which allow administrators to define rules that specify how pods can communicate with each other and with other network endpoints. These policies can be used to implement a zero-trust network model, where only explicitly allowed traffic is permitted.

Beyond Network Policies, teams managing ingress and service-to-service routing in GKE can also adopt the Kubernetes Gateway API, which offers a more expressive, role-oriented model for configuring traffic management and security at the cluster edge.

For additional security, GKE supports the use of private clusters, where nodes are assigned private IP addresses, and the control plane is accessible only through a private endpoint within the VPC. This configuration reduces exposure to the internet and enhances security. GKE also integrates with Google Cloud VPC, enabling features like VPC Service Controls and Cloud Armor to provide further network protection.

Related content: Read our guide to Kubernetes Security Checklist

Key GKE Security Best Practices

Here are some of the main techniques that organizations can use to secure their GKE environments.

1. Keep the GKE Infrastructure Up to Date

Regular upgrades ensure that clusters run the latest versions of Kubernetes, which include patches for vulnerabilities, improvements in system stability, and new features that enhance the management and scalability of containerized applications.

GKE provides automated tools and processes to support these upgrades, minimizing downtime and operational overhead. For example, GKE’s release channels allow administrators to subscribe clusters to automatic update streams based on their stability and feature requirements. The Node Auto-Upgrade feature ensures that worker nodes are kept current with the master’s version.

2. Leverage GKE Sandbox

GKE Sandbox provides an additional layer of isolation for containerized workloads, enhancing security by minimizing the risk of malicious code affecting the host system or other containers. It uses gVisor, a lightweight sandbox environment that intercepts and manages system calls made by the container.

This setup is especially useful when running untrusted or third-party code. It restricts what the container can do and access, reducing the attack surface. Developers can designate specific pods to run within the sandbox environment through simple configuration changes, applying stronger isolation to sensitive workloads while leaving other services on standard containers.

3. Use CIS Benchmarks for GKE

The CIS Benchmark for Kubernetes is a set of standardized security guidelines for securing Kubernetes environments, with specific guidance for managed services including Google Kubernetes Engine. They provide a checklist covering various aspects of GKE security, including cluster setup, network configurations, and logging and monitoring practices. Aligning GKE deployments with these recommendations helps ensure that clusters are configured to resist common vulnerabilities and threats.

The benchmarks are regularly updated to reflect changing security practices and threat landscapes. Implementing them requires a systematic review of the current cluster configurations against the guidelines provided. This may involve adjusting settings related to access controls, network policies, and pod security policies among others.

4. Restrict Network Access

Administrators should implement network policies that define explicit rules for pod communications. These policies specify which pods can communicate with each other and with external services, creating a list of allowed interactions. By default, all pods in a GKE cluster can communicate without restrictions, but policies can change this behavior to deny-all, allowing traffic only if it matches a defined policy.

Another way to enhance the security of microservices and sensitive workloads is to use private GKE clusters. Private clusters provide an added layer of security by ensuring that nodes are assigned private IP addresses and that the control plane is accessible only within the cluster’s Virtual Private Cloud (VPC) or through a specified private connection.

5. Use Shielded GKE Nodes

Shielded GKE nodes protect against rootkits and bootkits, ensuring the integrity of the operating system (OS). They prevent unauthorized modifications by leveraging secure boot and a virtual Trusted Platform Module (vTPM).

Secure boot checks that the OS kernel and system software are signed with a known cryptographic key at startup, blocking malicious software from loading during the boot process. The vTPM provides a secure environment for cryptographic operations, further securing the node against tampering and ensuring that sensitive operations like key generation are protected.

6. Enable Binary Authorization

Binary Authorization is a service that ensures that only verified images are deployed in the clusters. It integrates with GKE to enforce deploy-time security policies, preventing the deployment of unauthorized or potentially harmful images. It requires images to be signed by trusted authorities before deployment, allowing organizations to control container environments.

Setting up Binary Authorization involves defining and applying a policy that specifies which container images are authorized for deployment based on their signatures. Administrators can configure these policies to match organizational security requirements, including exemptions for specific images or enforcement rules for all deployments. The service automatically blocks any image that does not meet the policy criteria.

7. Apply the Principle of Least Privilege

The principle of least privilege involves restricting user and application permissions to the minimum necessary to perform their tasks. This reduces the risk of accidental or malicious actions that can compromise cluster security. In practice, this means assigning specific roles to users and service accounts that limit their access and actions within the GKE environment.

Administrators can thus control who can view, modify, or delete resources, minimizing potential avenues for security breaches. In addition to user permissions, least privilege should extend to applications running within GKE. By using Kubernetes namespaces and network policies, administrators can segregate workloads and limit their communications.

8. Implement Role-Based Access Control (RBAC)

Role-Based Access Control (RBAC) allows administrators to define roles with specific permissions and bind those roles to users, groups, or service accounts. This granularity ensures that entities within the GKE environment have only the access they need to perform their functions.

To set up RBAC in GKE, administrators create Role or ClusterRole objects that define the permissions available within a namespace or across the cluster, respectively. These roles are then linked to users through RoleBinding or ClusterRoleBinding objects. This setup enables control over who can access what within the cluster, reducing the risk of unauthorized actions.

9. Leverage Workload Identity Federation

Workload Identity Federation allows organizations to extend their existing identity solutions to manage access to GKE clusters securely. This enables applications running on GKE to assume an identity from an external identity provider, such as Active Directory or another cloud provider’s IAM system, for authenticating against Google Cloud services.

By using short-lived tokens instead of long-term credentials, it minimizes the risk of credential leakage and enhances security posture. It simplifies the management of credentials across hybrid and multi-cloud environments by enabling a secure method for applications to access Google Cloud resources, reducing the complexity of managing multiple sets of credentials.

10. Implement Google Cloud KMS Key Management Service

Google Cloud Key Management Service (KMS) enhances data security by managing encryption keys with a centralized service. It allows for the encryption of sensitive data at rest, using managed cryptographic keys without the complexity of maintaining an in-house key management system. Organizations can create, use, rotate, and destroy cryptographic keys.

Google Cloud KMS integrates with GKE and other Google Cloud services, providing a uniform method for encrypting data across the cloud environment. This simplifies the management of encryption keys and policies, enabling administrators to apply comprehensive security measures across all stored data. KMS also supports automatic key rotation and logging.

Kubernetes Security and Observability with Calico

Tigera’s commercial solutions provide Kubernetes security and observability for multi-cluster, multi-cloud, and hybrid-cloud deployments. Both Calico Enterprise and Calico Cloud provide the following features for security and observability:

Security

  • Zero trust for workloads – Prevent lateral movement of threats and maintain compliance by applying fine-grained security policies to restrict communication between workloads and third-party applications, the internet, and other workloads.
  • Compliance reporting and alerts – Continuously monitor and enforce compliance controls, easily create custom reports for audit.
  • Intrusion detection & prevention (IDS/IPS) – Detect and mitigate Advanced Persistent Threats (APTs) using machine learning and a rule-based engine that enables active monitoring.
  • Microsegmentation across Host/VMs/Containers – Deploy a scalable, unified microsegmentation model for hosts, VMs, containers, pods, and services that works across all your environments.
  • Data-in-transit encryption – Protect sensitive data and meet compliance requirements with high-performance encryption for data-in-transit.

Observability

  • Dynamic Service and Threat Graph – Observe upstream and downstream dependencies for microservices, and service-to-service interactions within a Kubernetes cluster, with a dynamic live view that helps identify security gaps and troubleshoot connectivity issues faster.
  • Application-Layer Observability – Gain visibility into service-to-service communication within your Kubernetes environment, without the operational complexity and performance overhead of service mesh.
  • Dynamic Packet Capture – Perform packet capture for a specific pod or collection of pods with this self-service, on-demand tool. The tool integrates with Kubernetes RBAC to limit and secure users’ access to the endpoints and namespaces assigned to them.
  • DNS Dashboard – Quickly confirm or eliminate DNS as the root cause for microservice and application connectivity issues in Kubernetes.
  • Flow visualizer – Get a 360-degree view of a namespace or workload, including analytics around how security policies are being evaluated in real time and a volumetric representation of flows.

Next steps:

X