Currently, the control plane generates three JSON Web Tokens for different purposes.
a) User JWT
This one is generated once an user authenticate with the control plane, i.e chainloop auth login
, it will be minted once the authentication with the upstream OIDC identity provider is completed. This token is valid for 24 hours and it's what the CLI uses to authenticate requests (stored at /.config/chainloop/config.toml).
b) Robot Account JWT
This is along non-expiring token (but revocable) meant to be used as part of the integration with the CI.
chainloop wf robot-account ...
c) CAS temporary download/upload JWT
The CLI, when it needs to perform an operation with the artifact-CAS, asks the control plane for short-living credentials to do so.
This token is signed with a private key in the control plane and verified with a public key in the CAS, see https://github.com/chainloop-dev/chainloop/tree/main/app/artifact-cas#authnauthz
On the other hand, both the User JWT (a) and the robot-account token (b) use a HS256
symmetric passphrase for both signing and verifying, in fact they use the same key, this task is about making sure that each JWT builder uses their own passphrase.
NOTE: Using a different signing method, i.e asymmetric, JWKS is out of the scope of this task, in my opinion can should tackle it in a follow up task.
Currently, the passphrase that both JWT builders use is defined here
|
string generated_jws_hmac_secret = 2; |
We should split that in two different configuration options
NOTE: before this task I'd take a look at #23 since configuration options might change.
- Deprecate current configuration key and add two new ones that clearly state what's their target audience.
- Update GRPC middlewares and JWT builders