Google Kubernetes Engine (GKE) Autopilot clusters enforce various security policies that are designed to prevent many common attack pathways. This document shows platform administrators how to enforce some or all of these Autopilot policies in Standard clusters. You can't disable cluster policy enforcement in Autopilot clusters, because Autopilot clusters are designed for a higher baseline GKE security posture.
In Standard clusters, you can enable and disable specific policies at any time. Organization administrators can control whether specific Autopilot policies can be disabled by enforcing a custom constraint in the organization, folder, or project. You can use these predefined policies to enforce security best practices without needing to write complex RBAC roles and bindings. Many of the cluster-level policies can help you to improve your cluster security even if you aren't interested in using Autopilot mode for the cluster or workloads. For more information about the available Autopilot cluster policies, see the Supported policies section.
Considerations for enforcing Autopilot cluster policies
While Autopilot clusters always enforce these policies, Standard clusters often have existing workloads and node pools that might violate policies that you enforce. Before you enforce or disable a policy in your cluster, read the following considerations:
- Changes apply only to new workloads: when you enable a policy that applies to workloads, the changes apply only to Pods that are created or modified after you enable that policy. Existing Pods that violate the policy can continue to run. Before you enable a policy, review the existing workloads in the cluster to verify that they comply with the policy's constraint.
- Node pool policies apply to all nodes: when you enable a policy that
applies to the node pools in your Standard cluster, the constraints
apply to both new and existing node pools. If an existing node pool violates
the policy, the cluster update operation fails. For example, if you try to
enable the
no-standard-node-poolspolicy in a cluster that has an existing user-managed node pool, your operation fails. Before you enable a node pool policy, review the existing node pools in the cluster. - Enabling all policies enables Autopilot mode: if you enable all of the available Autopilot policies (including the policy that prevents user-managed node pools), then all of the workloads in your cluster can run only in Autopilot mode. This means that all of your workloads must comply with the Autopilot security constraints and with all of the cluster policies. This approach lets you run the entire Standard cluster in Autopilot mode, with the option to disable specific policies when required.
Before you begin
Before you start, make sure that you have performed the following tasks:
- Enable the Google Kubernetes Engine API. Enable Google Kubernetes Engine API
- If you want to use the Google Cloud CLI for this task,
install and then
initialize the
gcloud CLI. If you previously installed the gcloud CLI, get the latest
version by running the
gcloud components updatecommand. Earlier gcloud CLI versions might not support running the commands in this document.
Enable specific Autopilot policies in your cluster
Use the gcloud CLI or the GKE API to enable specific
policies when you create or update a Standard cluster. To add specific
Autopilot cluster policies to the list of policies that
GKE enforces in the cluster, use the
--autopilot-cluster-policies flag with the gcloud container clusters create
command or the gcloud container clusters update command.
The following example shows you how to enable policies in an existing cluster:
gcloud container clusters update CLUSTER_NAME \
--location=CONTROL_PLANE_LOCATION \
--autopilot-cluster-policies=AUTOPILOT_POLICIES
Replace the following:
CLUSTER_NAME: the name of your Standard cluster.CONTROL_PLANE_LOCATION: the region or zone of the cluster control plane, likeus-central1orus-central1-a.AUTOPILOT_POLICIES: a comma-separated list of Autopilot cluster policies to start enforcing in the cluster, such asno-system-mutation,no-system-impersonation. You must specify one or more supported policies. The policies that you specify are appended to the list of policies that GKE already enforces in the cluster. To disable the enforcement of a policy, see the Disable specific Autopilot policies in your cluster section.
If the command fails with an error message that starts with Bad value [invalid
policy]:, verify that all of the policy names that you specified are in the
list of supported policies.
Verify policy enforcement
After you enable a specific policy, you can verify that the enforcement works by
trying to create a resource that violates that policy. For example, if you
enable the no-system-mutation policy, you can try to create a Pod in the
kube-system namespace. GKE blocks the Pod creation operation
and displays an error message that's similar to the following:
Error from server (Forbidden): pods is forbidden: User cannot create resource "pods" in API group "" in the namespace "kube-system": GKE Warden authz [denied by managed-namespaces-limitation]: the namespace "kube-system" is managed and the request's verb "create" is denied
Disable specific Autopilot policies in your cluster
You can disable any of the Autopilot cluster policies at any time.
Disabling a policy is useful in situations where your security requirements have
changed, or when an existing workflow was disrupted when you enabled that
policy. To remove a policy from the list of policies that GKE
enforces in the cluster, use the --remove-autopilot-cluster-policies flag with
the gcloud container clusters update command:
gcloud container clusters update CLUSTER_NAME \
--location=CONTROL_PLANE_LOCATION \
--remove-autopilot-cluster-policies=AUTOPILOT_POLICIES
You must specify at least one value for the
--remove-autopilot-cluster-policies flag. If you specify this flag without a
value, the operation fails.
If the command fails with an error message that starts with Bad value [invalid
policy]:, verify that all of the policy names that you specified are in the
list of supported policies.
Enforce Autopilot cluster policies in organizations
Organization administrators can enforce the use of these cluster policies across
an organization, project, or folder by using
custom organization policy constraints. This additional measure can help
you to prevent unauthorized or unintended removal of required cluster policies
from a cluster. Use the ClusterPolicyConfig field in your custom constraint,
like in the following example:
name: organizations/ORGANIZATION_ID/customConstraints/custom.autopilotClusterPolicies
resourceTypes:
- container.googleapis.com/Cluster
methodTypes:
- CREATE
- UPDATE
condition: "resource.ClusterPolicyConfig.no_system_mutation == true && resource.ClusterPolicyConfig.no_system_impersonation == true"
actionType: ALLOW
displayName: Autopilot policies in Standard clusters.
description: For all new and existing Standard clusters, enable the no_system_mutation and no_system_impersonation Autopilot cluster policies. For more information, see https://docs.cloud.google.com/kubernetes-engine/security/autopilot-cluster-policies-standard.
Supported policies
Each of the Autopilot policies that's available in Standard
clusters implements one or more security best practices at the cluster level.
Policies like no-system-mutation, no-system-impersonation, and
no-unsafe-webhooks help to improve the security of any GKE
cluster, even if you aren't interested in using Autopilot mode.
The following table describes the Autopilot policies that you can enable in Standard clusters and helps you to prepare for policy enforcement:
| Policy name | Description | What to do before enablement |
|---|---|---|
no-system-mutation |
Prevent the creation or modification of resources in GKE
system namespaces (such as kube-system). |
Move your Pods from system namespaces into your own namespaces. |
no-system-impersonation |
Blocks attempts to impersonate system users and prevents the creation of CertificateSigningRequests using system principals. | Look for any unauthorized CertificateSigningRequests that were generated for system identities. If you find any approved unauthorized CertificateSigningRequests, rotate your cluster credentials to invalidate the certificates. |
no-unsafe-webhooks |
Prevents admission webhooks and policies from intercepting critical system
resources such as Node objects, PersistentVolumes, or
CertificateSigningRequests. |
Use the Recommender service to identify webhooks that intercept system resources. If you find any webhooks, modify the webhook configuration. For more information, see Ensure control plane stability when using webhooks. |
no-standard-node-pools |
Prevent any user-managed node pools, including manually created and auto-created node pools, from existing in the cluster. Only Autopilot node pools can exist in the cluster. | Delete all existing non-Autopilot node pools, including the default node pool that was created with the cluster. |
What's next
- Learn more about how to harden your cluster security.
- Learn about the other Autopilot security measures.