Profile Applicability:

  • Level 1

Description:
 In Kubernetes, secrets are used to store sensitive data such as passwords, tokens, and keys. This check ensures that access to secrets is minimized, limiting the exposure of sensitive information to only the pods, services, and users that absolutely require it. By controlling access to secrets, you prevent unauthorized users or workloads from accessing sensitive information.

Rationale:
 Exposing secrets to unauthorized users or workloads increases the risk of data leaks, security breaches, and privilege escalation. By limiting access to secrets and enforcing strict access control policies, you reduce the potential attack surface in your Kubernetes cluster and protect sensitive information from being compromised.

Impact:

  • Pros:

    • Enhances security by limiting the exposure of sensitive data.

    • Reduces the risk of unauthorized access to credentials or tokens.

    • Helps in adhering to security best practices and compliance standards (e.g., GDPR, HIPAA).

  • Cons:

    • Requires careful configuration of RBAC and ServiceAccount policies.

    • Can introduce operational overhead to manage and monitor secret access.

Default Value:
 By default, Kubernetes allows all workloads in the same namespace to access secrets in that namespace. Without proper access control, secrets are accessible to any user or pod with sufficient permissions.

Pre-requisites:
 Ensure that RBAC (Role-Based Access Control) and Service Accounts are properly configured to control access to secrets. Additionally, PodSecurityPolicies or equivalent admission controllers should be used to enforce these policies.

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 only trusted users and workloads have access to secrets.

  3. Verify that secrets are not exposed to workloads that do not need them. Check the ServiceAccount settings for pods to ensure they are restricted to only necessary services.

  4. Ensure that PodSecurityPolicies or similar mechanisms are in place to limit which pods can access secrets.

Using Azure CLI:

1. List the current RoleBindings and ClusterRoleBindings to check for permissions related to secrets:

kubectl get rolebindings --all-namespaces -o=jsonpath='{.items[*].subjects[*].name}'

kubectl get clusterrolebindings --all-namespaces -o=jsonpath='{.items[*].subjects[*].name}'

2. List the secrets in a specific namespace to confirm the access restrictions:

kubectl get secrets --namespace=<namespace-name>

3. Ensure that the RBAC policies are configured to restrict access to secrets. You can use the following command to check access control policies:

kubectl describe rolebinding <rolebinding-name> --namespace=<namespace-name>

Implementation Plan:

Using Azure Console:

1. In the Azure portal, navigate to Azure Kubernetes Service (AKS) and review the Role-Based Access Control (RBAC) settings.

2. Bind this Role to trusted service accounts that require access to secrets:

3. Apply these RBAC roles and RoleBindings to ensure that only the necessary workloads or users can access secrets.

Using Azure CLI:

1. Create a Role to restrict access to secrets:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: secret-access-restricted
  namespace: <namespace-name>
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "list"]

2. Apply the Role using the following command:

 kubectl apply -f secret-access-role.yaml


3. Create a RoleBinding to bind the Role to the appropriate service account or user:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: secret-access-binding
  namespace: <namespace-name>
subjects:
- kind: ServiceAccount
  name: <service-account-name>
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: secret-access-restricted
  apiGroup: rbac.authorization.k8s.io

4. Apply the RoleBinding:

 kubectl apply -f secret-access-binding.yaml


Backout Plan:

Using Azure Console:

  1. If restricting access to secrets causes issues with legitimate workloads, revert the changes in the Azure portal by modifying the RBAC roles and RoleBindings to re-enable access to secrets where necessary.

Using Azure CLI:

1. To revert the configuration, delete the Role and RoleBinding with the following commands:

kubectl delete role secret-access-restricted --namespace=<namespace-name>
kubectl delete rolebinding secret-access-binding --namespace=<namespace-name>


References:

  1. Kubernetes Secrets Documentation

  2. Azure Kubernetes Service (AKS) Best Practices

  3. Kubernetes RBAC Documentation