-
Notifications
You must be signed in to change notification settings - Fork 24.7k
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
Expand manage_slm
privilege
#67539
Comments
Pinging @elastic/es-security (Team:Security) |
Pinging @elastic/es-docs (Team:Docs) |
I tested this in a 8.0 snapshot build, and it looks like the Here's the reproduction steps for my test:
The response indicates the snapshot failed.
You can repeat steps 5 & 6. Each time will result in snapshot failure.
The response now indicates a successful snapshot was taken:
|
It does seem odd that we use the As is, this sorta feels like a workaround. Maybe a |
I think @jrodewig is right. The privileges are still needed with the current code. The logic in So, unless a policy is created with no authentication, the task will always be executed with the privileges of the user who creates the policy. I am not entirely sure why we also set an I also agree the recommendation of using raw action names is off. We don't currently have a |
Thank you @jrodewig for the investigation! It was on me to verify, thank you for your time. Thanks for pitching in @ywangd . I misread the code. @ywangd I think we should add the privileges to create (and delete snapshots) to the |
I am not sure what was the original intention of having |
The intention doesn't make much sense because if you can create an SLM policy but not create snapshots, you create a policy that does a snapshot 1 minute from now, circumventing your restriction. In addition, it's preferable to run the snapshots under the owner user context for auditing purposes (or better attribution in general). |
Makes sense. I agree
|
manage_slm
privilege
Since the current docs are correct, I changed the title and removed the |
The description from SLM with Security is a bit unclear to me.
The list mentions privileges to create and delete snapshots (
cluster:admin/snapshot/*
) when working with SLM, but from my reading of the SLM code that is not necessary. The internal client used by the SLM tasks runs under sufficient privileges to create and remove snapshots, irrespective of the users privileges.I think we should proceed to remove the
cluster:admin/snapshot/*
mention in the docs.Maybe someone from @elastic/es-core-features can verify my theory.
The text was updated successfully, but these errors were encountered: