mumrah commented on code in PR #12673:
URL: https://github.com/apache/kafka/pull/12673#discussion_r976972071
##########
docs/security.html:
##########
@@ -1136,13 +1136,29 @@ <h3 class="anchor-heading"><a id="security_sasl"
class="anchor-link"></a><a href
</ol>
<h3 class="anchor-heading"><a id="security_authz"
class="anchor-link"></a><a href="#security_authz">7.4 Authorization and
ACLs</a></h3>
- Kafka ships with a pluggable Authorizer and an out-of-box authorizer
implementation that uses zookeeper to store all the acls. The Authorizer is
configured by setting <tt>authorizer.class.name</tt> in server.properties. To
enable the out of the box implementation use:
+ Kafka ships with a pluggable authorization framework, which is configured
by setting <tt>authorizer.class.name</tt> in server.properties. Configured
implementations must extend
<code>org.apache.kafka.server.authorizer.Authorizer</code>. Kafka provides
default implementations which store ACLs in the cluster metadata (either
Zookeeper or the KRaft metadata log).
+
+ For Zookeeper-based clusters, the provided implementation is configurd as
follows:
<pre class="line-numbers"><code
class="language-text">authorizer.class.name=kafka.security.authorizer.AclAuthorizer</code></pre>
- Kafka acls are defined in the general format of "Principal P is
[Allowed/Denied] Operation O From Host H on any Resource R matching
ResourcePattern RP". You can read more about the acl structure in <a
href="https://cwiki.apache.org/confluence/display/KAFKA/KIP-11+-+Authorization+Interface";>KIP-11</a>
and resource patterns in <a
href="https://cwiki.apache.org/confluence/display/KAFKA/KIP-290%3A+Support+for+Prefixed+ACLs";>KIP-290</a>.
In order to add, remove or list acls you can use the Kafka authorizer CLI. By
default, if no ResourcePatterns match a specific Resource R, then R has no
associated acls, and therefore no one other than super users is allowed to
access R. If you want to change that behavior, you can include the following in
server.properties.
+ For KRaft clusters, use the following configuration on all nodes (whether
controllers/brokers are combined or configured separately):
Review Comment:
```suggestion
For KRaft clusters, use the following configuration on all nodes
(brokers, controllers, or combined broker/controller nodes):
```
##########
docs/security.html:
##########
@@ -1136,13 +1136,29 @@ <h3 class="anchor-heading"><a id="security_sasl"
class="anchor-link"></a><a href
</ol>
<h3 class="anchor-heading"><a id="security_authz"
class="anchor-link"></a><a href="#security_authz">7.4 Authorization and
ACLs</a></h3>
- Kafka ships with a pluggable Authorizer and an out-of-box authorizer
implementation that uses zookeeper to store all the acls. The Authorizer is
configured by setting <tt>authorizer.class.name</tt> in server.properties. To
enable the out of the box implementation use:
+ Kafka ships with a pluggable authorization framework, which is configured
by setting <tt>authorizer.class.name</tt> in server.properties. Configured
implementations must extend
<code>org.apache.kafka.server.authorizer.Authorizer</code>. Kafka provides
default implementations which store ACLs in the cluster metadata (either
Zookeeper or the KRaft metadata log).
+
+ For Zookeeper-based clusters, the provided implementation is configurd as
follows:
Review Comment:
```suggestion
For Zookeeper-based clusters, the provided implementation is configured
as follows:
```
##########
docs/security.html:
##########
@@ -1136,13 +1136,29 @@ <h3 class="anchor-heading"><a id="security_sasl"
class="anchor-link"></a><a href
</ol>
<h3 class="anchor-heading"><a id="security_authz"
class="anchor-link"></a><a href="#security_authz">7.4 Authorization and
ACLs</a></h3>
- Kafka ships with a pluggable Authorizer and an out-of-box authorizer
implementation that uses zookeeper to store all the acls. The Authorizer is
configured by setting <tt>authorizer.class.name</tt> in server.properties. To
enable the out of the box implementation use:
+ Kafka ships with a pluggable authorization framework, which is configured
by setting <tt>authorizer.class.name</tt> in server.properties. Configured
implementations must extend
<code>org.apache.kafka.server.authorizer.Authorizer</code>. Kafka provides
default implementations which store ACLs in the cluster metadata (either
Zookeeper or the KRaft metadata log).
+
+ For Zookeeper-based clusters, the provided implementation is configurd as
follows:
<pre class="line-numbers"><code
class="language-text">authorizer.class.name=kafka.security.authorizer.AclAuthorizer</code></pre>
- Kafka acls are defined in the general format of "Principal P is
[Allowed/Denied] Operation O From Host H on any Resource R matching
ResourcePattern RP". You can read more about the acl structure in <a
href="https://cwiki.apache.org/confluence/display/KAFKA/KIP-11+-+Authorization+Interface";>KIP-11</a>
and resource patterns in <a
href="https://cwiki.apache.org/confluence/display/KAFKA/KIP-290%3A+Support+for+Prefixed+ACLs";>KIP-290</a>.
In order to add, remove or list acls you can use the Kafka authorizer CLI. By
default, if no ResourcePatterns match a specific Resource R, then R has no
associated acls, and therefore no one other than super users is allowed to
access R. If you want to change that behavior, you can include the following in
server.properties.
+ For KRaft clusters, use the following configuration on all nodes (whether
controllers/brokers are combined or configured separately):
+ <pre class="line-numbers"><code
class="language-text">authorizer.class.name=org.apache.kafka.metadata.authorizer.StandardAuthorizer</code></pre>
+
+ Kafka ACLs are defined in the general format of "Principal {P} is
[Allowed|Denied] Operation {O} From Host {H} on any Resource {R} matching
ResourcePattern {RP}". You can read more about the ACL structure in <a
href="https://cwiki.apache.org/confluence/display/KAFKA/KIP-11+-+Authorization+Interface";>KIP-11</a>
and resource patterns in <a
href="https://cwiki.apache.org/confluence/display/KAFKA/KIP-290%3A+Support+for+Prefixed+ACLs";>KIP-290</a>.
In order to add, remove or list ACLs, you can use the Kafka ACL CLI
<code>kafka-acls.sh</code>. By default, if no ResourcePatterns match a specific
Resource R, then R has no associated ACLs, and therefore no one other than
super users is allowed to access R. If you want to change that behavior, you
can include the following in server.properties.
<pre class="line-numbers"><code
class="language-text">allow.everyone.if.no.acl.found=true</code></pre>
One can also add super users in server.properties like the following (note
that the delimiter is semicolon since SSL user names may contain comma).
Default PrincipalType string "User" is case sensitive.
<pre class="line-numbers"><code
class="language-text">super.users=User:Bob;User:Alice</code></pre>
+ <h5 class="anchor-heading"><a id="kraft_principal_forwarding"
class="anchor-link"></a><a href="#kraft_principal_forwarding">KRaft Principal
Forwarding</a></h5>
+
+ In KRaft clusters, admin requests such as <code>CreateTopics</code> and
<code>DeleteTopics</code> are sent to the broker listeners and forwarded to the
current controller through the first listener configured in
<code>controller.listener.names</code>.
+ Authorization of these requests is done on the controller node. This is
achieved by way of an <code>Envelope</code> request which packages both the
underlying request from the client as well as the client principal.
Review Comment:
Is it worth linking to the KIP that adds Envelope requests?
##########
docs/security.html:
##########
@@ -1136,13 +1136,29 @@ <h3 class="anchor-heading"><a id="security_sasl"
class="anchor-link"></a><a href
</ol>
<h3 class="anchor-heading"><a id="security_authz"
class="anchor-link"></a><a href="#security_authz">7.4 Authorization and
ACLs</a></h3>
- Kafka ships with a pluggable Authorizer and an out-of-box authorizer
implementation that uses zookeeper to store all the acls. The Authorizer is
configured by setting <tt>authorizer.class.name</tt> in server.properties. To
enable the out of the box implementation use:
+ Kafka ships with a pluggable authorization framework, which is configured
by setting <tt>authorizer.class.name</tt> in server.properties. Configured
implementations must extend
<code>org.apache.kafka.server.authorizer.Authorizer</code>. Kafka provides
default implementations which store ACLs in the cluster metadata (either
Zookeeper or the KRaft metadata log).
+
+ For Zookeeper-based clusters, the provided implementation is configurd as
follows:
<pre class="line-numbers"><code
class="language-text">authorizer.class.name=kafka.security.authorizer.AclAuthorizer</code></pre>
- Kafka acls are defined in the general format of "Principal P is
[Allowed/Denied] Operation O From Host H on any Resource R matching
ResourcePattern RP". You can read more about the acl structure in <a
href="https://cwiki.apache.org/confluence/display/KAFKA/KIP-11+-+Authorization+Interface";>KIP-11</a>
and resource patterns in <a
href="https://cwiki.apache.org/confluence/display/KAFKA/KIP-290%3A+Support+for+Prefixed+ACLs";>KIP-290</a>.
In order to add, remove or list acls you can use the Kafka authorizer CLI. By
default, if no ResourcePatterns match a specific Resource R, then R has no
associated acls, and therefore no one other than super users is allowed to
access R. If you want to change that behavior, you can include the following in
server.properties.
+ For KRaft clusters, use the following configuration on all nodes (whether
controllers/brokers are combined or configured separately):
+ <pre class="line-numbers"><code
class="language-text">authorizer.class.name=org.apache.kafka.metadata.authorizer.StandardAuthorizer</code></pre>
+
+ Kafka ACLs are defined in the general format of "Principal {P} is
[Allowed|Denied] Operation {O} From Host {H} on any Resource {R} matching
ResourcePattern {RP}". You can read more about the ACL structure in <a
href="https://cwiki.apache.org/confluence/display/KAFKA/KIP-11+-+Authorization+Interface";>KIP-11</a>
and resource patterns in <a
href="https://cwiki.apache.org/confluence/display/KAFKA/KIP-290%3A+Support+for+Prefixed+ACLs";>KIP-290</a>.
In order to add, remove or list ACLs, you can use the Kafka ACL CLI
<code>kafka-acls.sh</code>. By default, if no ResourcePatterns match a specific
Resource R, then R has no associated ACLs, and therefore no one other than
super users is allowed to access R. If you want to change that behavior, you
can include the following in server.properties.
<pre class="line-numbers"><code
class="language-text">allow.everyone.if.no.acl.found=true</code></pre>
One can also add super users in server.properties like the following (note
that the delimiter is semicolon since SSL user names may contain comma).
Default PrincipalType string "User" is case sensitive.
<pre class="line-numbers"><code
class="language-text">super.users=User:Bob;User:Alice</code></pre>
+ <h5 class="anchor-heading"><a id="kraft_principal_forwarding"
class="anchor-link"></a><a href="#kraft_principal_forwarding">KRaft Principal
Forwarding</a></h5>
+
+ In KRaft clusters, admin requests such as <code>CreateTopics</code> and
<code>DeleteTopics</code> are sent to the broker listeners and forwarded to the
current controller through the first listener configured in
<code>controller.listener.names</code>.
Review Comment:
```suggestion
In KRaft clusters, admin requests such as <code>CreateTopics</code> and
<code>DeleteTopics</code> are sent to the broker listeners by the client. The
broker then forwards the request to the active controller through the first
listener configured in <code>controller.listener.names</code>.
```
##########
docs/security.html:
##########
@@ -1136,13 +1136,29 @@ <h3 class="anchor-heading"><a id="security_sasl"
class="anchor-link"></a><a href
</ol>
<h3 class="anchor-heading"><a id="security_authz"
class="anchor-link"></a><a href="#security_authz">7.4 Authorization and
ACLs</a></h3>
- Kafka ships with a pluggable Authorizer and an out-of-box authorizer
implementation that uses zookeeper to store all the acls. The Authorizer is
configured by setting <tt>authorizer.class.name</tt> in server.properties. To
enable the out of the box implementation use:
+ Kafka ships with a pluggable authorization framework, which is configured
by setting <tt>authorizer.class.name</tt> in server.properties. Configured
implementations must extend
<code>org.apache.kafka.server.authorizer.Authorizer</code>. Kafka provides
default implementations which store ACLs in the cluster metadata (either
Zookeeper or the KRaft metadata log).
Review Comment:
Should we mention "server.properties" explicitly? Do we do that elsewhere in
the docs?
##########
docs/security.html:
##########
@@ -1136,13 +1136,29 @@ <h3 class="anchor-heading"><a id="security_sasl"
class="anchor-link"></a><a href
</ol>
<h3 class="anchor-heading"><a id="security_authz"
class="anchor-link"></a><a href="#security_authz">7.4 Authorization and
ACLs</a></h3>
- Kafka ships with a pluggable Authorizer and an out-of-box authorizer
implementation that uses zookeeper to store all the acls. The Authorizer is
configured by setting <tt>authorizer.class.name</tt> in server.properties. To
enable the out of the box implementation use:
+ Kafka ships with a pluggable authorization framework, which is configured
by setting <tt>authorizer.class.name</tt> in server.properties. Configured
implementations must extend
<code>org.apache.kafka.server.authorizer.Authorizer</code>. Kafka provides
default implementations which store ACLs in the cluster metadata (either
Zookeeper or the KRaft metadata log).
+
+ For Zookeeper-based clusters, the provided implementation is configurd as
follows:
<pre class="line-numbers"><code
class="language-text">authorizer.class.name=kafka.security.authorizer.AclAuthorizer</code></pre>
- Kafka acls are defined in the general format of "Principal P is
[Allowed/Denied] Operation O From Host H on any Resource R matching
ResourcePattern RP". You can read more about the acl structure in <a
href="https://cwiki.apache.org/confluence/display/KAFKA/KIP-11+-+Authorization+Interface";>KIP-11</a>
and resource patterns in <a
href="https://cwiki.apache.org/confluence/display/KAFKA/KIP-290%3A+Support+for+Prefixed+ACLs";>KIP-290</a>.
In order to add, remove or list acls you can use the Kafka authorizer CLI. By
default, if no ResourcePatterns match a specific Resource R, then R has no
associated acls, and therefore no one other than super users is allowed to
access R. If you want to change that behavior, you can include the following in
server.properties.
+ For KRaft clusters, use the following configuration on all nodes (whether
controllers/brokers are combined or configured separately):
+ <pre class="line-numbers"><code
class="language-text">authorizer.class.name=org.apache.kafka.metadata.authorizer.StandardAuthorizer</code></pre>
+
+ Kafka ACLs are defined in the general format of "Principal {P} is
[Allowed|Denied] Operation {O} From Host {H} on any Resource {R} matching
ResourcePattern {RP}". You can read more about the ACL structure in <a
href="https://cwiki.apache.org/confluence/display/KAFKA/KIP-11+-+Authorization+Interface";>KIP-11</a>
and resource patterns in <a
href="https://cwiki.apache.org/confluence/display/KAFKA/KIP-290%3A+Support+for+Prefixed+ACLs";>KIP-290</a>.
In order to add, remove or list ACLs, you can use the Kafka ACL CLI
<code>kafka-acls.sh</code>. By default, if no ResourcePatterns match a specific
Resource R, then R has no associated ACLs, and therefore no one other than
super users is allowed to access R. If you want to change that behavior, you
can include the following in server.properties.
Review Comment:
Can we break this long line?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
