Profile Applicability:
• Level 1
Description:
Ensure that the default service account is not used for workloads that require access to the Kubernetes API. Explicit service accounts should be created and assigned to workloads to better control and review access rights.
Rationale:
Kubernetes provides a default service account that is automatically assigned to pods when no specific service account is defined. While convenient, using the default service account can make it difficult to track and audit access rights for workloads. By creating explicit service accounts, you can better control and restrict access, ensuring the principle of least privilege is applied.
Impact:
Pros:
Improves security by preventing broad access granted to the default service account.
Enables more granular auditing of workloads and their access to the Kubernetes API.
Enhances the ability to enforce least privilege by using specific service accounts.
Cons:
Requires the creation and management of additional service accounts for workloads that need access to the Kubernetes API.
Workloads requiring Kubernetes API access will require explicit configuration for service account creation.
Default Value:
By default, the default service account allows its service account token to be mounted in pods within its namespace.
Pre-requisites:
Access to Kubernetes using kubectl with sufficient privileges to modify service account configurations.
Ability to patch service accounts and manage role bindings.
Remediation
Test Plan:
Using AWS Console:
Review the roles and cluster roles bound to the default service account for each namespace.
Ensure that no roles or cluster roles, apart from the default ones, are bound to the default service account.
Ensure that automountServiceAccountToken: false is set for each default service account to prevent automatic mounting of its token.
For each workload that requires access to the Kubernetes API, create a dedicated service account.
Using AWS CLI:
List all service accounts across namespaces:
kubectl get serviceaccounts --all-namespaces -o yaml
Review the output to ensure no roles or bindings have been assigned to the default service account.
Check that automountServiceAccountToken: false is set for the default service account.
Create explicit service accounts for workloads requiring Kubernetes API access, ensuring minimal and necessary permissions.
Implementation Plan
Using AWS Console:
Identify the namespaces where the default service account is still being used and having roles or cluster roles bound to it.
Remove any role bindings or cluster role bindings associated with the default service account that are not part of the defaults.
Modify the default service account in each namespace to include automountServiceAccountToken: false. T
Create new service accounts where necessary for workloads requiring access to the Kubernetes API. Bind them to the appropriate roles or cluster roles based on their specific needs.
Using AWS CLI:
Identify the default service accounts using
kubectl get serviceaccounts --all-namespaces -o yaml.
Patch the default service account in each namespace to disable the automatic mounting of the service account token:
kubectl patch serviceaccount default -p $'automountServiceAccountToken: false'
If applicable, create new service accounts for workloads requiring Kubernetes API access and bind them to appropriate roles.
Backout Plan
Using AWS Console:
If the changes result in broken workloads, revert the automountServiceAccountToken setting to true for the default service account.
Re-create any necessary role bindings for workloads that require specific permissions.
Using AWS CLI:
If any issues arise, restore the previous configuration for the default service account by re-enabling automountServiceAccountToken: true.
Recreate role or cluster role bindings for the default service account if needed.