Repository navigation
docs: authenticate to the Kubernetes Proxy with a service-account key or a PAT - #940
Draft
slayerjain wants to merge 1 commit into
Draft
slayerjain wants to merge 1 commit into
slayerjain wants to merge 1 commit into
Conversation
… or a PAT The Kubernetes Proxy REST API page told callers, CI included, to trade a personal access token for the cluster shared token and send that token on every call. The shared token is the credential the proxy's own in-cluster components use, and the proxy now accepts it only on the routes those components call. - Authentication now sends a service-account key (CI and automation) or a PAT (a person) straight in the Bearer header. It explains what a key can call (per-route permissions, enforce vs. the default audit mode), how to set up a service account for CI (ITG_RUNNER / ATG_RUNNER, key expiry and rotation), the failure modes, and how long the proxy caches a validation. - The PAT -> shared-token exchange and the Console's Get Shared Token button are documented as deprecated, with the 403 the shared token now gets and how to migrate a script. - The quick start, the endpoint reference and the static-deduplication example use the key directly. Signed-off-by: slayerjain <shubhamkjain@outlook.com>
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
The Kubernetes Proxy REST API page told every caller, CI pipelines included, to exchange a personal access token for the cluster's shared token (
POST /get-shared-token, or the Console's Get Shared Token button) and send that token on every call.That token is the credential the proxy's own in-cluster components (node agents, the external replay runner) authenticate with. It names no user, so a copy held by a CI system carries cluster-wide authority with no owner and no per-consumer revocation. The proxy is being changed (keploy/k8s-proxy#1126) to accept the shared token only on the routes those in-cluster components call, in every RBAC mode, and to answer 403 everywhere else.
This PR moves the docs to the replacement, which the proxy already accepts today:
enforcevs. the default audit mode), setting up a service account for CI (ITG_RUNNERforkeploy cloud replay,ATG_RUNNERforkeploy test-suite --cloud, key expiry and rotation), the failure modes, and how long the proxy caches a validation.tokenIdcaching).Ordering
Sending a PAT or a service-account key directly already works on current proxy releases, so the new instructions are safe to publish before the proxy change. The "the shared token gets 403" statements become true with the k8s-proxy release that carries #1126; this PR should merge with or before it.
Open point for reviewers
Neither runner role a service account can hold includes starting or stopping a recording or an in-cluster replay (
record:start,record:stop,replay:start,replay:stop). The page says so, and that underenforcethose routes need the key of someone who holds them on the cluster (a cluster admin). Whether a CI pipeline that drives recordings should get a dedicated runner role is a product decision, not made here.