Service accounts for applications in GCP - Deep Dive

Overview - Service accounts for applications

What is it?

Service accounts are special accounts used by applications or virtual machines to interact securely with cloud services. They act like digital identities that let applications prove who they are and what they are allowed to do. Instead of using a person's login, applications use service accounts to get access to resources safely. This helps keep cloud environments secure and organized.

Why it matters

Without service accounts, applications would need to use human user credentials, which is risky and hard to manage. This could lead to accidental or malicious access to sensitive data or services. Service accounts solve this by providing controlled, automated access with clear permissions. This keeps cloud systems safer and easier to audit, preventing costly security mistakes.

Where it fits

Before learning about service accounts, you should understand basic cloud concepts like users, permissions, and resources. After mastering service accounts, you can explore advanced topics like Identity and Access Management (IAM) roles, workload identity federation, and secure secret management. Service accounts are a key step in managing cloud security for applications.

Mental Model

Core Idea

A service account is a digital identity that applications use to securely prove who they are and what they can do in the cloud.

Think of it like...

Imagine a service account as a special employee badge given only to robots working in a building. Each robot has a badge that tells the security guards exactly what rooms it can enter and what tasks it can perform, without needing a human to escort it.

┌───────────────────────────────┐
│        Application             │
│  (needs to access cloud)       │
└──────────────┬────────────────┘
               │ uses
               ▼
┌───────────────────────────────┐
│       Service Account          │
│  (digital identity with rights)│
└──────────────┬────────────────┘
               │ authenticates
               ▼
┌───────────────────────────────┐
│       Cloud Services           │
│  (resources with permissions) │
└───────────────────────────────┘

Build-Up - 7 Steps

1

Foundation

What is a service account?

Concept: Introduce the idea of a service account as a non-human identity for applications.

A service account is like a user account but for applications or machines. It lets them access cloud resources securely without using a person's login. Each service account has its own credentials and permissions.

Result

You understand that service accounts are special accounts for apps, not people.

Knowing that service accounts are separate from human users helps prevent mixing personal and automated access, which is key for security.

2

Foundation

Why applications need service accounts

Concept: Explain why applications cannot use human credentials safely and need their own identities.

Applications often need to read data, write logs, or call other services. Using human credentials for this is unsafe because passwords can leak or be misused. Service accounts provide a safer way by giving apps their own identity and limited permissions.

Result

You see why service accounts improve security and automation.

Understanding the risks of using human credentials for apps clarifies why service accounts are essential for cloud security.

3

Intermediate

How permissions work with service accounts

🤔Before reading on: do you think service accounts have all permissions by default or only what you assign? Commit to your answer.

Concept: Service accounts have specific permissions assigned through roles to control what they can do.

In GCP, you assign roles to service accounts that define what actions they can perform. For example, a service account might have permission to read storage buckets but not delete them. This principle is called 'least privilege'—giving only the access needed.

Result

You learn that service accounts are powerful only within their assigned limits.

Knowing that permissions are explicit and limited prevents over-permissioning, which is a common security mistake.

4

Intermediate

Using service accounts with applications

🤔Before reading on: do you think applications store service account keys locally or use built-in cloud features? Commit to your answer.

Concept: Applications use service accounts by authenticating with keys or cloud metadata services to get tokens.

Applications can authenticate using service account keys (files with credentials) or, when running on cloud VMs, use the metadata server to get tokens automatically. This avoids storing sensitive keys in code or files.

Result

You understand how apps securely prove their identity using service accounts.

Knowing the difference between key files and metadata tokens helps choose safer authentication methods.

5

Intermediate

Managing service account keys securely

🤔Before reading on: do you think service account keys should be shared widely or tightly controlled? Commit to your answer.

Concept: Service account keys are sensitive and must be managed carefully to avoid leaks.

Keys are like passwords for service accounts. If leaked, attackers can impersonate the app. Best practice is to avoid long-lived keys, rotate them regularly, and use cloud features like workload identity to reduce key use.

Result

You learn the importance of key security and alternatives to keys.

Understanding key risks drives better security practices and reduces attack surfaces.

6

Advanced

Workload identity federation for service accounts

🤔Before reading on: do you think service accounts can be used outside GCP without keys? Commit to your answer.

Concept: Workload identity federation lets external workloads access GCP service accounts without keys.

Instead of sharing keys, external apps can use identity providers (like AWS or on-premises systems) to get short-lived tokens that GCP trusts. This improves security by avoiding key distribution and supports multi-cloud setups.

Result

You see how service accounts can be used securely beyond GCP environments.

Knowing workload identity federation expands your ability to secure hybrid and multi-cloud applications.

7

Expert

Common pitfalls and advanced best practices

🤔Before reading on: do you think assigning broad roles to service accounts is safe in production? Commit to your answer.

Concept: Experts avoid over-permissioning, use automation for key rotation, and monitor service account usage closely.

In production, giving service accounts only the exact permissions needed prevents damage if compromised. Automating key rotation and auditing usage helps detect misuse early. Also, using workload identity reduces key risks. Ignoring these leads to serious security breaches.

Result

You understand how to manage service accounts securely at scale.

Knowing these advanced practices prevents common security failures and supports compliance.

Under the Hood

Service accounts work by having a unique identity in the cloud IAM system. When an application uses a service account, it authenticates by presenting credentials or tokens. The cloud verifies these credentials and issues access tokens with permissions based on assigned roles. These tokens are then used to call cloud APIs securely. The system uses cryptographic signatures and token expiration to ensure security and prevent misuse.

Why designed this way?

Service accounts were designed to separate human and machine identities to improve security and automation. Early cloud systems used human credentials for everything, which was risky. By creating dedicated identities for applications with fine-grained permissions, cloud providers made it easier to control access and audit usage. Alternatives like sharing user passwords were rejected due to high risk and poor scalability.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│ Application   │──────▶│ Service       │──────▶│ IAM System    │
│ requests token│       │ Account       │       │ verifies and  │
│ from metadata │       │ credentials   │       │ issues token  │
└───────────────┘       └───────────────┘       └───────────────┘
                                   │
                                   ▼
                          ┌─────────────────┐
                          │ Cloud APIs with  │
                          │ access control   │
                          └─────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do service accounts have full access to all cloud resources by default? Commit yes or no.

Common Belief: Service accounts automatically have full access to all cloud resources once created.

Reality: Service accounts have no permissions by default; you must explicitly assign roles to grant access.

Why it matters: Assuming full access leads to security risks if permissions are not carefully assigned and audited.

Quick: Can you safely share service account keys in public code repositories? Commit yes or no.

Common Belief: Service account keys are safe to share because they only allow limited access.

Reality: Service account keys are sensitive credentials; sharing them publicly exposes your cloud resources to attackers.

Why it matters: Leaked keys can lead to unauthorized access, data loss, or cloud resource abuse.

Quick: Do service accounts only work inside the cloud provider's environment? Commit yes or no.

Common Belief: Service accounts can only be used by applications running inside the cloud provider's infrastructure.

Reality: With workload identity federation, service accounts can be used securely by external applications without sharing keys.

Why it matters: Believing this limits secure multi-cloud or hybrid cloud architectures.

Quick: Does deleting a service account immediately revoke all access tokens issued to it? Commit yes or no.

Common Belief: Deleting a service account instantly invalidates all tokens and access granted through it.

Reality: Access tokens may remain valid until they expire; immediate revocation requires additional steps like disabling keys or revoking tokens.

Why it matters: Assuming immediate revocation can cause security gaps if tokens remain active after deletion.

Expert Zone

1

Service accounts can be impersonated by other identities if granted the 'Service Account Token Creator' role, which requires careful control.

2

Using workload identity federation reduces the need for long-lived keys, but requires setting up trust relationships with external identity providers.

3

Audit logs for service account usage are critical for detecting misuse but can be overwhelming without proper filtering and alerting.

When NOT to use

Service accounts are not suitable for human users; use user accounts instead. For short-lived or ephemeral workloads, consider using workload identity federation or OAuth tokens directly. Avoid using service account keys in client-side applications or public environments; use metadata server tokens or workload identity instead.

Production Patterns

In production, teams create multiple service accounts with minimal permissions per application component. They automate key rotation and use monitoring tools to track service account activity. Workload identity federation is increasingly used to integrate on-premises or multi-cloud workloads without key management. Least privilege and separation of duties are enforced through IAM policies.

Connections

Identity and Access Management (IAM)

Service accounts are a type of identity managed by IAM systems.

Understanding IAM helps grasp how service accounts get permissions and how access is controlled in the cloud.

OAuth 2.0 Authentication

Service accounts use OAuth tokens to authenticate and authorize access to cloud APIs.

Knowing OAuth principles clarifies how service accounts securely prove identity without sharing passwords.

Digital Certificates in Public Key Infrastructure (PKI)

Service account keys use cryptographic signatures similar to digital certificates to prove identity.

Recognizing this connection helps understand the security strength behind service account authentication.

Common Pitfalls

#1 Using overly broad permissions for service accounts.

Wrong approach:

gcloud iam service-accounts add-iam-policy-binding [e-mail] --member='allUsers' --role='roles/editor'

Correct approach:

gcloud iam service-accounts add-iam-policy-binding [e-mail] --member='serviceAccount:[e-mail]' --role='roles/storage.objectViewer'

Root cause:

Misunderstanding the principle of least privilege and assigning roles too broadly.

#2 Storing service account keys in public code repositories.

Wrong approach:

Including service-account-key.json file in a public GitHub repo.

Correct approach:

Using environment variables or secret managers to provide credentials securely without committing keys.

Root cause:

Lack of awareness about credential exposure risks and secure secret management.

#3 Using long-lived service account keys instead of metadata tokens.

Wrong approach:

Downloading and distributing JSON key files to all application instances.

Correct approach:

Configuring applications on GCP VMs to use the metadata server for automatic token retrieval.

Root cause:

Not leveraging cloud platform features that reduce key management complexity and risk.

Key Takeaways

Service accounts provide secure, automated identities for applications to access cloud resources without using human credentials.

Assigning minimal permissions to service accounts following the principle of least privilege is critical for security.

Avoid sharing or exposing service account keys; use cloud-native authentication methods like metadata tokens or workload identity federation.

Understanding how service accounts integrate with IAM and OAuth helps manage access and authentication effectively.

Advanced practices like key rotation, auditing, and workload identity federation enhance security and scalability in production.

Practice

1. What is the main purpose of a service account in Google Cloud Platform (GCP)?

easy

A. To allow applications to authenticate and access GCP resources securely

B. To create user accounts for people to log in to GCP Console

C. To store data in Google Cloud Storage buckets

D. To monitor network traffic between virtual machines

Solution

1. Step 1: Understand service account role

   A service account is a special account used by applications or virtual machines to authenticate and access Google Cloud resources securely without user intervention.

2. Step 2: Differentiate from user accounts

   User accounts are for people to log in, while service accounts are for applications or services to act on behalf of users or themselves.

3. Final Answer:

   To allow applications to authenticate and access GCP resources securely -> Option A

4. Quick Check:

   Service account = app authentication [OK]

Hint: Service accounts are for apps, not people [OK]

Common Mistakes:

• Confusing service accounts with user accounts
• Thinking service accounts store data
• Assuming service accounts monitor network

2. Which of the following is the correct way to assign a service account to a Compute Engine VM instance during creation?

easy

A. Use the --service-account flag with gcloud compute instances create

B. Add the service account email to the VM's firewall rules

C. Specify the service account in the VM's startup script

D. Create a user account with the same name as the service account

Solution

1. Step 1: Identify how to assign service accounts to VMs

   The gcloud compute instances create command supports a --service-account flag to specify which service account the VM should use.

2. Step 2: Eliminate incorrect options

   Firewall rules do not assign service accounts, startup scripts do not assign service accounts, and user accounts are unrelated to service account assignment.

3. Final Answer:

   Use the --service-account flag with gcloud compute instances create -> Option A

4. Quick Check:

   Assign service account with --service-account flag [OK]

Hint: Use --service-account flag when creating VM [OK]

Common Mistakes:

• Trying to assign service account via firewall
• Using startup scripts to assign service accounts
• Confusing user accounts with service accounts

3. Consider this Python code snippet using Google Cloud client libraries:

from google.cloud import storage

client = storage.Client()
buckets = list(client.list_buckets())
print(len(buckets))

What must be true for this code to successfully list buckets?

medium

A. The user must be logged in to GCP Console in a browser

B. The environment must have a service account with Storage Viewer role configured

C. The code must run on a VM with no service account assigned

D. No authentication is needed to list buckets

Solution

1. Step 1: Understand authentication requirement

   Google Cloud client libraries require authentication, usually via a service account or user credentials, to access resources like buckets.

2. Step 2: Identify required permissions

   To list buckets, the service account or user must have at least the Storage Viewer role to read bucket metadata.

3. Final Answer:

   The environment must have a service account with Storage Viewer role configured -> Option B

4. Quick Check:

   Service account with Storage Viewer role needed [OK]

Hint: List buckets needs Storage Viewer role on service account [OK]

Common Mistakes:

• Assuming user login in browser is enough
• Running code without any service account
• Thinking no auth is needed for bucket listing

4. You deployed an application on a GCP VM with a service account, but it fails to access Cloud Storage buckets. What is the most likely cause?

medium

A. The service account email is not the same as the VM name

B. The VM does not have an external IP address

C. The application code is missing the Cloud Storage client library import

D. The service account lacks the necessary IAM permissions for Cloud Storage

Solution

1. Step 1: Check service account permissions

   If the application cannot access Cloud Storage, the most common reason is missing IAM permissions on the service account assigned to the VM.

2. Step 2: Rule out other causes

   Lack of external IP does not block access if using private Google access; missing import causes code errors but not permission failures; service account email unrelated to VM name.

3. Final Answer:

   The service account lacks the necessary IAM permissions for Cloud Storage -> Option D

4. Quick Check:

   Missing IAM permissions cause access failure [OK]

Hint: Check IAM roles on service account first [OK]

Common Mistakes:

• Assuming external IP is required for access
• Blaming code imports without error evidence
• Confusing service account email with VM name

5. You want to deploy a serverless application on Cloud Run that accesses a Cloud SQL database securely. Which approach correctly uses a service account to grant least privilege access?

hard

A. Assign the Cloud Run service account the Storage Admin role to access Cloud SQL

B. Use the default Compute Engine service account with Owner role for Cloud Run

C. Create a service account with only Cloud SQL Client role and assign it to the Cloud Run service

D. Create a user account with Cloud SQL Admin role and embed its credentials in the app

Solution

1. Step 1: Identify least privilege principle

   Grant only the permissions needed. For Cloud SQL access, the Cloud SQL Client role is sufficient.

2. Step 2: Assign correct service account to Cloud Run

   Create a dedicated service account with Cloud SQL Client role and assign it to the Cloud Run service to avoid over-permission.

3. Step 3: Eliminate insecure or excessive options

   Using default service account with Owner role is too broad; Storage Admin role is unrelated; embedding user credentials is insecure.

4. Final Answer:

   Create a service account with only Cloud SQL Client role and assign it to the Cloud Run service -> Option C

5. Quick Check:

   Least privilege: Cloud SQL Client role on service account [OK]

Hint: Use least privilege role on dedicated service account [OK]

Common Mistakes:

• Using overly broad Owner role
• Assigning unrelated roles like Storage Admin
• Embedding user credentials in app code