Authorization and Policies

Here are some thoughts on how to make authorization pluggable, and how to express authorization policy.


> On Sep 19, 2014, at 6:45 PM, erictune <notifications@github.com> wrote:
> 
> In docs/authorization.md:
> 
> > +}
> > +```
> > +
> > +#### Subject attributes
> > +The format and semantics of the User and Groups strings depends on the authentication setup.
> > +
> > +*TBD: how groups list gets populated.  Does this come from identity provider, or from a kubernetes API resource, or somewhere else.  Getting it from the authentication provider is attractive when integrating with a system like LDAP that knows users and groups, or a system like OpenAM that stores membership data.  But it is not clear that group information is readily available from all identity providers.*
> > +
> > +
> > +#### Verbs
> > +
> > +A verb is a string which describes the action being taken.  Kubernetes core code defines the following mappings from (HTTP method, object Kind) to verb.
> > +
> > +HTTP Method        | Resource prefix         | Verb
> > +------------------ | ----------------------- | ----
> > +GET                | /pods                   | core.read
> namespace.write is special because it lets people add and delete namespaces. That's not something I think average core.writer-ers need, but it is definitely less dangerous than cluster.write.
> 
At least so far there hasn't been an explicit delete proposed, and I don't know if namespace add is an action so much as the authz layer allowing an action against a previously undefined namespace.  We may not want to call it add/delete when describing it (it's been confusing some folks on our end).=