Add local JWT development server with key generation scripts#9647
Add local JWT development server with key generation scripts#9647simvlad wants to merge 2 commits intotemporalio:mainfrom
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 698b205891
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| # Collect permissions (default to system:admin if none specified) | ||
| if [ $# -eq 0 ]; then | ||
| PERMISSIONS='["system:admin"]' |
There was a problem hiding this comment.
The default permission emitted when no permission arguments are passed is system:admin, but the default JWT claim mapper only treats temporal-system as the system-wide scope (permissionScopeSystem), so this token is interpreted as namespace system admin instead of cluster/system admin. In practice, running ./config/jwt/generate-token.sh with defaults can produce tokens that are denied for cluster-level APIs and normal namespace operations unless explicit permissions are provided.
Useful? React with 👍 / 👎.
1 participant
What changed?
development-jwt.yamlconfig that runs Temporal with JWT authorization enabled using a JWKS file loaded from local disk. Loading from local disk is added in Support file scheme for JWT key provider #9590.config/jwt/setup-keys.shto generate an RSA key pair and JWKS file in/tmp/temporal-jwt-test/.config/jwt/generate-token.shto create signed JWTs for testing.make start-jwttarget.Why?
Testing JWT authentication currently requires an external identity provider or manual key/token setup. This provides a self-contained local workflow:
make start-jwtgenerates keys automatically and starts the server with auth enforced, andgenerate-token.shproduces tokens on demand.How did you test it?
Tested this in conjunction with #9582. Was able to list the workflows by passing the token and dumping their history. When the token is not used, the auth fails with "Request denied".
Potential risks
Keys are stored in /tmp/temporal-jwt-test/ which is world-readable. This is acceptable for local development but the scripts should not be used in shared or production environments.