Added proposal for "acting-as". #16933

erictune · 2015-11-06T19:05:01Z

This change is

erictune · 2015-11-06T19:19:49Z

@smarterclayton @liggitt @pweil- @pmorie @lavalamp @bgrant0607

erictune · 2015-11-06T19:19:55Z

smarterclayton · 2015-11-06T19:46:10Z

Not a ton of time to comment today, but in general some form of scoped delegation on behalf of the user is good. It's even better if it's the intersection of a service account for the controller (scoped) and the user context (scoped). Or even further, a named scope that the delegation occurs in (permission is intersection of controller, user, and a scope the controller applies).

erictune · 2015-11-06T20:06:27Z

@smarterclayton I don't want to involve a human user in the intersection. It should be possible for a human user to create a replication controller, and then leave the company, thus no longer appear in ldap, and that replication controller should not stop working. That is too tight a coupling between a corporate database and a production system. We've tried that tight coupling, and bad things happen.

erictune · 2015-11-06T20:29:54Z

@smarterclayton @liggitt does openshift already do something in this area?

smarterclayton · 2015-11-06T21:09:20Z

It should be possible for a human user to create a replication controller, and then leave the company, thus no longer appear in ldap, and that replication controller should not stop working.

Sorry, wasn't implying that. I was merely saying that the actor the RC is acting on behalf of should be the service account (which is a user), and it should be clear that the "on behalf of" and the RC's permissions should be able to be made safe.

smarterclayton · 2015-11-06T21:20:01Z

I personally do not believe end users should be the "actors" in the system except for very transient things (things that should run to completion within the scope of a period of employment with 99.9% certainty)

erictune · 2015-11-06T21:35:38Z

Agreed.

smarterclayton · 2015-11-06T22:17:04Z

We run all controllers (well, almost all) under their own service accounts
that are only granted a subset of roles. However, they still often end up
with the ability to create pods across all namespaces (at least some of
them).

We do use pod security policy to limit the impact of the creation for many

the service account in the namespace must have the appropriate
permissions, so the controller is not any more privileged than the highest
role a service account in the namespace has.

On Nov 6, 2015, at 3:30 PM, Eric Tune notifications@github.com wrote:

@smarterclayton https://github.com/smarterclayton @liggitt
https://github.com/liggitt does openshift already do something in this
area?

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

liggitt · 2015-11-08T05:31:15Z

docs/proposals/acting-as.md

+  master This does require users to change their flags, but we can support the
+  old way for several release cycles.
+- change apiserver to recognize an "Acting-As" header in requests, and to check whether the
+  originally authenticated user is able to act as that user.


do you envision only being able to act as a user, or also as a group?
how do you envision the authn layer checking if a user (or group) is allowed to act as another user?

I envisioned only being able to act as a user. I envision that the steps are:

authenticate user as we do today

authorize user to act-as another user

lookup group membership of (effective) user

authorize REST action using effective user and its group membership

I was thinking that we would only let you act-as a kubernetes ServiceAccount, not as another type of account. Since ServiceAccount is a kubernetes object, it can be referenced in Openshift (or other) Policy statements. So, you can have a Policy and Role like this:

kind: Role ... rules: - resourceNames: [ "namespace/foo/serviceAccounts/default", ...] - verb: ["actAs"] ----- kind: roleBinding ... usernames: ["system:replicationController"] roleRef: "that one up there"

which says that user "system:replicationController" can "actAs" (or maybe "use") the default service account for namespace foo (and probably every other namespace, as they get added.)

liggitt · 2015-11-08T06:14:12Z

cc @deads2k

deads2k · 2015-11-09T16:14:18Z

docs/proposals/acting-as.md

+1. this is a common class of bugs in systems such as this.
+1. we might trust ourselves to keep controllers in the main repo free from these bugs;
+   but we will not have time to closely review contributed code for these bugs.
+1. out authorization rules will get more complex over time, so deputies will have


typo "out" should be "our"

deads2k · 2015-11-10T13:33:52Z

Pulling @liggitt's comment out into the main thread:

It could help with the confused deputy, but it depends when it gets confused... if the problem is that it gets tricked into doing something cross-namespace, it could correctly lower its permissions to scope to the namespace it was tricked into, but it would be too late...
Do you envision changing controllers to operate on a single namespace at a time? That seems more likely to help, but also have a much larger performance impact (N list operations instead of a single one across all namespaces, etc)

I share the concern. I definitely want the ability for a user to act as a ServiceAccount, but I'm not certain that this approach reduces the trust required for controllers. Whoever enables the controller must still trust that the controller switches identity correctly. Meaning that the controller is triggered to request the correct SA and that code for selecting an SA is not bugged. That seems like I'm still trusting the controller to properly use all the permissions it has for its own identity and all the transitive permissions it gets from the SAs its allowed to act-as.

I still want the feature to allow a regular user to act as a more privileged service account for some tasks (sort of like sudo), but I'm not sure this helps with the controller trust problem.

lavalamp · 2015-11-10T16:12:04Z

Is there a rule we can enforce to make controllers extremely unlikely to
have such bugs? Like, every object/request must have a "acting-as"
field/header, and the controller's own identity is not allowed to actually
perform mutations, only to list the appropriate things? I think that would
prevent the controller from accidentally using its own identity.

But I also think that at some level you have to trust that the system
components handle identity correctly.

On Tue, Nov 10, 2015 at 5:34 AM, David Eads notifications@github.com
wrote:

Pulling @liggitt https://github.com/liggitt's comment out into the main
thread:

It could help with the confused deputy, but it depends when it gets
confused... if the problem is that it gets tricked into doing something
cross-namespace, it could correctly lower its permissions to scope to the
namespace it was tricked into, but it would be too late...
Do you envision changing controllers to operate on a single namespace at a
time? That seems more likely to help, but also have a much larger
performance impact (N list operations instead of a single one across all
namespaces, etc)

I share the concern. I definitely want the ability for a user to act as a
ServiceAccount, but I'm not certain that this approach reduces the trust
required for controllers. Whoever enables the controller must still trust
that the controller switches identity correctly. Meaning that the
controller is triggered to request the correct SA and that code for
selecting an SA is not bugged. That seems like I'm still trusting the
controller to properly use all the permissions it has for its own identity
and all the transitive permissions it gets from the SAs its allowed to
act-as.

I still want the feature to allow a regular user to act as a more
privileged service account for some tasks (sort of like sudo), but I'm
not sure this helps with the controller trust problem.

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

erictune · 2015-11-10T19:35:57Z

@yuvipanda

k8s-github-robot · 2016-08-15T18:22:37Z

This PR hasn't been active in 90 days. Closing this PR. Please reopen if you would like to work towards merging this change, if/when the PR is ready for the next round of review.

cc @erictune

You can add 'keep-open' label to prevent this from happening again, or add a comment to keep it open another 90 days

k8s-bot · 2016-08-15T23:17:30Z

GCE e2e build/test passed for commit 87e94a9.

erictune · 2016-08-23T22:29:39Z

@deads2k You have implemented some of this, and some other things that this proposal did not forsee. Does it make sense to merge this and then update it, or abandon it, or something else?

deads2k · 2016-08-24T11:57:47Z

@deads2k You have implemented some of this, and some other things that this proposal did not forsee. Does it make sense to merge this and then update it, or abandon it, or something else?

I've implemented the mechanics of impersonation (acting-as), but not the usage being described here.

I think we (at least @liggitt and myself) agree with you that we should stop using the insecure port for controllers and that we need to more tightly scope the powers that individual controllers have. We're less sure of using impersonation to do it.

Not much progress was made on stabilizing rbac in 1.4, but it is on my personal objective list for 1.5 so I'm hoping to make things like default policy achievable. I think that in combination with a special purpose "service accounts from namespace kube-infra are special" authorizer for alternative authorization approaches makes the "Special-purpose accounts" a viable option. How do you feel about pursuing that avenue?

erictune · 2016-08-29T21:08:38Z

I like that approach for kubelet. I like it less for controller-manager
and scheduler. Here is why:

Kubelet has authorization requirements that are really hard to implement
without making RBAC more complex, such as "kubelets should only be able to
pull secrets for pods scheduled to them". Controllers and Scheduler don't
have as difficult requirements, IMO.
We try to write controllers that are provided by the project in a way
that third-parties can copy. Third parties cannot easily copy the customer
authorizer pattern. Kubelet does not need to have third-party
implementations, so no special requirement here.
There are so many kubelets that authorization efficiency (cycles spent in
authz code in apiserver) is a concern. I don't know that this is a concern
to the same degree for controllers.

On Wed, Aug 24, 2016 at 4:58 AM, David Eads notifications@github.com
wrote:

@deads2k https://github.com/deads2k You have implemented some of this,
and some other things that this proposal did not forsee. Does it make sense
to merge this and then update it, or abandon it, or something else?

I've implemented the mechanics of impersonation (acting-as), but not the
usage being described here.

I think we (at least @liggitt https://github.com/liggitt and myself)
agree with you that we should stop using the insecure port for controllers
and that we need to more tightly scope the powers that individual
controllers have. We're less sure of using impersonation to do it.

Not much progress was made on stabilizing rbac in 1.4, but it is on my
personal objective list for 1.5 so I'm hoping to make things like default
policy achievable. I think that in combination with a special purpose
"service accounts from namespace kube-infra are special" authorizer for
alternative authorization approaches makes the "Special-purpose accounts" a
viable option. How do you feel about pursuing that avenue?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#16933 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHuudl07O9gnoJJRD49G75_Hb7BiJh3pks5qjDHxgaJpZM4Gdp-q
.

erictune · 2016-08-29T21:13:49Z

Impersonation can reduce instances of the confused deputy problem due to
bugs in controller implementations.

How do you and liggitt rate the importance of "avoid confused deputy"? Do
you know ways to address it other than impersonation?

On Mon, Aug 29, 2016 at 2:08 PM, Eric Tune etune@google.com wrote:

I like that approach for kubelet. I like it less for controller-manager
and scheduler. Here is why:

Kubelet has authorization requirements that are really hard to implement
without making RBAC more complex, such as "kubelets should only be able to
pull secrets for pods scheduled to them". Controllers and Scheduler don't
have as difficult requirements, IMO.

We try to write controllers that are provided by the project in a way
that third-parties can copy. Third parties cannot easily copy the customer
authorizer pattern. Kubelet does not need to have third-party
implementations, so no special requirement here.

There are so many kubelets that authorization efficiency (cycles spent
in authz code in apiserver) is a concern. I don't know that this is a
concern to the same degree for controllers.

On Wed, Aug 24, 2016 at 4:58 AM, David Eads notifications@github.com
wrote:

@deads2k https://github.com/deads2k You have implemented some of this,
and some other things that this proposal did not forsee. Does it make sense
to merge this and then update it, or abandon it, or something else?

I've implemented the mechanics of impersonation (acting-as), but not the
usage being described here.

I think we (at least @liggitt https://github.com/liggitt and myself)
agree with you that we should stop using the insecure port for controllers
and that we need to more tightly scope the powers that individual
controllers have. We're less sure of using impersonation to do it.

Not much progress was made on stabilizing rbac in 1.4, but it is on my
personal objective list for 1.5 so I'm hoping to make things like default
policy achievable. I think that in combination with a special purpose
"service accounts from namespace kube-infra are special" authorizer for
alternative authorization approaches makes the "Special-purpose accounts" a
viable option. How do you feel about pursuing that avenue?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#16933 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHuudl07O9gnoJJRD49G75_Hb7BiJh3pks5qjDHxgaJpZM4Gdp-q
.

k8s-bot · 2016-08-30T00:38:19Z

Can one of the admins verify that this patch is reasonable to test? If so, please reply "ok to test".
(Note: "add to whitelist" is no longer supported. Please update configurations in kubernetes/test-infra/jenkins/job-configs/kubernetes-jenkins-pull instead.)

This message will repeat several times in short succession due to jenkinsci/ghprb-plugin#292. Sorry.

deads2k · 2016-08-30T11:43:39Z

We try to write controllers that are provided by the project in a way
that third-parties can copy. Third parties cannot easily copy the customer
authorizer pattern.

A third party controller could provide a ClusterRole (or Role, if the controller is going to be "personal" in an namespace), which is then bound to a service account.

deads2k · 2016-08-30T11:54:17Z

How do you and liggitt rate the importance of "avoid confused deputy"?

Important, but well bounded. In OpenShift, we bind individual controllers to roles which limit the controllers to the individual resources they must have access to run. For instance, the RS controller can

"get", "list", "watch", "update"    "replicasets"
"update"     "replicasets/status"
"list", "watch", "create", "delete"    "pods"
"create", "update", "patch"    "events"

That significantly reduces risk, since anyone able to create a replicaset has implicit control over pods already. That means that the confused deputy risk for the controller is only cross namespace attacks. Cross namespace bugs are actually pretty easy to review for since there's only one namespace involved per-action.

That why we aren't overly concerned about impersonation. The difficulty in code review for determining safe usage of two clients instead of one client and when to use which client (users probably shouldn't be creating events as a for instance) seems additive to the problem of cross namespace bug inspection.

With RBAC, its now possible to start using a similar strategy in kube. I'm working towards creating default ClusterRoles which can include the roles required for the individual controllers to run. Then there's more wiring to complete in order to get the SA tokens into the controllers, but I think its all achievable.

deads2k · 2016-09-02T19:21:57Z

@erictune convinced me that we need a way to scope impersonation and one way of doing it is to intersect the rights of the impersonater with the rights of the impersonatee. In OpenShift, we do this using scopes inside of the user.Info.Extra field, but alternate approaches could make sense too.

We both agreed that the next step for controllers is to find a way to scope the overall powers of individual controllers (probably using ClusterRoles) and that this would be in addition to that effort, not instead of it.

@erictune as I understood the next steps, you were going to propose a mechanism for driving this intersection and demonstrate inside of a controller. We might end up taking the intersection first (it provides utility for callers regardless of whether controllers use it).

k8s-github-robot · 2016-12-01T01:15:49Z

Adding label:do-not-merge because PR changes docs prohibited to auto merge
See http://kubernetes.io/editdocs/ for information about editing docs

k8s-github-robot · 2016-12-01T19:27:42Z

This PR hasn't been active in 90 days. Closing this PR. Please reopen if you would like to work towards merging this change, if/when the PR is ready for the next round of review.

cc @erictune

You can add 'keep-open' label to prevent this from happening again, or add a comment to keep it open another 90 days

googlebot added the cla: yes label Nov 6, 2015

k8s-github-robot assigned smarterclayton Nov 6, 2015

k8s-github-robot added kind/design Categorizes issue or PR as related to design. size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Nov 6, 2015

liggitt reviewed Nov 8, 2015
View reviewed changes

deads2k reviewed Nov 9, 2015
View reviewed changes

k8s-github-robot assigned brendandburns and unassigned liggitt May 6, 2016

brendandburns assigned erictune and unassigned brendandburns May 7, 2016

Added proposal for "acting-as".

87e94a9

erictune force-pushed the auth-design-updates branch from 4d01f80 to 87e94a9 Compare May 17, 2016 18:12

erictune mentioned this pull request Jun 9, 2016

Finish implementing Acting-As #27152

Closed

k8s-github-robot added retest-not-required-docs-only do-not-merge DEPRECATED. Indicates that a PR should not merge. Label can only be manually applied/removed. labels Jul 22, 2016

apelisse removed the do-not-merge DEPRECATED. Indicates that a PR should not merge. Label can only be manually applied/removed. label Aug 11, 2016

k8s-github-robot closed this Aug 15, 2016

smarterclayton reopened this Aug 15, 2016

erictune added release-note-none Denotes a PR that doesn't merit a release note. and removed release-note-label-needed labels Aug 23, 2016

k8s-github-robot added kind/design Categorizes issue or PR as related to design. kind/old-docs labels Dec 1, 2016

k8s-github-robot added the do-not-merge DEPRECATED. Indicates that a PR should not merge. Label can only be manually applied/removed. label Dec 1, 2016

k8s-github-robot closed this Dec 1, 2016

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Added proposal for "acting-as". #16933

Added proposal for "acting-as". #16933

erictune commented Nov 6, 2015 •

edited by k8s-github-robot

Loading

erictune commented Nov 6, 2015

erictune commented Nov 6, 2015

smarterclayton commented Nov 6, 2015

erictune commented Nov 6, 2015

erictune commented Nov 6, 2015

smarterclayton commented Nov 6, 2015

smarterclayton commented Nov 6, 2015

erictune commented Nov 6, 2015

smarterclayton commented Nov 6, 2015

liggitt Nov 8, 2015

erictune Nov 9, 2015

liggitt commented Nov 8, 2015

deads2k Nov 9, 2015

deads2k commented Nov 10, 2015

lavalamp commented Nov 10, 2015

erictune commented Nov 10, 2015

k8s-github-robot commented Aug 15, 2016

k8s-bot commented Aug 15, 2016

erictune commented Aug 23, 2016

deads2k commented Aug 24, 2016

erictune commented Aug 29, 2016

erictune commented Aug 29, 2016

k8s-bot commented Aug 30, 2016

deads2k commented Aug 30, 2016

deads2k commented Aug 30, 2016

deads2k commented Sep 2, 2016

k8s-github-robot commented Dec 1, 2016

k8s-github-robot commented Dec 1, 2016

Added proposal for "acting-as". #16933

Added proposal for "acting-as". #16933

Conversation

erictune commented Nov 6, 2015 • edited by k8s-github-robot Loading

erictune commented Nov 6, 2015

erictune commented Nov 6, 2015

smarterclayton commented Nov 6, 2015

erictune commented Nov 6, 2015

erictune commented Nov 6, 2015

smarterclayton commented Nov 6, 2015

smarterclayton commented Nov 6, 2015

erictune commented Nov 6, 2015

smarterclayton commented Nov 6, 2015

liggitt Nov 8, 2015

Choose a reason for hiding this comment

erictune Nov 9, 2015

Choose a reason for hiding this comment

liggitt commented Nov 8, 2015

deads2k Nov 9, 2015

Choose a reason for hiding this comment

deads2k commented Nov 10, 2015

lavalamp commented Nov 10, 2015

erictune commented Nov 10, 2015

k8s-github-robot commented Aug 15, 2016

k8s-bot commented Aug 15, 2016

erictune commented Aug 23, 2016

deads2k commented Aug 24, 2016

erictune commented Aug 29, 2016

erictune commented Aug 29, 2016

k8s-bot commented Aug 30, 2016

deads2k commented Aug 30, 2016

deads2k commented Aug 30, 2016

deads2k commented Sep 2, 2016

k8s-github-robot commented Dec 1, 2016

k8s-github-robot commented Dec 1, 2016

erictune commented Nov 6, 2015 •

edited by k8s-github-robot

Loading