<p>We're trying to create different kuberentes secrets and offer access to specific secrets through specific service accounts that are assigned to pods. For example:</p>
<p>Secrets</p>
<pre><code>- User-Service-Secret
- Transaction-Service-Secret
</code></pre>
<p>Service Account</p>
<pre><code>- User-Service
- Transaction-Service
</code></pre>
<p>Pods</p>
<pre><code>- User-Service-Pod
- Transaction-Service-Pod
</code></pre>
<p>The idea is to restrict access to <code>User-Service-Secret</code>secret to <code>User-Service</code> service account that is assign to <code>User-Service-Pod</code>. So we can set this all up with the relevant kuberentes resources (i.e. ServiceAccount, Role, RoleBinding), but we realize that this may not be actually enforced, because <code>Transaction-Service-Pod</code> can just as easily read the <code>User-Service-Secret</code> secret when Pod starts up, even though the service account its assign to doesn't have <code>get</code> permission to the <code>User-Service-Secret</code>.</p>
<p>How do we actually enforce the RBAC system?</p>
<p>FYI we are using EKS</p>

<p>First it is important to distinguish between API access to the secret and consuming the secret as an environment variable or a mounted volume.</p>
<p>TLDR:</p>
<ul>
<li>RBAC controls who can access a secret (or any other resource) using K8s API requests.</li>
<li>Namespaces or the service account's <code>secrets</code> attribute control if a pod can consume a secret as an environment variable or through a volume mount.</li>
</ul>
<h1>API access</h1>
<p>RBAC is used to control if an identity (in your example the service account) is allowed to access a resource via the K8s API. You control this by creating a RoleBinding (namespaced) or a ClusterRoleBinding (cluster-wide) that binds an identity to a Role (namespaced) or a ClusterRole (not-namespaced) to your identity (service account). Then, when you assign the service account to a pod by setting the <code>serviceAccountName</code> attribute, running kubectl get secret in that pod or the equivalent method from one of the client libraries would mean you have credentials available to make the API request.</p>
<h1>Consuming Secrets</h1>
<p>This however is independent of configuring the pod to consume the secret as an environment variable or a volume mount. If the container spec in a pod spec references the secret it is made available inside that container. Note, per container, not per pod. You can limit what secret a pod can mount by having the pods in different namespaces, because a pod can only refer to a secret in the same namespace. Additionally, you can use the service account's <code>secrets</code> attribute, to limit what secrets a pod with thet service account can refer to.</p>
<pre><code>$ kubectl explain sa.secrets
KIND:     ServiceAccount
VERSION:  v1

RESOURCE: secrets &lt;[]Object&gt;

DESCRIPTION:
     Secrets is the list of secrets allowed to be used by pods running using
     this ServiceAccount. More info:
     https://kubernetes.io/docs/concepts/configuration/secret

     ObjectReference contains enough information to let you inspect or modify
     the referred object.
</code></pre>
<p>You can learn more about the security implications of Kubernetes secrets in the <a href="https://kubernetes.io/docs/concepts/configuration/secret/#restrictions" rel="nofollow noreferrer">secret documentation</a>.</p>
