From 1b90f44da6e6ea4b5f8a14db6bf0bebeda8f2a48 Mon Sep 17 00:00:00 2001 From: Paszymaja <36695377+Paszymaja@users.noreply.github.com> Date: Fri, 10 Jun 2022 12:40:02 +0200 Subject: [PATCH 1/3] Fixed typos Fixed some typos and improved grammar. --- .../docs/concepts/security/rbac-good-practices.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/content/en/docs/concepts/security/rbac-good-practices.md b/content/en/docs/concepts/security/rbac-good-practices.md index 7361c3a163..0bf9440b42 100644 --- a/content/en/docs/concepts/security/rbac-good-practices.md +++ b/content/en/docs/concepts/security/rbac-good-practices.md @@ -22,15 +22,15 @@ The good practices laid out here should be read in conjunction with the general ### Least privilege -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, +Ideally, minimal RBAC rights should be assigned to users and service accounts. Only permissions +explicitly required for their operation should be used. While each cluster will be different, some general rules that can be applied are : - Assign permissions at the namespace level where possible. Use RoleBindings as opposed to ClusterRoleBindings to give users rights only within a specific namespace. - Avoid providing wildcard permissions when possible, especially to all resources. 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. - 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) @@ -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 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. - Avoid the default auto-mounting of service account tokens by setting `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 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 granting rights to this resource. ### 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), users with this right can effectively escalate their privileges. ### 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 roles with rights they do not already have. From 3eb9334ee21e9a0949834902840fb4dee2081ba4 Mon Sep 17 00:00:00 2001 From: SzymonPrzepiora Date: Wed, 15 Jun 2022 14:04:18 +0200 Subject: [PATCH 2/3] suggested changes --- content/en/docs/concepts/security/rbac-good-practices.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/content/en/docs/concepts/security/rbac-good-practices.md b/content/en/docs/concepts/security/rbac-good-practices.md index 0bf9440b42..58da33c10a 100644 --- a/content/en/docs/concepts/security/rbac-good-practices.md +++ b/content/en/docs/concepts/security/rbac-good-practices.md @@ -30,7 +30,7 @@ some general rules that can be applied are : ClusterRoleBindings to give users rights only within a specific namespace. - Avoid providing wildcard permissions when possible, especially to all resources. As Kubernetes is an extensible system, providing wildcard access gives rights - not just to all object types present in the cluster, but also to all future object types + not just to all object types that currently exist in the cluster, but also to all future object types which are created in the future. - 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) @@ -128,8 +128,7 @@ granting rights to this resource. ### Escalate verb -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), +Generally, the RBAC system prevents users from creating clusterroles with more rights than the user possesses. 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. ### Bind verb From 30eb2cc0cfabc19db9640559eceaa6d39f52dd60 Mon Sep 17 00:00:00 2001 From: Paszymaja <36695377+Paszymaja@users.noreply.github.com> Date: Wed, 27 Jul 2022 14:12:15 +0200 Subject: [PATCH 3/3] Update content/en/docs/concepts/security/rbac-good-practices.md Co-authored-by: divya-mohan0209 --- content/en/docs/concepts/security/rbac-good-practices.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/content/en/docs/concepts/security/rbac-good-practices.md b/content/en/docs/concepts/security/rbac-good-practices.md index 7699a0da45..fe858bba72 100644 --- a/content/en/docs/concepts/security/rbac-good-practices.md +++ b/content/en/docs/concepts/security/rbac-good-practices.md @@ -135,7 +135,8 @@ granting rights to this resource. ### Escalate verb -Generally, the RBAC system prevents users from creating clusterroles with more rights than the user possesses. 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), +Generally, the RBAC system prevents users from creating clusterroles with more rights than the user possesses. +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. ### Bind verb