Service accounts in Google Cloud are special accounts used by applications, virtual machines, and other resources to authenticate and interact with Google Cloud APIs. Unlike user accounts, service accounts are designed for non-human entities and provide a secure way to manage permissions programmat…Service accounts in Google Cloud are special accounts used by applications, virtual machines, and other resources to authenticate and interact with Google Cloud APIs. Unlike user accounts, service accounts are designed for non-human entities and provide a secure way to manage permissions programmatically.
When assigning service accounts to resources, you establish an identity that the resource uses to access other Google Cloud services. This is fundamental for implementing the principle of least privilege, where each resource receives only the permissions necessary for its function.
To assign a service account to a Compute Engine VM instance, you can specify it during creation using the Console, gcloud CLI, or API. Using gcloud, the command includes the --service-account flag followed by the service account email. For existing instances, you must stop the VM before changing its service account.
For GKE workloads, you can use Workload Identity to link Kubernetes service accounts to Google Cloud service accounts, enabling pods to authenticate securely. This approach is preferred over storing service account keys.
Cloud Functions, Cloud Run, and App Engine services also support custom service account assignment. During deployment, you specify which service account the service should use for authentication when calling other APIs.
Key considerations when assigning service accounts include:
1. Access Scopes - For Compute Engine, you can limit OAuth scopes even if the service account has broader IAM permissions
2. Default Service Accounts - Google Cloud creates default service accounts automatically, but creating custom ones with specific permissions is recommended for production
3. Cross-Project Access - Service accounts can be granted permissions in other projects, enabling secure cross-project resource access
4. Impersonation - Users or other service accounts can impersonate a service account if granted the Service Account Token Creator role
Properly configuring service account assignments ensures your resources can securely communicate while maintaining strong access controls and auditability across your cloud environment.
Assigning Service Accounts to Resources
Why It Is Important
Service accounts are fundamental to Google Cloud Platform's security model. They enable resources like Compute Engine instances, Cloud Functions, and App Engine applications to authenticate and interact with other GCP services securely. Proper assignment of service accounts ensures that resources have the appropriate permissions to perform their tasks while following the principle of least privilege.
What It Is
A service account is a special type of Google account that belongs to an application or virtual machine rather than an individual user. When you assign a service account to a resource, that resource assumes the identity and permissions of the service account when making API calls to other GCP services.
There are three types of service accounts: - Default service accounts: Automatically created when you enable certain APIs - User-managed service accounts: Created by users for specific purposes - Google-managed service accounts: Created and managed by Google for internal processes
How It Works
1. Creating a Service Account: Navigate to IAM & Admin > Service Accounts, or use gcloud commands: gcloud iam service-accounts create [NAME] --display-name [DISPLAY_NAME]
2. Granting Roles to the Service Account: Assign appropriate IAM roles that define what the service account can do: gcloud projects add-iam-policy-binding [PROJECT_ID] --member serviceAccount:[SA_EMAIL] --role [ROLE]
3. Assigning to Resources: - Compute Engine: Specify during instance creation or change on a stopped instance - Cloud Functions: Set during deployment - App Engine: Configure in app.yaml or through Console - GKE: Use Workload Identity for pod-level service account binding
4. Access Scopes: For Compute Engine, access scopes work alongside IAM roles. Best practice is to set full cloud-platform scope and control access through IAM roles.
Key Concepts to Remember
- Service accounts use keys or metadata server for authentication - Resources can only have ONE service account attached at a time - Changing service accounts on Compute Engine requires stopping the instance first - Default service accounts often have overly permissive Editor role - Custom service accounts with minimal permissions are recommended
Exam Tips: Answering Questions on Assigning Service Accounts to Resources
1. Principle of Least Privilege: Always choose answers that involve creating custom service accounts with minimal required permissions rather than using default service accounts.
2. Know the Attachment Process: Remember that Compute Engine instances must be stopped to change their service account. This is a common exam topic.
3. Understand Scope vs. IAM Roles: Access scopes are legacy and act as an additional limit. IAM roles are the primary permission mechanism. When both are mentioned, IAM roles take precedence in determining effective permissions.
4. Cross-Project Access: Service accounts can be granted permissions in other projects. Look for scenarios requiring resources in one project to access resources in another.
5. Service Account Impersonation: Understand that users can be granted the Service Account User role to impersonate a service account, which is useful for testing and deployment scenarios.
6. Default vs. Custom: Questions often test whether you know that default service accounts should be replaced with custom ones for production workloads.
7. Workload Identity for GKE: For Kubernetes-related questions, Workload Identity is the recommended approach for assigning Google service accounts to Kubernetes pods.
8. Key Management: Prefer attached service accounts over downloaded keys. Using the metadata server is more secure than managing key files.