09 2 security
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
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
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
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 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.
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
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.
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.
We turn our attention next to the