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 guess I don't see the argument that it's impossible to properly test auth without everything configured under New.  I agree that different apiserver code should be able to easily parameterize input (cli or test) and then apply it to the master, but that can also be done by providing the necessary factory methods on master.  My take would be something like client.Config that has a Bind flags function, and use that as a factory for auth.  I agree as well that it should be easy to properly initialize the master with and without auth in the existing binary, in brendans new all-in-one, and in integration tests.  But if it's not possible to more finely control that auth definition that means it's much harder to reuse that code to build component plugins, which leads to further problems.  How else will they be able to ensure they properly implement those concerns?

This strikes me as a pretty classic composition problem - master is the confluence of many different problem domains, but if it's impossible to test in isolation if it becomes coupled in too many directions and hides details.  Breaking those pieces up should improve tests, not reduce them.

> On Nov 2, 2014, at 4:58 PM, Eric Tune <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
> 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?
> …
> —
> Reply to this email directly or view it on GitHub.