Self-service constraints when combined with ACLs
-
This is a follow up question to the one I posted on ACL inheritance for network objects.. Essentially, when building a self-service resource set, it isn't obvious whether the included resource set is supposed to override any ACLs, or work in tandem.
For example, if I grant "viewer" rights to the pool, why do I need to provide a set of read-only templates, read-only networks, and read-only SRs? It seems to me that the ACLs should take care of that, and the SS should cover anything I need to provide additional operator or admin rights [i.e. read/write SRs, etc.] (in fact, I don't even know what rights the SS resource set actually confers -- is it admin/operator/something else?)
I feel like I have a fundamental misunderstanding of ACLs and SS. Coming from vSphere, I am trying to emulate an inherited DAC permission model, but the XO ACLs seem too limited (I think having an explicit "deny" ACL would dramatically help here by allowing permission "hole-punching"), and the SS isn't dynamic enough.
Can someone help shed some light on how ACLs and SS work together, if at all?
-
O olympicgreg marked this topic as a question on
-
You should have kept on thread, it's easier to track. Anyway, another ping to @pdonias
-
This is essentially why I said in the other thread that "Self Service and ACLs weren't designed to work together"
To keep it simple: Self Service will indeed allow some users to see and use some resources even though they don't have ACLs for them. Then, when they create VMs, it will automatically assign ACLs on the objects under the hood. That's why, even though it's not impossible, most of the time it's not recommended to use them together since you might override ACLs that Self Service assigns automatically.
We're actually starting to think of a redesign (or at least improvements) of those 2 features so feedback is very welcome about any use case that you might have that isn't covered by them at the moment. I already took note of the "dynamic" need for resource set objects.
-
@pdonias
Thanks for the reply and clarification on this.In our environment, we are a test environment, so we are constantly spinning up VMs on isolated networks segregated by VLANs. We have admins and we have users. Users can make VMs and make use of pretty much all the resources, but they can't create or config resources (so they pretty much have "operator" access).
However, there are resources I don't want users to have access to -- or even see even if the user is granted rights higher up in the hierarchy. I would like to see the idea of an ACL "deny" which basically punches a negative access hole in the ACL hierarchical resolution.
I foresee myself mostly using the ACLs instead of the self-service set because of how we operate and because the ACLs are more transparent and (more) dynamically adjusting (i.e. using hierarchical resolution). Coming from a VMware world, the ACL model make more sense to me and I would be able to more easily map my current permission model.
It might be nice to assign ACLs based on tags (or containers) as well. This would allow me to place certain resources into those containers/tag groups and assign ACLs based on them without considering each individual object.
In the ACL screen, right now the ACLs are individually shown. This is very noisy when you have lots of ACLs and it is hard to get a picture of the permission model. I think a reorg of how the ACL information is presented is needed to help make informed authorization decisions. -
@lsouai-vates extra feedback on ACLs
-
@olympicgreg Hello!
And thanks for your feedback on the ACL subject.
I note this on our XO-6 next features, so we will discuss on it and see what we can improve.
Indeed the ACL subject is quite not trivial and we keep on working on it.Have a good day and don't hesitate to give us feedbacks on XO features.
