GKE Autopilot security measures
This page describes the security features, configurations, and settings inGoogle Kubernetes Engine (GKE) Autopilot mode. This information is forSecurity specialists who want to understand the security constraints thatGoogle applies in Autopilot mode, and the security features that areavailable for use in Autopilot. To learn more about common roles andexample tasks that we reference in Google Cloud content, seeCommon GKE user roles and tasks.
Before reading this page, familiarize yourself with the following:
Terminology
In GKE, you can use Autopilot by creating anAutopilot cluster or by running a workload in an AutopilotComputeClass in any Standard cluster. This page describes securitymeasures for Autopilot in both of these situations by using thefollowing terminology:
- Autopilot cluster
- The entire cluster uses Autopilot mode.
- Autopilot workloads in Standard clusters
- The cluster uses Standard mode, and you run specific workloads inAutopilot by using ComputeClasses.
Security measures in Autopilot
Best practice: Use Autopilot clustersfor comprehensive enforcement of the Autopilot security measures.GKE applies various security best practices and settings bydefault in Autopilot mode, including many of the recommendations in thesecurity overview and inHarden your cluster security.
In Autopilot clusters, GKE strictly enforces all of themeasures on this page by default. This default configuration makesAutopilot clusters the recommended way to use GKE.For Autopilot workloads in Standard clusters,GKE enforces the security measures in the following sections on abest-effort basis.
Enforcement of Kubernetes Pod Security Standards
The Kubernetes project has a set of security guidelines named thePod Security Standards that define the following policies:
- Privileged: No access restrictions. Not used in Autopilot.
- Baseline: Prevents known privilege escalation pathways. Allows mostworkloads to run without significant changes.
- Restricted: Highest level of security. Requires significant changes tomost workloads.
In Autopilot mode, GKE enforces Pod security constraintsby using Kubernetes admission controllers. The default Autopilot Podadmission policy includes all of the recommendations in the Baseline level ofthe Pod Security Standards, with some modifications for usability. Additionally,the default admission policy includes many constraints from the Restricted levelof the Pod Security Standards, but avoids restrictions that would block amajority of your workloads from running.
To apply additional restrictions to comply with the full Restricted policy, youcan optionally use thePodSecurity admission controllerin specific namespaces.
The following table describes how the controls in the default Autopilotadmission policy compare to the controls in the Baseline and the Restrictedlevels of the Pod Security Standards. For more information about each control inthis table, see the corresponding entry inPod Security Standards.
When evaluating compliance, we considered how the constraints apply to your ownworkloads. This excludes verified Google Cloud partner workloads andsystem workloads that require specific privileges to function.
| Control | Baseline policy compliance | Restricted policy compliance | Additional information |
|---|---|---|---|
| HostProcess | Autopilot blocks HostProcess. | ||
| Host namespaces | Autopilot blocks host namespaces. Some containers fromverified partners are allowed to use host namespaces. | ||
| Privileged containers | Autopilot blocks privileged containers by default. Autopilot allows privileged containers from verified partners for purposes such as running security and monitoring tooling. | ||
| Linux capabilities | Autopilot workloads can only access the capabilities specified in the Baseline Pod Security Standard by default. You can manually enable the following capabilities:
Autopilot also allows some verified partner workloads to set dropped capabilities. | ||
| HostPath volumes | Partially complies | Partially complies | Autopilot allows containers to request read-only access to/var/log for debugging, but denies all other read or write access. |
| HostPorts | Setting specific host ports is disallowed, which mitigates somescheduling issues, and prevents accidental or deliberate direct network exposure of services. You can manually set uprandom host port assignment from a known range to support direct-connection networking applications such as game servers. | ||
| AppArmor | The AppArmor docker-default security profile isautomatically applied to Container-Optimized OS. | ||
| SELinux | SELinux isn't applied because AppArmor is already applied. SELinux is also not mandatory in the Pod Security Standards. | ||
/proc mount type | In GKE version 1.33 and later, if the Pod securityContext setsprocMount toUnmasked, Autopilot rejects the Pod. In versions earlier than 1.33, Autopilot automatically overwrites the value in theprocMount field toDefault. | ||
| seccomp profile | Autopilot applies theRuntimeDefault seccomp profile to all workloads. You can manually override this setting for specific workloads by setting the profile toUnconfined in the Pod specification. | ||
| sysctls | GKE does not set the --allowed-unsafe-sysctls kubelet flag so pods with unsafe sysctls fail to schedule. For additional protection, as of 11 July 2023, new 1.27+ clusters also have a policy rule to enforce the securityContext settings and reject Pods that use unsafe sysctls. | ||
| Volume types | Autopilot allows only the volume types in the Restricted policy with the following additions: HostPath volumes with read-only access to/var/log for debugging, gcePersistentDisk for Compute Engine persistent disks, and nfs for network file system volumes. | ||
| Privilege escalation | This setting only provides protection to containers that aren't running as root. Industry surveys show that 76% of containers run as root, so Autopilot allows running as root to enable most workloads. This setting is also currently useful inde-privileging workloads to non-root by allowing use of file system capabilities to work arounddeficiencies with Kubernetes root capability handling. | ||
| Run as non-root | Industry surveys show that 76% of containers run as root, so Autopilot allows running as root to enable most workloads. | ||
| Run as non-root user | Containers can setrunAsUser to0.Industry surveys show that 76% of containers run as root, so Autopilot allows running as root to enable most workloads |
Built-in security configurations
In addition to the Pod Security Standards, Google applies many security settingsin Autopilot based on industry best practices and our expertise. Thesebuilt-in security configurations are strictly applied in Autopilotclusters. For Autopilot workloads in Standard clusters, Googleapplies these configurations, with some exceptions that are described in thetable that follows, on abest-effort basis.
The following table describes some of the security configurations thatAutopilot applies for you:
| Configuration | Description |
|---|---|
| Host options |
|
| Linux capabilities | You can use the followingLinux capabilities: "SETPCAP", "MKNOD", "AUDIT_WRITE", "CHOWN", "DAC_OVERRIDE", "FOWNER", "FSETID", "KILL", "SETGID", "SETUID", "NET_BIND_SERVICE", "SYS_CHROOT", "SETFCAP", "SYS_PTRACE" You can also manually enable the following capabilities:
|
| Privileged containers | Containers can't run inPrivileged mode unless the container is deployed by aGoogle Cloud partner. Privileged containers can make changes to the underlying node, such as changing the kubelet. This access could increase the impact of a Pod compromise. |
| GKE-managed namespaces | As a security measure, Autopilot doesn't allow deploying workloads in GKE-managed namespaces, such askube-system. |
| Container isolation | Autopilot enforces the following restrictions on containers to limit the impact of container escape vulnerabilities. Linux capabilities and kernel security
|
| Pod-level security policy enforcement | Autopilot supports enforcement mechanisms for Pod-level security policies such as thePodSecurity admission controller,Gatekeeper, orPolicy Controller. However, you might not need to use any of these if the built-in security configurations described on this page already meet your requirements. |
| SSH to nodes | Autopilot blocks SSH access to nodes. GKE handles all operational aspects of the nodes, including node health and all Kubernetes components running on the nodes. You can still connect remotely to your running containers using the Kubernetes |
| User impersonation | Autopilot supportsuser impersonation for all user-defined users and groups. In Autopilot clusters only, system users and groups (like the |
| Mutating dynamic admission webhooks | In Autopilot clusters only, GKE modifies mutating webhooks to exclude resources in managed namespaces, such as Autopilot also rejects webhooks that specify one or more of the following resources, and any sub-resources of those resources. - group: "" resource: nodes- group: "" resource: persistentVolumes- group: certificates.k8s.io resource: certificatesigningrequests- group: authentication.k8s.io resource: tokenreviews You can't use the |
| ValidatingAdmissionPolicies | In Autopilot clusters only, GKE modifies Autopilot also rejects - group: "" resource: nodes- group: "" resource: persistentVolumes- group: certificates.k8s.io resource: certificatesigningrequests- group: authentication.k8s.io resource: tokenreviews You can't use the |
| Certificate signing requests | You can create CertificateSigningRequests in Autopilot to create certificates that are signed by the cluster certificate authority. To prevent interference with system components, Autopilot clusters reject CertificateSigningRequests for known privileged identities, such as system groups, system agents, or Google-managed IAM service agents. This constraint doesn't apply in Standard clusters, which let you create CertificateSigningRequests for known privileged identities. |
| GKE security features | Autopilot clusters enable recommended GKE security features for you. For a list of enabled and optional security features, refer tosecurity features in Autopilot. |
| Node operating system | Autopilot uses Container-Optimized OS withcontainerd as the node operating system. Container-Optimized OS is created and managed by Google. |
| GKE version upgrades | Autopilot clusters are enrolled in a GKE release channel upon creation, and automatic upgrades are always enabled. Google automatically upgrades your control plane and nodes to the latest qualified version in the release channel over time. |
Security boundaries in Autopilot
Autopilot provides access to the Kubernetes API but removes permissionsto use some highly privileged Kubernetes features, such as privileged Pods. Thegoal is to limit the ability to access, modify, or directly control the nodevirtual machine (VM). Autopilot implements these restrictions to limitworkloads from having low-level access to the node VM, so thatGoogle Cloud can offer full management of nodes, and a Pod-levelSLA.
Important: The security boundary for GKE nodes is thesingle-tenant VM. The ability to access the node VM from Pods is not considereda security boundary for Autopilot. Any node-level access isinconsistent with the security goals of GKE Autopilot andis not supported. Google might remove any node-level access without notice.Our intent is to prevent unintended access to the node VM. We accept submissionsto that effect through theGoogle 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 ofany GKE cluster. As a security best practice, we recommend thatyou avoid granting powerful GKE or Kubernetes privileges widelyand instead use namespace administrator delegation wherever possible as described in ourmulti-tenancy guidance.
Autopilot provisions single-tenant VMs in your project for yourexclusive use. On each individual VM, your Autopilot workloads mightrun together, sharing a security-hardened kernel. Since the shared kernelrepresents a single security boundary, we recommend that if you require strongisolation, such as high-risk or untrusted workloads, run your workloads onGKE Sandbox Pods to providemulti-layer security protection.
Security recommendations based on use case
The following sections provide you with links and recommendations to plan,implement, and manage the security of your Autopilot clusters dependingon your use case.
Plan cluster security
| Use case | Resources |
|---|---|
| Understand how GKE as a platform approaches security |
|
| Understand your role in hardening your environment | Learn about theshared responsibility model. |
| View Google's recommendations for hardening measures and incident response |
|
| Understand how GKE implements audit logging |
|
Authenticate and authorize
After setting up your Autopilot clusters, you might need toauthenticate your users and applications to use resources such as the KubernetesAPI or Google Cloud APIs.
| Use case | Resources |
|---|---|
| Authenticate users or applications to the cluster API server |
|
| Authenticate applications to Google Cloud APIs and services | Autopilot clusters let you use Workload Identity Federation for GKE to securely authenticate your workloads to Google Cloud APIs by configuring Kubernetes service accounts to act as IAM service accounts. For instructions, refer toConfigure applications to use Workload Identity Federation for GKE. |
| Authorize actions at the project level | To authorize actions across clusters at the project level, use IAM. You can grant or deny access to specific GKE and Kubernetes API resources using IAM roles and permissions. For instructions, refer toCreate IAM policies. |
| Authorize actions at the cluster level | To authorize actions on Kubernetes API resources in specific clusters, use the built-in Kubernetes role-based access control (RBAC) mechanism. For instructions, refer toAuthorize actions in clusters using RBAC. |
| Authorize actions at the organization level | You can use Google Cloud Organization Policy Service to enforce constraints on specific operations on GKE resources across your Google Cloud organization. For instructions, refer toRestrict actions on GKE resources using custom organization policies. |
Harden clusters and workloads
If you have specialized isolation or hardening requirements beyond thepre-configured Autopilot measures, consider the following resources:
| Use case | Resources |
|---|---|
| Restrict public access to your cluster endpoint | Configure the network isolation of your Autopilot clusters and disable the external endpoint of the cluster control plane. For instructions, refer toConfigure the control plane access. |
| Restrict cluster access to specific networks | Usecontrol plane authorized networks to specify IP address ranges that can access your cluster. |
| Store sensitive information outside your cluster | Storing sensitive data in an external, encrypted storage provider with versioning enabled is a common compliance requirement and a best practice. Use Secret Manager to store your data and access it from your Autopilot clusters using Workload Identity Federation for GKE. For instructions, refer toAccess secrets stored outside GKE clusters using Workload Identity Federation for GKE. |
| Verify container images before deployment to your cluster | Use Binary Authorization to check the integrity of the container images referenced in your Pod manifests at deploy time. For instructions, refer toVerify container images at deploy time using Binary Authorization. |
Monitor your security posture
After setting up your clusters and deploying your workloads, you should set upand configure monitoring and logging so that you have observability over yourcluster security posture. We recommend that you do all of the following:
- Enroll your clusters in theGKE security posture dashboardto audit workloads for concerns such as problematic security configurationsor vulnerabilities in your container operating system packages and getactionable mitigation information.
- Get notified about new security bulletins and upgrade events usingcluster notifications.
- Observe your clusters using theGKE dashboardin Cloud Monitoring or theObservability tab in GKE.
- Learn how toview andmanage yourGKE audit logs in Cloud Logging.
What's next
- Read theGKE security overview.
- Read theGKE hardening guide.
- Subscribe tosecurity bulletins andrelease notes.
Except as otherwise noted, the content of this page is licensed under theCreative Commons Attribution 4.0 License, and code samples are licensed under theApache 2.0 License. For details, see theGoogle Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
Last updated 2026-02-19 UTC.