Authorization and Policies

Here are some thoughts on how to make authorization pluggable, and how to express authorization policy.
I'm fine with that.

Let's do an open auth / z / n hangout this week and talk through various aspects

> On Sep 19, 2014, at 6:56 PM, erictune <notifications@github.com> wrote:
> 
> In docs/authorization.md:
> 
> > +type Authorizer interface {
> > +  Authorize(a Attributes)
> > +}
> > +```
> > +to determine whether or not to allow each API action.
> > +The APIserver will have a caching layer to avoid repeated calls to `Authorize` with the same arguments in a short time span.  As a consequence, policy changes will not take instant effect.
> > +
> > +_TBD: It is not yet determined whether the pluing implementation will use redirects, will use the APIserver as a multiplexer.  In the latter case, the APIserver could handle authentication and authorization before muxing to plugins.  In the former case, plugins need to also implement authentication and authorization, perhaps with a common library, if they are also written in Go._
> > +
> > +### Attributes
> > +
> > +The APIserver composes a set of Attributes from the request to pass to the `Authorize` function.
> > +```go
> > +type Attributes struct {
> > +  // Subject attributes
> > +  User string       // a user identifier (e.g. "alice@example.com" or "alice.openid.example.org")
> I'm no longer thinking that kubernetes needs a userAccount REST resource. If you agree with this overall approach, then I'll also update access.md in this PR to delete references to userAccount.
> 
> —
> Reply to this email directly or view it on GitHub.