<p>If not specified, pods are run under a default service account.</p>
<ul>
<li>How can I check what the default service account is authorized to do?</li>
<li>Do we need it to be mounted there with every pod?</li>
<li>If not, how can we disable this behavior on the namespace level or cluster level.</li>
<li>What other use cases the default service account should be handling?</li>
<li>Can we use it as a service account to create and manage the Kubernetes deployments in a namespace? For example we will not use real user accounts to create things in the cluster because users come and go.</li>
</ul>
<p>Environment: Kubernetes 1.12 , with RBAC</p>

Ijaz Ahmad
<ol>
<li>A default service account is automatically created for each namespace.</li>
</ol>
<blockquote>
<p>kubectl get serviceaccount</p>
<p>NAME    SECRETS   AGE</p>
<p>default   1       1d</p>
</blockquote>
<ol start="2">
<li><p>Service accounts can be added when required. Each pod is associated with exactly one service account but multiple pods can use the same service account.</p>
</li>
<li><p>A pod can only use one service account from the same namespace.</p>
</li>
<li><p>Service account are assigned to a pod by specifying the account’s name in the pod manifest. If you don’t assign it explicitly the pod will use the default service account.</p>
</li>
<li><p>The default permissions for a service account don't allow it to
list or modify any resources. The default service account isn't allowed to view cluster state let alone modify it in any way.</p>
</li>
<li><p>By default, the default service account in a namespace has no permissions other than those of an unauthenticated user.</p>
</li>
<li><p>Therefore pods by default can’t even view cluster state. Its up to you to grant them appropriate permissions to do that.</p>
</li>
</ol>
<blockquote>
<p>kubectl exec -it test -n foo sh / # curl
localhost:8001/api/v1/namespaces/foo/services {   &quot;kind&quot;: &quot;Status&quot;,<br />
&quot;apiVersion&quot;: &quot;v1&quot;,   &quot;metadata&quot;: {</p>
<p>},   &quot;status&quot;: &quot;Failure&quot;,   &quot;message&quot;: &quot;services is forbidden: User
&quot;system:serviceaccount:foo:default&quot; cannot list resource
&quot;services&quot; in API group &quot;&quot; in the namespace &quot;foo&quot;&quot;,   &quot;reason&quot;:
&quot;Forbidden&quot;,   &quot;details&quot;: {
&quot;kind&quot;: &quot;services&quot;   },   &quot;code&quot;: 403</p>
</blockquote>
<p>as can be seen above the default service account cannot list services</p>
<p>but when given proper role and role binding like below</p>
<pre><code>apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  creationTimestamp: null
  name: foo-role
  namespace: foo
rules:
- apiGroups:
  - &quot;&quot;
  resources:
  - services
  verbs:
  - get
  - list

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  creationTimestamp: null
  name: test-foo
  namespace: foo
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: foo-role
subjects:
- kind: ServiceAccount
  name: default
  namespace: foo
</code></pre>
<p>now i am able to list the resurce service</p>
<pre><code>kubectl exec -it test -n foo sh
/ # curl localhost:8001/api/v1/namespaces/foo/services
{
  &quot;kind&quot;: &quot;ServiceList&quot;,
  &quot;apiVersion&quot;: &quot;v1&quot;,
  &quot;metadata&quot;: {
    &quot;selfLink&quot;: &quot;/api/v1/namespaces/bar/services&quot;,
    &quot;resourceVersion&quot;: &quot;457324&quot;
  },
  &quot;items&quot;: []
</code></pre>
<ol start="8">
<li><p>Giving all your service accounts the <code>clusteradmin</code> ClusterRole is a
bad idea. It is best to give everyone only the permissions they need to do their job and not a single permission more.</p>
</li>
<li><p>It’s a good idea to create a specific service account for each pod
and then associate it with a tailor-made role or a ClusterRole through a
RoleBinding.</p>
</li>
<li><p>If one of your pods only needs to read pods while the other also needs to modify them then create two different service accounts and make those pods use them by specifying the <code>serviceaccountName</code> property in the
pod spec.</p>
</li>
</ol>
<p>You can refer the below link for an in-depth explanation.</p>
<p><a href="https://developer.ibm.com/recipes/tutorials/service-accounts-and-auditing-in-kubernetes/" rel="noreferrer">Service account example with roles</a></p>
<p>You can check <code>kubectl explain serviceaccount.automountServiceAccountToken</code> and edit the service account</p>
<p>kubectl edit serviceaccount default -o yaml</p>
<pre><code>apiVersion: v1
automountServiceAccountToken: false
kind: ServiceAccount
metadata:
  creationTimestamp: 2018-10-14T08:26:37Z
  name: default
  namespace: default
  resourceVersion: &quot;459688&quot;
  selfLink: /api/v1/namespaces/default/serviceaccounts/default
  uid: de71e624-cf8a-11e8-abce-0642c77524e8
secrets:
- name: default-token-q66j4
</code></pre>
<p>Once this change is done whichever pod you spawn doesn't have a serviceaccount token as can be seen below.</p>
<pre><code>kubectl exec tp -it bash
root@tp:/# cd /var/run/secrets/kubernetes.io/serviceaccount
bash: cd: /var/run/secrets/kubernetes.io/serviceaccount: No such file or directory
</code></pre>
