GKE Autopilot security capabilities

This page describes the security features, configurations, and settings in Google Kubernetes Engine (GKE) Autopilot. GKE Autopilot clusters implement many security configurations for you, which makes Autopilot the recommended way to run GKE.

This page is intended for Security specialists who want to understand the security restrictions that Google specifically applies to Autopilot clusters, and the security features that are available for use in Autopilot. To learn more about common roles and example tasks that we reference in Google Cloud content, see Common GKE Enterprise user roles and tasks.

Before reading this page, ensure that you're familiar with the following:

• General overview of GKE security
• General overview of Autopilot mode and Standard mode

Security measures in Autopilot

Autopilot clusters enable and apply security best practices and settings by default, including many of the recommendations in the security overview and in Harden your cluster security.

If you want recommended resources based on your use case, skip to Security resources by use case. The following sections describe the security policies that Autopilot applies for you.

Autopilot and the Kubernetes Pod Security Standards

The Kubernetes project has a set of security guidelines named the Pod Security Standards that define the following policies:

• Privileged: No access restrictions. Not used in Autopilot.
• Baseline: Prevents known privilege escalation pathways. Allows most workloads to run without significant changes.
• Restricted: Highest level of security. Requires significant changes to most workloads.

In Autopilot mode, GKE enforces Pod security constraints using a custom admission controller named GKE Warden. We enforce a default security policy that includes all of the recommendations in the Baseline level of the Pod Security Standards, with some modifications for usability. Additionally, the default GKE Warden admission policy for Autopilot enforces many constraints from the Restricted level of the Pod Security Standards, but avoids restrictions that would block a majority of your workloads from running.

If you need to apply additional restrictions to comply with the full Restricted policy, you can optionally use the PodSecurity admission controller in specific namespaces.

The following table describes how the controls in the default Autopilot GKE Warden policy compare to the controls in the Baseline and the Restricted levels of the Pod Security Standards. For descriptions of each control in this table, see the corresponding entry in Pod Security Standards.

When evaluating compliance, we considered how the constraints apply to your own workloads. This excludes verified Google Cloud partner workloads and system workloads that require specific privileges to function.

Built-in security configurations

Google applies many built-in security settings to Autopilot clusters based on industry best practices and our expertise. The following table describes some of the security configurations that Autopilot applies for you:

"SETPCAP", "MKNOD", "AUDIT_WRITE", "CHOWN", "DAC_OVERRIDE", "FOWNER", "FSETID", "KILL", "SETGID", "SETUID", "NET_BIND_SERVICE", "SYS_CHROOT", "SETFCAP", "SYS_PTRACE"

- group: ""
  resource: nodes
- group: ""
  resource: persistentVolumes
- group: certificates.k8s.io
  resource: certificatesigningrequests
- group: authentication.k8s.io
  resource: tokenreviews

- group: ""
  resource: nodes
- group: ""
  resource: persistentVolumes
- group: certificates.k8s.io
  resource: certificatesigningrequests
- group: authentication.k8s.io
  resource: tokenreviews

Security boundaries in Autopilot

Autopilot provides access to the Kubernetes API but removes permissions to use some highly privileged Kubernetes features, such as privileged Pods. The goal is to limit the ability to access, modify, or directly control the node virtual machine (VM). Autopilot implements these restrictions to limit workloads from having low-level access to the node VM, so that Google Cloud can offer full management of nodes, and a Pod-level SLA.

Our intent is to prevent unintended access to the node VM. We accept submissions to that effect through the Google Vulnerability Reward Program (VRP) and will reward reports at the discretion of the Google VRP reward panel.

By design, privileged users such as cluster administrators have full control of any GKE cluster. As a security best practice, we recommend that you avoid granting powerful GKE or Kubernetes privileges widely and instead use namespace administrator delegation wherever possible as described in our multi-tenancy guidance.

Autopilot provisions single-tenant VMs in your project for your exclusive use. On each individual VM, your Autopilot workloads might run together, sharing a security-hardened kernel. Since the shared kernel represents a single security boundary, we recommend that if you require strong isolation, such as high-risk or untrusted workloads, run your workloads on GKE Sandbox Pods to provide multi-layer security protection.

Security resources based on use case

The following sections provide you with links and recommendations to plan, implement, and manage the security of your Autopilot clusters depending on your use case.

Plan cluster security

Authenticate and authorize

After setting up your Autopilot clusters, you might need to authenticate your users and applications to use resources such as the Kubernetes API or Google Cloud APIs.

Harden clusters and workloads

If you have specialized isolation or hardening requirements beyond the pre-configured Autopilot measures, consider the following resources:

Monitor your security posture

After setting up your clusters and deploying your workloads, you should set up and configure monitoring and logging so that you have observability over your cluster security posture. We recommend that you do all of the following:

• Enroll your clusters in the GKE security posture dashboard to audit workloads for concerns such as problematic security configurations or vulnerabilities in your container operating system packages and get actionable mitigation information.
• Get notified about new security bulletins and upgrade events using cluster notifications.
• Observe your clusters using the GKE dashboard in Cloud Monitoring or the Observability tab in GKE.
• Learn how to view and manage your GKE audit logs in Cloud Logging.

What's next

• Read the GKE security overview.
• Read the GKE hardening guide.
• Subscribe to security bulletins and release notes.