Open Stack

On 10/19/2015 11:53 AM, Fox, Kevin M wrote:
> +1.
>
> I think there may be a slight issue with this and Heat, or any other service depending on Heat though. It would have to be very carefully through through, since Heat acts on behalf of the user as the User him/herself would, so scoping may need to interact differently there, then say Nova. Maybe a flag in the service catalog saying if the service can be scoped or not?

I think there is a subtlety there you are not making clear.  Why would 
Heat, or any other service not be scoped?  The only rule I am seeing in 
Heat's policy would be

|"service:index": "rule:context_is_admin", ||http://git.openstack.org/cgit/openstack/heat/tree/etc/heat/policy.json |

But that certainly suffers from the admin-ess problem.  There is 
certainly something strange with the deny rules;  it is trivial to 
bypass this role with a trust.  Somethin needs a second look there anyway.


>
> Thanks,
> Kevin
> ________________________________________
> From: Adam Young [ayoung at redhat.com]
> Sent: Monday, October 19, 2015 6:53 AM
> To: OpenStack Development Mailing List
> Subject: [openstack-dev] [cross-project] Admin
>
> While I tend to play up  bug 968696 for dramatic effect, the reality is
> we have a logical contradiction on what we mean by 'admin' when talking
> about RBAC.
>
> In early iterations of OpenStack, roles were global.  This is reflected
> in many of the Policy checks that only look for the global role.
> However, prior to the Keystone-Light rewrite, role assignments became
> scoped to tenants.  This shows up in the Keystone git history.  As this
> pattern got established, some people wrote policy checks that assert:
>
>        role==admin and tenant_id=resource.tenant_id
>
> This contradicts the global-ness of the admin roles.  If I assign
> ('joeuser', 'admin','mytenant') I've just granted them the ability to
> perform all of the admin operations.
>
> Thus, today we have a situation where, unless the user rewrites the
> default policy, they have to only assign the role  admins to users that
> are trusted to be admins on the whole deployment.
>
> We have a few choices.
>
> 1.  Remove Admin from the scoping for projects. Admin is a special role
> reserved only for system admins.  Replace project scoped admins with
> 'manager' or some other comparable role.  This is actually the easiest
> solution.
>
> 2.  Create a special project for administrative actions.  Cloud admin
> users are assigned to this project. Communicate that project Id to the
> remote systems.  This is what the policy.v3cloudsample.json file
> (http://git.openstack.org/cgit/openstack/keystone/tree/etc/policy.v3cloudsample.json)
> recommends.
>
> However, 2 is really not practical without some significant
> engineering.  For a new deployment, it would require the following steps.
> 1) Every single policy file would have to be "templatized"
> 2) Then deployment mechanism would have to create the admin project, get
> the id for it, and string replace it in the policy file.
>
> We could make this happen in Devstack.  The same is true of Puppet,
> OSAD, and Fuel.  There would be a lag and the downstream mechanisms
> would eventually pick it up, multiple releases down the road.
> I went through this logic back when I started proposing the Dynamic
> Policy approach.  If OpenStack managed policy deployment via an
> inte4rnal mechanism, then adding things like the admin_project_id
> becomes trivial.
>
>
> While I think Dynamic Policy provides a lot of value, I concede that it
> is overkill for just substituting in a single value.  The real reason I
> am backing off Dynamic Policy for the moment is that we need to better
> understand what part of policy should be dynamic and what part should be
> static;  we are just getting that clean now.
>
>
> There is an additional dimension to the admin_project_id issue that
> several developers want solved.  In larger deployments, different users
> should have administrative capabilities on different endpoints.
> Sometimes this is segregated by service (storage admins vs network
> admins) and sometimes by region.
>
> Having a special project clearly communicates the intention of RBAC.
> But even clearer would be to have the role assignment explicitly on the
> catalog item itself.  Which of the following statements would you think
> is clearer?
>
>
> 1) Assign Joe the admin role on the project designated to administer
> endpoint 0816.
> 2) 1) Assign Joe the admin role on endpoint 0816.
>
> I think you will agree that it is the latter.  Making this happen would
> not be too difficult on the Keystone side, and would require fairly
> simple changes on the policy enforcement of the remote projects.  We've
> already discussed "endpoint binding of tokens" where an endpoint needs
> to know its own ID.  Having a new "scope" in a token that is endpoint_id
> would be fairly easy to execute.
>
>
> One project, though, it that all of the client tooling would need to
> change.  Horizon, openstackclient, and keystoneauth would need to handle
> "endpoint" as the scope.  This includes third party integrations, which
> we do not control.
>
>
> All of these constraints drive toward a solution where we link the admin
> project to the existing endpoint ids.
>
> Make the catalog a separate domain.
> Make regions, services, and endpoints projects
> Use the rules of Hierarchical Multitenancy to manage the role
> assignments for a project.
>
> On the enforcing side, endpoints *must* know their own ID.  They would
> have checks that assert token.project_id = self.endpoint_id.
>
> This is the "least magic" approach.  It reuses existing abstractions
> without radically altering them.  The chance of a collision between an
> existing project_id and and endpoint_id is vanishingly small\, and could
> be addressed by modifying one or the other accordingly. The biggest
> effort would be in updating  the policy files, but this seems to be
> within the capability of  cross project efforts.
>
>
> We will be discussing this at the Cross Project session at the summit
> on Global Admin
>
> https://mitakadesignsummit.sched.org/event/51c8f2ea29aa0b63f85e424b0acf9741
>
> Please read this, process it, and be ready to help come to a proper
> conclusion of this bug.
>
>
> References:
> "admin"-ness not properly scoped
> https://bugs.launchpad.net/keystone/+bug/968696
> Original Dynamic Policy Post
> https://adam.younglogic.com/2014/11/dynamic-policy-in-keystone/
> Current Dynamic Policy Wiki https://wiki.openstack.org/wiki/DynamicPolicies
> Endpoint_ID from URL https://review.openstack.org/#/c/199844/
> Catalog Scoped Roles https://review.openstack.org/#/c/228477/
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151019/8ece53d7/attachment.html>