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

Re: Kerberos 5 authentication for gear access (ssh and ssh+git) - Should this get a PEP?




On Jul 5, 2013, at 1:32 PM, Mark Lamourine <markllama redhat com> wrote:

> 
> 
> ----- Original Message -----
>> 
>> 
>> On Jul 5, 2013, at 1:11 PM, Mark Lamourine < markllama gmail com > wrote:
> SNIP
> 
>> 
>> 
>> Exactly. It would be impossible (without some validation) to prevent an
>> authorized OpenShift user from granting gear access to a user who might have
>> a company approved principal but who is not authorized (by policy) to access
>> OpenShift gears.
>> 
>> Since the goal is to give an organization better control of gear access, this
>> would eventually have to be fixed.
>> 
>> Is this an audit problem or a prevention problem? You can always do the
>> enforcement of that at the node level as well, which allows nodes in
>> different geos/ districts to make their own decisions. The broker typically
>> would not make that determination up front because it is a placement/runtime
>> binding.
> 
> The ssh keys and/or krb5 principals are entered at the broker (via console or CLI/REST).  For an SSH key, validation then makes no sense (unless the keys are also stored in LDAP so they can be selected or checked from it). Why would you not want to validate new entries  against an existing known list at entry time so that the entering user can be assured that they haven't typo'd or something?  

Different problem, this is more of a user nicety than a hard requirement.  There's nothing stopping me from adding incorrect public keys, or adding a Kerberos principal that is not yet in use.

> If you delay the check it just looks to the user who's failing logins like the end account is screwed up.

So here's a concrete example.  I am a production administrator.  I am not legally allowed to access user applications running in certain geographies (europe, china, etc).  The broker has to be agnostic of that requirement, because gear placement is pretty generic, and mucking with key distribution at that level is ugly (possible, but to me it screams inappropriate abstraction).  So while my principal may be distributable to all nodes, some sets of nodes may simply deny my principal access.  Denial at the gear level can be communicated in many ways - perhaps my access denial is temporary, time based, etc.

Also, there is nothing preventing you from having two sets of principals, those assigned to the administrative functions of your apps, and those related to node access.  In that case you're not validating against Openshift, but you are deploying something specific to a particular infrastructure.  Generally those sorts of problems are handled as plugins - we can allow someone to validate, but if you solve automatic principal provisioning you generally wouldn't have this problem.

> 
> BTW, this is *not* something I'm expecting to do in the first iteration.
> 
> - Mark
> 
> 
> 
>> --
>> ----
>> Mark Lamourine < markllama gmail com >
>> Dad, Hubbie, Software Developer, System Administrator, Road Cyclist
>> 
>> _______________________________________________
>> 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]