Skip to content


Authentication or authn is all about the principal. If we’re discussing service, it’s about service identity. When we refer to the entity authenticated by a computer system, network, or other appliances, we refer to it as a principal.

Individuals, computer systems, services, and abstract concepts, such as threads and processes, can function as principals. These principals must be authenticated, meaning they must be identified by an identity provider before they can be assigned rights or privileges over resources they can act upon.

When we say we are performing authentication, we are validating some credential and ensuring that the credential is valid and trusted.

Once the authentication succeeds, we can discuss an authenticated principal. Suppose the credential is not valid or can’t be trusted. In that case, we say that we have an unauthenticated principal or we didn’t have a principal to authenticate in the first place.

An example of authentication is when traveling, you must present your passport or an ID to the customs officer. They are the ones that authenticate your passport or ID and ensure that it’s valid and trusted.

SPIFFE Overview📜

Every workload in Istio is given a distinct identity as a Kubernetes ServiceAccount. The workload uses this identity to interact with other workloads. This service account is the identity that Pods use and present at runtime. Istio uses the X.509 certificate from the service account and it creates a new identity according to the spec called SPIFFE (secure production identity framework for everyone):

  • X.509 certificate (from SA) + SPIFFE spec = IDENTITY
  • SPIFFE is a spec that describes:
    • A naming scheme for workload identities.
    • spiffe://cluster.local/ns/default/sa/my-sa
    • How to encode those names into a X.509 certificate.
    • How a client Validates an X.509 certificate to authenticate the SPIFFE identity inside of it.

According to SPIFFE, a valid SPIFFE identity is established if you have X.509, handle it in a certain way, authenticate it using standard methods, and verify the subject’s alternate name. This results in an authenticated principal.

During runtime, we use these certificates to perform mutual TLS. The Envoy proxies are modified to include the SPIFFE validation process during the TLS handshake. This process authenticates source and destination principals. These authenticated principals are then accessible for policy purposes.

Mutual TLS (mTLS)📜

Typically, when we use TLS, it is a one-way process. For example, when you visit, you’ll see a lock icon indicating that the site is secure. However, you still need to give Google proof of your identity. Mutual TLS is a distinct approach that addresses this issue. When two services want to communicate using mTLS, they must provide certificates to verify each other’s identity. This way, both parties can trust each other.

Enabling mTLS for all your services is highly recommended and can provide significant benefits. However, there might be scenarios where legacy applications do not support mTLS yet. You will discover a timing challenge when enabling mTLS simultaneously on multiple services.

Suppose we aim to enable mTLS throughout our deployment. However, implementing mutual TLS creates a dilemma, as a connection can only be mutual TLS or not.

When a client tries to connect to a server using mTLS, but the server doesn’t support it, the connection will fail. Suppose a server tries to utilize mTLS, but the client only desires plain-text communication. In that case, the connection will not be established.

That means if I want to enable mTLS, I must simultaneously redeploy the client and server in a coordinated manner.

Fortunately, Istio has a graceful mode where we can opt into mutual TLS. It is called Permissive mode.

Permissive mode is enabled by default when you install Istio. When Permissive mode is on, clients can connect using mTLS, and you can then serve mTLS. Responding in plain text is an option if the client doesn’t use mTLS. I am allowing the client to choose whether to use mTLS or not. You can gradually roll out mTLS across your mesh using this mode.

You can turn on Permissive mode and provision server certificates. If a client requests to implement mTLS or simple TLS, accept their request and gradually roll out mutual TLS to your clients. There is always an option to opt into mTLS gradually.

Once you have moved all services over, you can remove Permissive mode and set it to STRICT.

Strict mode states you can only do mTLS. Clients must do mTLS and present their certificate if they try to connect.


Our attention will now turn to the resources of PeerAuthentication and RequestAuthentication.