I am trying to tighten our security posture. Currently, many of our Compute Engine instances are using the "Default Service Account" with the Editor role, which I know is a huge risk. What is the standard workflow for creating fine-grained custom roles? How do I identify which permissions a service actually needs without breaking the application in production?
3 answers
The best tool for this is the "IAM Recommender" in the Google Cloud Console. It analyzes your service account activity over the last 90 days and suggests smaller, more specific roles based on actual usage. You should create a dedicated service account for each microservice. Instead of the "Editor" role, use "Predefined Roles" like roles/storage.objectViewer or roles/pubsub.publisher. If those are still too broad, create a "Custom Role" and manually add only the specific API permissions required. Always test these in a staging project before applying to production to avoid permission-denied errors.
Have you considered using "Workload Identity" if you are running these on GKE, or are you strictly using standalone Compute Engine VMs?
Always use Service Account Impersonation instead of downloading JSON keys. Keys are a massive liability if they ever get checked into a Git repo.
Exactly, Karen. We actually had a security incident last year due to a leaked JSON key. Switching to impersonation and short-lived tokens saved our team.
Matthew, we are 100% on Compute Engine right now. Does Workload Identity work for VMs, or is that a Kubernetes-only feature? Workload Identity is specifically for GKE. For VMs, you should stick to attaching service accounts directly, but ensure you disable the "Automatic Role Grant" for the default service account at the organization level to prevent future leaks.