Hi All, We are using istio in EKS.
We have done POC on istio rbac, we were able to define the service role binding based on service account by mentioning the user and namespace level by mentioning that in properties. Is there any way we can allow only a particular service to access other service. Instead of mentioning the user or namespace level, we want to control based on the service.
Is there any way we can allow only a particular service to access other service. Instead of mentioning the user or namespace level, we want to control based on the service.
Are you trying to control the egress traffic for a service? Currently this is not supported by Istio RBAC. Let me know if you’re thinking something else.
Hi YangminZhu, Thanks for your reply.
Actually this is not egress, this is in between the services.
Lets say I have a namespace called apps, which has istio-injection label enabled by default.
I have 3 micro services A, B and C. I want to have a control that only A can talk to C.
Till now, we are achieving this using service account, we link a service account to micro service A and create a service role binding allowing the service account used for micro service A to access micro service C.
Is there a way we can directly mention the service name of micro service A in the service role binding so that only micro service A can talk to micro service C without using any service account.
In Kubernetes, service accounts are how you present identities. Istio then issue a certificate per service account, by default the identity of a service looks like this spiffe://cluster.local/ns/<some-ns>/sa/<some-service>. You then can use this identity in your RBAC rules. Is there a particular reason why you do not want to use service account?
The preferred way is to use the service account as the identity as Phillip mentioned.
There are some problems to use the service name in this case, not to mention it’s not supported in the RBAC. The first problem is it may be not secure to be used for access control, the second problem is it’s possible that a single pod is selected by many different services, in this case it’s unclear what service should be used in the server side.
Thanks Phillipe and YangminZhu for the reply.
The main reason being, we are creating service account separately and then while deploying the actual application we are mentioning that service account.
So any deployment can mention that service account in the deployment yaml file and then it will have access to the service.
Since we will not have ay fine grained control over only this server can use this service account, thought of giving the permission only to that service.