Professional Cloud Security Engineer

Service Account Provisioning and Lifecycle Management

In Google Cloud, a service account provides an identity for non-human workloads, applications, and virtual machines that need to make authorized API calls. There are three distinct types: default service accounts automatically created by services, user-managed service accounts created manually for specific workloads, and Google-managed service accounts used internally by platform services. Security administrators control these identities by provisioning dedicated, single-purpose accounts rather than relying on shared or generic credentials.

Creating a custom identity requires the Service Account Admin role on the project or resource hierarchy level. When provisioning new accounts, administrators assign clear, descriptive names to define their intended boundaries and specific workloads. Access to these accounts is controlled through allow policies containing role bindings that associate principals with precise IAM permissions.

Service accounts follow a strict lifecycle that moves through enabled, disabled, and deleted states. During employee offboarding or security incident investigations, administrators should switch an account to the disabled state instead of deleting it immediately. Disabling revokes active authentication while preserving configuration, which prevents system outages and allows for auditing. A deleted account has a 30-day recovery window, but recreating an account with an identical name can cause security and permission anomalies.

Service Account Impersonation and Credential Security Governance

Service account impersonation allows an authorized user or workload to assume the identity of a target service account dynamically without using static private keys. The control plane uses the Service Account Credentials API to generate temporary credentials, such as short-lived OAuth 2.0 access tokens and OIDC ID tokens. To grant this ability, administrators assign the Service Account Token Creator role on the target resource. To prevent compromised tokens from refreshing access indefinitely, the system blocks self-impersonation loops.

Organizations eliminate long-lived private keys by using Workload Identity Federation to establish trust between external systems and Google Cloud APIs. This approach allows workloads to exchange external security tokens for temporary Google Cloud credentials:

• Workload Identity for GKE binds Kubernetes service accounts to Google Cloud service accounts to authenticate containerized applications.
• External Identity Federation uses workload identity pools to authenticate resources from external cloud providers such as AWS or Azure.
• Compute Resource Attachment uses the Service Account User role to attach identities directly to virtual machines and serverless workloads.

Security policies should actively prevent the creation of static, user-managed private keys across all projects. Administrators enforce the iam.disableServiceAccountKeyCreation organization policy constraint to stop users from generating downloadable credential files. In addition, the Service Account Key Exposure Response service automatically detects and disables keys that are leaked publicly. When managing legacy keys, administrators should disable the key before permanent deletion to test for operational dependencies.

Granular Authorization and Identity-Resource Dual Role Configuration

A service account functions as both an identity that requests access to resources and a manageable resource that other principals can configure. When treated as an identity, permissions granted on projects or buckets determine what actions the service account can perform. When treated as a resource, IAM permissions granted directly on the service account determine which users can manage, attach, or impersonate it. Failing to separate these two roles can lead to unintended privilege escalation paths.

Certain administrative permissions require strict oversight because they allow users to elevate their own privileges. A principal with the iam.serviceAccounts.setIamPolicy permission can alter allow policies on the service account to grant themselves impersonation rights. Similarly, the iam.serviceAccountKeys.create permission allows principals to generate persistent credentials for any account they can manage. Granting these permissions on a service account that possesses higher privileges than the requesting user creates an immediate security loophole.

Organizations maintain least-privilege guardrails by deploying organization policy constraints across the resource hierarchy:

• iam.disableServiceAccountKeyCreation prevents the generation of static private key files.
• iam.automaticIamGrantsForDefaultServiceAccounts stops the platform from assigning broad Editor roles to default accounts.
• iam.disableServiceAccountCreation centralizes identity creation by blocking unapproved account provisioning.

Security teams can apply these constraints conditionally by using resource tags to grant exceptions without weakening the entire environment. For example, applying an exemption tag to a specific folder allows designated projects to bypass key creation restrictions while the rest of the organization remains protected. When attaching identities to compute resources, administrators enforce the iam.serviceAccounts.actAs permission along with service-specific constraints like appengine.enforceServiceAccountActAsCheck.

Maintaining an audit trail is critical for detecting identity misuse and unauthorized credential requests. Administrators must enable Data Access audit logs for the Security Token Service API and IAM API to track all token minting and impersonation events. When configuring federation pools, mapping the google.subject claim to a non-reusable external identity attribute ensures every API call traces back to a distinct source principal.