Profile Applicability:
Level 1
Description:
Access to Kubernetes secrets should be restricted to only those users and service accounts that absolutely need it. This check ensures that secrets are not exposed to unauthorized users or service accounts, minimizing the risk of accidental or malicious access to sensitive data.
Rationale:
Secrets are used to store sensitive information such as passwords, API keys, and tokens. If not properly protected, unauthorized users or workloads could access these secrets, leading to data breaches, compromise of services, or other security incidents. Minimizing access to secrets is a key security best practice for reducing the attack surface and securing sensitive information.
Impact:
Pros:
Reduces the risk of exposing sensitive data.
Helps enforce the principle of least privilege for both users and service accounts.
Cons:
Additional management effort to properly configure and enforce access controls for secrets.
May require careful review of who needs access to secrets to ensure minimal disruption.
Default Value:
By default, Kubernetes does not restrict access to secrets, and any user with the necessary RBAC permissions can access them. Therefore, explicit policies and role bindings should be implemented to minimize access.
Pre-requisites:
Ensure that Role-Based Access Control (RBAC) is properly configured and that secrets are stored in a secure and encrypted manner.
Remediation
Test Plan:
Using Azure Console:
Navigate to the Kubernetes RBAC settings and review the role bindings for secrets.
Ensure that only authorized users or service accounts have access to secrets.
Using Azure CLI:
Use the following command to check which users or service accounts have access to secrets:
kubectl get secrets --all-namespaces
Review the roles or role bindings that grant access to secrets.
Implementation Plan:
Using Azure Console:
Review the Kubernetes role bindings and policies for accessing secrets.
Ensure that only the necessary roles (e.g., admin roles) have access to secrets and that other roles are restricted from accessing them.
Apply the principle of least privilege by creating separate roles for managing secrets with limited access.
Using Azure CLI:
List the role bindings related to secrets:
kubectl get rolebindings --all-namespaces -o yaml
Modify or delete any role bindings that grant unnecessary access to secrets.
Backout Plan:
Using Azure Console:
If restricting access to secrets causes operational issues, temporarily restore the previous access configuration for the affected roles or service accounts.
Using Azure CLI:
Revert any changes made to the role bindings by re-creating the previous access configuration using the following command:
kubectl create rolebinding <binding-name> --role=<role-name> --user=<user-name> --namespace=<namespace>