Hi all,
We just published the design proposal for implementing "Predefined access policies for systems" [1].
If you have any questions/comments/suggestions, please do let us know.
[1] https://beaker-project.org/dev/proposals/predefined-access-policies.html
Best, Amit.
----- Original Message -----
From: "Amit Saha" asaha@redhat.com To: "Beaker development" beaker-devel@lists.fedorahosted.org Sent: Thursday, February 5, 2015 9:12:56 PM Subject: [Beaker-devel] Design proposal: Predefined Access Policies for Systems
Hi all,
We just published the design proposal for implementing "Predefined access policies for systems" [1].
If you have any questions/comments/suggestions, please do let us know.
[1] https://beaker-project.org/dev/proposals/predefined-access-policies.html
Best, Amit. _______________________________________________ Beaker-devel mailing list Beaker-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/beaker-devel
Amit, I read the Link you provided. I do have a question. Is this work being done to satisfy additional BZ or other long term goal? Who or What it the actual "use case". I see there is a "grey area" of dependency for "Scheduler Integration for System Pools"
Thanks, Jeff
Hi Jeff,
Amit, I read the Link you provided. I do have a question. Is this work being done to satisfy additional BZ or other long term goal? Who or What it the actual "use case". I see there is a "grey area" of dependency for "Scheduler Integration for System Pools"
Sorry, I don't understand what you mean by "grey area" of dependency.
The main goal of this work is to implement "Predefined Access Policies". The use case is to make it possible for multiple systems to share the same access policy without the same policy needing to be defined separately for all the systems which was first introduced in Beaker 0.15 [1].
Upon some discussions (on this mailing list) and thought, we reached the conclusion that this goal would be best met by introducing the "system pools" feature which we had earlier only considered as a standalone change and also included the "Scheduler Integration for System Pools" change [2].
So, here is a sample use case:
You create a system pool and define a "pool policy". Now any system in Beaker (both outside and inside the system pool) can be access controlled by this pool policy or by its own custom policy.
[1] https://beaker-project.org/dev/proposals/access-policies-for-systems.html [2] https://beaker-project.org/dev/proposals/system-pools.html
Best, Amit.
On 02/09/2015 10:37 AM, Amit Saha wrote:
Hi Jeff,
Amit, I read the Link you provided. I do have a question. Is this work being done to satisfy additional BZ or other long term goal? Who or What it the actual "use case". I see there is a "grey area" of dependency for "Scheduler Integration for System Pools"
Sorry, I don't understand what you mean by "grey area" of dependency.
The main goal of this work is to implement "Predefined Access Policies". The use case is to make it possible for multiple systems to share the same access policy without the same policy needing to be defined separately for all the systems which was first introduced in Beaker 0.15 [1].
Upon some discussions (on this mailing list) and thought, we reached the conclusion that this goal would be best met by introducing the "system pools" feature which we had earlier only considered as a standalone change and also included the "Scheduler Integration for System Pools" change [2].
So, here is a sample use case:
You create a system pool and define a "pool policy". Now any system in Beaker (both outside and inside the system pool) can be access controlled by this pool policy or by its own custom policy.
[1] https://beaker-project.org/dev/proposals/access-policies-for-systems.html [2] https://beaker-project.org/dev/proposals/system-pools.html
I think I see what Jeff's getting at - on the development side, we know the problem we're aiming to solve with this feature, but that isn't clear from the design proposal itself. It's missing the clear motivating use case where we explain what it means from a user perspective. Something like:
===================== The original custom access policy feature implemented in Beaker 0.15 presents some usability challenges for shared system management:
* By default, each new system is created with a custom access policy that merely grants all users the "View" permission. Only the system owner (which defaults to the user that created the system entry) can edit the custom access policy or do anything else with the system.
* This is inconvenient for shared system management, as it means each new system needs to have its ACL configured appropriately for the group that manages it. Changes to ACLs must also be applied to all systems covered by that ACL.
* While these activities can be scripted through the remote web API, there are still plenty of opportunities to get things wrong.
This design proposal addresses that problem by changing the procedure for configuring a newly added group managed system to be:
* add the new system to the appropriate system pool * configure the system to use the pool ACL rather than its own custom ACL
The new system will then use the preconfigured pool ACL for access control, and automatically respect any future changes to that ACL. If access needs to be temporarily restricted to a select group, then the system can be switched back to using its custom ACL for a time, before being returned to using the appropriate pool ACL. =====================
This description also suggests some potential follow on RFEs (which can be listed as deferred for now):
- allow a "Notify CC" to be set at the pool level, not just at the individual system level - enhancing the "add system" modal to allow specifying a system pool up front (and configuring the ACL settings accordingly) - setting or changing the active policy via CSV upload
For that last, we'd also need to ensure that whatever is used to represent the custom access policy in the CSV can't also be used as a valid pool name (e.g. "<custom>" or something like that).
As far as the impact on the "System Pools" design proposal, I realised that the "strict filtering by pool" requirement described there isn't all that difficult once the core system pools feature is implemented. It's only the pool *preferences* feature that can't be readily handled in the current scheduler architecture.
Cheers, Nick.
----- Original Message -----
From: "Amit Saha" asaha@redhat.com To: "Beaker development" beaker-devel@lists.fedorahosted.org Cc: "Jeffrey Burke" jburke@redhat.com Sent: Sunday, February 8, 2015 7:37:48 PM Subject: Re: [Beaker-devel] Design proposal: Predefined Access Policies for Systems
Hi Jeff,
Amit, I read the Link you provided. I do have a question. Is this work being done to satisfy additional BZ or other long term goal? Who or What it the actual "use case". I see there is a "grey area" of dependency for "Scheduler Integration for System Pools"
Sorry, I don't understand what you mean by "grey area" of dependency.
The main goal of this work is to implement "Predefined Access Policies". The use case is to make it possible for multiple systems to share the same access policy without the same policy needing to be defined separately for all the systems which was first introduced in Beaker 0.15 [1].
Upon some discussions (on this mailing list) and thought, we reached the conclusion that this goal would be best met by introducing the "system pools" feature which we had earlier only considered as a standalone change and also included the "Scheduler Integration for System Pools" change [2].
A dependency is what I meant by "grey area". It was poorly worded on my part.
So, here is a sample use case:
You create a system pool and define a "pool policy". Now any system in Beaker (both outside and inside the system pool) can be access controlled by this pool policy or by its own custom policy.
I understand the changes. I will start a new thread with my other questions.
Thanks, Jeff
[1] https://beaker-project.org/dev/proposals/access-policies-for-systems.html [2] https://beaker-project.org/dev/proposals/system-pools.html
Best, Amit.
-- Amit Saha SED, Hosted & Shared Services Red Hat, Inc.
On 02/09/2015 10:37 AM, Amit Saha wrote:
So, here is a sample use case:
You create a system pool and define a "pool policy". Now any system in Beaker (both outside and inside the system pool) can be access controlled by this pool policy or by its own custom policy.
Ah, so the intent is to allow use of the pool policy without being a member of the pool?
While I like that as a general notion, we may need to consider the UX implications. One possibility might be to segment the pool selection list so pools the system is part of appear first.
Alternatively, we might wish to restrict the UX in the initial implementation to only allowing a choice from pools the system is a part of, rather than all pools. I think that's going to be easier to explain in the documentation, rather than decoupling the two decisions and having to explain that pool membership and pool policy inheritance are actually unrelated. I'm a fan of this approach, as I'm struggling to think of a good use case (or, indeed, *any* use case) for making the two decisions completely independent.
If we later get an *RFE* to allow use of pool policies for systems that aren't members of that pool, we could consider it based on a concrete use case rather than speculation.
Cheers, Nick.
On 02/10/2015 12:33 PM, Nick Coghlan wrote:
On 02/09/2015 10:37 AM, Amit Saha wrote:
So, here is a sample use case:
You create a system pool and define a "pool policy". Now any system in Beaker (both outside and inside the system pool) can be access controlled by this pool policy or by its own custom policy.
Ah, so the intent is to allow use of the pool policy without being a member of the pool?
While I like that as a general notion, we may need to consider the UX implications. One possibility might be to segment the pool selection list so pools the system is part of appear first.
Oops - I changed my mind as I thought through the implications, but didn't go back and update this paragraph accordingly.
s/like/see the appeal of/ to fix that :)
Cheers, Nick.
Excerpts from Amit Saha's message of 2015-02-06 12:12 +10:00:
We just published the design proposal for implementing "Predefined access policies for systems" [1].
If you have any questions/comments/suggestions, please do let us know.
[1] https://beaker-project.org/dev/proposals/predefined-access-policies.html
This looks good overall, there is just a few bits of the CLI that don't quite make sense.
Create an access policy for a pool with a single rule:
bkr pool-policy-create --pool=<poolname> \ --permission=reserve --group=qeteam
Remove the pool policy:
bkr pool-policy-remove --pool=<poolname>
Neither of these should be necessary. A pool will always have a policy associated with it. Removing the policy from a pool doesn't make sense, and creating the policy for a pool should not be an explicit step.
The actual adding/removing of rules should use the existing bkr policy-grant/policy-revoke commands, which will need to be extended to accept a new option --pool instead of --fqdn.
Through the bkr cli:
bkr policy-grant --system=test1.example.com --pool-policy <poolname>
The system will now use the access policy defined by the pool. Note that this will not a custom access policy that may already exist for the system. It will just not be applicable.
policy-grant is the wrong subcommand for this. bkr policy-grant is for adding rules to a policy, but the operation here is setting the policy for a system. So it should be a new option --pool-policy=<poolname> on bkr system-modify.
Similarly "revoking a pool policy" doesn't make sense, the operation is actually setting the system to use a custom policy. So this should also be an option on bkr system-modify. Either --pool-policy='' which is a bit awkward, or else a separate mutually exclusive option like --use-custom-policy.
----- Original Message -----
From: "Dan Callaghan" dcallagh@redhat.com To: "beaker-devel" beaker-devel@lists.fedorahosted.org Sent: Friday, February 13, 2015 3:28:05 PM Subject: Re: [Beaker-devel] Design proposal: Predefined Access Policies for Systems
Excerpts from Amit Saha's message of 2015-02-06 12:12 +10:00:
We just published the design proposal for implementing "Predefined access policies for systems" [1].
If you have any questions/comments/suggestions, please do let us know.
[1] https://beaker-project.org/dev/proposals/predefined-access-policies.html
This looks good overall, there is just a few bits of the CLI that don't quite make sense.
Create an access policy for a pool with a single rule: bkr pool-policy-create --pool=<poolname> \ --permission=reserve --group=qeteam Remove the pool policy: bkr pool-policy-remove --pool=<poolname>
Neither of these should be necessary. A pool will always have a policy associated with it. Removing the policy from a pool doesn't make sense, and creating the policy for a pool should not be an explicit step.
The actual adding/removing of rules should use the existing bkr policy-grant/policy-revoke commands, which will need to be extended to accept a new option --pool instead of --fqdn.
Through the bkr cli: bkr policy-grant --system=test1.example.com --pool-policy <poolname> The system will now use the access policy defined by the pool. Note that this will not a custom access policy that may already exist for the system. It will just not be applicable.
policy-grant is the wrong subcommand for this. bkr policy-grant is for adding rules to a policy, but the operation here is setting the policy for a system. So it should be a new option --pool-policy=<poolname> on bkr system-modify.
Similarly "revoking a pool policy" doesn't make sense, the operation is actually setting the system to use a custom policy. So this should also be an option on bkr system-modify. Either --pool-policy='' which is a bit awkward, or else a separate mutually exclusive option like --use-custom-policy.
Thanks for the comments.
I updated the proposal: http://gerrit.beaker-project.org/#/c/3987/1
----- Original Message -----
From: "Nick Coghlan" ncoghlan@redhat.com To: beaker-devel@lists.fedorahosted.org Sent: Tuesday, February 10, 2015 12:33:47 PM Subject: Re: [Beaker-devel] Design proposal: Predefined Access Policies for Systems
On 02/09/2015 10:37 AM, Amit Saha wrote:
So, here is a sample use case:
You create a system pool and define a "pool policy". Now any system in Beaker (both outside and inside the system pool) can be access controlled by this pool policy or by its own custom policy.
Ah, so the intent is to allow use of the pool policy without being a member of the pool?
While I like that as a general notion, we may need to consider the UX implications. One possibility might be to segment the pool selection list so pools the system is part of appear first.
That's a good idea. Considering that there will potentially be a large number of pools and will only increase with time, presenting the ones which the system is a member of first may be a good idea.
Alternatively, we might wish to restrict the UX in the initial implementation to only allowing a choice from pools the system is a part of, rather than all pools. I think that's going to be easier to explain in the documentation, rather than decoupling the two decisions and having to explain that pool membership and pool policy inheritance are actually unrelated. I'm a fan of this approach, as I'm struggling to think of a good use case (or, indeed, *any* use case) for making the two decisions completely independent.
For the use case that a pool owner creates a pool, adds systems to it and wants to use the same pool policy across systems - your suggestion is perfect. What if I want to make use of a random pool's access policy because I just happen to find my requirements are identical but I do not/cannot add my system to the pool?
If we later get an *RFE* to allow use of pool policies for systems that aren't members of that pool, we could consider it based on a concrete use case rather than speculation.
That's what I just did above .. :-)
Best, Amit.
On 02/16/2015 06:09 PM, Amit Saha wrote:
From: "Nick Coghlan" ncoghlan@redhat.com of, rather than all pools. I think that's going to be easier to explain in the documentation, rather than decoupling the two decisions and having to explain that pool membership and pool policy inheritance are actually unrelated. I'm a fan of this approach, as I'm struggling to think of a good use case (or, indeed, *any* use case) for making the two decisions completely independent.
For the use case that a pool owner creates a pool, adds systems to it and wants to use the same pool policy across systems - your suggestion is perfect. What if I want to make use of a random pool's access policy because I just happen to find my requirements are identical but I do not/cannot add my system to the pool?
Then I'd tell you that's a bad idea because you have no idea how that pool's policy is going to evolve in the future. It may meet your needs today, but what about tomorrow? Next week? Next year?
Allowing a system owner to use a pool policy without their system being part of the relevant pool now strikes me as a genuinely *bad* idea, since it creates a dependency without a mutual agreement between the two parties, so the pool owner may change their ACLs without even considering the possible implications for systems outside the pool that may be using that ACL.
By contrast, if systems can only be assigned policies from pools they're members of, then you have a bidirectional agreement:
* someone with management rights on the pool adds the system * someone with management rights on the system chooses that pool's policy
Something this does suggest to me is that it should be possible to have "open pools", where everyone with an account on the Beaker instance is able to add their systems. In access policy rules, I believe "Everybody" is indicated by having both the group and the user be NULL - perhaps the same semantics could be used for the pool owner? (i.e. a pool without any specifically designated owner is an "open pool" where everyone with system policy management access can add and remove their own systems from that pool)
I think it's also a valid use case for being able to clone an existing policy from an arbitrary pool when creating a new pool.
Regards, Nick.
On 02/16/2015 06:01 PM, Amit Saha wrote:
Similarly "revoking a pool policy" doesn't make sense, the operation is actually setting the system to use a custom policy. So this should also be an option on bkr system-modify. Either --pool-policy='' which is a bit awkward, or else a separate mutually exclusive option like --use-custom-policy.
Thanks for the comments.
I updated the proposal: http://gerrit.beaker-project.org/#/c/3987/1
That should be live once the site rebuilds.
In reviewing it, I did notice another missing piece: managing pool ownership after creation.
That may need a dedicated "pool-modify" subcommand.
Cheers, Nick.
Excerpts from Nick Coghlan's message of 2015-02-16 18:30 +10:00:
On 02/16/2015 06:09 PM, Amit Saha wrote:
For the use case that a pool owner creates a pool, adds systems to it and wants to use the same pool policy across systems - your suggestion is perfect. What if I want to make use of a random pool's access policy because I just happen to find my requirements are identical but I do not/cannot add my system to the pool?
Then I'd tell you that's a bad idea because you have no idea how that pool's policy is going to evolve in the future. It may meet your needs today, but what about tomorrow? Next week? Next year?
Allowing a system owner to use a pool policy without their system being part of the relevant pool now strikes me as a genuinely *bad* idea, since it creates a dependency without a mutual agreement between the two parties, so the pool owner may change their ACLs without even considering the possible implications for systems outside the pool that may be using that ACL.
Yes I agree, the system should only be able to use the policy from a pool which it is a member of, not any arbitrary pool. It keeps the UI simpler too (a select rather than a typeahead).
Something this does suggest to me is that it should be possible to have "open pools", where everyone with an account on the Beaker instance is able to add their systems. In access policy rules, I believe "Everybody" is indicated by having both the group and the user be NULL - perhaps the same semantics could be used for the pool owner? (i.e. a pool without any specifically designated owner is an "open pool" where everyone with system policy management access can add and remove their own systems from that pool)
I think it's also a valid use case for being able to clone an existing policy from an arbitrary pool when creating a new pool.
Yes these are both interesting RFEs (open pools and copying policies) but let's leave them out of this first iteration.
From: "Dan Callaghan" dcallagh@redhat.com
Something this does suggest to me is that it should be possible to have "open pools", where everyone with an account on the Beaker instance is able to add their systems. In access policy rules, I believe "Everybody" is indicated by having both the group and the user be NULL - perhaps the same semantics could be used for the pool owner? (i.e. a pool without any specifically designated owner is an "open pool" where everyone with system policy management access can add and remove their own systems from that pool)
I think it's also a valid use case for being able to clone an existing policy from an arbitrary pool when creating a new pool.
Yes these are both interesting RFEs (open pools and copying policies) but let's leave them out of this first iteration.
+1 for listing those as deferred features rather than including them in the proposal.
Cheers, Nick.
----- Original Message -----
From: "Nick Coghlan" ncoghlan@redhat.com To: beaker-devel@lists.fedorahosted.org Sent: Monday, February 16, 2015 6:30:53 PM Subject: Re: [Beaker-devel] Design proposal: Predefined Access Policies for Systems
On 02/16/2015 06:09 PM, Amit Saha wrote:
From: "Nick Coghlan" ncoghlan@redhat.com of, rather than all pools. I think that's going to be easier to explain in the documentation, rather than decoupling the two decisions and having to explain that pool membership and pool policy inheritance are actually unrelated. I'm a fan of this approach, as I'm struggling to think of a good use case (or, indeed, *any* use case) for making the two decisions completely independent.
For the use case that a pool owner creates a pool, adds systems to it and wants to use the same pool policy across systems - your suggestion is perfect. What if I want to make use of a random pool's access policy because I just happen to find my requirements are identical but I do not/cannot add my system to the pool?
Then I'd tell you that's a bad idea because you have no idea how that pool's policy is going to evolve in the future. It may meet your needs today, but what about tomorrow? Next week? Next year?
Allowing a system owner to use a pool policy without their system being part of the relevant pool now strikes me as a genuinely *bad* idea, since it creates a dependency without a mutual agreement between the two parties, so the pool owner may change their ACLs without even considering the possible implications for systems outside the pool that may be using that ACL.
By contrast, if systems can only be assigned policies from pools they're members of, then you have a bidirectional agreement:
- someone with management rights on the pool adds the system
- someone with management rights on the system chooses that pool's policy
Indeed. This is the right way to go about it. I have updated the design proposal: http://gerrit.beaker-project.org/#/c/3989/
It also adds the pool ownership modification use case and possible interfaces.
Best, Amit.
beaker-devel@lists.fedorahosted.org