Bedrock auth sources

[erictune]

The APIserver can authenticate users using a Bearer Token.
Currently, these can only be provided in a file, via --token_auth_file.

We should provide a way to get a token from the apiserver based on an external ("bedrock") authentication source.

Steps:

• add endpoint, e.g. "/login" to apiserver which serves a form which allows you to select a bedrock auth provider, click something, be redirected to that provider's site, be establish identity and allow apiserver to learn that identity
• maybe a similar flow, but for automated consumption by kubectl, etc.
• add "authentication plugins" for a couple authn providers, such as google.com and github.com.
• generate token (with some expiry) and give it to the user to cut from the UI and paste it into their .kubernetes_auth (or return as a parsable body for automated flow)
• make sure user records from different auth sources can't collide.

References:

• Allow actors against the apiserver to be authenticated and actions to be authorized #443
• Auth plugins #1430
• [https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/authentication.md]

[smarterclayton]

@liggitt had implemented several variants of this already in OpenShift - we should work to share the code we have where possible.

For instance here https://github.com/openshift/origin/tree/master/pkg/auth/oauth/external there are packages for both google and github, and we have people working on token generation for cut and paste to cli.

We've implemented oauth round trip, storage of tokens in etcd, grant flows, login with session cookie, oauth login provider that connects to a backend client credential cert, etc.

It's likely something we want in plugins rather than in core kube, with the option to run the server.

[liggitt]

In origin, we have an OAuth server (based on github.com/RangelReale/osin) with pluggable handling of:

• login flows
• grant approval flows
• storage (for OAuth clients, client authorizations, access tokens, and authorization tokens)

For login flows, we currently have:

• Simple username/password login form, backed by a password-authenticator interface
• Log in via Google or Github OAuth and extract identity on return

For grant approval, we have:

• Auto-grant
• Simple grant approval form

For OAuth-related storage, we have:

• etcd-based (with corresponding API objects and handlers)

[smarterclayton]

We also will shortly have the "start flow and then give me a page that i can copy and paste the token".

As a way of attacking this, I would think we could structure this into a series of pulls to Kube plugins/auth/... and try to break it into an optional package someone could use (unless we want Kube to always be the token vendor).

[liggitt]

All of the login/grant flows make sense as plugins. I have mixed feelings about the OAuth server (and OAuth-related storage)... it makes it really hard for clients to interact in a consistent way if there's not a predicable place to go to start the token request.

[smarterclayton]

Let me know when you have your pull drafted so we can discuss the specifics. @erictune, do you want to do an auth hangout this week and talk more details?

----- Original Message -----

All of the login/grant flows make sense as plugins. I have mixed feelings
about the OAuth server (and OAuth-related storage)... it makes it really
hard for clients to interact in a consistent way if there's not a predicable
place to go to start the token request.

---

Reply to this email directly or view it on GitHub:
#2202 (comment)

[erictune]

Sure. Why don't you setup whatever sort of hangout works best for you,
since I didn't get it right last time.
I'm free 7:30am -> 4pm Pacific this week except thursday after noon.

On Mon, Nov 10, 2014 at 10:41 AM, Clayton Coleman notifications@github.com
wrote:

Let me know when you have your pull drafted so we can discuss the
specifics. @erictune, do you want to do an auth hangout this week and talk
more details?

----- Original Message -----

All of the login/grant flows make sense as plugins. I have mixed feelings
about the OAuth server (and OAuth-related storage)... it makes it really
hard for clients to interact in a consistent way if there's not a
predicable
place to go to start the token request.

---

Reply to this email directly or view it on GitHub:

#2202 (comment)

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

[jheiss]

I'm interested in something along these lines. This ticket is a bit old and I'm not sure how it relates to the auth provider framework introduced in #23066.

My use case has Kerberos as the bedrock authentication source. I have written a bearer token issuing/verification service, and point kube-apiserver at it via the webhook token authentication feature. I'm currently wrapping kubectl with a script that authenticates to my service with Kerberos, gets a bearer token, runs kubectl config set-credentials, then execs kubectl. It would be nice if I could eliminate that wrapper script somehow.

[smarterclayton]

We integrated kerberos into openshift via the challenge client concept, which is vaguely on the roadmap to add to Kube and the eventual kubectl login. In theory we could allow kubectl login to exec down to a child process that can negotiate for your bearer token.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle rotten
/remove-lifecycle stale

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close