Is there a way we can restrict a pod not to use a particular service account, we give all the access to a service account and any pods running in the namespace can simply pretend themselves as using that service account. so even if we give control w.r.t service account level, any deployment can use the service account in the same namespace and get all the access. How can we solve this.?
Well, if the user doing the deployment can also deploy to any namespace, even to one that has a more privileged service account, it will be able to deploy to it to any ns with any service account, right?
I think one thing is what the user doing the deployment can do, and another might be what a pod can do. The service account can’t be changed by the pod running, only the user who does the deployment. So, the pod, can only do what the service account attached to it is allowed. So, no running pod can pretend to have another one.
The user doing the deployment, however, might be restricted more carefully. I’m not sure if more granularity into a single ns can be achieved today to express what an user can do. Maybe is something to improve 
But I’d look into how to restrict the user doing the deployment, not the pod itself (if I understand correctly what you are saying). The pod can’t pretend to use another service account, but the user doing the deployment can attach another service account and therefore that user rights, IIUC, is what you want to restrict.
Does it make sense?
Hi Rata, My doubt is not exactly the below
Well, if the user doing the deployment can also deploy to any namespace, even to one that has a more privileged service account, it will be able to deploy to it to any ns with any service account, right?
My question here is, if we are giving a privilege to a service account in a particular namespace, all the pods getting deployed in the namespace can use the same serviceaccount right, if we mention the serviceaccount name in the pod.yaml file.
So even if we secure everything with the serviceaccount, all developers can simply mention this serviceaccount name in their pod and they get the access. Is there a way we can link the serviceaccount to a particular pod so that only that pod can use that serviceaccount. Now whats happening here is even if we restrict the access based on a serviceaccount, people can easily mention that service account name in the pod and getting the access.
Exactly. What I’m trying to say is that is what you should check about, not the pod pretends to be some other, as you said. Sorry if I got that part wrong in the first email.
The question, then, is what can be done to restrict an user. For sure it can be restricted to certain ns, but I’m honestly not sure about the granularity it has. Maybe it doesn’t have this kind of granularity and is something to improve? If there isn’t, maybe some workaround can be found? (Using different ns, there might be other’s?)
Sorry about the previous email if this was clear :-/
Hopefully others can contribute more to the answer
Thanks for the response Rata
Even I thought of doing the same but we have n number of microservices, we may endup in creating separate namespace for all of those.
It’s possible to run multiple micro-services or apps or macro-services in a single NS. It’s just not the most well-supported path. What I see most users do is one service accou8nt per NS and one NS per logical “actor”.