Skip to content
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

Hierarchal? Policies #28689

Open
KyRobbins opened this issue Oct 11, 2024 · 0 comments
Open

Hierarchal? Policies #28689

KyRobbins opened this issue Oct 11, 2024 · 0 comments

Comments

@KyRobbins
Copy link

Is your feature request related to a problem? Please describe.
Not a bug, just a desired feature, to be able to handle policies in more of a hierarchal way, where you might have one user that is an "admin" type user with lots of access, but then you might have a lower "maintainer" that just needs to be able to go in and modify service accounts or something. Not currently seeing features that offer clear separation on that regard, just some tricks that don't quite accomplish what I'm thinking.

Describe the solution you'd like
There are probably a multitude of ways to do this, but just as an example, using a group-based policy making process where created policies can be tied to a group, meaning only those in that group (or a sub-group) can modify those policies. They also wouldn't be able to modify the policy in ways that affect permissions they don't have themselves. So a user who manages services accounts, can't add full access to everything to that service account and then sign in with it, they can only add up to the same level of access they currently have themselves via the associated group's policy.

With this, it would seem to make sense to make the policies apply by precedence, then by specificity. If I'm in the "maintenance" group that has access x, y, but explicitly not z, but I'm also in an "admin" group (that includes the "maintainer" group) that has x, y, and implicitly z, I should get access to z even if it's defined with higher "specificity" in the "maintenance" group that I don't have it.

Describe alternatives you've considered
I've tried setting up a policy for a "maintainer" that allows them to only modify policies that start with a service-* prefix, thus they can't edit their own policy, only service defined ones, but then they could just give the service account full access and sign in as them.

Explain any additional use-cases
Having a separation of ability between users is always needed, and though in many ways that does already exist in the current policy strategies, it's just not very fine grain control for specific resources, such as be able to distinguish different types of entities someone should be able to manage, and allowing limited access to defining policies.

Additional context
Nothing else to add

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants