Service Accounts & Security

Introduction to Service Account Management

In the complex ecosystem of Google Cloud, not every user is a human being. Applications, virtual machines (VMs), and automated scripts also require identities to access resources securely. This is where Service Account Management becomes a critical skill for any Associate Cloud Engineer (ACE). A service account is a special type of Google account that belongs to your application or a workload rather than an individual end-user.

Understanding Service Account Management is essential for the ACE exam because it forms the backbone of non-human identity and access management (IAM). Unlike human users who authenticate with passwords and multi-factor authentication, service accounts use cryptographic keys and tokens. Proper Service Account Management ensures that your automated processes have the exact permissions they need—no more, no less—adhering to the principle of least privilege.

Throughout this guide, we will explore the dual nature of service accounts, the different types of service accounts available, and the best practices for Service Account Management to keep your cloud environment secure.

白話文解釋（Plain English Explanation）

To better understand Service Account Management, let's look at three analogies from different categories.

1. The Key Card (Key Card Analogy)

Imagine a high-security office building. While employees have their own badges, the cleaning crew uses a generic Key Card to enter at night.

• The Service Account is the Key Card itself. It isn't tied to a specific person's name but to the "Cleaning Task."
• Service Account Management is like the security manager deciding which floors the card can access.
• If a new cleaner starts, they don't get a new name in the system; they just pick up the existing Key Card.

2. The Courier Service (Courier Analogy)

Think of a Service Account as a Courier for a large company.

• The company needs to send a package (data) from the Warehouse (Cloud Storage) to the Office (Compute Engine).
• The Courier doesn't need to know the CEO's password. They just need a specific ID badge that says "Authorized for Warehouse Entry."
• Service Account Management ensures the courier can only enter the warehouse and the office, but not the accounting department.

3. The Swiss Army Knife (Swiss Army Knife Analogy)

Consider a Service Account as a Swiss Army Knife kept in a shared toolbox.

• Different projects (applications) use this tool to perform specific tasks, like opening a bottle or cutting a wire.
• You don't ask the knife who is using it; you just ensure the knife is sharp and stored safely.
• Service Account Management involves deciding which "blades" (permissions) are included in this specific knife and who has the key to the toolbox (the serviceAccountUser role).

The Dual Nature of Service Accounts

A unique aspect of Service Account Management is understanding that a service account is both an identity and a resource.

As an Identity

When used as an identity, the service account is assigned IAM roles. For example, you might give a service account the roles/storage.objectViewer role so it can read files from a bucket. In this scenario, the service account is the "Who" in the IAM policy.

As a Resource

Because a service account is a resource within a project, you can control who has permission to manage or use it. For instance, you might grant a developer the roles/iam.serviceAccountUser role on a specific service account. This allows the developer to attach that service account to a VM. In this case, the service account is the "Which" (the resource) being acted upon.

Creating and Managing Service Accounts

Effective Service Account Management starts with knowing how to create and organize these identities.

Types of Service Accounts

1. User-managed Service Accounts: These are accounts you create yourself for specific applications. You have full control over their permissions and lifecycle.
2. Default Service Accounts: Google automatically creates these when you enable certain services (e.g., the Compute Engine default service account). They often come with broad permissions, so modern Service Account Management suggests replacing them with custom ones.
3. Google-managed Service Accounts: These are used by Google services to perform actions on your behalf (e.g., the Cloud Build service account). You cannot directly modify these, but you can see them in your IAM console.

Naming Conventions

Always use descriptive names. Instead of sa-1, use web-app-prod-logger. This makes Service Account Management much easier when auditing logs later.

Assigning Service Account Permissions

In Service Account Management, permissions are granted through IAM roles.

The Best Practice: Predefined Roles

Avoid using primitive roles (Owner, Editor, Viewer) for service accounts. Instead, use predefined roles that offer granular access, such as roles/pubsub.publisher or roles/bigquery.dataEditor.

Granting the serviceAccountUser Role

To allow a person or another service account to use a service account, you must grant them the roles/iam.serviceAccountUser role. Without this, even a Project Editor cannot attach a service account to a Compute Engine instance.

Service Account Keys: The Good, The Bad, and The Dangerous

A critical part of Service Account Management is handling keys. Service accounts can use two types of keys:

User-managed Keys

These are the JSON or P12 files you download.

Google-managed Keys

Google handles the creation, rotation, and storage of these keys automatically. When you run code on GCP infrastructure (like App Engine or GCE), the system uses these keys behind the scenes. This is the gold standard of Service Account Management.

Service Account Impersonation: The Secure Alternative

Why download a dangerous key when you can just "act as" the service account? This is called Service Account Impersonation.

How Impersonation Works

A user with the roles/iam.serviceAccountTokenCreator role can request short-lived credentials for a service account. This eliminates the need for long-lived JSON keys.

Benefits for Service Account Management

• Security: No files to lose or leak.
• Auditability: Logs show who requested the token and what they did with it.
• Efficiency: Credentials expire automatically, reducing the management overhead.

Service Account Scopes vs. IAM Roles

This is a frequent topic on the ACE exam. Scopes are a legacy method of controlling VM permissions.

• Scopes: Defined at the time a VM is created. They limit the "range" of what the VM can do (e.g., https://www.googleapis.com/auth/cloud-platform).
• IAM Roles: The modern way to define "what" the identity can do.

Workload Identity for GKE

For Kubernetes users, Service Account Management is handled through Workload Identity.

The Problem with Node Keys

In older setups, every Pod on a GKE node shared the same service account. This violated the principle of least privilege.

The Workload Identity Solution

Workload Identity allows you to bind a Kubernetes Service Account (KSA) to a Google Service Account (GSA). This ensures that each Pod has its own identity and specific permissions, significantly improving the security of your Service Account Management in containerized environments.

Using gcloud for Service Account Management

As an ACE, you must be comfortable with the command line.

Creating a Service Account

gcloud iam service-accounts create my-backend-sa \
    --display-name="Backend Processing Service Account"

Listing Service Accounts

gcloud iam service-accounts list

Granting Access to a Service Account

gcloud projects add-iam-policy-binding my-project-id \
    --member="serviceAccount:[email protected]" \
    --role="roles/storage.objectViewer"

Best Practices for Service Account Management

To maintain a secure cloud environment, follow these high-level Service Account Management principles:

1. Delete Unused Accounts: Regularly audit your project and remove service accounts that are no longer needed.
2. Rotate Keys Regularly: If you MUST use user-managed keys, rotate them every 90 days or less.
3. Limit Key Creation: Use Organization Policies to prevent users from creating service account keys altogether.
4. Use Audit Logs: Monitor Data Access Logs to see how service accounts are interacting with your data.

Troubleshooting Service Account Access

When a service account can't access a resource, check these three things in your Service Account Management workflow:

1. Hierarchy: Is the role granted at the correct level (Project vs. Bucket)?
2. Inheritance: Is there a Deny Policy at the Organization level blocking the access?
3. Activation: If the service account is attached to a VM, has the VM been restarted to pick up new permissions?

Common Exam Scenarios for ACE

Scenario 1: Developing Locally

"You are developing an application on your laptop that needs to access Cloud Pub/Sub. How should you authenticate?"

• Answer: Use gcloud auth application-default login to use your own credentials during development, or use service account impersonation. Avoid downloading a JSON key.

Scenario 2: VM Permissions

"A script on a VM needs to upload logs to a bucket but is receiving a 403 Forbidden error."

• Answer: Check if the service account attached to the VM has the roles/storage.objectCreator role. Also, check if the VM's access scopes allow "Storage" access.

Scenario 3: Cross-Project Access

"An application in Project A needs to read a database in Project B."

• Answer: In Project B, grant the Service Account from Project A the necessary IAM role. You don't need to move the service account.

FAQ

Q1: Can I change the email address of a service account? A: No. Once created, the email is permanent. You must delete and recreate the account if the name needs to change.

Q2: What is the limit on the number of service accounts per project? A: By default, you can have up to 100 service accounts per project, but this can be increased by requesting a quota increase.

Q3: Does deleting a project delete the service accounts inside it? A: Yes. All resources, including service accounts, are removed when a project is deleted.

Q4: Can a service account be a member of a Google Group? A: Yes! This is a great way to manage permissions for multiple service accounts at once.

Q5: What is a 'Short-lived' credential? A: It is a token (OAuth2 or ID token) that usually lasts for 1 hour, significantly reducing the window of opportunity for an attacker.

Summary Checklist for ACE

• Understand that service accounts are both identities and resources.
• Know the difference between User-managed, Default, and Google-managed accounts.
• Identify the security risks associated with Service Account Keys.
• Explain the benefits of Service Account Impersonation.
• Distinguish between IAM Roles and Access Scopes.
• Remember the gcloud commands for creating and binding service accounts.
• Apply the Principle of Least Privilege to all service account roles.