Profile Applicability:

  • Level 1

Description:
 In Azure Kubernetes Service (AKS), service accounts are used to grant access to Kubernetes resources for pods and workloads. It is considered a best practice to create and use dedicated service accounts for specific applications or workloads, rather than using the default service account. This check ensures that each application or workload uses a dedicated service account, reducing the risk of privilege escalation and improving security isolation.

Rationale:
 Using dedicated service accounts ensures that each workload has only the permissions it needs, following the principle of least privilege. This limits the potential impact of a compromised workload and simplifies access control management. By avoiding the use of the default service account, which might have broader access, you can better secure your AKS cluster.

Impact:

  • Pros:

    • Reduces the attack surface by limiting access to resources based on the needs of each workload.

    • Improves security by using service accounts that are tailored to specific roles or workloads.

    • Enables better management and auditing of workloads and their associated permissions.

  • Cons:

    • Requires additional configuration and management of service accounts.

    • Increases the complexity of managing workloads, especially in large-scale environments.

Default Value:
 By default, Kubernetes uses the default service account for all pods if no service account is specified. This should be avoided in favor of dedicated service accounts.

Pre-requisites:
 Ensure that Role-Based Access Control (RBAC) is configured and that service accounts are created and assigned to workloads as needed.

Remediation

Test Plan:

Using Azure Console:

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

  2. Review the Service Accounts used by the deployed workloads and ensure that each application or workload has its own dedicated service account.

  3. Check the Role Bindings and Role Assignments to confirm that service accounts are granted the necessary permissions.

Using Azure CLI:

  1. List the service accounts in your AKS cluster using the following command:

     kubectl get serviceaccounts --all-namespaces

  2. Verify that each application or workload is using its own dedicated service account and not the default service account.

Implementation Plan:

Using Azure Console:

  1. In the Azure portal, navigate to your AKS cluster.

  2. Create a dedicated service account for each application or workload using the Service Accounts section under Kubernetes Services.

  3. Assign appropriate RBAC roles to each service account to grant the minimum required permissions for the workload.

  4. Modify the deployment or pod configurations to reference the dedicated service accounts, replacing any use of the default service account.

Using Azure CLI:

  1. Create a dedicated service account for your workload:

     kubectl create serviceaccount <service-account-name> --namespace=<namespace-name>

  2. Create a role binding to assign the appropriate permissions to the service account:

    kubectl create rolebinding <rolebinding-name> --role=<role-name> --serviceaccount=<namespace-name>:<service-account-name> --namespace=<namespace-name>

  3. Update the deployment or pod specification to use the dedicated service account by adding the serviceAccountName field:

Backout Plan:

Using Azure Console:

  1. If the use of dedicated service accounts causes issues, revert the changes by switching back to the default service account for the affected workloads.

Using Azure CLI:

  1. Revert the service account assignment by editing the deployment or pod spec to use the default service account:
         kubectl edit deployment <deployment-name> --namespace=<namespace-name>

  2. Remove the serviceAccountName field or set it back to default.

References:

  1. Azure Kubernetes Service (AKS) Service Account Documentation

  2. Kubernetes Service Account Documentation