Service account keys are private keys that let an application authenticate as a service account and use Google Cloud resources. Because these keys can be stolen or leaked, they need regular rotation. The recommended rotation order is: identify the keys to replace, create replacement keys for the same service accounts, deploy the new keys to all applications, disable the old keys, monitor the applications to confirm they still work, and then delete the old keys. A central secret manager such as HashiCorp Vault or a custom notification system can handle the rotation process and reminders.
Rotate keys at least every 90 days. If a key may have been compromised, rotate it immediately. Frequent rotation reduces the risk from leaked credentials because an old key may already be disabled by the time an attacker tries to use it. The safest choice, however, is to avoid service account keys whenever possible and use workload identity federation instead.
Workload identity federation lets a workload authenticate to Google Cloud using an identity from an external identity provider (IdP), such as AWS, Azure, GitHub, or an on-premises system. That external identity is mapped to a Google Cloud service account without creating or storing long-lived private keys. This removes the main risk of a static key being stolen. Workload identity federation is the preferred method for workloads running outside Google Cloud, and it can also be used for workloads on Google Cloud and GKE.
Service accounts should be created for a single purpose, named clearly, and documented so teams can track how they are used. Unused service accounts should be disabled to reduce the risk of abuse. Disable an account before deleting it, because deleting first can remove IAM bindings. The Service Account Insights tool can help identify accounts that have not authenticated in the past 90 days.
Service accounts are non-human identities that let compute workloads and automated tools access Google Cloud resources. Google Cloud creates default service accounts for services such as Compute Engine and App Engine, and these accounts are often granted the basic Editor role across the entire project. That broad access violates the principle of least privilege. Organizations should avoid using default service accounts with broad roles and instead create dedicated user-managed service accounts for each workload.
Apply the organization policy constraint iam.automaticIamGrantsForDefaultServiceAccounts to stop Google Cloud from automatically granting the Editor role to default service accounts when APIs are activated. For projects that already have the grant, use the Policy Simulator to model the impact before removing permissions. Then assign only the fine-grained IAM roles each workload actually needs. For example, Cloud Build pipelines should only have roles needed to compile code and store images, App Engine should use per-version service accounts, and Compute Engine or Cloud Functions workloads should run with custom identities that can access only dependent resources such as BigQuery or Secret Manager. Binding minimal roles directly to dedicated accounts limits the damage if a workload is compromised.
Organizations should use organization policies to block the creation of long-lived service account keys. Instead, workloads should authenticate by service account impersonation and short-lived tokens. To impersonate a service account, the caller needs the iam.serviceAccounts.actAs permission, which is included in the Service Account User role. Inside a virtual machine, guest OS firewall rules should also block low-privilege local accounts from querying the metadata server to steal authentication tokens.
Enable Data Access logs for IAM and Token APIs to record token generation and impersonation events. These events appear in the serviceAccountDelegationInfo field of Cloud Audit Logs, allowing the team to trace actions back to the original user or CI/CD pipeline. Regular audits should find and remove inactive accounts and temporary credentials before they can be exploited.
Use Cloud Audit Logs and Security Command Center to monitor service account activity, including authentication events, API calls, and data access. Create alerts for unusual behavior, such as a dormant service account becoming active or a service account acting outside its normal pattern. Early detection of these patterns helps stop privilege escalation or spoofing attempts. The goal is to see not only what happened, but which identity caused it.
Default service accounts are powerful and can be shared across many resources, which makes them a large attack surface. Organizational policies should restrict or disable default service accounts and block automatic IAM grants that give them broad roles like Editor. Dedicated, single-purpose service accounts should replace them. Organization policy constraints enforce these rules across the entire resource hierarchy, and automated monitoring can detect policy violations.
Remove unused service accounts to reduce the attack surface. The Activity Analyzer can show the last authentication date of a service account, helping teams find inactive accounts. A service account should be disabled and left in place for a period before it is deleted, because deleting and recreating a service account with the same name creates a new identity with different IAM bindings. For default service accounts, verify that nothing depends on them before disabling or deleting them, because recreating them can break services. Finally, review role recommendations to remove unused permissions and keep every service account aligned with least privilege.
Professional Cloud Security Engineer
Gauge your current knowledge
Gauge your current knowledge
StudyCerts
StudyCerts