Protecting cluster metadata

Standard

---

Google Kubernetes Engine (GKE) uses instance metadata to configure node virtual machines (VMs), but some of this metadata is potentially sensitive and should be protected from workloads running on the cluster.

Before you begin

Before you start, make sure 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 gcloud components update.
  Note: For existing gcloud CLI installations, make sure to set the compute/region and compute/zone properties. By setting default locations, you can avoid errors in gcloud CLI like the following: One of [--zone, --region] must be supplied: Please specify location.

Configure node service account

Each node's service account credentials continue to be exposed to workloads. By default, your nodes use the Compute Engine default service account. You should configure a minimally-privileged service account for your nodes to use instead of the Compute Engine default service account. Then, attach this service account to your nodes, so that an attacker cannot circumvent GKE metadata protections by using the Compute Engine API to access the underlying VM instances directly.

For more information, refer to Use least privilege node service accounts.

Caution: Do not use a service account that has compute.instances.get permission, the Compute Instance Admin role, or other similar permissions, as they allow potential attackers to obtain instance metadata using the Compute Engine API. Restrict the permissions of a node VM by using service account permissions, not access scopes. For more information, see Migrating from legacy access scopes.

To create a minimally privileged node service account, perform the following steps:

1. Create a new Identity and Access Management (IAM) service account and save the email address in an environment variable:

   gcloud iam service-accounts create NODE_SA_NAME \
       --display-name="DISPLAY_NAME"
   export NODE_SA_EMAIL=$(gcloud iam service-accounts list --format='value(email)' \
       --filter='displayName:DISPLAY_NAME')
   

   Replace the following:

   • NODE_SA_NAME: the name of your new node service account.
   • DISPLAY_NAME: the display name of the new service account.

   The node service account email address has the format NODE_SA_NAME@PROJECT_ID.iam.gserviceaccount.com.

2. Configure your service account with the minimum roles and permissions to run your GKE nodes:

   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member=serviceAccount:$NODE_SA_EMAIL \
       --role=roles/monitoring.metricWriter
   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member=serviceAccount:$NODE_SA_EMAIL \
       --role=roles/monitoring.viewer
   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member=serviceAccount:$NODE_SA_EMAIL \
       --role=roles/logging.logWriter
   

   Replace PROJECT_ID with your Google Cloud project ID.

   Additionally, if your cluster pulls private images from Artifact Registry, add the roles/artifactregistry.reader role:

   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member=serviceAccount:$NODE_SA_EMAIL \
       --role=roles/artifactregistry.reader
   

Metadata concealment

Warning: Workload Identity Federation for GKE replaces the need to use metadata concealment and the two approaches are incompatible. We recommend that you use Workload Identity Federation for GKE instead of metadata concealment.

Beta

This product or feature is subject to the "Pre-GA Offerings Terms" in the General Service Terms section of the Service Specific Terms. Pre-GA products and features are available "as is" and might have limited support. For more information, see the launch stage descriptions.

GKE metadata concealment prevents user Pods from accessing kube-env, which contains kubelet credentials, and the VM's instance identity token.

Metadata concealment firewalls traffic from user Pods (Pods not running on HostNetwork) to the cluster metadata server, only allowing safe queries. The firewall prevents user Pods from using kubelet credentials for privilege escalation attacks, or from using VM identity for instance escalation attacks.

Workload Identity Federation for GKE replaces the need to use metadata concealment and expands on the protections that metadata concealment offers. You should use Workload Identity Federation for GKE instead of metadata concealment in all situations. To learn more, see About Workload Identity Federation for GKE.

To enable metadata concealment, use the deprecated --workload-metadata=SECURE option in your gcloud beta container clusters create command or in your gcloud beta container node-pools create command.

Limitations

Metadata concealment has limitations such as the following:

• Metadata concealment only protects access to kube-env and the node's instance identity token.
• Metadata concealment does not restrict access to the node's service account.
• Metadata concealment does not restrict access to other related instance metadata.
• Metadata concealment does not restrict access to other legacy metadata APIs.
• Metadata concealment doesn't restrict traffic from Pods running on the host network (hostNetwork: true in the Pod specification).

Disabling and transitioning from legacy metadata APIs

The v0.1 and v1beta1 Compute Engine metadata server endpoints were deprecated and shutdown on September 30, 2020.

For the shutdown schedule, refer to v0.1 and v1beta1 metadata server endpoints deprecation.

What's next

• Enable Workload Identity Federation for GKE on your clusters.