Auth plugins

[erictune]

This supercedes #1358.

Since some folks want a very simple default implementation for auth, and others want to be able to plug in a more full-featured implementation, I've focused on the problem of defining how Authorization plugs in.

In the process, I found I was unable to talk about that without also defining how Authentication and Group Membership should plug in.

I've also removed the text from access.md about "userAccounts", since I no longer feel that is resource type has to be part of kubernetes.

[erictune]

As @smarterclayton suggested, lets have a hangout to discuss auth.
I created a poll to pick a time. Anyone interested is welcome.
http://doodle.com/u62he7769miweses
Once a time is selected, I'll contact folks with meeting details.

[erictune]

Status update:

Hangout happening tomorrow. Progress on modifying or committing this plan expected for after that.

[roberthbailey]

typo: pacakges

[erictune]

fixed.

[smarterclayton]

As per discussion today, LGTM with some follow ups

@liggitt and I will open a quick predesign with the minimal set of in-tree interfaces we need to implement an API handler that can check a token, a simple file based mechanism to serve as the basis for tokens, and the client flags that allow the apiserver to start it. We'll then follow up with a set of pulls (and a pull to this doc) describing a simple oauth server on top of etcd that can sit in the plugins/* dir and serve as a source of oauth flows for tokens which assumes an external user store (of some form). We'll need to sort through what that store's interfaces are.

In parallel we'll want to get the policy / attributes flows you describe here wired in. Some form of ABAC policy is still worth discussing - how do you want to handle that?

[erictune]

I have a mostly written doc describing an ABAC language. I'll send a PR
for that after this merges.

In terms of using and implementing an AuthorizationProvider, I'm happy to
do it. I should probably work on my 0.7 milestone before I do
authorization though.

On Tue, Sep 30, 2014 at 5:42 PM, Clayton Coleman notifications@github.com
wrote:

As per discussion today, LGTM with some follow ups

@liggitt https://github.com/liggitt and I will open a quick predesign
with the minimal set of in-tree interfaces we need to implement an API
handler that can check a token, a simple file based mechanism to serve as
the basis for tokens, and the client flags that allow the apiserver to
start it. We'll then follow up with a set of pulls (and a pull to this doc)
describing a simple oauth server on top of etcd that can sit in the
plugins/* dir and serve as a source of oauth flows for tokens which assumes
an external user store (of some form). We'll need to sort through what that
store's interfaces are.

In parallel we'll want to get the policy / attributes flows you describe
here wired in. Some form of ABAC policy is still worth discussing - how do
you want to handle that?

—
Reply to this email directly or view it on GitHub
#1430 (comment)
.

[erictune]

My notes from hangout:

• need client plugin too (addressed by Refactor the client (again) to better support auth #1500)
• want implicit and explicit login flows separate endpoints
• will eventually want service accounts. these might look like groups. we might want to have an official k8s group representation to support these and to make the group/authz/authn interaction less complex. service accounts are for accessing kubernetes API. Are they different from the idea of having credentials to access some other cloud service, or integrated?
• something about Kubelet security which I forgot byt maybe @smarterclayton remembers

[smarterclayton]

On Oct 2, 2014, at 7:51 PM, erictune notifications@github.com wrote:

My notes from hangout:

need client plugin too (addressed by #1500)
want implicit and explicit login flows separate endpoints
will eventually want service accounts. these might look like groups. we might want to have an official k8s group representation to support these and to make the group/authz/authn interaction less complex. service accounts are for accessing kubernetes API. Are they different from the idea of having credentials to access some other cloud service, or integrated?
something about Kubelet security which I forgot byt maybe @smarterclayton remembers
Protecting the Kubelet API from malicious parties, which includes the HTTP POST API for creating pods

—
Reply to this email directly or view it on GitHub.

[kubernetes-bot]

Can one of the admins verify this patch?