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.
This is the gcloud CLI account flow, and Runtime says so
auth print-access-token returns the token of the account gcloud is logged
in as. Application Default Credentials are a different mechanism with,
commonly, a different principal — often a service account. Runtime never
reports one as the other: when gcloud has no active account, the identity
reads gcloud-account-unset rather than adc, because a record naming the
wrong credential source misattributes every action taken under it.
Both probes run under the credential_probe process class — the same
pinned, sanitized subprocess command run uses — and the token goes
straight into memory. It is never carried on the identity, returned in a
result, quoted in an error, or written to the audit log. That is also why
gcloud auth print-access-token is refused when you ask for it through
command run: the difference is where the bytes go.
Setup¶
Where the project comes from¶
gcloud invoked through the Command Engine gets --project= from
gcloud's own configuration — never from a
Runtime file:
gcloud config set project acme-staging # gcloud owns this
runtime command run gcloud compute instances list
Or pass it on the command, which wins for that invocation:
Runtime resolves the project and builds the final argument list before policy evaluates it, so the command policy judges is the command that runs. Nothing is added afterwards.
Reading gcloud's configured project means running gcloud config get-value
project, which may write logs and configuration state while answering.
Runtime therefore records a context_probe intent before it happens; if it
cannot, the project is left unresolved rather than probed anyway.
Changes are refused today. gcloud ... delete through the Command Engine
stops with an explanation: Runtime pinned a project name that gcloud
re-resolves itself, which is not a strong enough binding to back a change.
Reads are allowed.
Related binaries¶
gsutil and bq map to the same gcp provider — they are part of the same
SDK and share its configuration. Both are registered context-aware, like
gcloud itself.
Logout¶
This genuinely revokes, via gcloud auth application-default revoke.
Kubernetes¶
Validation: reads the kubeconfig's current-context. There is no
shell-out and no kubectl dependency for the auth check itself.
The read goes through Runtime's adapter-only native-state resolver: the file is
opened once, read under a size bound, and identified in any message by a
logical name rather than its path. Your kubeconfig is in the File Engine's
protected set
— runtime files read ~/.kube/config is refused — and this keeps the
authentication check from being a second, wider way to the same file. The
resolution order is kubectl's own: authentication.kubernetes.kubeconfig_path
if set, else $KUBECONFIG as a merge list where the first file that sets
current-context wins, else ~/.kube/config.
Setup¶
authentication:
kubernetes:
enabled: true
kubeconfig_path: "" # defaults to $KUBECONFIG, then ~/.kube/config
Kubeconfig resolution¶
authentication.kubernetes.kubeconfig_pathinconfig.yaml$KUBECONFIG~/.kube/config
Where the namespace comes from¶
kubectl gets its context and namespace from your kubeconfig, which
Runtime reads and never writes:
kubectl config use-context staging
kubectl config set-context --current --namespace orders
runtime command run kubectl get pods
Or pass them on the command:
KUBECONFIG merge order is honoured the way kubectl honours it — the first
file that sets current-context wins — and Runtime fingerprints every file in
the list, so an edit that changes which file wins is detectable even when the
resolved value did not change.
Runtime never switches kubeconfig contexts for you. Changes are refused
today for the same reason as gcloud: kubectl delete and kubectl apply
stop with an explanation, while reads run.
Related binaries¶
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¶
There is no session to clear — a kubeconfig is a file. This prints guidance and is audited.
OpenShift¶
Validation: oc whoami.
Setup¶
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¶
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 adapters can bind their selected account or subscription, aws and az
remain context-unsupported through command run, even
though the compiled policy names them. vault is context-free and uses its own
credentials, subject to its command and environment policy.
OIDC is often already below a native CLI: kubeconfig exec plugins, ADC/workload identity federation, AWS role chains, and Azure federated credentials may all obtain short-lived credentials without Runtime handling the exchange. Runtime's job is to preserve that provider-native mechanism and record the resolved auth disposition, not to become another identity provider.
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.
Operational examples on this site were verified against Runtime 0.9.8. After bootstrap, the version-exact files in Runtime Home win.