Summary
Support JWT-based authentication as an alternative to mTLS for Substrate system components.
The current alpha auth direction appears to rely on mTLS between ate-system components, which in turn depends on certificate provisioning paths such as the Kubernetes PodCertificate API / pod certificate controller. That creates a deployment blocker for clusters where PodCertificate is not available or not enabled.
Problem
mTLS and JWT authentication are both reasonable options for in-cluster component identity, but requiring mTLS as the only supported auth path makes Substrate harder to install and evaluate broadly.
In particular:
- PodCertificate is not generally available across Kubernetes distributions today.
- Some managed clusters may not expose or support the required API/features.
- Local/dev/Kind installs may need extra bootstrap machinery just to get component auth working.
- Operators may already have a working projected service account token / OIDC JWT path available.
This means auth for core Substrate components can become coupled to a certificate delivery mechanism that is not portable enough yet.
Proposal
Add support for JWT-based authentication and authorization for Substrate system components, either as:
- A first-class alternative to mTLS, or
- A portable default/bootstrap mode, with mTLS also available when certificate provisioning is available.
The JWT path could use Kubernetes projected service account tokens, with appropriate audiences and short lifetimes, and validate them at the receiving component boundary.
For example:
atelet authenticates to ate-api-server with a projected service account JWT.ate-api-server validates issuer, audience, expiry, subject, namespace, and service account identity.- Authorization maps trusted service accounts to allowed component roles/actions.
- mTLS remains supported as another authentication mode.
Goals
- Do not require PodCertificate availability for a basic secure install.
- Provide a portable auth path that works on standard Kubernetes clusters.
- Support mTLS as a parallel authentication option where available.
- Keep authorization explicit and component-scoped.
- Make install docs clear about the supported auth modes and tradeoffs.
Non-Goals
- Deprecating or removing mTLS.
- Solving actor identity credential delivery in this issue.
- Designing a full dynamic policy language for all authz decisions.
Open Questions
Related Issues
Summary
Support JWT-based authentication as an alternative to mTLS for Substrate system components.
The current alpha auth direction appears to rely on mTLS between
ate-systemcomponents, which in turn depends on certificate provisioning paths such as the Kubernetes PodCertificate API / pod certificate controller. That creates a deployment blocker for clusters where PodCertificate is not available or not enabled.Problem
mTLS and JWT authentication are both reasonable options for in-cluster component identity, but requiring mTLS as the only supported auth path makes Substrate harder to install and evaluate broadly.
In particular:
This means auth for core Substrate components can become coupled to a certificate delivery mechanism that is not portable enough yet.
Proposal
Add support for JWT-based authentication and authorization for Substrate system components, either as:
The JWT path could use Kubernetes projected service account tokens, with appropriate audiences and short lifetimes, and validate them at the receiving component boundary.
For example:
ateletauthenticates toate-api-serverwith a projected service account JWT.ate-api-servervalidates issuer, audience, expiry, subject, namespace, and service account identity.Goals
Non-Goals
Open Questions
atelet->ate-api-server,ateom->atelet, router -> API server, others?Related Issues