[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Part 1 of role-based access control (RBAC) going in origin master today (fwd)

Not yet.  Probably in a few weeks as the UI gets closed out.

On Sep 4, 2013, at 7:22 PM, Lynn Root <lroot redhat com> wrote:

Hey folks -

Is there a design page for this that I can linked to directly?  This email is great- but hoping for something more 'permanent' and perhaps more in detail.


Begin forwarded message:

From: Jan Pazdziora <jpazdziora redhat com>
Subject: Part 1 of role-based access control (RBAC) going in origin master today (fwd)
Date: August 15, 2013 6:48:11 AM PDT

Role based access control in OpenShift starts to get shapes:

----- Forwarded message from Clayton Coleman <ccoleman redhat com> -----

Date: Wed, 14 Aug 2013 11:20:53 -0400 (EDT)
From: Clayton Coleman <ccoleman redhat com>
To: "dev lists openshift redhat com" <dev lists openshift redhat com>
Subject: Part 1 of role-based access control (RBAC) going in origin master
Sender: dev-bounces lists openshift redhat com

It currently defaults to off (while we fiddle with the UI and make sure the REST API is everything we need), but master this afternoon (via https://github.com/openshift/origin-server/pull/3322) will have the underlying support for the following items suitable for folks to play around with:

 1) Membership on a domain - add users to one of three roles (view, edit, admin) on a domain, and have those permissions and ssh keys propagate to the apps.

 2) Application and domain scopes - create an auth token for a specific application that has a limited set of permissions, so that an automated service machine can scale your app

 3) Multi-domain support in the REST API - each user can create as many domains as they have gears, or a configurable MAX_DOMAINS_PER_USER value which defaults to 1

 4) A domain has a new attribute "allowed_gear_sizes" - an array of all of the gear sizes members of that domain can use to create apps.  Defaults to all possible gear types.

The REST API for membership is exposed in API versions 1.5 and 1.6 and is in PREVIEW - there may be incompatible changes that we will communicate via this list over the next 3-6 weeks as we implement the UI.  

Here are the roles we have now

   - when the user is the owner of a domain - can do anything
   - when the user is NOT the owner of a domain - can do everything EXCEPT change the allowed_gear_sizes, remove the owner, or destroy the domain

 edit - can create applications, ssh to applications, make any changes to applications, but can't change membership of an app or domain.

 view - can only view the data on the broker about the app via the REST API.  Will not be able to view environment variables.  Will not be able to ssh to apps.

We definitely want to add more roles below edit, but we need to build it around concrete use cases.  The model we're using now is either you can't do anything destructive (view), you can be totally destructive but can't grant or remove access (edit), or you can do anything (admin).  

Example API interactions

 Return the list of domains I have access to

   curl -u test:me https://myserver/broker/rest/domains

 Return the list of all applications I have access to (part of Lili's change last sprint)

   curl -u test:me https://myserver/broker/rest/applications

 The list of members on an application or domain:

   curl -u test:me https://myserver/broker/rest/domain/abc/members

   { name ..., members: [
       id: 'unique identifier of member',
       type: 'user',                      # in the future will be team, group, etc
       role: 'view/edit/admin',
       owner: true/false,
       explicit_role: nil or 'view/edit/domain'
         # if not nil, this user is explicitly assigned a role on this resource

 Add a member (SUBJECT TO CHANGE WARNING etc...) if you know the user id

   curl -X POST -u test:me https://myserver/broker/rest/domain/abc/members -H "Content-Type: application/json" -d '{"members": [{"id": "uuid of user", "role": "view/edit/admin"}]}'

 or if you know the user's login

   curl -X POST -u test:me https://myserver/broker/rest/domain/abc/members -H "Content-Type: application/json" -d '{"members": [{"login": "login field of user", "role": "view/edit/admin"}]}'

 You can create an application scope like:

   curl -X POST -u test:me https://myserver/broker/rest/user/authorizations -d scope=application/<uuidofapp>/[view|edit|admin|scale|build]

   If you are granted access to an application via its scope, you are also granted access to its application.

A few other minor changes

 Attempting to create a domain of a different name now returns 409 and an error about being past your limit, but is no longer sending "field" = "name"

 API versions older than 1.5 will not allow you to create multiple domains

 The order domains are returned by /broker/rest/domains is always your domains first, ordered by creation date.  So your first domain is always returned first.

 Attempting to view a resource you don't have access to will respond with 404 Not Found always.  

 403 Forbidden is returned when you try to execute an action you don't currently have permission to do.  A message is included in the 403 response that says what permission you don't have.

Notes for Origin developers

 When you add new controller methods, you need to use the following two constructs to properly protect those resources:

   1) Always query Mongoid on the primary resource using the new "accessible(to)" query filter at the end of the query set:

      e.g. in KeysController#index:


      Accessible applies the scope rules and filters out resources you can't see.  It also applies membership checks for Domains and Applications. EVERY METHOD in a controller needs to be using accessible(...) on the primary resource, and you should add it at the end of the query chain (before you actually do the query to Mongoid).

   2) Any controller method that changes the state in the DB should call the "authorize! <permission>, <resource>" helper as soon as possible in the method

      e.g. in ApplicationsController#create

        authorize! :create_application, @domain

      This checks the current user's role on the domain and then maps the permission to a role (in ability.rb), and then raises the proper exception if the user is denied. There are a set of permissions already mapped to roles, if you have any questions please contact me and I'll help you figure out what should be mapped to what.  

This is a pretty big change, so please ask questions.  We'll be continuing to clean this up over the next few weeks, and drop in the RHC and UI changes necessary to support this.

dev mailing list
dev lists openshift redhat com

----- End forwarded message -----

Jan Pazdziora | adelton at #ipa*, #brno
Principal Software Engineer, Identity Management Engineering, Red Hat

Lynn Root
Associate Software Engineer

dev mailing list
dev lists openshift redhat com

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]