<p>I am having a k3s cluster with my application pods running. In all the pods when I login ( with <code>kubectl exec &lt;pod_name&gt; -n &lt;ns&gt; -it /bin/bash</code> command ) there is <strong><code>kubernetes.io</code></strong> directory which contain secret token that anyone can get if they do  <code>cat token</code> :</p>
<pre><code>root@Ubuntu-VM: kubectl exec app-test-pod -n app-system -it /bin/bash
root@app-test-pod:/var/run/secrets/kubernetes.io/serviceaccount# ls -lhrt
total 0
lrwxrwxrwx 1 root root 12 Oct 11 12:07 token -&gt; ..data/token
lrwxrwxrwx 1 root root 16 Oct 11 12:07 namespace -&gt; ..data/namespace
lrwxrwxrwx 1 root root 13 Oct 11 12:07 ca.crt -&gt; ..data/ca.crt
</code></pre>
<p>This seems a security threat (or vulnerability). Can someone let me know if there is a way to remove this dependency from pod so that I can restrict users (even root users also) to access this secret if they login to pod ? Also If this is possible then how will pods do communicate with the API Server ?</p>

solveit
<p>To clarify a couple of things:</p>
<blockquote>
<p>This seems a security threat (or vulnerability).</p>
</blockquote>
<p>It actually isn't a vulnerability unless you configured it to be one.
The ServiceAccount you are talking about is the <code>deafult</code> one which exists in every namespace.
By default that ServiceAccount does not have any permissions that make it unsafe.
If you want to you <em>can</em> add certain rights to the <code>default</code> ServiceAccount <a href="https://kubernetes.io/docs/reference/access-authn-authz/rbac/" rel="noreferrer">using RBAC</a>. For example you can configure it to be able to list all Pods in the same namespace but unless you do that, the ServiceAccount is not considered a vulnerability at all and will not be able to retrieve any useful information.
This applies to <em>all</em> ServiceAccounts, not only the <code>default</code> one.</p>
<blockquote>
<p>Can someone let me know if there is a way to remove this dependency from pod so that I can restrict users (even root users also) to access this secret if they login to pod ?</p>
</blockquote>
<p>Yes it is possible, actually there are two options:</p>
<p>Firstly there is a field called <code>automountServiceAccountToken</code> for the <code>spec</code> section in Pods which you can set to <code>false</code> if you do not want the <code>default</code> ServiceAccount to be mounted at all.</p>
<p>Here is an example:</p>
<pre class="lang-yaml prettyprint-override"><code>apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  automountServiceAccountToken: false
  [...]
</code></pre>
<p>Other than that you can create/edit a ServiceAccount and assign it the <code>automountServiceAccountToken: false</code> field:</p>
<pre class="lang-yaml prettyprint-override"><code>apiVersion: v1
kind: ServiceAccount
automountServiceAccountToken: false
metadata:
  namespace: default
[...]
</code></pre>
<blockquote>
<p>Also If this is possible then how will pods do communicate with the API Server ?</p>
</blockquote>
<p>Pods actually do not need to communicate with the API server at all.
Even when using features like a <code>livenessProbe</code> it is not necessary for Pods to communicate with the API server at all.
As a matter of fact most Pods <em>never</em> communicate with the API server.
The only reason a Pod would need to communicate with the API server is if it is planning on directly interacting with the cluster. Usually this is never required unless you want to write a <a href="https://kubernetes.io/docs/concepts/extend-kubernetes/operator/" rel="noreferrer">custom operator</a> or something similar.
You will still be able to use all the functionality a Pod has to offer you even if you do not mount the ServiceAccount because all those features are based around a Kubernetes communicating with your Pod not the other way around (a <code>livenessProbe</code> for example is being evaluated by <code>kubelet</code>, there is no need at all for the Pod to communicate with the API).</p>
