Overview
The default service account should not be used to ensure that rights granted to applications can be more easily audited and reviewed.
Rationale
Kubernetes provides a default service account which is used by cluster workloads where no specific service account is assigned to the pod.
Where access to the Kubernetes API from a pod is required, a specific service account should be created for that pod, and rights granted to that service account.
The default service account should be configured such that it does not provide a service account token and does not have any explicit rights assignments.
Impact
All workloads which require access to the Kubernetes API will require an explicit service account to be created.
Audit
For each namespace in the cluster, review the rights assigned to the default service account and ensure that it has no roles or cluster roles bound to it apart from the defaults.
Additionally ensure that the automountServiceAccountToken: false setting is in place for each default service account.
Remediation guidance
Create explicit service accounts wherever a Kubernetes workload requires specific access to the Kubernetes API server.
Modify the configuration of each default service account to include this value
automountServiceAccountToken: false
Default Value
By default the default service account allows for its service account token to be mounted in pods in its namespace.
References
Service-wide remediation
Recommended when many resources are affected: fix the platform baseline first so new resources inherit the secure setting, then remediate the existing flagged resources in batches.
Kubernetes
Use admission policies, baseline cluster configuration, GitOps templates, and namespace or workload guardrails so new deployments follow the control by default.
Operational rollout
- Fix the baseline first at the account, subscription, project, cluster, or tenant scope that owns this control.
- Remediate the currently affected resources in batches, starting with internet-exposed and production assets.
- Re-scan and track approved exceptions with an owner and expiry date.
Query logic
These are the stored checks tied to this control.
Kubernetes default Service Accounts that automatically mount
Connectors
Covered asset types
Expected check: eq []
{
serviceAccounts(
where: { internalName: "default", automountServiceAccountToken: true }
) {
...AssetFragment
}
}
Kubernetes RoleBindings bound to default Service Accounts
Connectors
Covered asset types
Expected check: eq []
{
serviceAccounts(
where: {
internalName: "default"
roleBindingSubjects_SOME: { roleBinding: { idFromProvider_NOT: "" } }
}
) {
roleBindingSubjects {
roleBinding {
...AssetFragment
}
}
}
}
Kubernetes ClusterRoleBindings bound to default Service Accounts
Connectors
Covered asset types
Expected check: eq []
{
serviceAccounts(
where: {
internalName: "default"
clusterRoleBindingSubjects_SOME: {
clusterRoleBindings: { idFromProvider_NOT: "" }
}
}
) {
clusterRoleBindingSubjects {
clusterRoleBindings {
...AssetFragment
}
}
}
}
Kubernetes