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

Re: Some thoughts on shared access to applications



Much needed and highly anticipated feature. Not only for practical considerations where different groups: dev, release engineers, 24X7 Ops would want to operate on the same application for different aspects of management, the simplest case during feature development where a dev asks the teammate to debug an app in their gear independently can be easily supported without the need of sharing explicitly ssh keys and rhc tokens.
Something like multiple domains per User can be used to have isolated mesh of interconnected apps/topology.
Personally from my view point I like the role classification described.
Thx



From: "dev-request lists openshift redhat com" <dev-request lists openshift redhat com>
To: dev lists openshift redhat com
Sent: Saturday, July 6, 2013 9:00 AM
Subject: dev Digest, Vol 16, Issue 23

Send dev mailing list submissions to
    dev lists openshift redhat com

To subscribe or unsubscribe via the World Wide Web, visit
    http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
or, via email, send a message with subject or body 'help' to
    dev-request lists openshift redhat com

You can reach the person managing the list at
    dev-owner lists openshift redhat com

When replying, please edit your Subject line so it is more specific
than "Re: Contents of dev digest..."


Today's Topics:

  1. Some thoughts on shared access to applications (Clayton Coleman)
  2. Munin plugins for OpenShift (Tim Bielawa)


----------------------------------------------------------------------

Message: 1
Date: Fri, 5 Jul 2013 16:27:48 -0400 (EDT)
From: Clayton Coleman <ccoleman redhat com>
To: Openshift Dev <dev lists openshift redhat com>
Subject: Some thoughts on shared access to applications
Message-ID:
    <2128282006 24947482 1373056068712 JavaMail root redhat com>
Content-Type: text/plain; charset=utf-8

There's been discussion recently about how multiple users could access an individual application.  There have been various comments on it over time - I wanted to summarize the latest thinking and start a discussion about the various features/behavior.

Current model:

  A CloudUser *owns* a Domain, which *contains* zero or more Application
  A Domain is a logical grouping of Applications

  Application
    -> domain (contains)
    Domain
      -> owner (owns)
      CloudUser

  Application has SSH keys from its owner (app.domain.owner.ssh_keys)
  The usage and limitations of the application reflect the capabilities of the owner domain (the ability to upload client certificates, etc)


Possible changes:

  A CloudUser may own many Domains
  A Domain has one or more Members
  An Application has one or more Members
  All Members of a Domain are Members of the contained Applications
  A Member has a Role within an Application or Domain
  A Member who has a Role on a Domain, has an equivalent Role on the contained Applications
  Members have *view* access on the resource and any contained resources
  Applications receive SSH keys from all Members with sufficient access
  A CloudUser has *view* rights on CloudUsers on the Domains they are a Member of
    (i.e. you can only see users you collaborate with)
  A configuration setting would allow CloudUsers to view all other CloudUsers
    Otherwise, adding a user would require sharing an Invitation via a unique secret
 
  Possible future additions:

  A Team has one or more Members
  A Team has *access* to one or more Domains
  A Team has a Role, that is assigned to all Members when they are added to domains
  A Member may be assigned a more limited Role on a specific application


Here are some proposed Roles (roles inherit the permissions of lesser roles).  Multiple names are suggested as examples

  read/view
  - can view the application or domain in the REST API
  - no access to viewing environment variables or SSL certificates

  control/ops/monitor
  - can stop/start/restart individual gears or the entire application
  - can change scale factors
  - can read and set environment variables
  - can view and set aliases, including SSL certificates

  developer/deployer
  - can add/remove cartridges
  - can trigger builds or deployments
  - can create applications in a domain (and delete apps they created?)

  manager/admin
  - can add/remove users, change roles, delete applications, delete domains

  owner
  - can transfer ownership of a domain


We've discussed splitting SSH access off into a separate variable - a Gear Role:

  none
  - the Member's SSH keys are not transferred to the gear, and so has no SSH or Git access

  edit/write/push/ssh
  - can SSH to the gear
  - can push changes to Git

  * In the future, it might be nice to have a role in between none and edit/write where the user has only read access to the gear.  This is a fairly complex implementation though and needs more thought.

  * All owners and admin/managers are implicitly edit/write/push/ssh enabled (since they can change their own roles).


Some simplifying assumptions we've discussed:

  All access to applications is implicit by virtue of Domain membership

  - You are granted access to an application by virtue of being a Member of the containing domain
  - The point of a Domain is to group applications.  Since grouped applications often have security interconnections, it's natural to make the assumption that access to one is implicitly granting access to all.  Multiple domains can be used to partition applications.
  - This also simplifies the access control protection on domains - many clients may need to access only a single app, but want to use the existing API to navigate to the app.  Backwards compatibility is pretty important here

  Team membership would be denormalized to the Applications

  - Allows fast read access control patterns for showing a list of applications you have access to and checking membership
  - Has the possibility to introduce "membership storms" where adding a user to a team triggers jobs on hundreds of applications.  Team membership changes might be queued centrally to avoid this
  - The "team" would also be a member on the app
  - Denormalization has to be handled cleanly so that removing a user from the domain doesn't remove the Member entry for a user from the team
 
  Any sort of external group integration would map to a Team
 
  - For instance, to map an LDAP group to a Team, you would store a bit of metadata with the Team and then when the user logs in you could do an initial LDAP groups -> team check to provision the user.  A background process would manage LDAP removal.  Only active OpenShift users would be materialized into the Team (prevents excessive group operations)

  Inheritance of roles

  - Rather than do complex permission bits, it's conceptually simpler to have a set of nested roles where each level lets you do more things.  If we can get the roles right, that makes the modelling and behavior a lot easier to control.
  - A lot of operations on the app are destructive (i.e. stopping an app means the app is useless).  So most of the higher roles are ordered from least to most destructiveness


Queries that have to be fast:

  - List of applications I have access to
  - List of domains that I have access to
  - Do I have access to this domain/application?

  The most efficient model for those queries is going to be a list of members on each application object, with an index on the nested member ids.  We are explicitly assuming high hundreds of users on each application, which means the index selectivity will be high.  Also, given that the list of applications may span tens or hundreds of domains, the info needed for generating a REST API response needs to be denormalized from the domain onto the application (probably just domain_namespace).

I'm sure I've left some stuff out - please ask if something fundamental is missing.



------------------------------

Message: 2
Date: Fri, 05 Jul 2013 17:11:40 -0400
From: Tim Bielawa <tbielawa redhat com>
To: "Openshift Dev" <dev lists openshift redhat com>
Subject: Munin plugins for OpenShift
Message-ID: <87wqp4k8z7 fsf deepfryer rdu redhat com>
Content-Type: text/plain; charset="us-ascii"


I wrote a simple munin plugin for charting gears present/idle on nodes
[0]. All the relevant bits are available on GitHub [1].

Does anyone else have any useful plugins written for Munin+OpenShift? I
couldn't find any in a standard 5-second Google search for "munin
openshift".

Obligatory pretty pictures (fancier ones are in references):

https://raw.github.com/tbielawa/openshift-munin-plugins/master/gears_present.png

https://raw.github.com/tbielawa/openshift-munin-plugins/master/charts/openshift_gears_present-node01.ose-poc.png


I'd love to collaborate if there's any interest in this beyond what I've
done already (pull requests accepted).


Enjoy!

[0] http://blog.lnx.cx/2013/07/05/a-munin-plugin-for-openshift/
[1] https://github.com/tbielawa/openshift-munin-plugins

--
Tim Bielawa, Software Engineer/Scribe
      We are all cloud
GCA - Production Control Team (RDU)
919.332.6411 Cell | IRC: tbielawa (#gca)
1BA0 4FAB 4C13 FBA0 A036  4958 AD05 E75E 0333 AE37
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 162 bytes
Desc: not available
URL: <http://lists.openshift.redhat.com/openshift-archives/dev/attachments/20130705/d9b99466/attachment.bin>

------------------------------

_______________________________________________
dev mailing list
dev lists openshift redhat com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev


End of dev Digest, Vol 16, Issue 23
***********************************



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