istio.io/content/en/docs/reference/config/security/request_authentication/index.html

160 lines
4.4 KiB
HTML

---
WARNING: THIS IS AN AUTO-GENERATED FILE, DO NOT EDIT. PLEASE MODIFY THE ORIGINAL SOURCE IN THE 'https://github.com/istio/api' REPO
source_repo: https://github.com/istio/api
title: RequestAuthentication
description: Request authentication configuration for workloads.
location: https://istio.io/docs/reference/config/security/request_authentication.html
layout: protoc-gen-docs
generator: protoc-gen-docs
schema: istio.security.v1beta1.RequestAuthentication
aliases: [/docs/reference/config/security/v1beta1/request_authentication]
number_of_entries: 1
---
<h2 id="RequestAuthentication">RequestAuthentication</h2>
<section>
<p>RequestAuthentication defines what request authentication methods are supported by a workload.
If 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:</p>
<ul>
<li>Require JWT for all request for workloads that have label <code>app:httpbin</code></li>
</ul>
<pre><code class="language-yaml">apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
name: httpbin
namespace: foo
spec:
selector:
matchLabels:
app: httpbin
jwtRules:
- issuer: &quot;issuer-foo&quot;
jwksUri: https://example.com/.well-known/jwks.json
---
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: httpbin
namespace: foo
spec:
selector:
matchLabels:
app: httpbin
rules:
- from:
- source:
requestPrincipals: [&quot;*&quot;]
</code></pre>
<ul>
<li>The next example shows how to set a different JWT requirement for a different <code>host</code>. The <code>RequestAuthentication</code>
declares it can accpet JWTs issuer by either <code>issuer-foo</code> or <code>issuer-bar</code> (the public key set is implicitly
set from the OpenID Connect spec).
&ldquo;`yaml
apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
name: httpbin
namespace: foo
spec:
selector:
matchLabels:
app: httpbin
jwtRules:
<ul>
<li>issuer: &ldquo;issuer-foo&rdquo;</li>
<li>issuer: &ldquo;issuer-bar&rdquo;
&mdash;
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: httpbin
namespace: foo
spec:
selector:
matchLabels:
app: httpbin
rules:</li>
<li>from:</li>
<li>source:
requestPrincipals: [&ldquo;issuer-foo/*&rdquo;]
to:
hosts: [&ldquo;example.com&rdquo;]</li>
<li>from:</li>
<li>source:
requestPrincipals: [&ldquo;issuer-bar/<em>&rdquo;]
to:
hosts: [&ldquo;another-host.com&rdquo;]
<code>
- 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:
</code>yaml
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: httpbin
namespace: foo
spec:
selector:
matchLabels:
app: httpbin
rules:
- from:
- source:
requestPrincipals: [&rdquo;</em>&rdquo;]
- to:
- operation:
paths: [&ldquo;/healthz]
&ldquo;`</li>
</ul></li>
</ul>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
<th>Required</th>
</tr>
</thead>
<tbody>
<tr id="RequestAuthentication-selector">
<td><code>selector</code></td>
<td><code><a href="/docs/reference/config/type/v1beta1/workload-selector.html#WorkloadSelector">WorkloadSelector</a></code></td>
<td>
<p>The selector determines the workloads to apply the RequestAuthentication on.
If not set, the policy will be applied to all workloads in the same namespace as the policy.</p>
</td>
<td>
No
</td>
</tr>
<tr id="RequestAuthentication-jwt_rules">
<td><code>jwtRules</code></td>
<td><code><a href="/docs/reference/config/security/jwt.html#JWTRule">JWTRule[]</a></code></td>
<td>
<p>Define the list of JWTs that can be validated at the selected workloads&rsquo; 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 recorgnized by the
rule. The token will be validated based on the JWT rule config. If validation fails, the request will
be rejected.
Note: if more than one token is presented (at different locations), the output principal is nondeterministic.</p>
</td>
<td>
No
</td>
</tr>
</tbody>
</table>
</section>