Description
Workloads using the same serviceAccountName in the same namespace use the API permissions of the same service account. Modern Pod-bound tokens are issued per Pod, so sharing an account does not mean identical token strings. A compromised workload can abuse the shared account’s permission scope.
Separate ServiceAccounts when workloads have different roles. Sharing an account can be appropriate for Pods with the same permission requirements, such as replicas of one application.
Potential impact
- Different workloads can receive common permissions beyond their needs.
- Compromise of one workload can affect other resources accessible to the shared account.
- Requests from different workloads can be harder to distinguish in audit logs.
Remediation
- Use separate ServiceAccounts for workloads with different purposes.
- Check shared accounts for excessive permissions.
- Separate identities according to application requirements and grant each account only the necessary RBAC permissions.
Examples
The two Pods are assumed to run in the same namespace. Create the referenced ServiceAccounts and required role bindings separately.
Before
yaml
apiVersion: v1
kind: Pod
metadata:
name: pod1
spec:
serviceAccountName: service1
containers:
- name: mycontainer
image: redis
---
apiVersion: v1
kind: Pod
metadata:
name: pod2
spec:
serviceAccountName: service1
containers:
- name: envars-test-container
image: nginx
After
yaml
apiVersion: v1
kind: Pod
metadata:
name: pod1
spec:
serviceAccountName: service1
containers:
- name: mycontainer
image: redis
---
apiVersion: v1
kind: Pod
metadata:
name: pod2
spec:
serviceAccountName: service2
containers:
- name: envars-test-container
image: nginx
Explanation:
- Before: Both workloads use the permissions of one ServiceAccount. Separate them if their access requirements differ.
- After: The workloads name different ServiceAccounts. Their role bindings must also differ as needed to achieve permission separation.