KubeRich
Browse documentation

AUTHENTICATION

EKS authentication

KubeRich uses the aws eks get-token exec entry already declared in your trusted local kubeconfig. The AWS CLI owns its credential chain, profiles, role assumption, SSO cache and refresh; KubeRich does not embed AWS credentials or create clusters. The local contracts below are implemented. Actual AWS/EKS qualification is pending. Automated checks establish local credential-helper behavior; they do not certify a real AWS account, role or SSO policy.

Supported local contracts

Complete SSO login outside KubeRich using the profile from your exec entry:

aws sso login --profile YOUR_PROFILE

Then retry with r or :retry. KubeRich does not open a browser automatically or rewrite your kubeconfig/AWS files. The AWS CLI may renew its own cached credentials as part of the configured helper. Explicit native :login is available for generic helpers with Always/IfAvailable/Never stdin semantics and TLS certificate renewal. It runs the declared helper; it does not infer an aws sso login command. See kubeconfig interoperability.

Opt-in real smoke

Run only on a test context explicitly authorized by its owner. The script refuses omitted scopes and non-AWS exec entries, and never falls back to the active/default context:

uv run python -m scripts.verify_eks_auth \
  --kubeconfig /absolute/path/to/test-kubeconfig \
  --context YOUR_EKS_TEST_CONTEXT \
  --namespace YOUR_TEST_NAMESPACE \
  --kubectl /absolute/path/to/kubectl \
  --acknowledge-test-cluster

It reads at most one pod per response through the Python adapter, forces only the session-local cache expiration for five concurrent reads, and performs the same pod read with real kubectl and a private connection snapshot. It creates no cluster resources, performs no exec and calls no provisioning APIs. Its report contains fixed outcomes/platform information; no token, account, ARN, context, namespace, kubeconfig, helper output or pod contents are retained. The private snapshot is removed and the client/TLS directory closed on success and failure.

This smoke does not prove naturally expiring tokens, the full SSO/role matrix, or the server-side principal merely from successful reads. Qualification must record actual AWS CLI/Kubernetes/kubectl/platform versions and the authorized profile/role/SSO scenarios separately, without publishing private identities. The checked-in tests use local synthetic helpers, and the kind verifier uses a synthetic AWS-shaped helper with a disposable service-account token. Neither is real-cloud evidence. See measured acceptance.

Sources