Skip to content

Commit 1b798b6

Browse files
Feediver1Feediver1
committed
DOC-1550
1 parent c546715 commit 1b798b6

File tree

1 file changed

+51
-26
lines changed

1 file changed

+51
-26
lines changed

‎modules/manage/pages/schema-reg/schema-reg-authorization.adoc

Lines changed: 51 additions & 26 deletions
Original file line numberDiff line numberDiff line change
@@ -197,11 +197,30 @@ For additional guidance on these operations, see the link:/api/doc/schema-regist
197197
Before you can enable Schema Registry Authorization, you must have:
198198

199199
ifndef::env-cloud[]
200-
* A valid Redpanda Enterprise license
200+
* A valid Redpanda Enterprise license.
201201
endif::[]
202202

203-
* `rpk` v25.2+
204-
* Cluster administrator permissions to modify cluster configuration
203+
ifdef::env-cloud[]
204+
* `rpk` v25.2+ installed. For installation instructions, see xref:manage:rpk/rpk-install.adoc[rpk installation].
205+
endif::[]
206+
207+
ifndef::env-cloud[]
208+
* `rpk` v25.2+ installed. For installation instructions, see xref:get-started/rpk-install.adoc[rpk installation].
209+
endif::[]
210+
211+
* Authentication enabled using `schema_registry_api.authn_method`, which specifies how clients must authenticate when accessing the Schema Registry API.
212+
213+
ifndef::env-cloud[]
214+
* If you have listeners configured for Schema Registry, be sure to xref:manage:security/authentication.adoc#basic-authentication[configure authentication] for them, and to identify them consistently (same host and port).
215+
endif::[]
216+
217+
* Cluster administrator permissions to modify cluster configurations.
218+
For example, to enable management of Schema Registry ACLs by the principal `schema_registry_admin`, run:
219+
220+
[,bash]
221+
----
222+
rpk security acl create --allow-principal schema_registry_admin --cluster --operation alter
223+
----
205224

206225
=== Enable authorization
207226

@@ -212,13 +231,6 @@ To enable Schema Registry Authorization for your cluster, run:
212231
rpk cluster config set schema_registry_enable_authorization true
213232
----
214233

215-
To enable management of Schema Registry ACLs by the principal `schema_registry_admin`, run:
216-
217-
[,bash]
218-
----
219-
rpk security acl create --allow-principal schema_registry_admin --cluster --operation alter
220-
----
221-
222234
For details, see xref:reference:properties/cluster-properties.adoc#schema_registry_enable_authorization[`schema_registry_enable_authorization`].
223235

224236
== Create and manage Schema Registry ACLs
@@ -306,7 +318,7 @@ jane User
306318

307319
When creating ACLs that include Schema Registry subjects, you might encounter errors if the subject doesn't exist or if there are configuration issues.
308320

309-
==== Common error: Subject not found
321+
==== Subject not found
310322

311323
Sometimes an ACL for a Kafka topic is created successfully, but the Schema Registry subject ACL fails:
312324

@@ -352,27 +364,40 @@ User:alice * TOPIC bar LITERAL READ
352364
The `Not found` error occurs in the request: `12:17:33.935 DEBUG sending request {"method": "POST", "URL: "http://127.0.0.1:8081/security/acls", "has_bearer": false,
353365
"has_basic_auth": false}`, meaning that the endpoint is not available (because you are using an older Redpanda version). You must upgrade to the current version of Redpanda.
354366

355-
ifndef::env-cloud[]
356-
This next error occurs when the user tries to create two ACLs, one for a topic and one for a registry-subject:
367+
==== Inconsistent listener configuration
368+
369+
This error occurs when the user tries to create an ACL for a principal:
370+
371+
[bash]
372+
----
373+
rpk security acl create --allow-principal "superuser" --operation "all" --registry-global -v
374+
13:07:02.810 DEBUG opening connection to broker {"addr": "seed-036d6a67.d2hiu9c8ljef72usuu20.fmc.prd.cloud.redpanda.com:9092", "broker": "seed_0"}
375+
...
376+
13:07:03.304 DEBUG sending request {"method": "POST", "URL": "https://127.0.0.1:8080/security/acls", "has_bearer": false, "has_basic_auth": true}
377+
PRINCIPAL HOST RESOURCE-TYPE RESOURCE-NAME RESOURCE-PATTERN-TYPE OPERATION PERMISSION ERROR
378+
User:superuser * REGISTRY LITERAL ALL ALLOW unable to POST "https://127.0.0.1:8080/security/acls": Post "https://127.0.0.1:8080/security/acls": http: server gave HTTP response to HTTPS client
379+
----
380+
381+
When using Schema Registry Authorization with multiple listeners, make sure that they are using the same address. There are two listeners for every Schema Registry ACL: a Kafka listener and a Schema Registry listener. If you have manually configured Kafka listeners, be sure to point them to the same cluster because rpk operates on the assumption that you are talking to a local host. For example, here `rpk` opened a connection with a Kafka broker (`seed-036d6a67.d2hiu9c8ljef72usuu20.fmc.prd.cloud.redpanda.com:9092`), which is using port `9092`. However, it is trying to request a POST to Schema Registry on a local host, `https://127.0.0.1:8080/security/acls`. So there is a mismatch of the host ports.
382+
383+
==== Resource names do not appear
384+
385+
The following output appears to suggest that there are missing resource names for the registry resource types:
357386

358387
[bash]
359388
----
360-
$ rpk security acl create --topic private --allow-principal mary --operation read --registry-subject private-key -v
361-
18:27:05.485 DEBUG opening connection to broker {"addr": "127.0.0.1:9092", "broker": "seed_0"}
362-
18:27:05.485 DEBUG connection opened to broker {"addr": "127.0.0.1:9092", "broker": "seed_0"}
363-
18:27:05.485 DEBUG issuing api versions request {"broker": "seed_0", "version": 4}
364-
18:27:05.485 DEBUG wrote ApiVersions v4 {"broker": "seed_0", "bytes_written": 31, "write_wait": "14.584µs", "time_to_write": "18.25µs", "err": null}
365-
18:27:05.487 DEBUG read ApiVersions v4 {"broker": "seed_0", "bytes_read": 331, "read_wait": "23.583µs", "time_to_read": "1.847542ms", "err": null}
366-
18:27:05.487 DEBUG connection initialized successfully {"addr": "127.0.0.1:9092", "broker": "seed_0"}
367-
18:27:05.487 DEBUG wrote CreateACLs v2 {"broker": "seed_0", "bytes_written": 45, "write_wait": "2.564792ms", "time_to_write": "8.75µs", "err": null}
368-
18:27:05.489 DEBUG read CreateACLs v2 {"broker": "seed_0", "bytes_read": 19, "read_wait": "20.042µs", "time_to_read": "1.465375ms", "err": null}
369-
18:27:05.489 DEBUG sending request {"method": "POST", "URL": "http://127.0.0.1:8081/security/acls", "has_bearer": false, "has_basic_auth": false}
389+
rpk security acl create --allow-principal jane --operation read,write --topic private --registry-global
370390
PRINCIPAL HOST RESOURCE-TYPE RESOURCE-NAME RESOURCE-PATTERN-TYPE OPERATION PERMISSION ERROR
371-
User:mary * SUBJECT private-key LITERAL READ ALLOW Invalid license: not present
372-
User:mary * TOPIC private LITERAL READ ALLOW
391+
User:jane * REGISTRY LITERAL READ ALLOW
392+
User:jane * REGISTRY LITERAL WRITE ALLOW
393+
User:jane * TOPIC private LITERAL READ ALLOW
394+
User:jane * TOPIC private LITERAL WRITE ALLOW
373395
----
374396

375-
The `Invalid license: not present` error indicates that the user is trying to create an ACL for a resource that requires a license, but no license is present. See xref:get-started:licensing/overview.adoc[Licensing overview] for details on how to obtain a license.
397+
When using the `--registry-global` option, be aware that `REGISTRY` resource types are global and apply to all of Schema Registry. They do not have a resource name because they are not tied to a specific resource. There are no resource names missing here.
398+
399+
ifndef::env-cloud[]
400+
376401
endif::[]
377402

378403
== Suggested reading

0 commit comments

Comments
 (0)