Repository navigation
Document how people, pods and CI jobs should authenticate to ate-api - #3119
Open
Max Thompson (thompsonmax) wants to merge 2 commits into
Open
Max Thompson (thompsonmax) wants to merge 2 commits into
Max Thompson (thompsonmax) wants to merge 2 commits into
Conversation
The authentication guide described only the jwtProviders file, so users fell back on kubectl ate's shared ate-client token. Organize it by caller instead: people running kubectl ate, pods in the Substrate cluster, pods in another cluster, and CI jobs. Each section says what works today, including pod certificates, what kubectl ate still needs from the Kubernetes API, and what isn't supported yet. Move the per-user ServiceAccount recipe and the authentication gaps out of the authorization guide so each fact lives in one place.
Max Thompson (thompsonmax)
requested review from
Eitan Yarmush (EItanya),
Shruti Nair (SHRUTI6991) and
Taahir Ahmed (ahmedtd)
and removed request for
Shruti Nair (SHRUTI6991)
October 22, 2026 17:09
Max Thompson (thompsonmax)
marked this pull request as ready for review
October 22, 2026 17:09
…ings Several recipes in the authentication guide failed when followed. In-cluster clients need their namespace labeled ate.dev/api-access=true, since the ate-system NetworkPolicy drops everything else. `get actors` needs -a. A pod in another cluster can't project a ClusterTrustBundle from the Substrate cluster. The per-user recipe also never created the ServiceAccount, bound the Role, or granted kubectl ate its own Kubernetes access. Add the missing steps, and say where an identity is weaker than it looks: trusting another cluster's issuer lets it mint ate-client, GKE's Kubernetes Engine Developer and basic Editor roles can act as any ServiceAccount, ate-system port-forward rights reach unauthenticated Envoy admin APIs, deleting a ServiceAccount doesn't revoke its tokens, and GitHub and Google tokens authenticate anyone, so the GitHub example uses an install-specific audience and an ID-based sub. Correct what happens to a client certificate from another CA, which RBAC a ServiceAccount already has, what discoveryTokenFile sends, and how to change a wrongly detected issuer. The authorization guide no longer lists Secrets as a way to get a token ate-api accepts: Secret-based tokens carry the legacy kubernetes/serviceaccount issuer, which no provider can name.
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.
Part of #1464.
docs/authentication.mdaround who is calling ate-api: a person runningkubectl ate, a pod in the Substrate cluster or another cluster, or a CI job, so people stop leaning on the sharedate-clienttoken.ate.dev/api-accessnamespace label the ate-system NetworkPolicy requires, and the Kubernetes RBACkubectl ateneeds to reach ate-api.ate-client, GKE's Kubernetes Engine Developer and basic Editor roles can act as any ServiceAccount, ate-system port-forward rights reach loopback-only Envoy admin APIs that can stop the data plane, and GitHub and Google tokens authenticate anyone.authorization.md, and drops its claim that a Secret-based token works there (ate-api rejects its issuer). The recipe and RBAC use kubectl ate: authenticate with ExecCredential plugins named by --credential-plugin #2851's names (ate-users,ate-api-client).For reviewers: #2851 (
--credential-plugin) rewrites the same sections, and its paragraph calling GitHub and Google tokens unsafe needs to match this one.Testing: checked each claim against the code on main (GitHub, GKE and Kubernetes behavior against their docs or source) and that the relative links resolve. None of the commands or manifests ran on a cluster.
AI use: AI-assisted.