RequestAuthentication

8 minute read

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

apiVersion: security.istio.io/v1 kind: RequestAuthentication metadata: name: httpbin namespace: foo spec: selector: matchLabels: app: httpbin jwtRules: - issuer: "issuer-foo" jwksUri: https://example.com/.well-known/jwks.json --- apiVersion: security.istio.io/v1 kind: AuthorizationPolicy metadata: name: httpbin namespace: foo spec: selector: matchLabels: app: httpbin rules: - from: - source: 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.

apiVersion: security.istio.io/v1 kind: RequestAuthentication metadata: name: req-authn-for-all namespace: istio-system spec: jwtRules: - issuer: "issuer-foo" jwksUri: https://example.com/.well-known/jwks.json --- apiVersion: security.istio.io/v1 kind: AuthorizationPolicy metadata: name: require-jwt-for-all namespace: istio-system spec: rules: - from: - source: 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).

apiVersion: security.istio.io/v1 kind: RequestAuthentication metadata: name: httpbin namespace: foo spec: selector: matchLabels: app: httpbin jwtRules: - issuer: "issuer-foo" - issuer: "issuer-bar" --- apiVersion: security.istio.io/v1 kind: AuthorizationPolicy metadata: name: httpbin namespace: foo spec: selector: matchLabels: app: httpbin rules: - from: - source: requestPrincipals: ["issuer-foo/*"] to: - operation: hosts: ["example.com"] - from: - source: requestPrincipals: ["issuer-bar/*"] to: - operation: 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:

apiVersion: security.istio.io/v1 kind: AuthorizationPolicy metadata: name: httpbin namespace: foo spec: selector: matchLabels: app: httpbin rules: - from: - source: requestPrincipals: ["*"] - to: - operation: 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.

apiVersion: security.istio.io/v1 kind: RequestAuthentication metadata: name: jwt-on-ingress namespace: istio-system spec: selector: matchLabels: app: istio-ingressgateway jwtRules: - issuer: "example.com" jwksUri: https://example.com/.well-known/jwks.json --- apiVersion: security.istio.io/v1 kind: AuthorizationPolicy metadata: name: require-jwt namespace: istio-system spec: selector: matchLabels: app: istio-ingressgateway rules: - from: - source: requestPrincipals: ["*"] --- apiVersion: networking.istio.io/v1 kind: VirtualService metadata: name: route-jwt spec: hosts: - foo.prod.svc.cluster.local gateways: - istio-ingressgateway http: - name: "v2" match: - headers: "@request.auth.claims.sub": exact: "dev" route: - destination: host: foo.prod.svc.cluster.local subset: v2 - name: "default" route: - destination: host: foo.prod.svc.cluster.local subset: v1

Field Type Description Required

Field	Type	Description	Required
`selector`	`WorkloadSelector`	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 `selector` or `targetRefs` can be set for a given policy.	No
`targetRefs`	`PolicyTargetReference[]`	Optional. The targetRefs specifies a list of resources the policy should be applied to. The targeted resources specified will determine which workloads the policy applies to. Currently, the following resource attachment types are supported: `kind: Gateway` with `group: gateway.networking.k8s.io` in the same namespace. `kind: Service` with `""` in the same namespace. This type is only supported for waypoints. If not set, the policy is applied as defined by the selector. At most one of the selector and targetRefs can be set. NOTE: If you are using the `targetRefs` field in a multi-revision environment with Istio versions prior to 1.22, it is highly recommended that you pin the policy to a revision running 1.22+ via the `istio.io/rev` label. This is to prevent proxies connected to older control planes (that don’t know about the `targetRefs` field) from misinterpreting the policy as namespace-wide during the upgrade process. NOTE: Waypoint proxies are required to use this field for policies to apply; `selector` policies will be ignored.	No
`jwtRules`	`JWTRule[]`	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

selector

WorkloadSelector

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 selector or targetRefs can be set for a given policy.

targetRefs

PolicyTargetReference[]

Optional. The targetRefs specifies a list of resources the policy should be applied to. The targeted resources specified will determine which workloads the policy applies to.

Currently, the following resource attachment types are supported:

kind: Gateway with group: gateway.networking.k8s.io in the same namespace.
kind: Service with "" in the same namespace. This type is only supported for waypoints.

If not set, the policy is applied as defined by the selector. At most one of the selector and targetRefs can be set.

NOTE: If you are using the targetRefs field in a multi-revision environment with Istio versions prior to 1.22, it is highly recommended that you pin the policy to a revision running 1.22+ via the istio.io/rev label. This is to prevent proxies connected to older control planes (that don’t know about the targetRefs field) from misinterpreting the policy as namespace-wide during the upgrade process.

NOTE: Waypoint proxies are required to use this field for policies to apply; selector policies will be ignored.

jwtRules

JWTRule[]

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.

JWTRule

JSON Web Token (JWT) token format for authentication as defined by RFC 7519. See OAuth 2.0 and OIDC 1.0 for how this is used in the whole authentication flow.

Examples:

Spec for a JWT that is issued by https://example.com, with the audience claims must be either bookstore_android.apps.example.com or bookstore_web.apps.example.com. The token should be presented at the Authorization header (default). The JSON Web Key Set (JWKS) will be discovered following OpenID Connect protocol.

issuer: https://example.com audiences: - bookstore_android.apps.example.com bookstore_web.apps.example.com

This example specifies a token in a non-default location (x-goog-iap-jwt-assertion header). It also defines the URI to fetch JWKS explicitly.

issuer: https://example.com jwksUri: https://example.com/.secret/jwks.json fromHeaders: - "x-goog-iap-jwt-assertion"

Field	Type	Description	Required
`issuer`	`string`	Identifies the issuer that issued the JWT. See issuer A JWT with different `iss` claim will be rejected. Example: `https://foobar.auth0.com` Example: `1234567-compute@developer.gserviceaccount.com`	Yes
`audiences`	`string[]`	The list of JWT audiences that are allowed to access. A JWT containing any of these audiences will be accepted. The service name will be accepted if audiences is empty. Example: `audiences: - bookstore_android.apps.example.com bookstore_web.apps.example.com`	No
`jwksUri`	`string`	URL of the provider’s public key set to validate signature of the JWT. See OpenID Discovery. Optional if the key set document can either (a) be retrieved from OpenID Discovery of the issuer or (b) inferred from the email domain of the issuer (e.g. a Google service account). Example: `https://www.googleapis.com/oauth2/v1/certs` Note: Only one of `jwksUri` and `jwks` should be used.	No
`jwks`	`string`	JSON Web Key Set of public keys to validate signature of the JWT. See https://auth0.com/docs/jwks. Note: Only one of `jwksUri` and `jwks` should be used.	No
`fromHeaders`	`JWTHeader[]`	List of header locations from which JWT is expected. For example, below is the location spec if JWT is expected to be found in `x-jwt-assertion` header, and have `Bearer` prefix: `fromHeaders: - name: x-jwt-assertion prefix: "Bearer "` Note: Requests with multiple tokens (at different locations) are not supported, the output principal of such requests is undefined.	No
`fromParams`	`string[]`	List of query parameters from which JWT is expected. For example, if JWT is provided via query parameter `my_token` (e.g `/path?my_token=<JWT>`), the config is: `fromParams: - "my_token"` Note: Requests with multiple tokens (at different locations) are not supported, the output principal of such requests is undefined.	No
`outputPayloadToHeader`	`string`	This field specifies the header name to output a successfully verified JWT payload to the backend. The forwarded data is `base64_encoded(jwt_payload_in_JSON)`. If it is not specified, the payload will not be emitted.	No
`fromCookies`	`string[]`	List of cookie names from which JWT is expected. // For example, if config is: `from_cookies: - auth-token` Then JWT will be extracted from `auth-token` cookie in the request. Note: Requests with multiple tokens (at different locations) are not supported, the output principal of such requests is undefined.	No
`forwardOriginalToken`	`bool`	If set to true, the original token will be kept for the upstream request. Default is false.	No
`outputClaimToHeaders`	`ClaimToHeader[]`	This field specifies a list of operations to copy the claim to HTTP headers on a successfully verified token. This differs from the `output_payload_to_header` by allowing outputting individual claims instead of the whole payload. The header specified in each operation in the list must be unique. Nested claims of type string/int/bool is supported as well. `outputClaimToHeaders: - header: x-my-company-jwt-group claim: my-group - header: x-test-environment-flag claim: test-flag - header: x-jwt-claim-group claim: nested.key.group` [Experimental] This feature is a experimental feature.	No
`timeout`	`Duration`	The maximum amount of time that the resolver, determined by the PILOT_JWT_ENABLE_REMOTE_JWKS environment variable, will spend waiting for the JWKS to be fetched. Default is 5s.	No

JWTHeader

This message specifies a header location to extract JWT token.

Field	Type	Description	Required
`name`	`string`	The HTTP header name.	Yes
`prefix`	`string`	The prefix that should be stripped before decoding the token. For example, for `Authorization: Bearer <token>`, prefix=`Bearer` with a space at the end. If the header doesn’t have this exact prefix, it is considered invalid.	No

ClaimToHeader

This message specifies the detail for copying claim to header.

Field	Type	Description	Required
`header`	`string`	The name of the header to be created. The header will be overridden if it already exists in the request.	Yes
`claim`	`string`	The name of the claim to be copied from. Only claim of type string/int/bool is supported. The header will not be there if the claim does not exist or the type of the claim is not supported.	Yes