diff --git a/doc/source/security/kubernetes/configure-users-groups-and-authorization.rst b/doc/source/security/kubernetes/configure-users-groups-and-authorization.rst
index 8bdef4252..f0378d8fc 100644
--- a/doc/source/security/kubernetes/configure-users-groups-and-authorization.rst
+++ b/doc/source/security/kubernetes/configure-users-groups-and-authorization.rst
@@ -6,31 +6,25 @@
 Configure Users, Groups, and Authorization
 ==========================================
 
-You can create a **user**, and optionally one or more **groups** that the
-**user** is a member of, in your Windows Active Directory or |LDAP| server.
+In the examples provided below, Kubernetes permissions will be given to
+**testuser** user. Two different ways to do this are presented: in the first
+option, **testuser** user is directly bound to a role; in the second option,
+**testuser** is indirectly associated to a Kubernetes group that has
+permissions.
 
-.. rubric:: |context|
+.. note::
+   For bigger environments, like a |DC| with many subclouds, or to minimize
+   Kubernetes custom cluster configurations, use the second option, where
+   permissions are granted through Kubernetes groups.
 
-The example below is for a **testuser** user who is a member of the,
-**billingDeptGroup**, and **managerGroup** groups. See `Microsoft
-documentation on Windows Active Directory
-<https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/vi
-rtual-dc/active-directory-domain-services-overview>`__ for additional
-information on adding users and groups to Windows Active Directory.
+.. _configure-users-groups-and-authorization-option-1-b2f-ck4-dlb:
 
-Use the following procedure to configure the desired authorization on
-|prod-long| for the user or the user's group\(s):
+--------------------------------------------------------
+Grant Kubernetes permissions through direct role binding
+--------------------------------------------------------
 
-.. rubric:: |proc|
-
-
-.. _configure-users-groups-and-authorization-steps-b2f-ck4-dlb:
-
-#.  In |prod-long|, bind Kubernetes |RBAC| role\(s) for the **testuser**.
-
-    For example, give **testuser** admin privileges, by creating the
-    following deployment file, and deploy the file with :command:`kubectl
-    apply -f` <filename>.
+#.  Create the following deployment file and deploy the file with :command:
+    `kubectl apply -f` <filename>.
 
     .. code-block:: none
 
@@ -47,27 +41,73 @@ Use the following procedure to configure the desired authorization on
           kind: User
           name: testuser
 
+.. _configure-users-groups-and-authorization-option-2-b2f-dk4-dlb:
 
-    Alternatively, you can bind Kubernetes |RBAC| role\(s) for the group\(s)
-    of the **testuser**.
+-------------------------------------------
+Grant Kubernetes permissions through groups
+-------------------------------------------
 
-    For example, give all members of the **billingDeptGroup** admin
-    privileges, by creating the following deployment file, and deploy the
-    file with :command:`kubectl apply -f` <filename>.
+#.  Create the following deployment file and deploy the file with :command:
+    `kubectl apply -f` <filename>.
 
     .. code-block:: none
 
-        kind: ClusterRoleBinding
         apiVersion: rbac.authorization.k8s.io/v1
+        kind: ClusterRole
         metadata:
-         name: testuser-rolebinding
-        roleRef:
-         apiGroup: rbac.authorization.k8s.io
-         kind: ClusterRole
-         name: cluster-admin
+          name: cluster-reader-role
+        rules:
+        - apiGroups: ["*"]
+          resources: ["*"]
+          verbs: ["get", "watch", "list"]
+        ---
+        apiVersion: rbac.authorization.k8s.io/v1
+        kind: ClusterRoleBinding
+        metadata:
+          name: cluster-reader-rolebinding
         subjects:
-        - apiGroup: rbac.authorization.k8s.io
-          kind: Group
-          name: billingDeptGroup
+        - kind: Group
+          name: k8s-reader
+          apiGroup: rbac.authorization.k8s.io
+        roleRef:
+          kind: ClusterRole
+          name: cluster-reader-role
+          apiGroup: rbac.authorization.k8s.io
+        ---
+        # Note: the ClusterRole "cluster-admin" already exists in the system.
+        apiVersion: rbac.authorization.k8s.io/v1
+        kind: ClusterRoleBinding
+        metadata:
+          name: cluster-admin-rolebinding
+        subjects:
+        - kind: Group
+          name: k8s-admin
+          apiGroup: rbac.authorization.k8s.io
+        roleRef:
+          kind: ClusterRole
+          name: cluster-admin
+          apiGroup: rbac.authorization.k8s.io
 
+#.  Create the groups **k8s-reader** and **k8s-admin** in your Windows Active
+    Directory or |LDAP| server. See `Microsoft documentation on Windows Active
+    Directory
+    <https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/
+    virtual-dc/active-directory-domain-services-overview>`__ for additional
+    information on adding users and groups to Windows Active Directory.
 
+#.  To give Kubernetes permissions to **testuser**, add this user in either the
+    **k8s-reader** or **k8s-admin** groups in your Windows Active Directory or
+    |LDAP| server, depending on the permissions you want to grant. The
+    permissions are given because there is a mapping between a Windows Active
+    Directory or |LDAP| group and a Kubernetes group with same name. To remove
+    Kubernetes permissions from **testuser** user, remove this user from
+    **k8s-reader** and **k8s-admin** groups in your Windows Active Directory or
+    |LDAP| server.
+
+    .. note::
+       The group names **k8s-reader** and **k8s-admin** are arbitrary. As long
+       as the Windows Active Directory or LDAP group have the same name as the
+       Kubernetes group, the mapping will happen. For example, if a more
+       company-specific approach is preferred, the groups **k8s-reader** and
+       **k8s-admin** groups could be named after departments, like
+       **billingDeptGroup** and **managerGroup**.