Profile Applicability:
• Level 1
Description:
Ensure that access to Kubernetes secrets is restricted to only the users and service accounts that absolutely need it. This includes service account tokens for the Kubernetes API or credentials used by workloads in the cluster.
Rationale:
Kubernetes secrets are sensitive data that can be used to escalate privileges or access external resources. Unauthorized access to these secrets could allow an attacker to gain unauthorized access to critical infrastructure or external systems. Reducing access to secrets minimizes the potential attack surface and the risk of privilege escalation.
Impact:
Pros:
Reduces the risk of unauthorized access to sensitive data and credentials stored as Kubernetes secrets.
Limits the exposure of secrets to only the necessary components, improving overall security.
Cons:
Care must be taken not to restrict access to essential system components that rely on secrets for operation.
Modifying RBAC permissions could impact workloads that rely on secret access for functioning.
Default Value:
By default, Kubernetes assigns get, list, and watch permissions on secret objects to certain roles such as cluster-admin and system controllers. These roles are granted broad access, including secret access for system operations.
Pre-requisites:
Access to Kubernetes cluster via kubectl with appropriate privileges.
Knowledge of current secret access configurations within the cluster.
Sufficient access to modify role-based access control (RBAC) settings.
Remediation
Test Plan:
Using AWS Console:
Review the users who have access to secret objects in the cluster. You can check for get, list, or watch permissions for secrets
Identify which principals (users or service accounts) have these permissions.
Review whether each principal really requires get, list, or watch permissions on secrets.
Using AWS CLI:
List all the clusterrolebindings for the cluster-admin role and other roles that may have access to secrets:
kubectl get clusterrolebindings -o=customcolumns=NAME:.metadata.name,ROLE:.roleRef.name,SUBJECT:.subjects[*].name
Review and identify which principals have the permissions to access secrets.
Implementation Plan
Using AWS Console:
Identify all the clusterrolebindings for users or service accounts with get, list, or watch permissions on secrets.
Modify the RBAC settings to ensure that only necessary users or service accounts have access to secrets. You can remove or limit the scope of access as follows:
kubectl delete clusterrolebinding [name]
For workloads or system components that require access to secrets, ensure that their permissions are specifically configured using appropriate roles and bindings.
Ensure that no critical workloads or system components are affected by these changes.
Using AWS CLI:
Review the clusterrolebindings for any principals that have get, list, or watch access to secrets.
Remove unnecessary clusterrolebindings using:
kubectl delete clusterrolebinding [name]
Modify permissions for necessary components, ensuring minimal access is granted.
Backout Plan
Using AWS Console:
If removing access causes issues with system components or workloads, re-create the clusterrolebinding for the users or service accounts that were affected.
Ensure that only the necessary permissions are granted to restore functionality without overexposing sensitive data.
Using AWS CLI:
If issues occur after removing permissions, recreate the clusterrolebinding using the following command:
kubectl create clusterrolebinding [name] --clusterrole=cluster-admin --user=[user]
Ensure proper testing and validation to ensure no essential workloads are broken by the change.
References: