reference: widen the definition of RBAC#55291
reference: widen the definition of RBAC#55291orangecms wants to merge 1 commit intokubernetes:mainfrom
Conversation
Entities in access controls are not necssarily individual people. System accounts, for example, are often managed by a team, and the respective system account is assigned the task related roles, e.g. for storage management or specific network configuration matters.
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
k8s-ci-robot
added
cncf-cla: yes
k8s-ci-robot
added
the
size/XS
✅ Pull request preview available for checkingBuilt without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
LGTM |
Caesarsage
left a comment
Caesarsage
left a comment
There was a problem hiding this comment.
Thanks @orangecms for your contributions. I left some comments you could check out
| Role-based access control (RBAC) is a method of regulating access to computer or | ||
| network resources based on the roles of individual users within your organization. | ||
| network resources based on the roles of individual users within an organization or | ||
| other entities in a system, such as system accounts performing specific tasks. |
There was a problem hiding this comment.
changing it from your to an make it less direct to readers which is against the style guide (https://kubernetes.io/docs/contribute/style/style-guide/#address-the-reader-as-you)
other entities is vague.
A cleaner wording could be
Role-based access control (RBAC) is a method of regulating access to computer or network resources based on the roles of *subjects* (users, groups, or service accounts) within your organization.
There was a problem hiding this comment.
I call them principals; see https://deploy-preview-50364--kubernetes-io-main-staging.netlify.app/docs/reference/access-authn-authz/authentication/ (preview for how PR 50364 plans to update the authn page).
There was a problem hiding this comment.
We can talk about both principals (which doesn't include groups) and subjects (which does / can).
lmktfy
left a comment
lmktfy
left a comment
There was a problem hiding this comment.
I definitely agree that the current wording doesn't seem right. You've already helped a lot by pointing that out.
I do have some other feedback.
| network resources based on the roles of individual users within an organization or | ||
| other entities in a system, such as system accounts performing specific tasks. |
There was a problem hiding this comment.
I think the word "individual" could still mislead. I'm afraid I would reword again:
| network resources based on the roles of individual users within an organization or | |
| other entities in a system, such as system accounts performing specific tasks. | |
| network resources based on the roles of specific users within an organization. | |
| As well as being useful to define access for individuals and groups of individuals, | |
| you can use Kubernetes RBAC to authorize other identity principals, such as [ServiceAccounts](/docs/concepts/security/service-accounts/). |
6 participants
Description
Entities in access controls are not necssarily individual people. System accounts, for example, are often managed by a team, and the respective system account is assigned the task related roles, e.g. for storage management or specific network configuration matters.
Issue
The current wording might be confusing, since "individual users within your organization" sounds like it only means human entities. The later paragraph "User-facing roles" makes clear that there are also system entities in RBAC.