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

Fixed typos

Browse Source 
Fixed some typos and improved grammar.
This commit is contained in:
Paszymaja
2022-06-10 12:40:02 +02:00
committed by GitHub
parent cdad0a7342
commit 1b90f44da6
1 changed files with 7 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/concepts/security/rbac-good-practices.md
+7 -7
View File
@@ -22,15 +22,15 @@ The good practices laid out here should be read in conjunction with the general
### Least privilege ### Least privilege
Ideally minimal RBAC rights should be assigned to users and service accounts. Only permissions Ideally, minimal RBAC rights should be assigned to users and service accounts. Only permissions
explicitly required for their operation should be used. Whilst each cluster will be different, explicitly required for their operation should be used. While each cluster will be different,
some general rules that can be applied are : some general rules that can be applied are :
- Assign permissions at the namespace level where possible. Use RoleBindings as opposed to - Assign permissions at the namespace level where possible. Use RoleBindings as opposed to
ClusterRoleBindings to give users rights only within a specific namespace. ClusterRoleBindings to give users rights only within a specific namespace.
- Avoid providing wildcard permissions when possible, especially to all resources. - Avoid providing wildcard permissions when possible, especially to all resources.
As Kubernetes is an extensible system, providing wildcard access gives rights As Kubernetes is an extensible system, providing wildcard access gives rights
not just to all object types presently in the cluster, but also to all future object types not just to all object types present in the cluster, but also to all future object types
which are created in the future. which are created in the future.
- Administrators should not use `cluster-admin` accounts except where specifically needed. - Administrators should not use `cluster-admin` accounts except where specifically needed.
Providing a low privileged account with [impersonation rights](/docs/reference/access-authn-authz/authentication/#user-impersonation) Providing a low privileged account with [impersonation rights](/docs/reference/access-authn-authz/authentication/#user-impersonation)
@@ -61,7 +61,7 @@ the RBAC rights provided by default can provide opportunities for security harde
In general, changes should not be made to rights provided to `system:` accounts some options In general, changes should not be made to rights provided to `system:` accounts some options
to harden cluster rights exist: to harden cluster rights exist:
- Review bindings for the `system:unauthenticated` group and remove where possible, as this gives - Review bindings for the `system:unauthenticated` group and remove them where possible, as this gives
access to anyone who can contact the API server at a network level. access to anyone who can contact the API server at a network level.
- Avoid the default auto-mounting of service account tokens by setting - Avoid the default auto-mounting of service account tokens by setting
`automountServiceAccountToken: false`. For more details, see `automountServiceAccountToken: false`. For more details, see
@@ -122,19 +122,19 @@ PersistentVolumes, and constrained users should use PersistentVolumeClaims to ac
### Access to `proxy` subresource of Nodes ### Access to `proxy` subresource of Nodes
Users with access to the proxy sub-resource of node objects have rights to the Kubelet API, Users with access to the proxy sub-resource of node objects have rights to the Kubelet API,
which allows for command execution on every pod on the node(s) which they have rights to. which allows for command execution on every pod on the node(s) to which they have rights.
This access bypasses audit logging and admission control, so care should be taken before This access bypasses audit logging and admission control, so care should be taken before
granting rights to this resource. granting rights to this resource.
### Escalate verb ### Escalate verb
Generally the RBAC system prevents users from creating clusterroles with more rights than Generally, the RBAC system prevents users from creating clusterroles with more rights than
they possess. The exception to this is the `escalate` verb. As noted in the [RBAC documentation](/docs/reference/access-authn-authz/rbac/#restrictions-on-role-creation-or-update), they possess. The exception to this is the `escalate` verb. As noted in the [RBAC documentation](/docs/reference/access-authn-authz/rbac/#restrictions-on-role-creation-or-update),
users with this right can effectively escalate their privileges. users with this right can effectively escalate their privileges.
### Bind verb ### Bind verb
Similar to the `escalate` verb, granting users this right allows for bypass of Kubernetes Similar to the `escalate` verb, granting users this right allows for the bypass of Kubernetes
in-built protections against privilege escalation, allowing users to create bindings to in-built protections against privilege escalation, allowing users to create bindings to
roles with rights they do not already have. roles with rights they do not already have.