I have 4 services running as 4 different deployments/pods in my kubernetes cluster, name them, A, B, C and D. D is providing a common service which A and B are using via rest API calls, but it behaves differently between the requests come from A and those from B. And for requests from C, D should just deny the request (not authorized). Is there a k8s built-in way of supporting identifying/authorizing pods within the cluster?
My current approach is to use service account, where I created two service accounts, SA1 and SA2, which are used by A and B respectively, and my service D is registered as token reviewer. Both A and B need to read the service account token and submit it with the request to D. Through reviewing the token, D can tell if the requests are from A or B. This works, but I'm not sure if this is the best way of achieving this. Since each deployment can only use one service account, this may increase the complexity of service account management and token reviewing complexity if we get more services.
I went through kubernetes documents, e.g. RBAC, ABAC, node authorization and etc... but seems these are all designed for authorization of cluster API access, rather than the authorisation of services running in the cluster.
azure seems have a solution https://github.com/Azure/aad-pod-identity which fulfills my requirement, but it also has dependencies to other deployments (Active directory), which I don't think we will have in our cluster.
This seems to me to be more about service-to-service security for services running on the same cluster.
I understand there is already a solution in place that works fine at a smaller scale but the concern is that it won't scale for more services. Also, it appears that the services are aware they run on Kubernetes inside a pod container and do something special to make authentication with service account tokens work - "...Both A and B need to read the service account token and submit it with the request to D".
In their answer, @coderanger mentions service mesh. If you expect the number of the services that call each other and that have to be secured to grow, a service mesh like Istio will be a good fit here. (I am not affiliated with Istio)
In addition to security, Istio offers a lot of features that one can pick and choose to use or not to. At large scale, it helps that the management is from a central control plane and, for example, with automated key & certificate provisioning and rotation.
With Istio, the application code doesn't have to change as Istio uses sidecar container pattern to deploy a proxy in the same pod along side each of the application services containers; the lightweight proxy handles the security, traffic management, telemetry... A nice "side effect" is that developers can still develop and test these service integrations locally without worrying about security.
What you have is correct, Service account tokens are the way to do, other systems generally build on top of them. Most service mesh tools do offer simpler systems for identity, though for something this small it would likely be overkill.