Service accounts in Google Cloud are special accounts used by applications, virtual machines, and services to authenticate and authorize access to Google Cloud resources. Unlike user accounts, service accounts are not tied to individuals but represent non-human identities that perform automated tas…Service accounts in Google Cloud are special accounts used by applications, virtual machines, and services to authenticate and authorize access to Google Cloud resources. Unlike user accounts, service accounts are not tied to individuals but represent non-human identities that perform automated tasks.
When configuring access and security, service accounts play a crucial role in IAM policies. Each service account has a unique email address format: service-account-name@project-id.iam.gserviceaccount.com. You can assign IAM roles to service accounts just like you would for user accounts.
There are three types of service accounts: default service accounts (created automatically for certain services), user-managed service accounts (created by users for specific purposes), and Google-managed service accounts (created and managed by Google).
To use service accounts in IAM policies, you grant them appropriate roles at various levels - organization, folder, project, or resource level. For example, granting a service account the Storage Object Viewer role on a Cloud Storage bucket allows applications using that service account to read objects from the bucket.
Best practices for using service accounts include: following the principle of least privilege by granting minimal necessary permissions, rotating service account keys regularly when using key-based authentication, using workload identity federation to avoid managing keys, and auditing service account usage through Cloud Audit Logs.
Service accounts can also be impersonated by users or other service accounts when granted the Service Account User or Service Account Token Creator roles. This allows temporary assumption of service account permissions for specific tasks.
You can manage service accounts through the Cloud Console, gcloud CLI, or Cloud IAM API. Monitoring service account activity helps identify unused accounts or excessive permissions that should be revoked to maintain security posture across your cloud environment.
Using Service Accounts in IAM Policies
Why It Is Important
Service accounts are fundamental to Google Cloud security and automation. They enable applications, virtual machines, and other non-human entities to authenticate and interact with GCP services securely. Understanding how to properly configure service accounts within IAM policies is critical for the Associate Cloud Engineer exam and real-world cloud administration.
What Are Service Accounts?
A service account is a special type of Google account that belongs to an application or compute workload rather than an individual user. Service accounts are identified by their email address, which follows the format: service-account-name@project-id.iam.gserviceaccount.com
There are three types of service accounts: - User-managed service accounts: Created by users for specific purposes - Default service accounts: Automatically created when certain services are enabled - Google-managed service accounts: Created and managed by Google for internal processes
How Service Accounts Work in IAM Policies
Service accounts can be used in IAM policies in two primary ways:
1. As an Identity (Principal): Service accounts can be granted roles on resources, allowing the applications using them to access those resources.
2. As a Resource: Users or other service accounts can be granted roles on a service account itself, such as the ability to impersonate it or manage its keys.
Key Concepts:
Service Account Impersonation: Users or service accounts can act as another service account if they have the roles/iam.serviceAccountTokenCreator role.
Service Account User Role: The roles/iam.serviceAccountUser role allows a principal to attach a service account to a resource like a VM instance.
Service Account Keys: Service accounts can authenticate using Google-managed keys or user-managed keys. Google-managed keys are preferred for security.
Workload Identity: For GKE, Workload Identity allows Kubernetes service accounts to act as IAM service accounts, providing a more secure authentication method.
Best Practices
- Follow the principle of least privilege when assigning roles to service accounts - Use separate service accounts for different applications or functions - Avoid using user-managed keys when possible; prefer Google-managed keys - Regularly audit service account permissions and usage - Disable unused service accounts rather than deleting them initially - Use Workload Identity for GKE workloads
Common IAM Roles for Service Accounts
- roles/iam.serviceAccountUser - Attach service accounts to resources - roles/iam.serviceAccountTokenCreator - Impersonate service accounts - roles/iam.serviceAccountAdmin - Full management of service accounts - roles/iam.serviceAccountKeyAdmin - Manage service account keys
Exam Tips: Answering Questions on Using Service Accounts in IAM Policies
1. Understand the difference between granting roles TO a service account versus ON a service account. Questions often test this distinction.
2. Remember the Service Account User role: When a question asks about allowing a user to deploy a VM with a specific service account, the answer typically involves roles/iam.serviceAccountUser.
3. Know the hierarchy: Service accounts belong to projects, but they can be granted access to resources in other projects.
4. Default service accounts: Be aware that Compute Engine and App Engine create default service accounts with Editor role, which is overly permissive for production.
5. Look for security-focused answers: Prefer options that use Google-managed keys, Workload Identity, or impersonation over user-managed keys.
6. Scope matters: When questions mention OAuth scopes on VMs, remember that scopes limit what the attached service account can do, but IAM roles define maximum permissions.
7. Cross-project scenarios: If a service account needs to access resources in another project, the service account must be granted appropriate roles in that target project.
8. Key rotation: For user-managed keys, understand that keys should be rotated regularly and old keys should be deleted.