RequestAuthentication

RequestAuthentication

RequestAuthentication defines what request authentication methods are supported by a workload. It will reject a request if the request contains invalid authentication information, based on the configured authentication rules. A request that does not contain any authentication credentials will be accepted but will not have any authenticated identity. To restrict access to authenticated requests only, this should be accompanied by an authorization rule. Examples:

  • Require JWT for all request for workloads that have label app:httpbin
  1. apiVersion: security.istio.io/v1beta1
  2. kind: RequestAuthentication
  3. metadata:
  4.   name: httpbin
  5.   namespace: foo
  6. spec:
  7.   selector:
  8.     matchLabels:
  9.       app: httpbin
  10.   jwtRules:
  11.   - issuer: "issuer-foo"
  12.     jwksUri: https://example.com/.well-known/jwks.json
  13. ---
  14. apiVersion: security.istio.io/v1beta1
  15. kind: AuthorizationPolicy
  16. metadata:
  17.   name: httpbin
  18.   namespace: foo
  19. spec:
  20.   selector:
  21.     matchLabels:
  22.       app: httpbin
  23.   rules:
  24.   - from:
  25.     - source:
  26.         requestPrincipals: ["*"]
  1. apiVersion: security.istio.io/v1
  2. kind: RequestAuthentication
  3. metadata:
  4.   name: httpbin
  5.   namespace: foo
  6. spec:
  7.   selector:
  8.     matchLabels:
  9.       app: httpbin
  10.   jwtRules:
  11.   - issuer: "issuer-foo"
  12.     jwksUri: https://example.com/.well-known/jwks.json
  13. ---
  14. apiVersion: security.istio.io/v1
  15. kind: AuthorizationPolicy
  16. metadata:
  17.   name: httpbin
  18.   namespace: foo
  19. spec:
  20.   selector:
  21.     matchLabels:
  22.       app: httpbin
  23.   rules:
  24.   - from:
  25.     - source:
  26.         requestPrincipals: ["*"]
  • A policy in the root namespace (“istio-system” by default) applies to workloads in all namespaces in a mesh. The following policy makes all workloads only accept requests that contain a valid JWT token.
  1. apiVersion: security.istio.io/v1beta1
  2. kind: RequestAuthentication
  3. metadata:
  4.   name: req-authn-for-all
  5.   namespace: istio-system
  6. spec:
  7.   jwtRules:
  8.   - issuer: "issuer-foo"
  9.     jwksUri: https://example.com/.well-known/jwks.json
  10. ---
  11. apiVersion: security.istio.io/v1beta1
  12. kind: AuthorizationPolicy
  13. metadata:
  14.   name: require-jwt-for-all
  15.   namespace: istio-system
  16. spec:
  17.   rules:
  18.   - from:
  19.     - source:
  20.         requestPrincipals: ["*"]
  1. apiVersion: security.istio.io/v1
  2. kind: RequestAuthentication
  3. metadata:
  4.   name: req-authn-for-all
  5.   namespace: istio-system
  6. spec:
  7.   jwtRules:
  8.   - issuer: "issuer-foo"
  9.     jwksUri: https://example.com/.well-known/jwks.json
  10. ---
  11. apiVersion: security.istio.io/v1
  12. kind: AuthorizationPolicy
  13. metadata:
  14.   name: require-jwt-for-all
  15.   namespace: istio-system
  16. spec:
  17.   rules:
  18.   - from:
  19.     - source:
  20.         requestPrincipals: ["*"]
  • The next example shows how to set a different JWT requirement for a different host. The RequestAuthentication declares it can accept JWTs issued by either issuer-foo or issuer-bar (the public key set is implicitly set from the OpenID Connect spec).
  1. apiVersion: security.istio.io/v1beta1
  2. kind: RequestAuthentication
  3. metadata:
  4.   name: httpbin
  5.   namespace: foo
  6. spec:
  7.   selector:
  8.     matchLabels:
  9.       app: httpbin
  10.   jwtRules:
  11.   - issuer: "issuer-foo"
  12.   - issuer: "issuer-bar"
  13. ---
  14. apiVersion: security.istio.io/v1beta1
  15. kind: AuthorizationPolicy
  16. metadata:
  17.   name: httpbin
  18.   namespace: foo
  19. spec:
  20.   selector:
  21.     matchLabels:
  22.       app: httpbin
  23.   rules:
  24.   - from:
  25.     - source:
  26.         requestPrincipals: ["issuer-foo/*"]
  27.     to:
  28.     - operation:
  29.         hosts: ["example.com"]
  30.   - from:
  31.     - source:
  32.         requestPrincipals: ["issuer-bar/*"]
  33.     to:
  34.     - operation:
  35.         hosts: ["another-host.com"]
  1. apiVersion: security.istio.io/v1
  2. kind: RequestAuthentication
  3. metadata:
  4.   name: httpbin
  5.   namespace: foo
  6. spec:
  7.   selector:
  8.     matchLabels:
  9.       app: httpbin
  10.   jwtRules:
  11.   - issuer: "issuer-foo"
  12.   - issuer: "issuer-bar"
  13. ---
  14. apiVersion: security.istio.io/v1
  15. kind: AuthorizationPolicy
  16. metadata:
  17.   name: httpbin
  18.   namespace: foo
  19. spec:
  20.   selector:
  21.     matchLabels:
  22.       app: httpbin
  23.   rules:
  24.   - from:
  25.     - source:
  26.         requestPrincipals: ["issuer-foo/*"]
  27.     to:
  28.     - operation:
  29.         hosts: ["example.com"]
  30.   - from:
  31.     - source:
  32.         requestPrincipals: ["issuer-bar/*"]
  33.     to:
  34.     - operation:
  35.         hosts: ["another-host.com"]
  • You can fine tune the authorization policy to set different requirement per path. For example, to require JWT on all paths, except /healthz, the same RequestAuthentication can be used, but the authorization policy could be:
  1. apiVersion: security.istio.io/v1beta1
  2. kind: AuthorizationPolicy
  3. metadata:
  4.   name: httpbin
  5.   namespace: foo
  6. spec:
  7.   selector:
  8.     matchLabels:
  9.       app: httpbin
  10.   rules:
  11.   - from:
  12.     - source:
  13.         requestPrincipals: ["*"]
  14.   - to:
  15.     - operation:
  16.         paths: ["/healthz"]
  1. apiVersion: security.istio.io/v1
  2. kind: AuthorizationPolicy
  3. metadata:
  4.   name: httpbin
  5.   namespace: foo
  6. spec:
  7.   selector:
  8.     matchLabels:
  9.       app: httpbin
  10.   rules:
  11.   - from:
  12.     - source:
  13.         requestPrincipals: ["*"]
  14.   - to:
  15.     - operation:
  16.         paths: ["/healthz"]

[Experimental] Routing based on derived metadata is now supported. A prefix ‘@’ is used to denote a match against internal metadata instead of the headers in the request. Currently this feature is only supported for the following metadata:

  • request.auth.claims.{claim-name}[.{nested-claim}]* which are extracted from validated JWT tokens. Use the . or [] as a separator for nested claim names. Examples: request.auth.claims.sub, request.auth.claims.name.givenName and request.auth.claims[foo.com/name]. For more information, see JWT claim based routing.

The use of matches against JWT claim metadata is only supported in Gateways. The following example shows:

  • RequestAuthentication to decode and validate a JWT. This also makes the @request.auth.claims available for use in the VirtualService.
  • AuthorizationPolicy to check for valid principals in the request. This makes the JWT required for the request.
  • VirtualService to route the request based on the “sub” claim.
  1. apiVersion: security.istio.io/v1beta1
  2. kind: RequestAuthentication
  3. metadata:
  4.   name: jwt-on-ingress
  5.   namespace: istio-system
  6. spec:
  7.   selector:
  8.     matchLabels:
  9.       app: istio-ingressgateway
  10.   jwtRules:
  11.   - issuer: "example.com"
  12.     jwksUri: https://example.com/.well-known/jwks.json
  13. ---
  14. apiVersion: security.istio.io/v1beta1
  15. kind: AuthorizationPolicy
  16. metadata:
  17.   name: require-jwt
  18.   namespace: istio-system
  19. spec:
  20.   selector:
  21.     matchLabels:
  22.       app: istio-ingressgateway
  23.   rules:
  24.   - from:
  25.     - source:
  26.         requestPrincipals: ["*"]
  27. ---
  28. apiVersion: networking.istio.io/v1alpha3
  29. kind: VirtualService
  30. metadata:
  31.   name: route-jwt
  32. spec:
  33.   hosts:
  34.   - foo.prod.svc.cluster.local
  35.   gateways:
  36.   - istio-ingressgateway
  37.   http:
  38.   - name: "v2"
  39.     match:
  40.     - headers:
  41.         "@request.auth.claims.sub":
  42.           exact: "dev"
  43.     route:
  44.     - destination:
  45.         host: foo.prod.svc.cluster.local
  46.         subset: v2
  47.   - name: "default"
  48.     route:
  49.     - destination:
  50.         host: foo.prod.svc.cluster.local
  51.         subset: v1
  1. apiVersion: security.istio.io/v1
  2. kind: RequestAuthentication
  3. metadata:
  4.   name: jwt-on-ingress
  5.   namespace: istio-system
  6. spec:
  7.   selector:
  8.     matchLabels:
  9.       app: istio-ingressgateway
  10.   jwtRules:
  11.   - issuer: "example.com"
  12.     jwksUri: https://example.com/.well-known/jwks.json
  13. ---
  14. apiVersion: security.istio.io/v1
  15. kind: AuthorizationPolicy
  16. metadata:
  17.   name: require-jwt
  18.   namespace: istio-system
  19. spec:
  20.   selector:
  21.     matchLabels:
  22.       app: istio-ingressgateway
  23.   rules:
  24.   - from:
  25.     - source:
  26.         requestPrincipals: ["*"]
  27. ---
  28. apiVersion: networking.istio.io/v1alpha3
  29. kind: VirtualService
  30. metadata:
  31.   name: route-jwt
  32. spec:
  33.   hosts:
  34.   - foo.prod.svc.cluster.local
  35.   gateways:
  36.   - istio-ingressgateway
  37.   http:
  38.   - name: "v2"
  39.     match:
  40.     - headers:
  41.         "@request.auth.claims.sub":
  42.           exact: "dev"
  43.     route:
  44.     - destination:
  45.         host: foo.prod.svc.cluster.local
  46.         subset: v2
  47.   - name: "default"
  48.     route:
  49.     - destination:
  50.         host: foo.prod.svc.cluster.local
  51.         subset: v1
FieldTypeDescriptionRequired
selectorWorkloadSelector

Optional. The selector decides where to apply the request authentication policy. The selector will match with workloads in the same namespace as the request authentication policy. If the request authentication policy is in the root namespace, the selector will additionally match with workloads in all namespaces.

If not set, the selector will match all workloads. At most one of the selector and targetRef can be set.

No
jwtRulesJWTRule[]

Define the list of JWTs that can be validated at the selected workloads’ proxy. A valid token will be used to extract the authenticated identity. Each rule will be activated only when a token is presented at the location recognized by the rule. The token will be validated based on the JWT rule config. If validation fails, the request will be rejected. Note: Requests with multiple tokens (at different locations) are not supported, the output principal of such requests is undefined.

No