# How to Use Agent Skills for Authenticating to Google Cloud: A Complete Guide

> Learn to authenticate to Google Cloud using Agent Skills and the google-cloud-recipe-auth skill. Securely obtain credentials for local development and production workloads with this comprehensive guide.

- Repository: [Google/skills](https://github.com/google/skills)
- Tags: how-to-guide
- Published: 2026-08-11

---

**Agent Skills provide structured, step-by-step guidance that helps both humans and services obtain secure credentials for Google Cloud through the `google-cloud-recipe-auth` skill, covering authentication flows from local development to production workloads.**

Google's Agent Skills framework offers codified operational knowledge for common cloud tasks. The **"Authenticating to Google Cloud"** skill (`google-cloud-recipe-auth`) in the `google/skills` repository delivers authoritative, actionable guidance for every Google Cloud authentication scenario. This article explains how to leverage this skill to implement secure, production-ready authentication.

## Understanding the Authentication Components

The skill organizes Google Cloud authentication into distinct identity types and credential mechanisms. Each component targets a specific use case, from interactive developer workflows to automated service-to-service calls.

### Human Identity and Interactive Access

For developers and administrators, the skill describes three primary identity sources:

- **Google-Managed Accounts** – Standard Google Cloud Identity or Google Workspace accounts
- **Federation** – SAML or OIDC identity providers integrated with Google Cloud
- **Workforce Identity Federation** – External identity systems without Google-hosted accounts

These options are documented in [`skills/cloud/google-cloud-recipe-auth/SKILL.md`](https://github.com/google/skills/blob/main/skills/cloud/google-cloud-recipe-auth/SKILL.md) lines 42-63, which outline when each identity model fits organizational requirements.

### Google Cloud CLI Authentication

The **gcloud CLI** serves as the primary tool for credential management. The skill provides precise commands for different contexts:

```bash

# Interactive login for human users

gcloud auth login

# Generate Application Default Credentials for client libraries

gcloud auth application-default login

```

These commands appear in lines 70-78 of the skill file, emphasizing that `application-default login` creates the local credential file that Google Cloud client libraries automatically discover.

## Application Default Credentials (ADC)

**ADC** is the foundational mechanism for client library authentication. The skill explains the three-tier lookup order that libraries follow:

1. `GOOGLE_APPLICATION_CREDENTIALS` environment variable pointing to a service account key file
2. Local credentials generated by `gcloud auth application-default login`
3. Attached service account metadata on GCP compute resources (GCE, Cloud Run, GKE, Cloud Functions)

This hierarchy is detailed in lines 16-19 of [`SKILL.md`](https://github.com/google/skills/blob/main/SKILL.md), ensuring zero-code configuration changes when moving from local development to production.

### Python Example: Accessing Cloud Storage with ADC

```python
from google.cloud import storage

# Client automatically discovers credentials via ADC

client = storage.Client()

for bucket in client.list_buckets():
    print(bucket.name)

```

The skill explicitly references this pattern: "Use the Python `storage.Client()` … ADC automatically finds your local credentials" (lines 15-20).

## Service Accounts for Production Workloads

The skill strongly advocates for **attached service accounts** over static key files. This approach eliminates credential management risks and enables automatic credential rotation.

### Cloud Run Service Account Attachment

```yaml
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: my-service
spec:
  template:
    spec:
      serviceAccountName: my-custom-sa@my-project.iam.gserviceaccount.com
      containers:
        - image: gcr.io/my-project/my-image

```

This configuration appears in lines 21-27 of the skill, demonstrating how to bind a custom service account to a serverless workload without embedding credentials.

## Workload Identity Federation

For workloads running outside Google Cloud—AWS, Azure, on-premises, or other clouds—**Workload Identity Federation** enables short-lived token exchange without service account keys.

### Federation Configuration Example

```bash

# Create the workload identity pool

gcloud iam workload-identity-pools create-pool gh-aws-pool \
    --location=global \
    --description="AWS pool"

# Configure the OIDC provider

gcloud iam workload-identity-pools providers create-oidc gh-aws-provider \
    --workload-identity-pool=gh-aws-pool \
    --location=global \
    --issuer-uri="https://sts.amazonaws.com" \
    --allowed-audiences="https://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/gh-aws-pool"

# Exchange external token for GCP access token

gcloud iam workload-identity-pools generate-access-token gh-aws-pool \
    --location=global \
    --service-account=my-sa@my-project.iam.gserviceaccount.com \
    --aws-token=eyJhbGciOi…

```

The skill guides this entire flow in lines 49-53, emphasizing that exchanged tokens are short-lived and require no persistent secrets in the external environment.

## Additional Authentication Patterns

### API Keys for Public APIs

For Google Maps Platform, Vertex AI Express, and other public API surfaces, the skill addresses **API key** usage with security constraints:

- Restrict keys to specific APIs, HTTP referrers, or IP addresses
- Store keys in **Secret Manager** rather than code or environment variables

These recommendations appear in lines 55-68 of [`SKILL.md`](https://github.com/google/skills/blob/main/SKILL.md).

### OAuth 2.0 ID Tokens for Service-to-Service Calls

When services communicate via OIDC, the skill demonstrates generating **ID tokens**:

```bash

# Generate ID token for authenticated service calls

gcloud auth print-identity-token --audiences=https://target-service-url

```

Include this token in the `Authorization: Bearer` header. The skill covers this pattern in lines 29-34.

## Validation and Agent-Guided Implementation

A distinctive feature of Agent Skills is the **validation checklist** (lines 36-50 of [`SKILL.md`](https://github.com/google/skills/blob/main/SKILL.md)). Agents use this structure to ask clarifying questions:

- Is this for human interactive use or automated service authentication?
- What is the runtime environment (local workstation, GCP compute, external cloud)?
- Are there organizational constraints on identity providers?
- What client libraries or API surfaces require access?

These questions ensure the recommended authentication method matches operational requirements before implementation begins.

## Source Files and References

| File | Purpose |
|------|---------|
| [`skills/cloud/google-cloud-recipe-auth/SKILL.md`](https://github.com/google/skills/blob/main/skills/cloud/google-cloud-recipe-auth/SKILL.md) | Core authentication guidance, examples, and validation checklist |
| [`skills/cloud/workload-manager-basics/SKILL.md`](https://github.com/google/skills/blob/main/skills/cloud/workload-manager-basics/SKILL.md) | Supplementary token inspection commands (`gcloud auth print-access-token`) |
| `skills/cloud/google-cloud-recipe-auth/references/` | Linked IAM best-practice documentation |

All files are available in the `google/skills` repository on GitHub.

## Summary

- **Agent Skills codify operational knowledge** – The `google-cloud-recipe-auth` skill provides structured, authoritative guidance for Google Cloud authentication decisions.

- **ADC unifies local and production authentication** – Client libraries automatically discover credentials through a predictable hierarchy, eliminating environment-specific code.

- **Attached service accounts eliminate key management** – Bind identities to compute resources rather than distributing and rotating static keys.

- **Workload Identity Federation extends zero-trust to external clouds** – Exchange external identity tokens for short-lived Google Cloud credentials without cross-cloud secret sharing.

- **Validation checklists guide context-appropriate choices** – Agents use structured questioning to match authentication methods to runtime environments and organizational constraints.

## Frequently Asked Questions

### What is the difference between `gcloud auth login` and `gcloud auth application-default login`?

`gcloud auth login` authenticates the gcloud CLI itself for command-line operations. `gcloud auth application-default login` creates credentials at `~/.config/gcloud/application_default_credentials.json` that Google Cloud client libraries in Python, Java, Go, Node.js, and other languages automatically discover. Use both for local development; use neither in production where attached service accounts or Workload Identity Federation provide credentials without manual steps.

### When should I use Workload Identity Federation instead of service account keys?

Use Workload Identity Federation when workloads run outside Google Cloud—on AWS, Azure, on-premises Kubernetes, or CI/CD platforms like GitHub Actions. Federation exchanges external identity tokens for short-lived Google Cloud access tokens. Service account keys create persistent secrets that must be stored, rotated, and protected; federation eliminates this operational burden and security risk entirely.

### How does an Agent Skill differ from standard documentation?

An Agent Skill provides **structured, machine-parseable guidance** with explicit decision points and validation steps. While traditional documentation describes options, the `google-cloud-recipe-auth` skill in `google/skills` includes a checklist that automated agents use to ask follow-up questions, verify prerequisites, and confirm the selected authentication method matches the user's runtime context. This enables both human learning and automated implementation assistance.

### Can I use API keys for Google Cloud service APIs?

No. According to the skill's guidance in lines 55-68, API keys are restricted to specific public API surfaces like Google Maps Platform and Vertex AI Express. Google Cloud service APIs—Compute Engine, Cloud Storage, BigQuery, Pub/Sub—require OAuth 2.0 or identity-based authentication through ADC, service accounts, or federation. API keys lack the granular IAM controls necessary for production cloud service access.