examples
examples copied to clipboard
Suggest: Leveraging latest default OAuth Access Scopes on GKE Node Pools
While I was going through one of the getting started docs, I stumbled onto a security-related configuration setting with the GKE cluster examples that I think should be addressed so that end users can benefit from a stronger out-of-the-box security posture. GCP's "Compute" OAuth scope is highly powerful when combined with the default compute service account that is by default bound to the very powerful Project Editor IAM role that allows pod-to-cloud VM "escape". See: https://youtu.be/vTgQLzeBfRU?t=1435 but note that instead of using curl/bash, one could have just installed and used gcloud with zero modifications.
Here are the occurrences in this repo: https://github.com/pulumi/examples/search?q=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fcompute
There are two main options for addressing this:
- Leave the default compute service account bound to the "Project Editor" IAM role and bound to the GKE nodepools. "Downscope" the OAuth scopes attached to the node pools to reduce the "scope" of the access from pods/nodes to just the following APIs:
Note: If an application/pod was currently using the default IAM Role and scopes attached to the GKE node instances to hit GCP APIs (like the compute or storage APIs), they will break. However, that can be fixed by leveraging https://cloud.google.com/kubernetes-engine/docs/how-to/hardening-your-cluster#workload_identity to associate GCP SA credentials directly with pods running specific GKE/K8s Service Accounts."oauthScopes": [ "https://www.googleapis.com/auth/devstorage.read_only", "https://www.googleapis.com/auth/logging.write", "https://www.googleapis.com/auth/monitoring", "https://www.googleapis.com/auth/servicecontrol", "https://www.googleapis.com/auth/service.management.readonly", "https://www.googleapis.com/auth/trace.append" ]
- Create a new/dedicated GCP Service Account, associate it instead of the default compute service account to all GKE nodepools, bind the following minimal IAM roles to that service account:
And you then have the ability to use the minimal scopes in option 1 above or specify the "any" scope:- roles/monitoring.viewer - roles/monitoring.metricWriter - roles/logging.logWriter - roles/stackdriver.resourceMetadata.writer
https://www.googleapis.com/auth/cloud-platform
. The minimal scopes are still preferred to reduce accidental permission additions from being effective, however.
Keep up the great work!