-
Notifications
You must be signed in to change notification settings - Fork 4.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
acl: allow auth methods created in the primary datacenter to optionally create global tokens #7899
Conversation
…ly create global tokens
Note that this is not meant to be a fix for #7381. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think about calling it token-scope
instead of token-type ? Type could be a lot of things, but scope may imply something more specific.
switch method.TokenType { | ||
case "local", "": | ||
case "global": | ||
if !a.srv.InACLDatacenter() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this only a restriction because the secondary servers would require a token to use in the RPC to the primary?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That and having to sleep-loop until replication brought your newly-created token back to the secondary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
…ly create global tokens (#7899)
Currently auth methods (and binding rules) are dc-local items that are not replicated between datacenters. They are also restricted to only being able to create dc-local ACL tokens.
This restriction was initially set in place to avoid an availability issue in any application that headlessly would make use of an auth method to dynamically create a token before application start (such as a kubernetes pod pre start hook). If these needed to make a synchronous RPC back to the primary datacenter (that may not even be up) then that would incur both an additional startup delay and the probability of bringing everything to a screeching halt in the event the primary datacenter is briefly disconnected.
While this argument still holds for any auth method used headlessly (
type=kubernetes
andtype=jwt
) it is harder to make the same justification for user-driven flows liketype=oidc
.In this PR I'm granting auth methods defined in the primary datacenter the option of being configured to exclusively create global ACL tokens.
type=kubernetes
andtype=jwt
as well.