Role-based access control (RBAC)

[erictune]

Feature Description

• One-line feature description (can be used as a release note): Role-based access control
• Primary contact (assignee): @ericchiang @deads2k @liggitt
• Responsible SIGs: sig-auth
• Design proposal link (community repo):
• Reviewer(s): @deads2k @ericchiang
• Approver (likely from SIG/area to which feature belongs): @erictune @smarterclayton
• Feature target (which target equals to which milestone):
  • Alpha release target - 1.3
  • Beta release target - 1.6
  • Stable release target - 1.8

kubernetes/kubernetes#25634
kubernetes/kubernetes#26753
kubernetes/website#643

[liggitt]

it’s astonishing how much checklists on github make me want to do whatever it takes to complete them

[ericchiang]

An update on this issue for alpha.

• Most of the design was directly lifted directly from the openshift documentation. We skipped over a formal proposal.
• The initial API was reviewed and added in pkg/apis/rbac: Add Openshift authorization API types kubernetes#24900
• The API group, an authorizer, and a small amount of unit tests where added in Add RBAC authorization API group and authorizer kubernetes#25634

TODO before alpha release

• Complete testing by adding integration tests
• Add minimal documentation to kubernetes/kubernetes.github.io
• Write release notes

[philips]

@erictune As we can't update this issue I think you have to check the boxes based on @ericchiang's comment #2 (comment)

[philips]

Ping @erictune cc @ericchiang

[ericchiang]

Integration tests here: kubernetes/kubernetes#26753

Docs here: kubernetes/website#631

Also there were a couple small fixes that need lgtms:

• Rbac api group make subject apiversion optional kubernetes#26984
• pkg/kubectl: add resource printers for rbac api group kubernetes#26975
• Rename RBAC 'subject' to 'subjects'. kubernetes#26924

[erictune]

The API group name "rbac.authorization.k8s.io/v1alpha1" is really long. Perhaps for Beta or GA we can shorten it somehow.

[erictune]

For beta, we need to:

• have a default set of roles, and docs about those roles. - https://deploy-preview-2618--kubernetes-io-master-staging.netlify.com/docs/admin/authorization/rbac/#default-clusterroles-and-clusterrolebindings
• examples of updating a role to add a user to it, remove a user from it, using kubectl. - https://deploy-preview-2618--kubernetes-io-master-staging.netlify.com/docs/admin/authorization/rbac/#command-line-utilities
• we need to decide what a service-account's default role is, which will be a breaking change, since it is not going to be the current effectively root role it has. - default permissions are none
• Rename RBAC 'subject' to 'subjects'. (Rename RBAC 'subject' to 'subjects'. kubernetes#26924)
• on by default for kube-up, and all GCE e2e tests work with RBAC enabled. - enabled in 1.6
• get feedback on whether it works well from large on-prem customers.

[ericchiang]

A couple other notes (not necessarily for beta)

• Add some basic caching mechanisms to the authorizer implementation. It's currently using a naive implementation that just queries the API group each time. - added in 1.6
• Get feedback on the bootstrapping procedure (--authorizer-rbac-super-user) - flag is removed in 1.6, default cluster roles/rolebindings are reconciled at startup
• Get feedback on the privilege escalation checks. Do these make sense, should an admin be able to turn them off or get around them some other way, etc.) - cluster admin can make API calls against unsecured port or as the system:masters superuser group to bypass escalation checks

[liggitt]

Not sure I'd consider choosing a default role for service accounts in rbac a breaking change. Authorizer settings have always been able to limit service account permissions.

[guoshimin]

Hi @erictune will RBAC in 1.3 have the ability to make policy decisions based on the attributes in the requested API object? Such as specifying what secrets can a pod mount as a volume? Looking over the code seems the answer is no, but I'd like to confirm. Thanks!

[ericchiang]

@guoshimin no. For alpha RBAC will only deal with top level objects. No field level authorization.

@olegshaldybin has a large proposal in kubernetes/kubernetes#27330. You may want to take a look at the discussion there.

[liggitt]

no, RBAC is object-level, not field-level.

[ericchiang]

Also realized that we don't have garbage collection (cleaning up role bindings to deleted roles). This would probably be something good to add to the beta release.

[deads2k]

I'd like to see an intent-based, idempotent API for binding roles to subjects. Something where I can post: "bind role/foo to user/bar" or "delete role/foo from group/bar" and not have to worry about the details of exactly which named binding needs to be mutated.

I think we should also consider a way to select which roles and subjects a given subject is allowed to bind. Right now, Jane in namespace J can forcibly add David to her namespace and there's nothing he can do about it. In addition, a permission granting role has value since the person handing out permissions may not want to have all the powers he's granting.

[alexbrand]

An intent-based API for managing policy sounds great. Just out of curiosity - Are there existing intent-based APIs in K8s?

[deads2k]

An intent-based API for managing policy sounds great. Just out of curiosity - Are there existing intent-based APIs in K8s?

The existing bindings endpoint comes to mind. I can't actually think of other resources where the primary usage is through mutation of existing resources instead of creation of new ones. Maintaining individual tuples doesn't seem like it would be a good idea though.

[erictune]

Request for a non-flag way to turn off bootstrapping mode (kubernetes/kubernetes#25634 (comment)) @jimmycuadra

[ericchiang]

I'm a little confused by that comment.

@jimmycuadra why do you need to turn this off the bootstrapping flag in the first place? I don't actually see anything in that post which explained that.

[jimmycuadra]

In our setup, the systemd unit file that starts apiserver is immutable, so we don't necessarily want the user specified by --authorization-rbac-super-user to have unlimited access for the foreseeable future. We want a way to bootstrap RBAC roles and bindings and then disable the initial user's unlimited access without having to change the set of arguments that the apiserver is started with.

[SEJeff]

@jimmycuadra And you couldn't use systemd's EnvironmentFile pointing to a file that is mutable to change the flags? That achieves the immutable systemd unit file with the flags without changing the scope of this feature. Could that work?