rules review API: what can I do?

[ericchiang]

xref kubernetes/enhancements#380

cc @kubernetes/sig-auth-proposals @kubernetes/api-reviewers @xilabao

[ericchiang]

@cjcullen @dims for proposed webhook integration.

[ericchiang]

@deads2k tired to articulate my concerns about making user extras configurable. ptal

[deads2k]

Unless there's an authorizer that actually conditionally allows access to particularly named resources based one their actual, I don't think this allows you to go fishing in other namespaces. I don't care enough to try to stop the good bits of the API, but is there any other way?

[ericchiang]

Unless there's an authorizer that actually conditionally allows access to particularly named resources based one their actual

From what I can see @dims' keystone authorizer does that https://github.com/dims/k8s-keystone-auth

@cjcullen any other insight into how/if GKE uses user extra?

Maybe we could re-word user-extra to try to emphasis its usage as part of this change?

Extra fields should NOT be used to grant access to new namespaces. Only to modify the
access of a user within a namespace.

[deads2k]

Extra fields should NOT be used to grant access to new namespaces. Only to modify the
access of a user within a namespace.

Granting access to other namespaces does not leak information, since if I lie about my extra and see "yes you have access to namespace X", I'd get that result regardless of whether the namespace exists.

[ericchiang]

Granting access to other namespaces does not leak information, since if I lie about my extra and see "yes you have access to namespace X", I'd get that result regardless of whether the namespace exists.

You're still leaking information about what users have been given access to what though, which could correlate to what exists. I could find out that project team-foo doesn't have any powers in namespace secret-project-bar but does have powers in namespace secret-project-spam.

It's probably not the biggest concern, but it feels weird to allow a user to control any fields that extend their access.

Can we let clients provide something like an additive "Impersonate-Extra-*" header that would only add extras to the authenticated user info? That way an admin could declare what extras are okay to freely add to a user:

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  # Any user bound to this role can add a "scopes" user extra field to their user info
  # through an HTTP header.
  name: scopes-adder
- apiGroups: ["authentication.k8s.io"]
  resources: ["userextras/scopes"]
  verbs: ["impersonate:additive"] # this is a bad name for the verb

This would let them use both SelfSubjectRulesReview with whatever extras an admin deemed okay, and would extend those capabilities to other commands.

[erictune]

There is not enough discussion, for my taste, of how a client (e.g. dashboard) would use the results of this API. Is it just so that it can hide/inactivate UI options that are not possible, or would it actually make its own authorization decisions and then act as a more powerful user? What client libraries will be provided to help the client make correct decisions from the cached results of the rules review? How long should clients cache the rules review? Is this just a glorified form of caching, and why not just add more pure caching of AccessReview decisions?

[bryk]

CC @kubernetes/dashboard-maintainers

[liggitt]

In Openshift, we use it to show/hide actions in a UI based on the user's permissions:

Example "can I" function:
https://github.com/openshift/origin-web-common/blob/master/src/services/authorizationService.js#L102-L131

Example use:
https://github.com/openshift/origin-web-console/blob/2fb62238b922bebd311ccb43bc00c39500452828/app/scripts/directives/overview/serviceInstanceRow.js#L59-L73

In a dashboard with many different actions, some of which involve multiple API calls, determing those permissions via individual SAR checks was far more expensive (both in terms of API requests and in terms of server-side work)

cc @spadgett @jwforres

[erictune]

When you say "server side" do you mean the UI server? Are you saying that the rules get loaded into javascript in the users browser to show, and cause actions to show/hide in the browser. Then, when the user takes an action, is the final decision still made by the UI-server or by the apiserver?

…

On Wed, Aug 9, 2017 at 7:45 AM, Jordan Liggitt ***@***.***> wrote: In Openshift, we use it to show/hide actions in a UI based on the user's permissions: Example "can I" function: https://github.com/openshift/origin-web-common/blob/master/src/services/ authorizationService.js#L102-L131 Example use: https://github.com/openshift/origin-web-console/blob/ 2fb62238b922bebd311ccb43bc00c39500452828/app/scripts/directives/overview/ serviceInstanceRow.js#L59-L73 In a dashboard with many different actions, some of which involve multiple API calls, determing those permissions via individual SAR checks was far more expensive (both in terms of API requests and in terms of server-side work) cc @spadgett <https://github.com/spadgett> @jwforres <https://github.com/jwforres> — You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub <#887 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHuuduSVg1FvdBT7t_vB-T0stBd9x1TDks5sWcYkgaJpZM4Oxecv> .

[liggitt]

When you say "server side" do you mean the UI server?

No, the apiserver that would have evaluated those dozens of subjectaccessreview requests.

Are you saying that the rules get loaded into javascript in the users browser to show, and cause actions to show/hide in the browser.

Yes

Then, when the user takes an action, is the final decision still made by the UI-server or by the apiserver?

The final decision is the API server's. This lets the UI avoid showing the user actions and wizards and pages that would just result in 403 errors from the API

Also, we don't really have a UI server... the openshift web console is a javascript-only application that speaks directly to the apiserver.

[erictune]

Cool. I like it. Would you consider adding these sentences or something like them to the doc: We do recommend is that the rules API be used for UIs to show/hide actions. We don't recommend that you have a highly privileged server which uses the output of the rules API to make its own authz decisions, as this raises confused deputy, cache lifetime/revokation, and correctness concerns. Preferred pattern is that the client (e.g. javascript in browser) still makes calls directly to the apiserver and is authorized by apiserver.

…

On Wed, Aug 9, 2017 at 8:10 AM, Jordan Liggitt ***@***.***> wrote: When you say "server side" do you mean the UI server? No, the apiserver that would have evaluated those dozens of subjectaccessreview requests. Are you saying that the rules get loaded into javascript in the users browser to show, and cause actions to show/hide in the browser. Yes Then, when the user takes an action, is the final decision still made by the UI-server or by the apiserver? The final decision is the API servers. This lets the UI avoid showing the user actions and wizards and pages that would just result in 403 errors from the API — You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub <#887 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHuudjekb4Q2KU4x1EFkDIoAKpcq0YI-ks5sWcv_gaJpZM4Oxecv> .

[ericchiang]

Thanks @erictune. Expanded the bit about how UIs might use this and tried to make it clear that this API shouldn't be used to drive external authz.

[rf232]

Having this all be dependent on the user knowing which Namespaces they have some form of access to might be quite inconvenient for a UI.
e.g. the kubernetes/dashboard currently (1) queries for the available namespaces and then (2) allows viewing the resources in each of those namespaces. If I understand the proposal correctly this would support the (2) part of this flow, but no way to support for the (1) part of this flow.
Is there room for a non namespaced version of this Spec, or a "Which namespaces have I more than zero access to" api? This would be a helpful part of this API for the dashboard

[ericchiang]

@rf232 for some background querying resources across all namespaces was deemed too expensive.

I know the actual namespace object is a bit special. I think users can "GET" the namespace object resource by name if they have any access in it already (couldn't find the code path that allows this). CoreOS has internally built apps that do something like:

• privileged service account lists all namespace
• looks up if a user can get each specific namespace
• builds list to display user from that

Agree that probably doesn't work at scale, but a "what namespaces can I see" might be a different API. I think openshift just implemented namespace filtering, so there's no prior art there.

[liggitt]

Is there room for a non namespaced version of this Spec

Yes, but it wouldn't do what you describe, it would tell you the things you could do across all namespaces (e.g. kubectl get pods --all-namespaces)

or a "Which namespaces have I more than zero access to" api? This would be a helpful part of this API for the dashboard

Agree it is useful (we built something close to that API in openshift), but it's a different API than this one and requires more capabilities from the authorization interface to implement performantly

I think users can "GET" the namespace object resource by name if they have any access in it already

Not quite, the admin/edit/view roles simply grant "get" "namespace", so when those roles are bound in a particular namespace, the ability to get that namespace is granted.

[rf232]

• privileged service account lists all namespace
• looks up if a user can get each specific namespace
• builds list to display user from that

This is a possibility, but recently at the dashboard we were looking at reducing the privileges the dashboard itself needs to lower the risk of privilege escalations with the dashboard.

[lpabon]

LGTM. Suggestion: Is it possible to add a client-server workflow example?

[liggitt]

typo: through

[liggitt]

"Some authorizers live external"

[ericchiang]

@kubernetes/sig-auth-proposals I'd like to merge this. SelfSubjectRulesReview was introduced in 1.8 and the webhook support has been reviewed kubernetes/kubernetes#53922 :)

[deads2k]

This represents the current state. I think updates may be required in light of kubernetes/kubernetes#53922, but we can start here.

/lgtm

[deads2k]

/test all

[k8s-github-robot]

/test all [submit-queue is verifying that this PR is safe to merge]

[k8s-github-robot]

Automatic merge from submit-queue.