You plan to deploy your cloud infrastructure using a CI/CD cluster hosted on Compute Engine. You want to minimize the risk of its credentials being stolen by a third party. What should you do?

The best practice for applications running on Compute Engine is to use a service account, not a user account. Service accounts are designed for non-human workloads. To minimize the risk of credential theft, you should prevent the creation of long-lived, user-managed service account keys. The constraints/iam.disableServiceAccountKeyCreation organization policy enforces this at scale. The CI/CD cluster can then use the more secure, automatically rotated credentials provided by the instance metadata server, eliminating the risk of static keys being leaked.

A. User accounts are for humans, not applications. Managing credentials in a self-hosted vault adds unnecessary complexity and risk compared to using attached service accounts.
B. A user account is the wrong identity type for a workload. Disabling service account creation prevents new service accounts but doesn't secure the one in use.
D. This policy relates to extending the lifetime of short-lived credentials, which is not the primary method for preventing the theft of long-lived static keys.

1. Google Cloud Documentation

"Best practices for working with service accounts"

Section: "Use service accounts for applications"

and Section: "Avoid using service account keys". It states

"We strongly recommend that you avoid using service account keys when possible... To further reduce risk

you can disable service account key creation".

2. Google Cloud Documentation

"Organization policy constraints"

Section: "IAM constraints". The description for iam.disableServiceAccountKeyCreation states it "Disables creation of external service account keys."

3. Google Cloud Documentation

"Authenticating workloads"

Section: "Best practices for workload authentication". It recommends using attached service accounts for workloads on Compute Engine.