Moar authorization attributes

Based on PR #2117.

Future PRs will
  - refactor the growing code duplication in `test/integration/auth_test.go`.
  - replace injected Authorizer with a new authorization mode and acl file.
  - improve documentation.
 

I considered creating the authorizer object outside master.New().  But that
reduces the coverage of a test like auth_test.go.  Testing is extra
important for security because a security regression is less likely to be
reported and more likely to result in a significant loss than a functional
regression. One answer is to use an e2e test to cover code in
cmd/apiserver, such as the factory for authorizers and its use of flags.
But I don't like that answer very much.   First e2e tests are miserable to
develop.  And when you add in multiple binaries needing testing like
Brendan's kubernetes single binary, and make it easy for users to wrap
authorizers like you suggested, then that is way to many combinations to
e2e test.

Thoughts?
On Nov 2, 2014 9:53 AM, "Clayton Coleman" <notifications@github.com> wrote:

> In pkg/master/master.go:
>
> > @@ -315,11 +317,18 @@ func (m *Master) init(c *Config) {
> >  	}
> >
> >  	// Install Authorizer
> > -	authorizer, err := apiserver.NewAuthorizerFromAuthorizationConfig(m.authorizationzMode)
> > -	if err != nil {
> > -		glog.Fatal(err)
> > +	var authorizer authorizer.Authorizer
>
> One concern here - now that the authorizer is part of Master, it's
> impossible for a consumer of Master to inject an authorizer wrapper that
> mutates or alters the behavior of the core authorization. So anyone
> attempting to load Master but alter authorization behavior (i.e. the mode,
> or the new from file location) is out of luck. I'd prefer that the master
> have the authorizer passed on config, and that authorizer construction
> happen before you initialize the master. If that conflicts with anything I
> said before, I apologize.
>
> Some concrete examples - we'd like to do the following things, probably in
> the same space of time that the work here is evolving:
>
>    - Load the policy from etcd
>    - Disable the policy altogether
>    - Generate an admin user on the fly on first startup and if not set,
>    assign a policy to them automatically
>    - Wrap the policy logic to contextualize from namespace (project).
>
> Having the authorizer initialized inside master.New essentially blocks any
> of that, which makes it harder to prototype or test aspects of authorizer
> functionality.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/GoogleCloudPlatform/kubernetes/pull/2122/files#r19713399>
> .
>