I haven’t been able to figure out if the istio service authentication identity is passed to the receiving service, this could be useful for in application that needs to make authorization decisions about service peers.
For instance Service A is calling Service B they authenticate to each over mTLS that termites at the sidecar, is there some metadata being passed to Service B saying that its communicating to Service A and vice versa?
Thanks for any help
Yes, there is metadata being passed, e.g., source.principal attribute (a list of Istio attributes can be found on https://istio.io/docs/reference/config/policy-and-telemetry/attribute-vocabulary/).
@leitang Metadata is being passed to the service/application, as it seems the link is more a reference to logging? Is there any information on how to access it depending on the protocol, and furthermore in this case where it’s an identity is suggested to use and trust these attributes to make authorization decisions in application?
AFAIK, metadata is passed between the Envoy filters, e.g., an identity can be generated by the Istio authentication Envoy filter and used in the Istio authorization Envoy filter to make authorization decisions.
When service A wants to talk to service B, A will verify B’s cert and its secure naming to make sure the one who’s presenting B’s cert is actually B. Secure naming information is stored in the Envoy config. https://istio.io/docs/concepts/security/#istio-identity. I think B is also making sure if A’s cert is presented by A, since it’s mTLS, but the doc on Istio website did not mention this part, maybe I’m wrong. @Tao_Li to confirm.
The server will verify client’s cert against its own root cert, extract the spiffe identity out, and perform RBAC if configured.
cc @Oliver since we just talked about this.
So since B doesn’t care about who it is as long as it’s presenting a valid cert, isn’t a little insecure, since anyone can pretend to be A?
I have a use case where I want service to service authorization to partially live inside the application. For instance, if Service A is calling Service B, Service B needs to know that its talking to Service A so it can decide whether Service A is authorized to do what it is requesting.
Given the above scenario, would a service know what other service is talking to it so it can make authorization decisions?
P.S. Generally authentication can easily be delegated to service mesh, but authorization, especially end-user authorization but even service to service authorization is much harder to delegate to the service mesh if one doesn’t have an endpoint model and fine grained controls
B can have an authZ policy to allow services with service account foo with namespace bar access it. Service account and namespace information is part of the SAN field in a workload cert. When A presents its cert, B will be able to see if it should allow A with the given cert or not. However, as discussed above, it seems like anyone can just steal the cert and pretend to have the service account foo. Luckily with SDS, this will not happen, since the cert is not written to any file, but in memory instead.
@leitang @Tao_Li @philliple So its still unclear to me, can the istio identity be used in application (not just in the istio authorization layer)?
For mTLS, you can parse the validated identity from the X-Forwarded-Client-Cert header, see more in this github issue: https://github.com/istio/istio/issues/8263#issuecomment-427520118
For JWT, currently we don’t pass the validated token in the header, we could add this feature, please feel free to open an issue if you have any use cases for this.
Thank you!
@YangminZhu Thanks for the information. For JWT, the whole JWT gets passed to the service right. So that’s not an issue.