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.