whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fixed the RBAC good practice guide.

Browse Source
This commit is contained in:
harshitasao
2022-05-26 12:15:20 +05:30
parent 85416c0c21
commit 789935a35d
1 changed files with 7 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/concepts/security/rbac-good-practices.md
+6 -2
View File
@@ -37,13 +37,14 @@ some general rules that can be applied are :
can avoid accidental modification of cluster resources. can avoid accidental modification of cluster resources.
- Avoid adding users to the `system:masters` group. Any user who is a member of this group - Avoid adding users to the `system:masters` group. Any user who is a member of this group
bypasses all RBAC rights checks and will always have unrestricted superuser access, which cannot be bypasses all RBAC rights checks and will always have unrestricted superuser access, which cannot be
revoked by removing Role Bindings or Cluster Role Bindings. As an aside, if a cluster is revoked by removing RoleBindings or ClusterRoleBindings. As an aside, if a cluster is
using an authorization webhook, membership of this group also bypasses that webhook (requests using an authorization webhook, membership of this group also bypasses that webhook (requests
from users who are members of that group are never sent to the webhook) from users who are members of that group are never sent to the webhook)
### Minimize distribution of privileged tokens ### Minimize distribution of privileged tokens
Ideally, pods shouldn't be assigned service accounts granted powerful permissions (listed [here](#Kubernetes-RBAC---Privilege-Escalation-Risks)). Ideally, pods shouldn't be assigned service accounts that have been granted powerful permissions (for example, any of the rights listed under
[privilege escalation risks](#privilege-escalation-risks)).
In cases where a workload requires powerful permissions, consider the following practices: In cases where a workload requires powerful permissions, consider the following practices:
- Limit the number of nodes running powerful pods. Ensure that any DaemonSets you run - Limit the number of nodes running powerful pods. Ensure that any DaemonSets you run
@@ -173,3 +174,6 @@ are allowed limited access to a system.
One option for mitigation of this issue would be to use [resource quotas](/docs/concepts/policy/resource-quotas/#object-count-quota) One option for mitigation of this issue would be to use [resource quotas](/docs/concepts/policy/resource-quotas/#object-count-quota)
to limit the quantity of objects which can be created. to limit the quantity of objects which can be created.
## {{% heading "whatsnext" %}}
* To learn more about **RBAC**, see [RBAC documentation](/docs/reference/access-authn-authz/rbac/).