> ## Documentation Index > Fetch the complete documentation index at: https://cloudanix.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Avoid Use Of System Masters Group ### More Info: The special group system:masters should not be used to grant permissions to any user or service account, except where strictly necessary (e.g. bootstrapping access prior to RBAC being fully available) ### Risk Level High ### Address Security ### Compliance Standards * CIS Kubernetes ### Triage and Remediation ### Remediation 1. **List all subjects currently bound to `system:masters`** * On any machine with kubectl access: ```bash theme={null} kubectl get clusterrolebindings -o yaml | grep -A5 '\bcluster-admin\b' kubectl get clusterrolebindings -o yaml | grep -A5 'system:masters' kubectl get clusterrolebindings -o wide ``` * Identify any `ClusterRoleBinding` where: * `.roleRef.name` is `cluster-admin`, and/or * Any subject has `kind: User` or `kind: Group` with `name: system:masters`. 2. **Inventory which concrete identities rely on `system:masters`** * For each binding referencing `system:masters` (either as `roleRef` == `cluster-admin` or subject group name), capture full details: ```bash theme={null} kubectl get clusterrolebinding -o yaml ``` * Note which are: * Human users (e.g., corporate SSO groups, individual user names). * Service accounts (kind: ServiceAccount). * External identities mapped to `system:masters` via authentication (e.g., OIDC, client cert CN/O, cloud IAM). 3. **Review necessity of cluster‑wide superuser access for each subject** * For each user/group/service account discovered: * Determine its actual operational purpose (admin, CI/CD, monitoring, break‑glass, etc.). * Confirm with owners whether: * Ongoing `cluster-admin`/`system:masters` level access is required, or * Access can be reduced to specific namespaces/verbs/resources, or * Access is only needed for rare break‑glass scenarios. 4. **Design replacement RBAC where full superuser is not strictly required** * For subjects that do **not** need full `system:masters`/`cluster-admin`: * Identify the minimal `ClusterRole`/`Role` (existing or to be created) that matches required permissions. * Prepare corresponding `RoleBinding`/`ClusterRoleBinding` manifests that: * Bind the subject to that minimal role. * Do **not** reference the `system:masters` group and avoid unnecessary `cluster-admin` usage. * Save the manifests locally (e.g. `restricted-access-.yaml`) for change review/approval. 5. **Apply reduced‑privilege bindings, then remove `system:masters` membership** * On any machine with kubectl access, for each subject you have redesigned access for: 1. Apply the replacement binding(s): ```bash theme={null} kubectl apply -f restricted-access-.yaml ``` 2. Remove the previous binding that relied on `system:masters` / `cluster-admin` (only after confirming new access works in a test): ```bash theme={null} kubectl delete clusterrolebinding ``` * For identities mapped to `system:masters` at the auth layer (e.g., client certs with O=system:masters, OIDC groups, cloud IAM bindings), coordinate with the identity/IAM team to: * Stop mapping those identities into `system:masters`. * Map them into the new, least‑privilege roles instead. 6. **Verify no users are effectively granted via `system:masters`** * On any machine with kubectl access, confirm there are no bindings referencing `system:masters` or unintended `cluster-admin` grants: ```bash theme={null} kubectl get clusterrolebindings -o yaml | grep -A5 'system:masters' || echo "No system:masters references found" kubectl get clusterrolebindings -o yaml | grep -A5 '\bcluster-admin\b' ``` * Manually confirm that: * Any remaining `cluster-admin` binding is strictly necessary (e.g., a controlled break‑glass account). * No regular user, group, or service account is granted access via `system:masters`. ```bash theme={null} # 1) List all ClusterRoleBindings referencing system:masters # Run on: any machine with kubectl access kubectl get clusterrolebindings -o json | \ jq -r ' .items[] | select( (.roleRef.kind=="ClusterRole" and .roleRef.name=="cluster-admin") or (.subjects[]?.kind=="Group" and .subjects[]?.name=="system:masters") ) | .metadata.name ' ``` Problem indication: * Any ClusterRoleBinding that: * Has `roleRef.name: cluster-admin` **and** a subject with `name: system:masters`, or * Has any subject with `kind: Group` and `name: system:masters`, means membership in `system:masters` gives full admin access. *** ```bash theme={null} # 2) Inspect each suspicious ClusterRoleBinding in detail # Replace with each name from the previous command kubectl get clusterrolebinding -o yaml ``` In the output, look for: * `subjects` entries like: * `kind: Group` with `name: system:masters` * Any identity provider group (e.g. from OIDC) that you know is mapped to `system:masters` * `roleRef` with `name: cluster-admin` or any highly privileged role. If `system:masters` is present in `subjects`, or if you know an external group is mapped to `system:masters`, that binding is high risk and needs human review. *** ```bash theme={null} # 3) List all RoleBindings that reference system:masters (less common, but possible) kubectl get rolebindings --all-namespaces -o json | \ jq -r ' .items[] | select(.subjects[]? | .kind=="Group" and .name=="system:masters") | "\(.metadata.namespace)/\(.metadata.name)" ' ``` Problem indication: * Any RoleBinding where a subject has `kind: Group` and `name: system:masters` is using this special group to grant namespace-scoped access and should be reviewed. Even if the Role is not `cluster-admin`, those subjects also inherit any cluster-wide privileges of `system:masters`. *** ```bash theme={null} # 4) Enumerate which Kubernetes users/groups are currently authenticated # (from kubeconfig contexts; this does NOT show all possible IdP users) kubectl config view --raw -o json | jq -r ' .users[]?.user | { username: (.username // "N/A"), client-certificate: (.["client-certificate-data"] // "cert-ref"), exec: .exec } ' ``` Problem indication: * Any user identity that you know (from your IdP, certificates, or API server auth config) is mapped into the `system:masters` group is a candidate for review. kubectl cannot see that mapping; you must correlate with your authentication setup. *** ```bash theme={null} # 5) Verify post-review state (re-run focused query) kubectl get clusterrolebindings -o json | \ jq -r ' .items[] | select(.subjects[]? | .kind=="Group" and .name=="system:masters") | .metadata.name ' ``` If this command prints **no names**, then no ClusterRoleBindings directly grant access to the `system:masters` group. If it still returns any names, those bindings still need human review and a decision on whether to keep or change them. ```bash theme={null} #!/usr/bin/env bash # # Report any bindings that grant cluster-admin or system:masters-equivalent # privileges so they can be reviewed manually. # # Run on: any machine with kubectl access and current-context set to target cluster set -euo pipefail echo "=== Context ===" kubectl config current-context echo echo "=== 1) ClusterRoleBindings referencing 'system:masters' group directly ===" kubectl get clusterrolebindings -o jsonpath='{range .items[?(@.subjects)]}{.metadata.name}{"\n"}{range .subjects[*]} KIND={.kind} NAME={.name} API-GROUP={.apiGroup}{"\n"}{end}{"\n"}{end}' \ | awk 'NR==1{print} /system:masters/ || NR==1' echo echo "=== 2) RoleBindings referencing 'system:masters' group directly (all namespaces) ===" kubectl get rolebindings --all-namespaces -o jsonpath='{range .items[?(@.subjects)]}{.metadata.namespace}{"/"}{.metadata.name}{"\n"}{range .subjects[*]} KIND={.kind} NAME={.name} API-GROUP={.apiGroup}{"\n"}{end}{"\n"}{end}' \ | awk 'NR==1{print} /system:masters/ || NR==1' echo echo "=== 3) ClusterRoleBindings granting 'cluster-admin' ===" kubectl get clusterrolebindings -o jsonpath='{range .items[?(@.roleRef.name=="cluster-admin")]}{.metadata.name}{"\n"}{.roleRef.kind}{" "}{.roleRef.name}{"\n"}{range .subjects[*]} KIND={.kind} NAME={.name} NAMESPACE={.namespace} API-GROUP={.apiGroup}{"\n"}{end}{"\n"}{end}' echo echo "=== 4) RoleBindings granting 'cluster-admin' (all namespaces) ===" kubectl get rolebindings --all-namespaces -o jsonpath='{range .items[?(@.roleRef.name=="cluster-admin")]}{.metadata.namespace}{"/"}{.metadata.name}{"\n"}{.roleRef.kind}{" "}{.roleRef.name}{"\n"}{range .subjects[*]} KIND={.kind} NAME={.name} NAMESPACE={.namespace} API-GROUP={.apiGroup}{"\n"}{end}{"\n"}{end}' echo echo "=== 5) Users in kubeconfig(s) that may map to high-privilege subjects ===" echo "Current kubectl kubeconfig:" kubectl config view --minify --raw echo echo "Note:" echo "- PROBLEMATIC output is any subject of kind 'User' or 'ServiceAccount' whose NAME is 'system:masters' in sections 1 or 2." echo "- Also review any 'User' or 'ServiceAccount' subjects bound to 'cluster-admin' (sections 3 and 4); these are not" echo " automatically violations of this control, but often indicate over-privileged identities." echo "- There is no safe automatic removal: for each flagged subject you must decide manually whether it is still needed," echo " and, if not, adjust or delete the corresponding RoleBinding/ClusterRoleBinding." ``` **Interpreting the output** * A **definite problem** for this specific control is any line in sections 1 or 2 where: * `KIND=Group` and `NAME=system:masters` * These bindings should be reviewed and, if not strictly required, updated to remove the `system:masters` group subject. ### Additional Reading: * [https://github.com/kubernetes/kubernetes/blob/master/pkg/registry/rbac/escalation\_check.go#L38](https://github.com/kubernetes/kubernetes/blob/master/pkg/registry/rbac/escalation_check.go#L38)