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

Some thoughts on shared access to applications

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

    -> 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)

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

   - can 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 Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]