Open ChefAustin opened 1 week ago
Hi @ChefAustin! Thank you for taking the time to write this proposal down, Sentinel is not my area of expertise, @tgross or @schmichael can have a more informed opinion on this one.
All the ACLs APIs have a similar problem, where we have the one "super ACL policy" which is that management token. Some of the other cluster management level APIs do have more fine-grained ACLs though, like the Raft operations or quotas APIs, so there's definitely precedent for this.
Doesn't look like we have another issue open for this, so let's mark this for roadmapping.
Proposal
Currently, the only Sentinel-related ACL permission is that of
sentinel-override
. Additionally, the only way to grant an ACL policy the ability to interact with the Sentinel Policy API is by way of amanagement
token.I would like to propose that new fine-grained ACL capabilities be added for each CRUD action invokable upon a Sentinel policy (i.e.
create-sentinel-policy
,read-sentinel-policy
,update-sentinel-policy
anddestroy-sentinel-policy
).Use-cases
Recently, I created up a pipeline for syntactically validating and then deploying new/updated Sentinel policies upon being added to our Nomad repository. When I went to run that pipeline for the first time, I got hit with
"Error writing Sentinel policy: Unexpected response code: 403 (Permission denied)"
and then realize that any API actions pertaining to Sentinel policies requires amanagement
token.Ideally, I'd like to explicitly define the capabilities that can be invoked within our CI/CD pipelines (by way of the CI/CD pipeline's leveraged token ACL Policy).
For example, I want our pipeline be able to
"read"
all (as a blanket rule; via the coarse-grained permission), as well as"submit-job"
and"sentinel-override"
but I don't want the pipeline to have the ability to, say,"alloc-exec"
or"csi-mount-volume"
.Attempted Solutions
No solution or workaround discovered outside of giving CI/CD pipeline a
management
token.