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..."
1. Some thoughts on shared access to applications (Clayton Coleman)
2. Munin plugins for OpenShift (Tim Bielawa)
Date: Fri, 5 Jul 2013 16:27:48 -0400
From: Clayton Coleman <ccoleman redhat com
To: Openshift Dev <dev lists openshift redhat com
Subject: Some thoughts on shared access to applications
<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.
CloudUser *owns* a Domain, which *contains* zero or more Application
A Domain is a logical grouping of Applications
-> domain (contains)
-> owner (owns)
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)
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
view the application or domain in the REST API
- no access to viewing environment variables or SSL certificates
- 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
- can add/remove cartridges
- can trigger builds or deployments
- can create applications in a domain (and delete apps they created?)
- can add/remove users, change roles, delete applications, delete domains
- can transfer ownership of a domain
We've discussed splitting SSH access off into a separate variable - a Gear Role:
- the Member's SSH keys are not transferred to the gear, and so has
no SSH or Git access
- 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.
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
. All the relevant bits are available on GitHub .
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
Obligatory pretty pictures (fancier ones are in references):https://raw.github.com/tbielawa/openshift-munin-plugins/master/gears_present.pnghttps://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).
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
Size: 162 bytes
Desc: not available
dev mailing listdev lists openshift redhat comhttp://lists.openshift.redhat.com/openshiftmm/listinfo/dev
End of dev Digest, Vol 16, Issue