[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?




----- 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?  If you delay the check it just looks to the user who's failing logins like the end account is screwed up.

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]