Enable user impersonation for brokers targeting k8s

[pmorie]

We need to enable user impersonation for brokers that target k8s. The use case for this is that brokers that provision resources into Kubernetes should be able to do so using the identity of the requesting user, so that those resources:

• Are subject to that user's quota / resource constraints
• Are subject to that user's security rules

This means that we need to send:

• The namespace
• The username
• The serviceaccount

in the originating identity header per openservicebrokerapi/servicebroker#222

[pmorie]

cc @bparees @jim-minter @jwforres @jmrodri @liggitt

[bparees]

@pmorie you probably want @jim-minter

[bparees]

Why do we need to send the service account? and what service account would we send? The service catalog's service account?

I agree the broker needs to be able to authenticate the service catalog's request, but that's distinct from impersonation.

[jim-minter]

1. FWIW I don't know what service account is being referenced here.

2. Instead of, or in addition to, a username, it would be great to have the capability of passing an opaque auth token to the broker, which it can use for its authenticating/authorizing its internal provisioning actions. This would save a broker from having to have the rights to impersonate arbitrary end users.

[pmorie]

Service account would be the service account associated with user identity

[bparees]

Service account would be the service account associated with user identity

why would we assume that even exists?

[bparees]

Instead of, or in addition to, a username, it would be great to have the capability of passing an opaque auth token to the broker, which it can use for its authenticating/authorizing its internal provisioning actions. This would save a broker from having to have the rights to impersonate arbitrary end users.

it doesn't make sense to require the service catalog to have credentials for the cluster the broker is talking to. The broker is the abstraction/bridge for the catalog.

That said, it does raise interesting questions for when you have multiple brokers each talking to a different cluster. When the service catalog tells a broker "it's ok to impersonate Bob", that's bob in what cluster? How did the SC validate this is Bob, and this is bob in what cluster?

[duglin]

@pmorie is this related? openservicebrokerapi/servicebroker#110

[pmorie]

@duglin it is!

[jim-minter]

it doesn't make sense to require the service catalog to have credentials for the cluster the broker is talking to

Doesn't it make sense for the service catalog to pass opaque credentials through from the client?

[bparees]

Doesn't it make sense for the service catalog to pass opaque credentials through from the client?

I don't think so. I wouldn't want the service catalog passing my credentials through to random brokers I may not trust.

The broker needs the following:

1. it needs to be able to authenticate the service catalog ("I trust that if you are asking me to do something, i should do it")
2. it needs to be told on who's behalf the request is being made ("I trust the SC, and therefore I trust it when it tells me that Bob made this request")
3. it needs to be trusted by the cluster to impersonate users ("the cluster trusts me to perform actions as Bob")

Now where things get fuzzy is in 2+3 since "Bob" could refer to bob on clusterA, or bob on clusterB. Having the SC gather bob's cluster credentials and pass them straight to the broker certainly "solves" that problem, but i'm pretty sure it opens up bigger problems.

[pmorie]

@jmrodri @eriknelson @luksa @vaikas relevant to your interests

[jmrodri]

@pmorie It is relevant. Though right now we're working wide open. At first I was thinking what @jim-minter was thinking that the service catalog would pass the credentials down to the broker, but @bparees definitely brings up some valid points.

[eriknelson]

+1, I was working under the assumption we'd be given some kind of a permission-scoped token to act on the behalf of the user. Credentials don't feel in the spirit of params, makes sense for context.

Now where things get fuzzy is in 2+3 since "Bob" could refer to bob on clusterA, or bob on clusterB.

Can a broker potentially act on more than one cluster? If so, we'll also need the targeted cluster as part of the context, if I understand this correctly?

[liggitt]

impersonation requires the broker to have all the information about the requesting user:

• username
• group names
• all "extra" attributes (used to plumb information like OAuth scopes, so dropping this can escalate a user)

impersonation also requires the broker to be allowed to act as the user whenever it feels like it

I agree that a permission-scoped token would be better, but kubernetes does not currently mint API tokens for end-users, or have a mechanism for scoping permissions per token.

[bparees]

Can a broker potentially act on more than one cluster? If so, we'll also need the targeted cluster as part of the context, if I understand this correctly?

I don't think there's any restriction on what a broker could "potentially" do (it doesn't have to act on any cluster at all, for that matter). Now as for what simplifying assumptions we want to make for now, I'd defer that to @pmorie and maybe @smarterclayton (and I'm sure there are other key folks involved in that decision, i just don't know all the stakeholders).

It seems like a reasonable assumption that for brokers that provision resources in the requester's name, there is only one cluster in play, and it's the cluster that the SC has already authenticated the requester against, but you're definitely relying on the template broker to understand and respect that. (Otherwise you're back to the case where the SC auth's bob against cluster1, tells the broker "here's bob" and the broker then proceeds to impersonate bob on cluster2, which is bad)

[deads2k]

What if we built an intersecting authorization check instead? A client could specify, "intersect my authorization with this other user.Info's power". A broker could then be granted more limited power like "admin" in most namespaces. Given the user information, the broker could be sure he didn't do anything the user couldn't have done, but compromise of the broker wouldn't allow cluster ending access.

[bparees]

it sounds plausible to me, but we still have the aforementioned problems of making sure "this user" as provided by the SC is the same as "this user" in the cluster the broker is talking to.

[pmorie]

Not an 0.0.2 item

[pmorie]

Moving to 1.0.0, since that is a GA release, and this is unlikely to happen before then.

[pmorie]

This is now in the 'validating-through-implementation' phase in OSB: openservicebrokerapi/servicebroker#222, so we can implement it in the catalog in an alpha way.

[pmorie]

I'm adding this to the 0.1.0 milestone because it's extremely important for brokers that target kubernetes.

[MHBauer]

The kubernetes information is described as " property from the Kubenernetes user.info object."

Is that supposed to be UserInfo ?
This API https://kubernetes.io/docs/api-reference/v1.7/#userinfo-v1beta1-authentication ?