Professional Cloud Security Engineer

Managing Service Accounts

Securing and Protecting Service Accounts

Service accounts are special identities that applications and virtual machines use to make API calls to Google Cloud services. Every GCP project comes with a default service account that gets attached to new resources by default, which is a common security risk because it often grants more permissions than the resource actually needs. The core principle for securing service accounts is least privilege: give the account only the permissions required for its specific job, nothing more. Default service accounts should be reviewed and often disabled or replaced with custom service accounts that have narrower roles. Regular audits of which service accounts exist and what roles they hold help catch over-permissioned accounts before they become a problem.

Identifying Scenarios Requiring Service Accounts

A service account is needed whenever code running on a GCP resource must authenticate to use another GCP service. For example, an application running on a Compute Engine VM needs a service account to read from Cloud Storage or write to Cloud SQL. Similarly, a Cloud Function or Kubernetes pod uses a service account to access APIs. The key question to ask is: "Does this resource need to talk to another Google Cloud service on its own behalf?" If yes, a service account is the right tool. External systems or users should not use service accounts; they should use regular user accounts or Workload Identity Federation instead.

Creating, Disabling, and Authorizing Service Accounts

Creating a service account involves giving it a name and an optional description, then assigning it IAM roles that determine what it can do. The authorization step is critical: without roles, the service account cannot access anything, but with the wrong roles it becomes a security risk. When an application no longer needs a service account, the account should be disabled first to stop any ongoing access, then deleted after confirming nothing depends on it. Disabling is safer than deleting because it can be reversed if something breaks. Service accounts can also be granted the ability to be impersonated by other principals, which is useful for administrative tasks but must be controlled carefully.

Securing, Auditing, and Mitigating the Usage of Service Account Keys

Service account keys are downloadable private keys that let anyone authenticate as that service account without needing GCP's normal controls. These keys are a major attack vector because if a key is leaked, an attacker gains whatever permissions the service account holds. Best practice is to avoid downloading keys whenever possible and instead rely on GCP's built-in authentication. When keys are absolutely necessary, they should be stored securely (never in source code or config files), rotated frequently, and never have the Owner role. Cloud Audit Logs track when keys are created, downloaded, or used, which is essential for detecting misuse. If a key is suspected of being compromised, it should be rotated immediately and the old key deleted.

Managing and Creating Short-Lived Credentials

Short-lived credentials are tokens that expire after a short time, typically minutes to hours, rather than lasting indefinitely like a service account key. GCP automatically provides short-lived credentials to resources running as a service account, so code running on a Compute Engine VM can access APIs without handling any keys. These credentials are more secure because they cannot be stolen and used later; if an attacker intercepts a token, it will likely have expired by the time they try to use it. When setting up authentication for applications, prefer the automatic short-lived credentials over manually created keys. For external systems, Workload Identity Federation can provide short-lived tokens without storing any long-lived secrets.

Configuring Workload Identity Federation

Workload Identity Federation lets external identities (such as users or workloads running on other cloud providers, on-premises systems, or CI/CD pipelines) authenticate to GCP services without creating and managing GCP service account keys. Instead, the external system uses its own identity system (like AWS STS, Azure AD, or SAML) to request a token that GCP accepts in exchange for short-lived GCP credentials. This removes the need to download and store GCP service account keys on external systems, which is a significant security improvement. Configuration involves creating a Workload Identity Pool, adding an external identity provider to that pool, and then allowing a GCP service account to be impersonated by members of that pool.

Managing Service Account Impersonation

Service account impersonation allows one principal to temporarily act as a service account, gaining all the permissions that the service account holds. This is useful for administrators who need to debug permissions or for automated systems that need to switch contexts. Impersonation is controlled through IAM policies: a user or service account must be granted the iam.serviceAccountUser role on the target service account to impersonate it. Because impersonation grants full access to the service account's permissions, it should be granted only to principals that genuinely need it and should be audited regularly. Short-lived impersonation tokens can be created that expire quickly, reducing the risk if the token is intercepted.