GCP Connector: Application Default Credentials Access

The GCP connector authenticates to Google Cloud APIs using Application Default Credentials (ADC) and enforces a per-operation IAM permission check before attaching any token. The GKE connector registers alongside it, sharing the same ADC token source. Connector id: gcp
GKE connector id: gke

Quick start

Run Cynative from an environment where ADC works:

gcloud auth application-default login
cynative -p "find externally exposed GCP load balancers"

Credential discovery

Cynative calls Google Application Default Credentials with the https://www.googleapis.com/auth/cloud-platform scope via google.FindDefaultCredentials. The ADC search order determines which identity is used.

Credential sources

GOOGLE_APPLICATION_CREDENTIALS — path to a credential JSON; the first source in the ADC search order.
On Windows, APPDATA locates the well-known ADC file.

Cynative reads GOOGLE_APPLICATION_CREDENTIALS only as a startup presence signal (to decide whether to emit a loud vs. quiet skip). The gcloud project/config variables (CLOUDSDK_*, GOOGLE_CLOUD_PROJECT) are not consulted by Cynative’s project resolution.

Registration and validation

Cynative finds ADC and then eagerly validates it at startup by minting a test cloud-platform token. The gcp and gke connectors register only if that succeeds. If ADC cannot be found, or the credential cannot mint a token (for example a revoked refresh token), both connectors are skipped. References:

How Application Default Credentials works — the ADC search order (GOOGLE_APPLICATION_CREDENTIALS → the gcloud auth application-default login file → the metadata server).

Target selection

Default target

The identity is whatever the ADC chain resolves — typically the user credentials written by gcloud auth application-default login, or an attached service account on a GCP host. There is no single fixed project target: the specific project/resource is chosen per request by the model in the request URL path (for example .../v1/projects/{project}/...).

Changing the target

Change the identity by re-pointing ADC: run gcloud auth application-default login, set GOOGLE_APPLICATION_CREDENTIALS to a credential JSON, or run on a host with a different attached service account. The project Cynative uses to build its testable-permission catalog is resolved from the ADC credential in order:

The credential’s own project (Credentials.ProjectID — populated from a service-account key’s project_id; empty for gcloud auth application-default login user credentials).
The ADC file’s quota_project_id — set via gcloud auth application-default set-quota-project PROJECT.
The GCE metadata project.

Note: GOOGLE_CLOUD_PROJECT and gcloud active-config variables (CLOUDSDK_CORE_PROJECT, CLOUDSDK_CONFIG, CLOUDSDK_ACTIVE_CONFIG_NAME) are not consulted by Cynative’s ADC project resolution.

Request usage

Use auth_provider: "gcp" and include a gcp_auth object:

{
  "gcp_auth": {
    "service": "compute",
    "location": "us-central1"
  }
}

gcp_auth.service is required. gcp_auth.location is used for regional or locational endpoints and is omitted for global endpoints. Minimal example:

const project = "my-project";
const resp = await http_request({
  method: "GET",
  url: `https://cloudresourcemanager.googleapis.com/v1/projects/${project}`,
  headers: [],
  body: "",
  auth_provider: "gcp",
  gcp_auth: { service: "cloudresourcemanager" }
});
console.log(resp.body);

Hardening

Because GCP has no general credential-downscoping primitive, the in-process action gate is the client-side control: a request resolves to a service and operation, those resolve to required IAM permissions, and every permission must be granted by the configured role before the ADC token is attached.

Host pinning

Cynative resolves Google API hosts to a service and location through the cached Discovery directory catalog. The resolved service and location must match the model-supplied gcp_auth claim, so a request cannot claim one Google service while sending credentials to another.

Action authorization

Cynative classifies the API operation, resolves the IAM permissions it requires, and authorizes every required permission against the configured role. The gate fails closed: if Cynative cannot resolve the service, operation, or required permissions, the request is denied. A small fixed set of methods need no IAM permission and are allowed without a role check: oauth2.tokeninfo, discovery.apis.getRest, discovery.apis.list, and any *.testIamPermissions probe.

Response redaction

Cynative redacts secret-shaped content and credential-named fields from responses before the model sees them. Redaction is a defense-in-depth layer — treat returned GCP data as sensitive.

Reading the startup posture

✓ gcp    access=default(read-only) · enforced=client · role=roles/viewer · my-project · sa@… · (+gke)

access=default(read-only) when connectors.gcp.role is roles/viewer; access=custom for any other role.
enforced=client — GCP has no general credential-downscoping primitive; the in-process per-operation IAM permission check is the sole client-side control.
role=<role> — the configured role verbatim.
(+gke) — the GKE connector is folded in.

Cynative configuration

The predefined or custom role the action gate authorizes against. Default roles/viewer.

connectors:
  gcp:
    role: roles/viewer

export CYNATIVE_CONNECTORS_GCP_ROLE=roles/viewer

A custom role is configured the same way:

connectors:
  gcp:
    role: projects/my-project/roles/cynativeReadonly

export CYNATIVE_CONNECTORS_GCP_ROLE=projects/my-project/roles/cynativeReadonly

The configured role may be a predefined role (roles/<id>) or a custom role (projects/<p>/roles/<r> or organizations/<o>/roles/<r>). The role is an operator-chosen ceiling, not inherently read-only: a custom role granting write permissions widens the gate accordingly. A role that cannot be fetched, is disabled, or is soft-deleted causes the gcp and gke connectors to be skipped at startup with a clear reason.

Cache settings

GCP hardening metadata (Discovery catalog and iam-dataset permission registry) is cached under <cache.dir>/gcp. The role definition is fetched live per run and is not cached.

cache:
  dir: ~/.cynative/cache
  ttl: 24h

GKE connector

The GKE connector provides Kubernetes API access to Google Kubernetes Engine clusters. It registers alongside the gcp connector, sharing the same ADC token source. Connector id: gke

How it works

Cynative reuses the same Google ADC token source as the GCP connector for Kubernetes bearer tokens. For each request it:

Resolves the cluster endpoint and CA data from the GKE Container API (requires ADC credentials with access to the Container API).
Attaches the ADC bearer token only after host and action authorization pass.
Applies the shared Kubernetes hardening model (host pinning, view RBAC gate, dial-time IP authorization, response redaction).

GKE requires an IP-literal endpoint. A DNS-based GKE control-plane endpoint resolves to shared Google Front End (GFE) infrastructure and is not IP-pinnable; the dial-time guard rejects it. Use a cluster whose endpoint is an IP literal.

Request usage

Use auth_provider: "gke" and include a gke_auth object:

{
  "gke_auth": {
    "project": "my-project",
    "location": "us-central1",
    "cluster_name": "prod"
  }
}

All three fields are required. project is a project ID (6–30 lowercase letters, digits, or hyphens, starting with a letter) or project number. location is a region (us-central1) or zone (us-central1-a). cluster_name is up to 40 lowercase letters, digits, or hyphens, starting with a letter and not ending with a hyphen.

const resp = await http_request({
  method: "GET",
  url: "https://34.71.1.2/api",
  headers: [],
  body: "",
  auth_provider: "gke",
  gke_auth: { project: "my-project", location: "us-central1", cluster_name: "prod" }
});
console.log(resp.body);

Configuring the ClusterRole

The read-only ClusterRole the GKE connector authorizes against is configurable (default view):

connectors:
  gke:
    cluster_role: view

export CYNATIVE_CONNECTORS_GKE_CLUSTER_ROLE=view

Widening the role past view widens Cynative’s permitted verbs — including writes. See the shared Kubernetes hardening model for full details.

Defense at a glance (GCP + GKE)

Control	GCP	GKE
Read-only by default	✓	✓
Enforcement model	per-operation IAM permission check against configured role	live `view` ClusterRole (kube-apiserver-style classification)
Configurable exposure	✓ predefined or custom role (default `roles/viewer`)	✓ `connectors.gke.cluster_role` (default `view`)
Credential downscoping	— · no general GCP primitive (CAB is GCS-only)	— · authn/authz decoupled in Kubernetes
Host pinning	✓ (Discovery-directory catalog: host → service/location)	✓ (cluster endpoint from the GKE Container API)
Dial-time IP authorization	✓ (default internal-range deny)	✓ (IP-literal endpoint only; DNS-based control-plane endpoints fail closed)
Model-supplied-credential rejection	✓	✓
Response redaction	✓	✓

Limitations

Credential downscoping is not used. GCP Credential Access Boundaries are Cloud-Storage-only; there is no general downscoping primitive. The in-process action gate is the sole client-side control.
Custom roles are resolved per run via iam.roles.get; the ADC principal must hold iam.roles.get on the role’s project or organization. An unresolvable, disabled, or soft-deleted role fails closed (all requests denied).
Organization-level permissions may not be testable at the caller project. Common Resource Manager resource-discovery methods (projects / folders / organizations list and search) are pinned and resolve correctly; other parent-scoped operations may be denied regardless of the configured role.
Action authorization fails closed when service, operation, or permission resolution fails.
DNS-based GKE control-plane endpoints fail closed. Use a cluster whose endpoint is an IP literal.
There is no client-side credential downscoping for GKE. The in-process view gate, host pinning, and dial-time IP authorization are the only client-side controls.
The GCP connector is for Google Cloud APIs. Use gke for Kubernetes API calls to GKE clusters.

Get Started

Using Cynative

Agents

Connectors

LLM Providers

Configuration

Project

GCP Connector: Application Default Credentials Access

Quick start

Credential discovery

Credential sources

Registration and validation

Target selection

Default target

Changing the target

Request usage

Hardening

Host pinning

Action authorization

Response redaction

Reading the startup posture

Cynative configuration

Cache settings

GKE connector

How it works

Request usage

Configuring the ClusterRole

Defense at a glance (GCP + GKE)

Limitations

​Quick start

​Credential discovery

​Credential sources

​Registration and validation

​Target selection

​Default target

​Changing the target

​Request usage

​Hardening

​Host pinning

​Action authorization

​Response redaction

​Reading the startup posture

​Cynative configuration

​Cache settings

​GKE connector

​How it works

​Request usage

​Configuring the ClusterRole

​Defense at a glance (GCP + GKE)

​Limitations

Quick start

Credential discovery

Credential sources

Registration and validation

Target selection

Default target

Changing the target

Request usage

Hardening

Host pinning

Action authorization

Response redaction

Reading the startup posture

Cynative configuration

Cache settings

GKE connector

How it works

Request usage

Configuring the ClusterRole

Defense at a glance (GCP + GKE)

Limitations