kubernetes v1.0.0

The pack names a reference, never a secret. Installing a pack registers capabilities and makes them governable; registration is not connectivity. The credential is created at the provider and held in the client's own secret manager under the reference the pack names, and deployment testing is still required to show the credential path works and cannot be bypassed.

Reference

secret-ref-kubernetes-sa-token

Custody

customer_vault

Injection

header (Authorization)

A service-account bearer token for the customer's own cluster, held in the client's own secret manager. The stored material must be the complete Authorization header value: the scheme 'Bearer', one separating space, then the signed JWT — 'Bearer <token>'. Issuance is external and belongs to the cluster: a cluster administrator creates a dedicated ServiceAccount for this integration and mints a token with 'kubectl create token <name>' (the TokenRequest API), optionally bound to an audience and a lifetime — per the retrieved authentication reference the created token is a signed JWT, service accounts authenticate as system:serviceaccount:(NAMESPACE):(SERVICEACCOUNT), and their bearer tokens are valid from outside the cluster. Prefer short-lived bound tokens from TokenRequest over legacy Secret-based tokens: a bound token expires on its own (the exp claim) and fails closed afterward, while legacy Secret-based tokens do not expire and remain valid until the Secret is deleted — and note that with the API server's service-account lookup enabled, deleting the token Secret revokes it, but merely stopping new issuance (removing the right to call TokenRequest) does NOT invalidate already-issued unexpired tokens: and per the retrieved TokenRequest reference a token bound to an object via boundObjectRef is valid only for as long as the bound object exists, so deleting the bound object (a Pod or Secret) invalidates such a token; a token bound only to the service account itself cannot be individually revoked before expiry, and revoking it means deleting the service account or rotating the cluster's signing keys. Rotation therefore sits with an external deployment custody job that re-mints and re-stores the value before expiry; the executor injects the stored value verbatim and performs no token lifecycle of its own. Least privilege, distinguishing scopes: namespaces are cluster-scoped objects, so listing or deleting them requires a ClusterRole/ClusterRoleBinding, while deployments, pods and the scale subresource are namespaced and should be granted by Role/RoleBinding in only the namespaces the deployment binds. Grant list (not merely get) for the registered collection reads on namespaces, deployments and pods; create on deployments for the create capability; update specifically on the deployments/scale SUBRESOURCE for the scale capability — general update on deployments is not required for it and must not be granted; and delete on deployments and namespaces only where the delete capabilities are enabled — never cluster-admin. Executor hygiene: the value must live only in executor memory for the lifetime of a call, must never be written to logs, traces or diagnostics, and must not appear in crash dumps; a deployment that cannot meet that bar must not enable the pack.

• kubernetes-cluster (api, internal): https://k8s-apiserver.invalid

The endpoint host 'k8s-apiserver.invalid' is a reserved non-production placeholder (an RFC 2606 reserved TLD): substitute the customer's cluster API server endpoint (host and, where non-standard, host:port) before enabling, in every endpoint, in the resource locator and in every egress allowlist entry. The allowlist matches exactly, so endpoints and allowlist must be substituted together, and substitution is a required deployment step. NAMESPACE and NAME in the endpoint paths are placeholders the deployment binds to concrete objects before enabling; this pack registers namespaced collection reads only — the cluster-wide list forms (GET /apis/apps/v1/deployments, GET /api/v1/pods across all namespaces) are not registered. The Kubernetes API is served over HTTPS with the cluster's own certificate authority, so the executor must trust the cluster CA; the egress allowlist governs the destination only and is not a TLS-trust statement. Tiering rationale: deployment creation registers as create AND deploy at the R3 floor, judged by effect — the body is an unrestricted Deployment spec (per the retrieved Deployment API reference), which selects container images, replica counts, service accounts, volume mounts and security contexts, so creating a Deployment is running caller-chosen code on the cluster, and deploy is one of the IRREVERSIBLE ACTIONS (delete, send, pay, deploy, approve, share and transfer); an installer's intention to pass only benign specs is not a restriction. Deployment deletion and namespace deletion register as delete at the R3 floor: deleting a Deployment deletes its ReplicaSets and Pods through the cascade, and deleting a namespace deletes every object in the namespace. Scaling registers as update AND deploy at the R3 floor: the scale subresource replaces the running replica count of a live workload — a deploy-equivalent reconfiguration of live infrastructure (scaling to zero takes the workload offline) — and the count's practical reversibility is not grounds for avoiding the deploy verb. Documented exclusions — this pack does not register: reading Secrets (GET /api/v1/namespaces/{ns}/secrets — the response IS the cluster's stored credentials, and per the retrieved authentication reference anyone who can read those Secrets can authenticate as the corresponding service account), pods/exec, pods/attach and pods/portforward (arbitrary command execution and network tunneling into containers — a different registration requiring its own review), pods/log, the deletecollection forms of every resource (bulk deletion by label selector), create/update/delete of RBAC objects (Roles, ClusterRoles and their bindings — privilege grant), node operations (cordon, drain, taints), PersistentVolumes and PersistentVolumeClaims, ServiceAccount and token creation, and every other Kubernetes API — a documented exclusion, not an approximated capability.

Draft review record dated 2026-09-21 · Reviewer: aaes-eng (an opaque id that resolves internally to the responsible reviewer)

• https://kubernetes.io/docs/reference/kubernetes-api/ (retrieved 2026-09-21)
• https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/deployment-v1/ (retrieved 2026-09-21)
• https://kubernetes.io/docs/reference/kubernetes-api/cluster-resources/namespace-v1/ (retrieved 2026-09-21)
• https://kubernetes.io/docs/reference/access-authn-authz/authentication/ (retrieved 2026-09-21)
• https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/ (retrieved 2026-09-21)
• https://kubernetes.io/docs/reference/kubernetes-api/authentication-resources/token-request-v1/ (retrieved 2026-09-21)

A pack review is not a vendor or examiner attestation. A retrieval date says when a source page was read; it does not by itself establish what the page said then. No pack is vendor-endorsed, and none has been connectivity-tested against a live vendor tenant.