Skip to content

09 2 security

Peer Authentication📜

The PeerAuthentication resource controls the communication between workloads. With the use of PeerAuthentication, we can configure the mTLS mode that workloads utilize to communicate. The default mode is Permissive, so servers requesting mTLS can use mTLS, and if they only do plain text, everything will still work.

You can control the mTLS mode at the mesh level, in specific namespaces, for specific workloads or ports. For example, you can set up STRICT mTLS for some workloads but then disable mTLS for communication on specific ports.

This example sets the STRICT mTLS mode for all workloads in the foo namespace: 

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: foo
spec:
  mtls:
    mode: STRICT

Below is a similar one, but here we are setting STRICT mode only to workloads with the specified label set using the selector and matchLabels fields: 

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: foo
spec:
  selector:
    matchLabels:
      app: prod
  mtls:
    mode: STRICT

Finally, port level, where we set the STRICT mode for all workloads and disable mTLS for port 5000: 

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: foo
spec:
  mtls:
    mode: STRICT
  portLevelMtls:
    5000:
      mode: DISABLE

Request Authentication📜

We have discussed services and how they communicate. However, we have not mentioned anything about users. So how do we authenticate users in Istio? The answer relies on the RequestAuthentication resource.

The RequestAuthentication is used for end user authentication and it verifies the credentials attached to the request. The request-level authentication uses JSON Web Token (JWT) validation. JWT tokens authenticate users, while SPIFFE identity authenticates services.

This RequestAuthentication resource applies to all workloads in the default namespace that have the app: httpbin label set:

apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
  name: httpbin
  namespace: default
spec:
  selector:
    matchLabels:
      app: httpbin
  jwtRules:
  - issuer: "issuer-foo"
    jwksUri: "someuri"

Any requests made to these workloads will need a JWT token. The RequestAuthentication resource determines how the token and its signature are verified using the key set provided in the jwksUri field.

Suppose the request to the selected workload does not contain a valid JWT token or doesn’t conform to the RequestAuthentication rules. In that case, the workload will reject the request. Similarly, the workload will reject the request if we don’t provide a JWT token.

Let’s assume we have authenticated the request. After obtaining the necessary information, we can address the second aspect of the access control question, which involves “performing an action on an object.” This aspect is known as authorization.

Like PeerAuthentication, RequestAuthentication can also be scoped at the mesh, namespace, or workload level.

Additionally, you can set up request authentication at the Ingress level. You can accomplish this by specifying the istio: ingressgateway label. Suppose you have already authenticated at the Ingress but need to implement further JWT token logic, such as authorization policies within your mesh. In that case, you can enable the forwardOriginalToken field by setting it to true. That will pass the original token to upstream services.

Istio takes the RequestAuthorization configuration, translates it into the Envoy config, and verifies pieces of the JWT token.

Next📜

We turn our attention next to the AuthorizationPolicy resource.