Add RFD 183: Access Request Kube Resource Allow List

[kimlisa]

rendered

part of: #46742

[github-actions]

The PR changelog entry failed validation: Changelog entry not found in the PR body. Please add a "no-changelog" label to the PR, or changelog lines starting with changelog: followed by the changelog entries for the PR.

[github-actions]

The PR changelog entry failed validation: Changelog entry not found in the PR body. Please add a "no-changelog" label to the PR, or changelog lines starting with changelog: followed by the changelog entries for the PR.

[r0mant]

@klizhentas @xinding33 Can you review this when you get a chance?

[nklaassen]

I'm curious why we have this under spec.options.request_mode.kubernetes_resources instead of, say, spec.allow.request.kubernetes_resources. Basically why is it a role option and not under spec.allow.request where most other access request configuration is? And what is the effect if the option is set differently in multiple roles the user has?

I haven't really thought about it hard enough to say one of those options is definitively better, I'm just wondering if there's a reason or it just seemed like the default way to do it

[nklaassen]

After slightly more thought, I think this doesn't really make sense as a role option, and an allow/deny rule would be better

Here's my mental model of role options (I'm sure there are exceptions to this but i think it's mostly accurate). Usually, role options are coalesced across all roles a user has to result in a single value, and usually that value ends up encoded in the user's certificate. For example, the forward_agent option is combined from all roles the user has, and it's encoded in the SSH cert when the user logs in. The same for many other options. Even when not encoded in the cert, usually you compute a single value from the user's entire role set.

If instead you want one role to allow the user to request certain kubernetes namespaces with certain target roles, and another role to allow the user to request kubernetes clusters with a different target role, and another role can deny the user requesting a specific namespace, I think this would be better as an allow/deny rule under spec.allow.request

[kimlisa]

@nklaassen updated RFD to reflect field change

rendered

[r0mant]

@kimlisa lgtm with one syntactic comment

[r0mant]

Do we need "mode" sub-field at all here then? Sounds like something like this would be slightly cleaner:

spec:
  allow:
    request:
      kubernetes_resources:
      - kind: "*"