Skip to main content
Schema Registry access rests on three things: how a client proves who it is, what that identity is allowed to do, and how the endpoint is reachable on the network.

​
Authentication

Configuration for each is in Connect.
Only the password is evaluated. Don’t rely on the username to identify a caller in audit trails or access rules—the identity comes entirely from the API key.
A request with no Authorization header, or one whose scheme is neither Basic nor Bearer, returns 401.

​
Authorization

StreamNative Cloud has two authorization models for the Schema Registry. Which applies depends on your cluster.

​
Role-based access control

Role-based access control (RBAC) is the current model. Permissions are scoped per subject, so a team can be granted access to its own schemas without seeing the schemas that belong to other teams. Bind a role to a service account and scope it to the subjects that account needs. A subject-prefix match lets one binding cover a whole team’s namespace. See Manage RBAC roles. Typical assignment:
  • Producers that register schemas: schema-writer.
  • Consumers that only resolve them: schema-reader.
  • CI pipelines that run compatibility checks and set modes: schema-manager.
  • Platform owners: schema-owner.
GET /subjects and the GET /schemas/ids/{id}/subjects endpoints return only the subjects your credentials can read, instead of returning a permission error. An empty array can mean the registry is empty or that your role covers none of the existing subjects.

​
Topic-level permission

Some Pulsar clusters authorize the registry through a single access control list (ACL) on its backing topic, public/__kafka_schemaregistry/__schema-registry, rather than per subject.
Under this model the permission is coarse: the same produce grant covers reads and writes, so a client that only needs to resolve schemas still gets the ability to register them. There’s no per-subject scoping. Prefer role-based access control where it’s available.
See Kafka Schema Registry on Pulsar clusters.

​
Operations that require no permission

A few endpoints are open to any authenticated caller: GET /schemas/types, the global GET /config, and GET /mode. They expose no schema content.

​
Network exposure

The Schema Registry is served on port 443 over HTTPS, at the cluster’s own endpoint—it isn’t a separately addressed service. It therefore inherits the cluster’s network configuration: a cluster reachable only over private networking has a Schema Registry reachable only over private networking. See Networking for the full endpoint and port list, and Test network connectivity to verify reachability.
Public cluster endpoints, including the Schema Registry, can use any public IP. Don’t build firewall rules around a resolved address. For outbound traffic from StreamNative Cloud, Static Egress IP provides fixed addresses.

​
Next steps

Connect

Configure each authentication mechanism.

Schema ID validation

Enforce schemas at the broker, not just in clients.