> ## Documentation Index
> Fetch the complete documentation index at: https://docs.streamnative.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Secure Kafka Schema Registry Access

> Authentication mechanisms, per-subject authorization, and network exposure for the Kafka Schema Registry on StreamNative Cloud.

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

| Mechanism  | Client support            | Notes                                                                                    |
| ---------- | ------------------------- | ---------------------------------------------------------------------------------------- |
| **Basic**  | All Kafka clients         | The API key is the password. The username is ignored—pass any non-empty placeholder.     |
| **OAuth2** | Kafka Java client         | Requires the `oauth-client` dependency and a custom bearer-token provider.               |
| **mTLS**   | Clients on a TLS listener | The client certificate identifies the caller, and the `Authorization` header is ignored. |

Configuration for each is in [Connect](/kafka/governance/sr/connect#authenticate).

<Note title="The Basic auth username carries no meaning">
  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.
</Note>

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.

| Role                                                                             | Read schemas | Write schemas | Manage compatibility | Delete subjects |
| -------------------------------------------------------------------------------- | ------------ | ------------- | -------------------- | --------------- |
| [`schema-reader`](/cloud/security/access/rbac/manage-rbac-roles#schema-reader)   | Yes          | N/A           | N/A                  | N/A             |
| [`schema-writer`](/cloud/security/access/rbac/manage-rbac-roles#schema-writer)   | Yes          | Yes           | N/A                  | N/A             |
| [`schema-manager`](/cloud/security/access/rbac/manage-rbac-roles#schema-manager) | Yes          | Yes           | Yes                  | N/A             |
| [`schema-owner`](/cloud/security/access/rbac/manage-rbac-roles#schema-owner)     | Yes          | Yes           | Yes                  | Yes             |

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](/cloud/security/access/rbac/manage-rbac-roles#schema-registry).

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`.

<Note title="Listing endpoints filter rather than fail">
  `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.
</Note>

### 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.

<Warning>
  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.
</Warning>

See [Kafka Schema Registry on Pulsar clusters](/cloud/governance/sr/kafka-schema-registry#grant-access).

### 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](/cloud/networking/networking) for the full endpoint and port list, and
[Test network connectivity](/cloud/networking/networking-testing) to verify reachability.

<Note title="Public endpoint IP addresses are not static">
  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](/cloud/networking/static-egress-ip) provides fixed addresses.
</Note>

## Next steps

<CardGroup cols={2}>
  <Card title="Connect" icon="plug" href="/kafka/governance/sr/connect">
    Configure each authentication mechanism.
  </Card>

  <Card title="Schema ID validation" icon="shield-check" href="/kafka/governance/sr/manage/schema-id-validation">
    Enforce schemas at the broker, not just in clients.
  </Card>
</CardGroup>