Professional Cloud DevOps Engineer

Authorization, Impersonation, and Least-Privilege Policy Enforcement

Service accounts are non-human identities used by applications and workloads to securely call Google Cloud services. They should be managed as resources with a defined lifecycle, including using clear naming conventions and disabling or deleting unused accounts identified by tools like Activity Analyzer.

The core security principle is least privilege, meaning each service account should have only the permissions it absolutely needs. Avoid using broad, built-in roles like Owner or Editor. Instead, assign specific predefined roles or create custom ones. A key step is to disable the automatic, overly permissive Editor role granted to default service accounts using organization policies.

For temporary, elevated access, use service account impersonation instead of sharing permanent credentials. This requires granting two specific roles to users or workloads. The Service Account User role allows a user to start a resource (like a VM) using a service account's identity. The Service Account Token Creator role allows a user or workload to generate short-lived access tokens for that service account. For applications in Google Kubernetes Engine, the Workload Identity User role provides a secure way for pods to impersonate service accounts.

Continuous monitoring is essential for security governance. Use Cloud Audit Logs to track all impersonation and token generation events. Tools like IAM Recommender analyze permission usage and suggest safe removals, while Activity Analyzer helps find inactive accounts. Together, these practices create a traceable, least-privilege environment that prevents unauthorized access and lateral movement.

Authentication Security and Key Management Strategies

Service account keys are long-lived credentials that are risky to store and manage. The primary goal is to eliminate their use by migrating to keyless authentication methods. The strategy involves two phases: first, enforce organization policies to prevent new key creation, and second, update existing workloads to use safer alternatives.

To stop new keys from being created, apply the iam.disableServiceAccountKeyCreation organization policy constraint across your resource hierarchy. You can use resource tags to create exceptions for specific projects that still need keys temporarily, allowing a controlled rollout of the policy.

For existing workloads, choose a replacement based on where the code runs. For workloads within Google Cloud (like on Compute Engine or GKE), use the built-in metadata server to get automatic, short-lived credentials. For hybrid or multi-cloud environments (like code in AWS or GitHub Actions), use Workload Identity Federation. This lets applications exchange tokens from other identity providers for short-lived Google Cloud tokens, completely removing the need to store keys.

When keys cannot be avoided, their lifecycle must be strictly controlled. Enforce key expiration with the iam.serviceAccountKeyExpiryHours policy and implement a regular rotation schedule. Furthermore, enable the iam.serviceAccountKeyExposureResponse policy set to DISABLE_KEY. This tells Google Cloud to automatically disable any key it detects has been publicly exposed, limiting the impact of a leak.

Provisioning and Lifecycle Management of Service Accounts

There are three types of service accounts: user-managed (which you create), default (created automatically when you enable services like Compute Engine), and Google-managed (owned and operated by Google). A service account is permanently tied to the project where it was created, which influences how you design your resource hierarchy.

Default service accounts are a security concern because they are automatically granted the powerful Editor role. To mitigate this risk, use the automaticIamGrantsForDefaultServiceAccounts organization policy to block this automatic grant. You can then manually assign these accounts only the specific, minimal permissions they require.

You can control where new service accounts can be created using the iam.disableServiceAccountCreation organization policy. Applying this at the organization or folder level allows you to centralize account management. However, be cautious about applying it at the project level, as it may prevent Google Cloud services from creating the default accounts they need to function.

To manage the high risk of service account keys, use policies like iam.disableServiceAccountKeyCreation and iam.disableServiceAccountKeyUpload. For newer organizations, these are enforced by default. If keys are necessary, use the iam.serviceAccountKeyExpiryHours policy to force them to expire after a set time. Always manage access permissions directly on each service account, not at the project or folder level, to maintain tight security boundaries.

Effective management also involves using tags to apply IAM and organization policies efficiently across many resources. Finally, use Cloud Audit Logs to monitor for high-risk actions, such as granting powerful organization-level admin roles to a service account, which could lead to widespread compromise.