Service Account Authentication and Key Management
Service accounts are special identities used by applications and workloads, not by people. To keep them secure, you should prioritize using short-lived credentials instead of permanent secrets. The preferred method for this is Workload Identity Federation, which lets workloads running on platforms like Google Kubernetes Engine (GKE) or external clouds like AWS use temporary tokens. This approach removes the need for static service account keys, which are a major security risk because they do not expire and can be easily leaked.
You should create single-purpose service accounts for each unique application, following the principle of least privilege. This means each account gets only the permissions it needs to perform its specific job, which limits the damage if an account is compromised. Using clear naming conventions helps you track which account belongs to which service. If you must use a service account key, it should be stored very securely and rotated frequently.
Regularly auditing your environment is necessary to find and remove unused service accounts. Tools like the Activity Analyzer can identify accounts that have not been used recently. It is a best practice to disable an account first before deleting it, which provides a safety period to ensure no critical processes are interrupted.
Application of the Principle of Least Privilege
Applying the principle of least privilege means granting only the minimum permissions a service account needs to function. You do this by using Identity and Access Management (IAM) roles, which are bundles of permissions. You should choose between predefined roles (created and managed by Google) and custom roles (which you create from specific permissions) for precise control. Avoid using broad basic roles like Editor or Owner, as they often grant far more access than an application needs.
A key strategy is to create user-managed service accounts designed for a single purpose, rather than relying on the default service accounts Google Cloud may create automatically. Default accounts often have high-level permissions and are riskier. Managing accounts as individual resources ensures their lifecycle matches the application they support. You should also use clear naming conventions and enable audit logging to track which identities are performing actions.
To keep permissions tight over time, you can use the IAM Recommender. This tool uses machine learning to find permissions that a service account is not using and suggests removing them. Regularly reviewing these recommendations prevents permission creep as your application evolves. To deploy a service account, a person needs the Service Account User role, which allows them to attach the service account to a resource like a virtual machine.
Resource Hierarchy and Policy Inheritance
The Google Cloud resource hierarchy organizes your resources in a tree: Organization at the top, then Folders, then Projects, and finally individual resources like a VM or a storage bucket. IAM policies set at a higher level, like a folder, are automatically inherited by all the child resources below it. This structure makes it easy to manage security broadly, but you must be careful to avoid granting over-privileged access across many projects.
To prevent over-privileged access, you should implement granular role bindings at the most specific resource level possible. Instead of granting a powerful role at the organization level, grant a more limited role directly to the specific project or resource where it is needed. This practice follows the principle of least privilege and ensures that a compromised service account can only affect a limited part of your environment.
Service account impersonation is a useful technique that allows a user or another service account to temporarily act as a service account. This is safer than using long-lived keys and is often used with Workload Identity Federation for workloads outside of Google Cloud. You can manage all these permissions and review your setup using the Google Cloud console or the gcloud command-line tool. Regularly auditing your resource hierarchy and checking audit logs helps ensure that inheritance has not accidentally granted too much power.