Skip to content

GCP, Kubernetes and OpenShift

These are CLI providers. The tool owns its credential store; the runtime only checks that a valid session exists. No token is ever handled by the runtime, and interactive login is never triggered by it — if a session is missing or expired, you are told which command to run yourself.

All three ship enabled: false. Enable one after you have logged in with the platform's own tooling.

GCP

Validation: gcloud auth print-access-token for validity, gcloud config get-value account for the subject.

Setup

gcloud auth application-default login       # the runtime never starts this

authentication:
  gcp:
    enabled: true
    binary: gcloud

runtime auth login gcp
runtime auth status

Runtime Context injection

gcloud invoked through the Command Engine receives --project= from the active Runtime Context's cloud.project:

runtime context use staging
runtime command run gcloud compute instances list

Nothing is injected when cloud.project is empty. Injection happens after policy evaluation, so it can never be used to bypass a denial.

gsutil and bq map to the same gcp provider — they are part of the same SDK and share ADC. Neither receives context injection.

Logout

runtime auth logout gcp

This genuinely revokes, via gcloud auth application-default revoke.

Kubernetes

Validation: reads the kubeconfig's current-context directly. There is no shell-out and no kubectl dependency for the auth check itself.

Setup

kubectl config use-context <name>

authentication:
  kubernetes:
    enabled: true
    kubeconfig_path: ""     # defaults to $KUBECONFIG, then ~/.kube/config

runtime auth login kubernetes
runtime auth status

Kubeconfig resolution

  1. authentication.kubernetes.kubeconfig_path in config.yaml
  2. $KUBECONFIG
  3. ~/.kube/config
export RUNTIME_AUTHENTICATION_KUBERNETES_KUBECONFIG_PATH=/path/to/kubeconfig

Runtime Context injection

kubectl receives -n <namespace> from the active Runtime Context's kubernetes.namespace:

runtime context use staging
runtime command run kubectl get pods       # -n staging

Note that kubernetes.context in context.yaml documents which kubeconfig context this Runtime Context expects — the runtime does not switch kubeconfig contexts for you. Use kubectl config use-context.

helm, flux and istioctl all map to the kubernetes auth provider, because they read the same active kubeconfig context kubectl does and the same validation applies. None of them receives namespace injection — pass -n yourself where those tools need it.

kustomize is deliberately unmapped: it only renders YAML to stdout and never talks to a cluster.

Logout

runtime auth logout kubernetes

There is no session to clear — a kubeconfig is a file. This prints guidance and is audited.

OpenShift

Validation: oc whoami.

Setup

oc login --token=<token> --server=https://api.openshift.example.com:6443

authentication:
  openshift:
    enabled: true
    binary: oc
    server: ""        # optional hint only

runtime auth login openshift
runtime auth status

server is stored as a hint. Login itself is still performed with oc login, outside the runtime.

Runtime Context injection

oc receives -n <namespace> from kubernetes.namespace, exactly like kubectl.

Logout

runtime auth logout openshift

This genuinely ends the session, via oc logout.

Not yet implemented

Provider Intended approach
AWS Validate the existing credential chain (env vars, ~/.aws/credentials, IAM role, SSO) — e.g. aws sts get-caller-identity
Azure Reuse the az account show / Azure CLI token cache
OIDC (CI/CD) Validate a workload identity token already injected by the pipeline

Until then, aws, az and vault still run through command run — they are in allowed_binaries and governed by subcommand rules, they just skip the Auth Engine and use their own credentials.

Deliberately unmapped

docker and podman have their own daemon and registry logins. terraform and pulumi resolve credentials through their own provider configuration. sops uses its own KMS/PGP/age keys. packer only builds images. None of these will gain an auth provider mapping — run their native login commands yourself.