-
Notifications
You must be signed in to change notification settings - Fork 321
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
Improve server-acl-init: Avoid forcibly creating the anonymous token policy when it already exists #2732
Comments
Thanks for filing, this has also been raised internally as a feature request for triaging and prioritization since this is coming from a Consul Enterprise customer. |
@inisitijitty do you want to use the acl:read for the partition token ? the partition token requires acl:write privilage to create other policies like the |
The
To offer a bit more background, I'm giving my users a bootstrap token and I intend to associate it with the following policies:
This setup doesn't work as intended. As highlighted earlier, the
And this doesn't fit the security model I have in mind. |
Is your feature request related to a problem? Please describe.
I am using Consul with admin partitions, each with its own Helm deployment. In my setup, I've observed that the
server-acl-init
subcommand forcefully wants to create the anonymous token policy in the default admin partition, even if it already exists. This behavior requires me to grant the bootstrap tokenacl = "write"
permissions, which is not ideal for the security model I am aiming for.Feature Description
I propose a change where the
server-acl-init
subcommand first checks if the anonymous token policy already exists before creating it. If the policy is already present, then no action is taken. This would reduce the scope of the bootstrap token permissions, enhancing the overall security and reducing the possibility of privilege escalation.Here are the relevant code sections:
server-acl-init
behavior: Linkpartition-init
: LinkUse Case(s)
This feature is particularly useful in scenarios where you are running Consul on Kubernetes in a multi-tenant environment with admin partitions. Each partition requires its own Helm deployment and managing ACL policies becomes crucial to maintaining secure boundaries between different partitions.
Contributions
I would be happy to contribute to this feature, but I may need some guidance on how to get started as this is my first time contributing to Consul.
The text was updated successfully, but these errors were encountered: