Professional Cloud Developer
Service accounts are special identities used by applications, not people, to call Google Cloud APIs. While you can use long-lived service account keys, Google strongly recommends using short-lived credentials for better security. Short-lived tokens, obtained through APIs like the Service Account Credentials API, reduce the risk if a credential is stolen because they expire quickly.
Long-lived user-managed key pairs are a security risk because they can be accidentally leaked in code or files. To protect your project, you should limit how many keys exist and use organization policy constraints to stop new keys from being created. If you must use keys, store them in a secure system and rotate them regularly to limit damage from a leak.
Service account impersonation lets a user or service temporarily act as a service account without needing its physical key. This is useful for testing. For applications running outside Google Cloud, Workload Identity Federation is the best method. It lets external systems exchange their own credentials for short-lived Google Cloud tokens, ensuring the application only gets the minimum set of permissions it needs.
For applications running on Google Cloud resources like Compute Engine or Cloud Run, the most secure method is to attach a service account directly to the resource. The application then uses the built-in Instance Metadata Service to automatically get fresh OAuth 2.0 access tokens. This is secure because Google manages the private keys, which are never exposed to your code, simplifying how your app consumes Google Cloud APIs.
To keep your environment secure, use audit logs to see which identities are accessing resources. Creating a dedicated service account for each application helps you track suspicious activity. You should also monitor for unused keys and delete them. Regularly rotating keys and setting expiry dates are critical steps to limit how long any credential can be used if it is compromised.
Application Default Credentials (ADC) is a system that automatically finds the right credentials for your code to call Google Cloud APIs. For local development, developers can run gcloud auth application-default login to create a local ADC file tied to their user account. This lets you test your application on your computer without handling service account key files. You can also use service account impersonation locally, which allows your user account to temporarily act as a service account to test permissions, provided you have the Service Account Token Creator role.
When your code runs on a managed Google Cloud service, ADC works differently. If a service account is attached to the resource (like a VM or container), ADC automatically queries the metadata server on that resource to get short-lived tokens. This provides secure, automatic access for your production workloads without needing to store any secrets in your application code or configuration files.
ADC looks for credentials in a specific order. First, it checks for the GOOGLE_APPLICATION_CREDENTIALS environment variable, which can point to a service account key file. If that's not set, it looks for local user credentials created by the gcloud CLI. Finally, if the code is running on a Google Cloud resource, it queries the metadata server for the tokens from the attached service account. This sequence allows the same code to work securely in both development and production.
Service accounts are used by applications and are identified by a unique email address. To use one, you attach it to a Google Cloud resource, like a Compute Engine virtual machine or a Kubernetes pod. The application on that resource can then use ADC to automatically get security tokens. Attaching an identity is more secure than using static key files because there are no files to leak.
Once a service account is created, you control what it can do by assigning IAM roles to it. You should follow the principle of least privilege, giving the account only the permissions it absolutely needs. Avoid using broad, default service accounts. Instead, create single-purpose service accounts for different applications and use clear naming conventions to track their use.
An application's access is controlled by two things: IAM permissions and OAuth 2.0 scopes. IAM roles define the actual permissions (like "read this bucket"). Scopes are a legacy method used mainly on VMs to broadly limit what an OAuth token can do. The best practice is to set the VM's access scope to the broad cloud-platform scope and then use precise IAM roles on the service account for fine-grained control.
Service account impersonation is also an authorization tool. It allows a user or another service account to temporarily "become" a service account and use its permissions. This is useful for testing or for administrative tasks, but it must be tightly controlled. By strictly limiting who has the permission to impersonate an account, you prevent privilege escalation and protect your resources.
Prepare and test your skills
Prepare and test your skills
StudyCerts
StudyCerts