11< h2 > Why is this an issue?</ h2 >
2- < p > Service account tokens are Kubernetes secrets created automatically to authenticate applications running inside pods to the API server. If a pod is
3- compromised, an attacker could use this token to gain access to other resources in the cluster.</ p >
2+ < p > Service account tokens are Kubernetes secrets to authenticate applications running inside pods to the API server. If a pod is compromised, an
3+ attacker could use this token to gain access to other resources in the cluster.</ p >
44< p > For example, they could create new pods, modify existing ones, or even delete critical system pods, depending on the permissions associated with
55the service account.</ p >
6- < p > Therefore, it’s recommended to disable the automounting of service account tokens when it’s not necessary for the application running in the
7- pod.</ p >
86< h3 > What is the potential impact?</ h3 >
97< h4 > Unauthorized Access</ h4 >
108< p > If a pod with a mounted service account gets compromised, an attacker could potentially use the token to interact with the Kubernetes API, possibly
@@ -21,15 +19,30 @@ <h4>Denial of Service</h4>
2119< h2 > How to fix it</ h2 >
2220< h3 > Code examples</ h3 >
2321< h4 > Noncompliant code example</ h4 >
22+ < p > In this example, the service account token is mounted in the pod < code > example-pod</ code > by default, but is unnecessary for the pod and its
23+ service(s) to function correctly.</ p >
2424< pre data-diff-id ="1 " data-diff-type ="noncompliant ">
2525apiVersion: v1
2626kind: Pod
2727metadata:
2828 name: example-pod
2929spec: # Noncompliant
3030 containers:
31- - name: example-pod
32- image: nginx:1.25.3
31+ - name: example-container
32+ image: nginx
33+ </ pre >
34+ < p > In this example, the service account token is mounted in the pod < code > example-pod</ code > and is necessary, for example because it allows a
35+ third-party service to authenticate with the Kubernetes API. However, no specific permissions are granted to the service account:</ p >
36+ < pre data-diff-id ="2 " data-diff-type ="noncompliant ">
37+ apiVersion: v1
38+ kind: Pod
39+ metadata:
40+ name: example-pod
41+ spec:
42+ serviceAccountName: example-sa # Noncompliant
43+ containers:
44+ - name: example-container
45+ image: nginx
3346</ pre >
3447< h4 > Compliant solution</ h4 >
3548< pre data-diff-id ="1 " data-diff-type ="compliant ">
@@ -39,13 +52,68 @@ <h4>Compliant solution</h4>
3952 name: example-pod
4053spec:
4154 containers:
42- - name: example-pod
43- image: nginx:1.25.3
55+ - name: example-container
56+ image: nginx
4457 automountServiceAccountToken: false
4558</ pre >
59+ < p > In the following example, Role bindings are created, but Cluster Role Bindings would be more appropriate if the service account is intended to be
60+ used across multiple namespaces:</ p >
61+ < pre data-diff-id ="2 " data-diff-type ="compliant ">
62+ ---
63+ apiVersion: v1
64+ kind: ServiceAccount
65+ metadata:
66+ name: example-sa
67+ namespace: default
68+
69+ ---
70+ apiVersion: rbac.authorization.k8s.io/v1
71+ kind: Role
72+ metadata:
73+ namespace: default
74+ name: example-role
75+ rules:
76+ - apiGroups: [""]
77+ resources: ["pods"]
78+ verbs: ["list"]
79+
80+ ---
81+ apiVersion: rbac.authorization.k8s.io/v1
82+ kind: RoleBinding
83+ metadata:
84+ name: example-role-binding
85+ namespace: default
86+ subjects:
87+ - kind: ServiceAccount
88+ name: example-sa
89+ namespace: default
90+ roleRef:
91+ kind: Role
92+ name: example-role
93+ apiGroup: rbac.authorization.k8s.io
94+
95+ ---
96+ apiVersion: v1
97+ kind: Pod
98+ metadata:
99+ name: example-pod
100+ namespace: default
101+ spec:
102+ serviceAccountName: example-sa
103+ containers:
104+ - name: example-container
105+ image: nginx
106+ </ pre >
46107< h3 > How does this work?</ h3 >
47- < p > The automounting of service account tokens can be disabled by setting < code > automountServiceAccountToken: false</ code > in the pod’s specification.
48- Additionally, it can be disabled in the configuration of an accompanied service account.</ p >
108+ < p > The essential part of the solution is to make sure that permissions within the cluster are constructed in a way that minimizes the risk of
109+ unauthorized access.</ p >
110+ < p > To do so, it follows a least-privilege approach.</ p >
111+ < ol >
112+ < li > If the service account token is unnecessary for the pod to function, disable automounting. </ li >
113+ < li > If the service account token is required, ensure that the service account has the least amount of permissions necessary to perform its
114+ function. </ li >
115+ </ ol >
116+ < p > Additionally, service account token automounting can be disabled directly from the service account specification file.</ p >
49117< h2 > Resources</ h2 >
50118< h3 > Documentation</ h3 >
51119< ul >
0 commit comments