Category: Data, Kubernetes, yaml

This article takes a stab at explaining access control in Istio, what authentication and authorization means and how the different Istio resources work together to answer the access control question: Can a subject perform an action on an object? If we translate the above question to the Istio and Kubernetes world, it would be “Can service X perform an action on service Y?”

The identity in the certificate is encoded in the Subject alternate name field of the certificate, and it looks like this: spiffe://cluster.local/ns//sa/

If we want to enable strict mutual TLS between services, we can use the PeerAuthentication resource to set the mTLS mode to STRICT.

This is because now we are authenticated and because we have an access token, we are authorized to call the customers workload.

Related Articles