Profile Applicability:
Level 1
Description:
In Kubernetes, each namespace has a default service account (default), which is automatically assigned to any pod that does not explicitly specify a service account. This check ensures that the default service account is not actively used for any workloads, helping to enforce proper isolation, security, and control by explicitly assigning service accounts to pods.
Rationale:
Using the default service account for workloads exposes the cluster to security risks, as this account is typically granted broad permissions by Kubernetes. Ensuring that default service accounts are not actively used limits potential attack surfaces, improves control over permissions, and enforces the principle of least privilege by making explicit decisions about access controls.
Impact:
Pros:
Reduces security risks by ensuring workloads run with explicitly defined, limited permissions.
Helps enforce the principle of least privilege by requiring the specification of service accounts with limited access to resources.
Increases auditability of who has access to resources within the cluster.
Cons:
Requires users to explicitly define and manage service accounts for each workload, which may increase operational overhead.
Some workloads may be affected if the necessary service accounts are not defined.
Default Value:
By default, all pods are assigned the default service account unless a specific service account is defined.
Pre-requisites:
Ensure that RBAC (Role-Based Access Control) and Service Accounts are properly configured to manage and restrict access to Kubernetes resources.
Test Plan:
Using Azure Console:
Navigate to the Azure portal and access your Azure Kubernetes Service (AKS) cluster.
Review the Pod specifications and check if the default service account is used in any pods.
Ensure that RBAC and Service Account configurations are in place to ensure that only custom service accounts are used for workloads.
Using Azure CLI:
1. Use the following command to list all pods and check if they are using the default service account:
kubectl get pods --all-namespaces -o=jsonpath='{.items[*].spec.serviceAccount}'
2. Ensure that no pods are using the default service account. If any pods are using the default service account, update their configurations to use a custom service account.
3. Use this command to list the service accounts in a specific namespace:
kubectl get serviceaccounts --namespace=<namespace-name>
Implementation Plan:
Using Azure Console:
1. In the Azure portal, go to your AKS cluster and access the Pod specifications.
2. Explicitly assign a custom service account to each pod by modifying the pod specification to use a service account that has the appropriate permissions for the workload:
3. Apply this configuration across all pods, ensuring that the default service account is not used in any of the pods.
Using Azure CLI:
1. Modify the Pod specification to use a custom service account:
serviceAccountName: <custom-service-account-name>
2. Apply the updated Pod configuration:
kubectl apply -f pod-spec.yaml
3. Ensure that all new pods are assigned to a specific, custom service account rather than using the default service account.
4. To create a custom service account and bind it to the appropriate roles, run:
kubectl create serviceaccount <service-account-name> --namespace=<namespace-name> kubectl create clusterrolebinding <binding-name> --clusterrole=admin --serviceaccount=<namespace-name>:<service-account-name>
Backout Plan:
Using Azure Console:
If changing the service account causes issues with workloads, revert the changes in the Azure portal by re-assigning the default service account to the affected pods.
Using Azure CLI:
1. Revert the Pod specification by removing the custom service account and allowing the default service account to be used:
serviceAccountName: default
2. Apply the reverted configuration:
kubectl apply -f pod-spec.yaml
3. If necessary, modify RBAC settings to allow the appropriate access to the default service account.
References:
Kubernetes RBAC Documentation
Kubernetes Best Practices for Service Accounts