Authorization and Policies

Here are some thoughts on how to make authorization pluggable, and how to express authorization policy.


> On Sep 18, 2014, at 4:58 PM, Joe Beda <notifications@github.com> wrote:
> 
> In docs/authorization.md:
> 
> > +
> > +### HTTP responses
> > +
> > +The HTTP responses for authentication and authorization failures are chosen to balance between allowing debugging and preventing information leakage.
> > + - If the user cannot be authenticated, then `401 Unauthorized` is returned, and `WWW-Authenticate` header is set.
> > +    - Prevents leakage of information contained in namespace names.
> > +    - `401 Unauthorized` and `WWW-Authenticate` required by some standards.
> > +    - despite its name, `Unauthorized` appears to be the correct error code for authentication failures.
> > + - If the request is to GET an object that does not exist, return `404 Not Found`.
> > +    - it was not found.
> > + - If the _subject_ attribute fails to matches the subject section of any policy with the empty namespace or the same namespace as the resource being requested, then return `404 Not Found`.
> > +    - Prevents leakage of names of namespaces and names which the user does not have any association with, and which might contain sensitive information in a multi-tenant setup.
> > + - Last, check if the _subject_ is authorized to _verb_ that _object_.  If not, return `403 Forbidden`.
> > +    - User can debug whether a call failed due to policy problem or incorrect name.
> > +
> > +## Default Implementation
> There is a danger in making a default implementation here. The danger is that it'll be assumed to be part of base k8s and that users will assume that it is there. I'd rather do something like have a default that just allows everything and then perhaps a simple file based policy engine on the master (or etcd?). We can build out an API based engine as we see the need. Our default install would use the 'yes' engine.
> 
Definitely a danger, unfortunately we have a shorter term need for this so either way we'd end up implementing something.  We can possibly try to consider that an "idea test" implementation which sits outside the core service and serves as a useful test bed.
> —
> Reply to this email directly or view it on GitHub.