You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
<p><code>oauth.jwks.endpoint.uri</code> points to the JWKS endpoint of the Kubernetes API server, which publishes the keys used to sign the Service Account tokens.
3468
-
Tokens are validated locally by the Kafka nodes using these keys.</p>
3467
+
<p><code>principal.builder.class</code> maps the validated tokens to Kafka principals.
3468
+
For more information on the requirements that apply to principal builders, see the description of setting a custom principal builder that follows.</p>
3469
3469
</li>
3470
3470
<li>
3471
-
<p><code>oauth.valid.issuer.uri</code> is the token issuer of your Kubernetes cluster and is checked against the <code>iss</code> claim of the token.</p>
3471
+
<p><code>unsecuredLoginStringClaim_sub</code> satisfies the parameter validation of the <code>OAuthBearerLoginModule</code> and isn’t used for authentication.</p>
3472
3472
</li>
3473
3473
<li>
3474
-
<p><code>oauth.server.bearer.token.location</code> and <code>oauth.ssl.truststore.location</code> point to the Service Account token and the Kubernetes CA certificate mounted by Strimzi into the Kafka containers.
3475
-
The token is used to authenticate against the JWKS endpoint, which is not available to unauthenticated users by default.</p>
3474
+
<p><code>oauth.check.access.token.type</code> is disabled because Service Account tokens don’t contain the <code>typ</code> claim expected by the OAuth standard.</p>
3476
3475
</li>
3477
3476
<li>
3478
-
<p><code>oauth.username.claim</code> uses the <code>sub</code> claim of the token as the name of the Kafka principal.</p>
3477
+
<p><code>oauth.custom.claim.check</code> restricts the listener to tokens issued for a specific audience.</p>
3479
3478
</li>
3480
3479
<li>
3481
-
<p><code>oauth.check.access.token.type</code> is disabled because Service Account tokens don’t contain the <code>typ</code> claim expected by the OAuth standard.</p>
3480
+
<p><code>oauth.valid.issuer.uri</code> is the token issuer of your Kubernetes cluster and is checked against the <code>iss</code> claim of the token.</p>
3482
3481
</li>
3483
3482
<li>
3484
-
<p><code>oauth.include.accept.header</code> is disabled because the Kubernetes API server rejects requests that set the <code>Accept</code> header.</p>
3483
+
<p><code>oauth.jwks.endpoint.uri</code> points to the JWKS endpoint of the Kubernetes API server, which publishes the keys used to sign the Service Account tokens.
3484
+
Tokens are validated locally by the Kafka nodes using these keys.</p>
3485
3485
</li>
3486
3486
<li>
3487
-
<p><code>unsecuredLoginStringClaim_sub</code> satisfies the parameter validation of the <code>OAuthBearerLoginModule</code> and isn’t used for authentication.</p>
3487
+
<p><code>oauth.username.claim</code> uses the <code>sub</code> claim of the token as the name of the Kafka principal.</p>
3488
3488
</li>
3489
3489
<li>
3490
-
<p><code>oauth.custom.claim.check</code> restricts the listener to tokens issued for a specific audience.</p>
3490
+
<p><code>oauth.server.bearer.token.location</code> and <code>oauth.ssl.truststore.location</code> point to the Service Account token and the Kubernetes CA certificate mounted by Strimzi into the Kafka containers.
3491
+
The token is used to authenticate against the JWKS endpoint, which is not available to unauthenticated users by default.</p>
3491
3492
</li>
3492
3493
<li>
3493
-
<p><code>principal.builder.class</code> maps the validated tokens to Kafka principals.
3494
-
For more information on the requirements that apply to principal builders, see the description of setting a custom principal builder that follows.</p>
3494
+
<p><code>oauth.include.accept.header</code> is disabled because the Kubernetes API server rejects requests that set the <code>Accept</code> header.</p>
<p>The <code>projected</code> volume asks Kubernetes to issue a token for the Service Account of the operand pod with the <code>my-internal-listener</code> audience and to store it in a file named <code>token</code>.</p>
10610
+
<p><code>sasl.login.callback.handler.class</code> sets the Strimzi callback handler that passes the token to the Kafka cluster.</p>
10611
10611
</li>
10612
10612
<li>
10613
-
<p>The volume is mounted at <code>/mnt/auth-token</code>, so the token is available in the <code>/mnt/auth-token/token</code> file.
10614
-
Additional volumes can be mounted only into paths that start with <code>/mnt</code>.
10615
-
For more information about additional volumes, see <a href="./configuring.html#con-common-configuration-volumes-reference" target="_blank" rel="noopener">Additional Volumes</a>.</p>
10613
+
<p><code>oauth.access.token.location</code> tells the Kafka client where to find the token file.</p>
10616
10614
</li>
10617
10615
<li>
10618
-
<p><code>oauth.access.token.location</code> tells the Kafka client where to find the token file.</p>
10616
+
<p>The <code>projected</code> volume asks Kubernetes to issue a token for the Service Account of the operand pod with the <code>my-internal-listener</code> audience and to store it in a file named <code>token</code>.</p>
10619
10617
</li>
10620
10618
<li>
10621
-
<p><code>sasl.login.callback.handler.class</code> sets the Strimzi callback handler that passes the token to the Kafka cluster.</p>
10619
+
<p>The volume is mounted at <code>/mnt/auth-token</code>, so the token is available in the <code>/mnt/auth-token/token</code> file.
10620
+
Additional volumes can be mounted only into paths that start with <code>/mnt</code>.
10621
+
For more information about additional volumes, see <a href="./configuring.html#con-common-configuration-volumes-reference" target="_blank" rel="noopener">Additional Volumes</a>.</p>
<p><code>oauth.jwks.endpoint.uri</code> points to the JWKS endpoint of the Kubernetes API server, which publishes the keys used to sign the Service Account tokens.
3910
-
Tokens are validated locally by the Kafka nodes using these keys.</p>
3909
+
<p><code>principal.builder.class</code> maps the validated tokens to Kafka principals.
3910
+
For more information on the requirements that apply to principal builders, see the description of setting a custom principal builder that follows.</p>
3911
3911
</li>
3912
3912
<li>
3913
-
<p><code>oauth.valid.issuer.uri</code> is the token issuer of your Kubernetes cluster and is checked against the <code>iss</code> claim of the token.</p>
3913
+
<p><code>unsecuredLoginStringClaim_sub</code> satisfies the parameter validation of the <code>OAuthBearerLoginModule</code> and isn’t used for authentication.</p>
3914
3914
</li>
3915
3915
<li>
3916
-
<p><code>oauth.server.bearer.token.location</code> and <code>oauth.ssl.truststore.location</code> point to the Service Account token and the Kubernetes CA certificate mounted by Strimzi into the Kafka containers.
3917
-
The token is used to authenticate against the JWKS endpoint, which is not available to unauthenticated users by default.</p>
3916
+
<p><code>oauth.check.access.token.type</code> is disabled because Service Account tokens don’t contain the <code>typ</code> claim expected by the OAuth standard.</p>
3918
3917
</li>
3919
3918
<li>
3920
-
<p><code>oauth.username.claim</code> uses the <code>sub</code> claim of the token as the name of the Kafka principal.</p>
3919
+
<p><code>oauth.custom.claim.check</code> restricts the listener to tokens issued for a specific audience.</p>
3921
3920
</li>
3922
3921
<li>
3923
-
<p><code>oauth.check.access.token.type</code> is disabled because Service Account tokens don’t contain the <code>typ</code> claim expected by the OAuth standard.</p>
3922
+
<p><code>oauth.valid.issuer.uri</code> is the token issuer of your Kubernetes cluster and is checked against the <code>iss</code> claim of the token.</p>
3924
3923
</li>
3925
3924
<li>
3926
-
<p><code>oauth.include.accept.header</code> is disabled because the Kubernetes API server rejects requests that set the <code>Accept</code> header.</p>
3925
+
<p><code>oauth.jwks.endpoint.uri</code> points to the JWKS endpoint of the Kubernetes API server, which publishes the keys used to sign the Service Account tokens.
3926
+
Tokens are validated locally by the Kafka nodes using these keys.</p>
3927
3927
</li>
3928
3928
<li>
3929
-
<p><code>unsecuredLoginStringClaim_sub</code> satisfies the parameter validation of the <code>OAuthBearerLoginModule</code> and isn’t used for authentication.</p>
3929
+
<p><code>oauth.username.claim</code> uses the <code>sub</code> claim of the token as the name of the Kafka principal.</p>
3930
3930
</li>
3931
3931
<li>
3932
-
<p><code>oauth.custom.claim.check</code> restricts the listener to tokens issued for a specific audience.</p>
3932
+
<p><code>oauth.server.bearer.token.location</code> and <code>oauth.ssl.truststore.location</code> point to the Service Account token and the Kubernetes CA certificate mounted by Strimzi into the Kafka containers.
3933
+
The token is used to authenticate against the JWKS endpoint, which is not available to unauthenticated users by default.</p>
3933
3934
</li>
3934
3935
<li>
3935
-
<p><code>principal.builder.class</code> maps the validated tokens to Kafka principals.
3936
-
For more information on the requirements that apply to principal builders, see the description of setting a custom principal builder that follows.</p>
3936
+
<p><code>oauth.include.accept.header</code> is disabled because the Kubernetes API server rejects requests that set the <code>Accept</code> header.</p>
<p>The <code>projected</code> volume asks Kubernetes to issue a token for the Service Account of the operand pod with the <code>my-internal-listener</code> audience and to store it in a file named <code>token</code>.</p>
11052
+
<p><code>sasl.login.callback.handler.class</code> sets the Strimzi callback handler that passes the token to the Kafka cluster.</p>
11053
11053
</li>
11054
11054
<li>
11055
-
<p>The volume is mounted at <code>/mnt/auth-token</code>, so the token is available in the <code>/mnt/auth-token/token</code> file.
11056
-
Additional volumes can be mounted only into paths that start with <code>/mnt</code>.
11057
-
For more information about additional volumes, see <a href="./configuring.html#con-common-configuration-volumes-reference" target="_blank" rel="noopener">Additional Volumes</a>.</p>
11055
+
<p><code>oauth.access.token.location</code> tells the Kafka client where to find the token file.</p>
11058
11056
</li>
11059
11057
<li>
11060
-
<p><code>oauth.access.token.location</code> tells the Kafka client where to find the token file.</p>
11058
+
<p>The <code>projected</code> volume asks Kubernetes to issue a token for the Service Account of the operand pod with the <code>my-internal-listener</code> audience and to store it in a file named <code>token</code>.</p>
11061
11059
</li>
11062
11060
<li>
11063
-
<p><code>sasl.login.callback.handler.class</code> sets the Strimzi callback handler that passes the token to the Kafka cluster.</p>
11061
+
<p>The volume is mounted at <code>/mnt/auth-token</code>, so the token is available in the <code>/mnt/auth-token/token</code> file.
11062
+
Additional volumes can be mounted only into paths that start with <code>/mnt</code>.
11063
+
For more information about additional volumes, see <a href="./configuring.html#con-common-configuration-volumes-reference" target="_blank" rel="noopener">Additional Volumes</a>.</p>
0 commit comments