Profile Applicability:

  • Level 1

Description:
 The system:masters group in Kubernetes provides unrestricted access to the cluster, including the ability to manage resources and change configurations. This check ensures that the system:masters group is avoided for day-to-day use, and only trusted users or service accounts with a specific, limited scope are granted administrative access to the cluster.

Rationale:
 The system:masters group grants full access to the cluster and can be dangerous if used improperly. It is critical to minimize its use in favor of more granular RBAC (Role-Based Access Control) permissions. Overuse or misuse of the system:masters group can lead to excessive privileges and potential security vulnerabilities, including unauthorized access and accidental misconfigurations.

Impact:

Pros:

  • Reduces the security risks by limiting who can perform administrative tasks in the cluster.

  • Helps enforce the principle of least privilege by ensuring only trusted users have elevated access.

  • Provides better control and auditing of who is able to make critical changes to the cluster.

Cons:

  • Requires careful planning to ensure that trusted users can still perform their necessary duties.

  • May introduce complexity when managing user access and permissions across a large number of users or teams.

Default Value:
 By default, the system:masters group includes the highest level of privileges in the cluster, granting full access to all cluster resources. It must be manually restricted or managed to minimize unnecessary access.

Pre-requisites:
 Ensure that RBAC is enabled in your Kubernetes cluster, and that users are assigned the appropriate roles and permissions based on their responsibilities.

Test Plan:

Using Azure Console:

  1. Navigate to the Azure portal and access your Azure Kubernetes Service (AKS) cluster.

  2. Review the Role-Based Access Control (RBAC) settings to ensure that the system:masters group is not overused.

  3. Check if users or service accounts have been granted access to the system:masters group and assess whether that access is necessary.

  4. Review the access control and audit logs to confirm that only authorized users are assigned to the system:masters group.

Using Azure CLI:

Use the following command to list all RoleBindings and ClusterRoleBindings that assign users to the system:masters group:

kubectl get clusterrolebindings -o=jsonpath='{.items[?(@.roleRef.name=="cluster-admin")].subjects[*].name}'

Check if any users or service accounts are assigned to the system:masters group:

kubectl get clusterrolebindings --all-namespaces -o=jsonpath='{.items[*].subjects[?(@.kind=="Group" && @.name=="system:masters")].name}'

Ensure that the system:masters group is restricted to only trusted administrators and that other users are granted more specific permissions.

Implementation Plan:

Using Azure Console:

  1. In the Azure portal, go to your AKS cluster and access the Access Control (IAM) section.

  2. Review and modify the RBAC roles to remove any unnecessary users or service accounts from the system:masters group.

Create custom RBAC roles that grant only the necessary permissions for each user or service account, such as:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: admin-role
rules:
- apiGroups: [""]
  resources: ["pods", "services", "deployments"]
  verbs: ["get", "list", "create", "update", "delete"]

  1. Bind the appropriate roles to users or service accounts using RoleBindings and ClusterRoleBindings, ensuring that only trusted users or service accounts are assigned to high-privilege roles.

  2. Remove unnecessary access from the system:masters group.

Using Azure CLI:

Remove users from the system:masters group by editing or deleting their ClusterRoleBindings or RoleBindings:

kubectl delete clusterrolebinding <binding-name>

Create a more restrictive ClusterRole with the necessary permissions for administrative users:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: limited-admin
rules:
- apiGroups: [""]
  resources: ["pods", "services"]
  verbs: ["get", "list", "create"]

Apply the new ClusterRole:

 kubectl apply -f limited-admin-role.yaml

Create a ClusterRoleBinding to bind the limited ClusterRole to a trusted user:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: limited-admin-binding
subjects:
- kind: User
  name: <user-name>
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: limited-admin
  apiGroup: rbac.authorization.k8s.io

Apply the ClusterRoleBinding:

 kubectl apply -f limited-admin-binding.yaml

Backout Plan:

Using Azure Console:

  1. If restricting the system:masters group causes issues, revert the changes by modifying the RBAC roles and RoleBindings in the Azure portal to reassign the necessary users to the system:masters group.

Using Azure CLI:

Revert the ClusterRoleBindings by re-adding the system:masters group to the appropriate users:

kubectl create clusterrolebinding <binding-name> --clusterrole=cluster-admin --user=<user-name>

If necessary, delete or modify any ClusterRoleBindings that restrict access to the system:masters group.

References:

  1. Kubernetes RBAC Documentation

  2. Azure Kubernetes Service (AKS) Role-Based Access Control

  3. Kubernetes Best Practices for RBAC