You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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
The text was updated successfully, but these errors were encountered: