feat(proposal): enhanced worker auth proposal #770
Conversation
cognifloyd
left a comment
cognifloyd
left a comment
There was a problem hiding this comment.
A couple of comments / questions.
I can't offer an informed opinion on the implementation (HMAC vs pub/private key pair). I'm fine with both/either. Whatever is both maintainable and secure enough.
| - specification of IP address in the claims to allow restriction by IP | ||
| - stricter expiration logic | ||
|
|
||
| In the case where the admins would prefer to continue using the symmetric token, all the above worker design logic will use the `VELA_SERVER_SECRET` token, which will not expire and not hinder executors' ability to pull from the queue. |
There was a problem hiding this comment.
Do you mean that the VELA_SERVER_SECRET can be used as a persistent worker auth token?
There was a problem hiding this comment.
Yes, the idea is that if it's provided (and there is a matching VELA_SECRET in the server env) then the server will honor that as a non-expiring auth method
| - The server secret would be dropped from the container environment altogether if platform admins opt in to this enhancement. | ||
| - All auth tokens (check in + registration) have a strict expiration. | ||
| - Registration tokens can only be generated by a platform administrator | ||
| - Registration tokens should expire very quickly |
There was a problem hiding this comment.
Any suggestions about how quickly? Would this be configurable?
There was a problem hiding this comment.
The default will be 1m since the accompanying CLI changes will be quick enough to not have that be a problem. But yes it will be configurable.
Co-authored-by: Jacob Floyd <[email protected]>
…nto proposal/worker-auth
No description provided.