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

Re: Some thoughts on shared access to applications




----- Original Message -----
> On 09/07/13 14:38 -0400, Luke Meyer wrote:
> >----- Original Message -----
> >
> >> From: "Clayton Coleman" <ccoleman redhat com>
> >> To: "Luke Meyer" <lmeyer redhat com>
> >> Cc: dev lists openshift redhat com
> >> Sent: Tuesday, July 9, 2013 1:36:30 PM
> >> Subject: Re: Some thoughts on shared access to applications
> >
> >> ----- Original Message -----
> >> > I can think of at least three reasons why people may want to group
> >> > apps.
> >> >
> >> > 1. Access control - I want to collaborate with group X on this set
> >> > of apps,
> >> > but not another.
> >> > 2. Grouping layers of a composed app, allowing them to use each
> >> > other as
> >> > resources while possibly scaling separately - for instance, a
> >> > messaging
> >> > layer, an API layer, a UI layer that are all separate apps.
> >> > 3. Access to / specification of shared resources; a Jenkins app is
> >> > a good
> >> > example, but also external DB definitions or other resources.
> >> >
> >> > Not trying to list everything here, but it shouldn't be hard to see
> >> > that the
> >> > different purposes are likely to be orthogonal, and it would
> >> > probably be bad
> >> > to use the domain as the scope for all of them. What is a domain
> >> > really,
> >> > anyway? Right now it's nothing but a device for keeping app names
> >> > unique on
> >> > the cloud domain. Does it need to be anything more than that? It
> >> > seems to me
> >> > that group membership for other purposes should be more of a
> >> > tagging system.
> >
> >> Elaborate? Define tagging?
> >
> >Specify each grouping that an app belongs in as a tag on the app. To
> >illustrate the point with speculative functionality:
> >
> This sorta sounds like the AWS concept of a security context. Would having a
> separate entity (security context) associated with all the other primary
> entities help. It seems like we are trying to derive access control using
> using entity relationships that are there for other purposes rather than
> replying on one discriptor of access control, such as a security context.

So in AWS, every entity is associated with one security context?  Can you compose contexts?

> 
> >If you (a developer) want to allow developers on team A to access a set of
> >apps, you tag all those apps with "access_group: team_A" and somewhere you
> >define who is in team A and what role(s) they get (perhaps this is in
> >LDAP), and that is applied to whatever apps you give that tag.
> >
> >If you want to compose a set of apps into one meta-app and have them find
> >each other according to rules you define, then you tag them as
> >"composed_app: app_A" and the broker connects them with the necessary env
> >vars (something like domain variables today, with Jenkins as the "build
> >layer").
> >
> >If you want to specify a set of env vars that will be used by multiple apps
> >(say, to access a DB) then you tag all those apps as "resource_group: db_A"
> >and something like "rhc set-env db_password=foo --tagged db_A" sets the var
> >for all those apps.
> >
> >And just in case a domain (as we know it today) actually does correspond to
> >something they want to group by (e.g. dev/qa/prod domains with different
> >versions of the same apps may correspond with a resource they all use), it
> >could be an implicit tag ("rhc set-env foo=bar --tagged domain_A"), or
> >there could just be a way to associate all current and future members of a
> >domain explicitly with a tag.
> >
> >The same app could be in multiple groupings, which is what makes me think of
> >tags. So, apps in multiple domains or groupings could use with the same
> >Jenkins builder just by tagging it multiple times, but it would still be
> >easy to have a separate Jenkins for say dev apps and prod apps.
> >
> >> >
> >> > ----- Original Message -----
> >> > From: "Clayton Coleman" <ccoleman redhat com>
> >> > To: "meghdoot bhattacharya" <meghdoot_b yahoo com>
> >> > Cc: dev lists openshift redhat com
> >> > Sent: Monday, July 8, 2013 5:15:45 PM
> >> > Subject: Re: Some thoughts on shared access to applications
> >> >
> >> > One of the biggest challenges, as we move from the single-domain
> >> > per account
> >> > model, is to adapt how we think about domain-wide concepts like
> >> > Jenkins
> >> > today. The simple path we've started on is a domain-wide
> >> > application.
> >> > E.g.:
> >> >
> >> > I have a domain A
> >> > When I add Jenkins in A, all other applications have access to it
> >> > Jenkins contributes "domain" environment variables that all other
> >> > apps have
> >> > access to.
> >> > Once Jenkins exists, I can add the jenkins client cart to other
> >> > apps in A
> >> > The Jenkins client cart uses the domain wide environment variable
> >> > to check
> >> > whether it's installable
> >> > If Jenkins is removed, it removes the jenkis client cart from other
> >> > apps in
> >> > A
> >> >
> >> > If we start to use domains to scope sets of users, how does Jenkins
> >> > react? I
> >> > personally would be frustrated having to have one Jenkins per
> >> > domain,
> >> > because Jenkins either costs me money or provisioning space (Online
> >> > vs
> >> > Enterprise). Hypothetically, what sorts of changes are required to
> >> > support
> >> > concepts like a shared Jenkins across domains:
> >> >
> >> > Each user may have different access to different domains
> >> > - adding the Jenkins Client and pointing it to a Jenkins server
> >> > domain B
> >> > may mean that some users in domain A can't see the server
> >> > - the info the client needs is from variables (url, user, and
> >> > password) so
> >> > the broker access is redundant
> >> >
> >> > The Jenkins server needs to know which Jenkins clients are
> >> > connected to it
> >> > so it can disable the client carts if it's removed
> >> > - because that could be every domain in the server, we'd need to
> >> > track the
> >> > "connection" between the server and client differently
> >> >
> >> > The Jenkins client won't have access to the domain wide environment
> >> > variables
> >> > - instead, the Jenkins client needs to be able to get access to the
> >> > info
> >> > about the jenkins server on install
> >> > - the broker could pass it, but then the broker has to know about
> >> > specifics
> >> > of environment variables
> >> > - The env var would have to be removed on deletion
> >> >
> >> > Thinking through the problem, it seems like what we would be trying
> >> > to do is
> >> > register a "connection" between a jenkins server and client. The
> >> > server
> >> > needs to expose a set of arbitrary info that the client must
> >> > consume. That
> >> > connection seems to be very similar to cartridge hooks, just
> >> > between apps.
> >> > One possible approach might be to allow client cartridges to
> >> > indicate they
> >> > have an external dependency that must be satisfied (app with
> >> > component X) on
> >> > creation, and then allow the client and server to expose an
> >> > "external"
> >> > connection hook that the broker could resolve prior to creation.
> >> >
> >> > For example:
> >> >
> >> > 1) User attempts to add jenkins-client to an app
> >> > 2) Broker sees that jenkins-client declares a "jenkins-server"
> >> > dependency
> >> > that is cross-application
> >> > 3) Broker looks in the domain for an app that can satisfy that
> >> > component
> >> > dependency
> >> > a) if it finds multiple, or none, the user will have to specify the
> >> > appropriate app
> >> > b) when adding a cart, user would have to tell the REST API what
> >> > app
> >> > should satisfy the dependency, including any app they have access
> >> > to
> >> > c) some thought must be given to backwards compatibility with
> >> > clients
> >> > 4) The broker checks for an external subscribe connection hook on
> >> > the
> >> > client cart and attempts to match that to an external publish hook
> >> > in the
> >> > server cart
> >> > 5) If it succeeds, it runs the server publish hook, then includes
> >> > that
> >> > output on the cartridge creation (or triggers the hook as part of
> >> > config)
> >> > 6) Cart configure succeeds or fails based on whether the input from
> >> > #5 is
> >> > acceptable, broker reports that back
> >> >
> >> > Obviously speculative, and is not the first problem we would go
> >> > solve... but
> >> > there are some interesting parallels there to app<->app connection
> >> > hooks and
> >> > how we would track and manage that.
> >> >
> >> > ----- Original Message -----
> >> > > 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
> >> > > ***********************************
> >> > >
> >> > >
> >> > >
> >> > > _______________________________________________
> >> > > dev mailing list
> >> > > dev lists openshift redhat com
> >> > > http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
> >> > >
> >> >
> >> > _______________________________________________
> >> > dev mailing list
> >> > dev lists openshift redhat com
> >> > http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
> >> >
> 
> >_______________________________________________
> >dev mailing list
> >dev lists openshift redhat com
> >http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
> 
> 


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