GCP Service Accounts Automation: Create & Manage for CI/CD

Setting up automation in Google Cloud can sound tricky, but it doesn’t have to be. In this guide, you’ll learn how to create and manage GCP service accounts for automation – the safe way. We’ll walk through step-by-step setup for CI/CD pipelines, explain why secure keys matter, and explore modern tools like Workload Identity Federation to keep your system both efficient and secure.

What is a GCP Service Account?

Think of a GCP service account as a robot user that helps your programs talk to Google Cloud – safely and automatically. Instead of a person logging in, a service account lets tools, scripts, or pipelines (like CI/CD systems, cron jobs, or APIs) access resources securely. These accounts handle the behind-the-scenes work, such as deploying apps or storing data.

In automation, they’re essential – but come with a key choice:

• Key-based access offers flexibility but adds security risks if keys leak.
• Identity Federation removes keys entirely for a safer, modern approach.

When to Use Service Accounts vs. Workload Identity Federation

There are two main ways to let your automation tools talk to Google Cloud securely.

(A) Service Accounts with Keys:
This is the classic method – you create a service account and download a private key (JSON file). It’s simple and works well for local scripts or small projects. But keys can get lost, shared, or leaked, which makes them a security risk if not managed carefully.

(B) Workload Identity Federation (WIF):
This newer, keyless approach lets your system (like GitHub Actions or AWS) authenticate to Google Cloud using short-lived credentials instead of static keys. It’s safer, scales better, and follows Google’s zero-trust model.

Recommendation: Use Workload Identity Federation for most CI/CD and automation workflows. It removes key management hassles and keeps your security posture strong.

How to Create a Service Account (Step-by-Step)

Creating a service account in Google Cloud is simple – and you can do it in three main ways: through the Console (UI), using the gcloud command line, or with Terraform for automation. No matter the method, remember: each service account should have one clear purpose and only the permissions it needs.

1. Create via Google Cloud Console (UI)

The easiest method for beginners.

1. Go to IAM & Admin → Service Accounts in your Google Cloud Console.
2. Click “Create Service Account.”
3. Enter a name like ci-cd-deployer and add a short description.
4. Assign the least privilege role – for example, Storage Object Viewer or Compute Admin, only if required.
5. (Optional) Grant users access to this service account.
6. Click Done.

Tip: Don’t give full “Owner” access unless absolutely necessary.

2. Create via gcloud CLI (for developers)

You can automate creation using a command like this:

gcloud iam service-accounts create ci-cd-deployer \
--description="Service account for CI/CD pipeline" \
--display-name="CI/CD Deployer"

Then attach a role (for example, Storage Admin) with:

gcloud projects add-iam-policy-binding PROJECT_ID \
--member="serviceAccount:ci-cd-deployer@PROJECT_ID.iam.gserviceaccount.com" \
--role="roles/storage.admin"

This method is great for scripting and repeatable setups.

3. Create via Terraform (for automation)

For large teams or DevOps pipelines, Terraform is ideal.

resource "google_service_account" "cicd" {
account_id = "ci-cd-deployer"
display_name = "CI/CD Deployer"
description = "Service account for CI/CD automation"
}

You can also attach roles using the google_project_iam_member resource.

Tip: Store your Terraform state securely and version control your configs.

Managing Keys and Safer Alternatives (Rotate, Store Securely)

Service account keys are powerful – and risky if not handled correctly. Think of them like “master keys” to your cloud house. If someone else gets them, they can unlock everything.

Google Cloud gives you two key types:

• Google-managed keys – automatically rotated and more secure.
• User-managed keys – you create and download them manually (riskier if lost or leaked).

If you must use user-managed keys, follow these rules:

1. Rotate keys regularly – ideally every 90 days or less. Delete old or unused keys quickly.
2. Store keys securely – use Secret Manager, HashiCorp Vault, or another encrypted vault. Never upload keys to GitHub, repos, or shared drives.
3. Use IAM conditions – limit where and how the service account can be used (e.g., restrict to certain IPs or services).
4. Monitor key usage – enable audit logs to track when and where your keys are used.

Better Alternative: Avoid long-lived keys completely. Instead, use Workload Identity Federation, which allows short-lived credentials and removes the need for key storage.

By rotating, restricting, and monitoring keys – or better, going keyless – you keep automation safe while reducing your cloud security risks.

(Source: Google Cloud – Best Practices for Managing Service Account Keys)

Best Practices for Automation & CI/CD

When you build automation or CI/CD pipelines in Google Cloud, service accounts act as the “robots” that perform deployments, builds, or API calls. To keep your setup secure and reliable, follow these key best practices:

1. Create one service account per pipeline or purpose – This limits the blast radius if credentials are compromised.
2. Use the principle of least privilege – Assign only the exact roles your automation needs (for example, roles/storage.objectAdmin instead of Owner).
3. Avoid using default service accounts – These often have overly broad permissions and pose security risks.
4. Use Workload Identity Federation – For GKE, Cloud Build, or GitHub Actions, this lets your workloads get temporary credentials without storing keys.
5. Audit your service accounts regularly – Review IAM policies, check logs for unusual activity, and disable unused accounts immediately.
6. Rotate permissions with environment changes – As your project grows, recheck roles to match current tasks only.

Example:
A Cloud Build pipeline can use Workload Identity Federation to deploy to GKE. Instead of storing a JSON key, Cloud Build temporarily “impersonates” a service account, ensuring safer and fully automated authentication.

Following these practices keeps your automation clean, secure, and ready for scale – without the risk of leaking long-lived credentials.

(Source: Google Cloud Documentation – Best Practices for Using Service Accounts in Automation and CI/CD)

Automation Examples (Mini-Code Snippets)

Let’s see how to automate GCP service account creation and usage using three simple tools – gcloud, Terraform, and Python. These examples are short and practical so you can copy and adapt them to your own setup.

1. Using gcloud (Command Line)

# Create a service account
gcloud iam service-accounts create ci-cd-bot \
--display-name="CI/CD Automation Bot"

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

Good for quick setup or scripting automation steps.
Docs: Create service accounts | Google Cloud

2. Using Terraform (Infrastructure as Code)

resource "google_service_account" "ci_cd_bot" {
account_id = "ci-cd-bot"
display_name = "CI/CD Automation Bot"
}

resource “google_project_iam_member” “ci_cd_storage” {
project = “my-project-id”
role = “roles/storage.admin”
member = “serviceAccount:${google_service_account.ci_cd_bot.email}”
}

Great for repeatable, version-controlled setups.

3. Using Python (Short-Lived Token via IAMCredentials API)

from Google.cloud import iam_credentials_v1

client = iam_credentials_v1.IAMCredentialsClient()
name = “projects/-/serviceAccounts/[email protected]”

token = client.generate_access_token(
name=name,
scope=[“https://www.googleapis.com/auth/cloud-platform”]
)
print(“Token:”, token.access_token)

Best for automation pipelines that need temporary credentials – no key files required!

These examples show how easily you can automate service account creation, role binding, and secure authentication using Google Cloud tools.

(Source: Google Cloud Documentation – IAM Client Libraries & Terraform Provider)

Audit, Rotate, and Clean-Up Checklist

Keeping your GCP service accounts secure is not a one-time job – it’s an ongoing habit. Here’s a quick checklist to help you audit, rotate, and clean up safely and efficiently:

•  Use clear names – follow a naming rule like team-purpose-env (e.g., ci-build-prod) and document every account.
•  One job per service account – don’t reuse the same account for multiple apps or teams.
•  Rotate keys regularly – change user-managed keys every 90 days or less.
•  Restrict key creation – apply an Org Policy to limit who can make or download keys.
•  Audit usage logs – review which services and users are using each service account monthly.
•  Disable or delete unused accounts – remove stale service accounts to reduce attack risk.
•  Monitor IAM roles – ensure each account only has the permissions it truly needs.
•  Review secrets storage – keep keys in Secret Manager or Vault, never in code repos.

 Tip: Download Technik Go’s free GCP Service Account Audit Checklist to make this routine easy!

(Source: Google Cloud Documentation – Best Practices for Managing Service Account Keys)

Troubleshooting & Common Pitfalls

Even skilled teams hit bumps when managing GCP service accounts. Here are some quick tips to fix the most common problems:

Quota limits

You can only create a certain number of service accounts and keys per project.
 Fix: Delete old or unused accounts, or request a quota increase in Google Cloud Console.

Wrong IAM role or scope

If your automation fails, it’s often due to missing or overly broad permissions.
 Fix: Check IAM policy bindings and grant only the needed roles (principle of least privilege).

Leaked keys

Exposed keys in GitHub or scripts are a major risk.
 Fix: Revoke and rotate the key immediately, and scan your repos for credentials.

Default service account overuse

Using default accounts gives too much access.
 Fix: Disable default service accounts and create purpose-built ones for each task.

Impersonation missing

If impersonation calls fail, the caller might lack roles/iam.serviceAccountTokenCreator.
 Fix: Add this specific role and check Audit Logs for denied actions.

(Sources: Google Cloud Documentation, Stack Overflow discussions, Datadog Security Blog)