How do you govern access to Schema Registry — what controls exist for subjects, contexts, and import/export operations?
answer
- ACLs on Subject resource (self-managed) / RBAC role bindings (Cloud)
- ops: READ / WRITE / DELETE / COMPATIBILITY / MODE
- MODE op gates IMPORT mode → guard it
- scope by subject pattern AND context
- exporters + import/export are privileged/audited
basics
~20 sSchema Registry access is governed by ACLs/RBAC scoped to subjects (and contexts). You grant operations like READ, WRITE, and global SUBJECT_COMPATIBILITY/MODE on specific subject (or context) resource patterns, so producers can register schemas, consumers can only read, and only privileged roles can change compatibility, mode, or run import/export.
solid answer
~40 sSelf-managed Schema Registry supports a security plugin with **ACLs** on **Subject** resources (and the global config), granting operations such as READ, WRITE, DELETE, plus global ones like SUBJECT_COMPATIBILITY and MODE. You scope rules to subject name patterns or **contexts**, so a producer role gets WRITE on its subjects, consumers get READ, and only operators can alter compatibility level or put a subject/context into IMPORT mode for schema linking. In **Confluent Cloud**, governance is **RBAC**: role bindings (e.g. ResourceOwner, DeveloperRead/Write, DataDiscovery, DataSteward) granted on Schema Registry, specific subjects, or contexts. The key governance principle: registering/evolving schemas, changing compatibility, changing **mode** (READWRITE/READONLY/IMPORT), and managing **exporters** are privileged operations that should be locked down — accidental WRITE or MODE access can corrupt the contract for every consumer.
go deeper
Know access is controlled by ACLs/RBAC with READ for consumers and WRITE for producers.
Know the operation set and that compatibility/mode are privileged and scopable by subject.
Explain context-scoped grants, MODE gating IMPORT mode, and exporter/import as privileged operations.
Design least-privilege governance across teams: per-context/subject role bindings, audited mode/exporter ops, locked global compatibility.
## Why governance matters here Schema Registry is a **shared contract store**. A bad registration, a loosened compatibility level, or a mode change ripples to every producer and consumer of that subject. So access control is about protecting the contract, not just the data. ## Self-managed: ACLs Open-source/self-managed Schema Registry ships a **security plugin** that enforces **ACLs**. The primary resource is the **Subject** (and a global/config resource). You grant **operations** on resource patterns: - **READ** — look up schemas/versions for a subject (consumers). - **WRITE** — register new schema versions (producers). - **DELETE** — soft/hard delete subjects or versions. - **SUBJECT_COMPATIBILITY** / global **COMPATIBILITY** — read/alter the compatibility level. - **MODE** — read/alter the registry/subject **mode** (READWRITE / READONLY / IMPORT). Critically, granting MODE lets a principal enable **IMPORT mode**, which is needed for schema linking but dangerous if misused. - Global config operations for the registry as a whole. Rules can be scoped by **subject name pattern** and by **context**, so you isolate teams/environments. ## Confluent Cloud / Confluent Platform: RBAC In managed/enterprise deployments governance is **Role-Based Access Control (RBAC)** with **role bindings**: - Roles like **ResourceOwner**, **DeveloperRead**, **DeveloperWrite**, **DataSteward**, **DataDiscovery** are bound to a principal on a **scope** — the Schema Registry cluster, a specific **subject**, or a **context**. - A DataSteward/ResourceOwner can manage tags, contracts, and compatibility; DeveloperWrite can register; DeveloperRead can only read. - Subject- and context-scoped bindings let you delegate ownership per team while keeping mode/exporter management central. ## Import/export and exporters Managing **exporters** (schema links) and performing **import/export** are administrative operations. They require the elevated privileges (MODE for IMPORT, plus exporter management permissions/roles). You don't want application service accounts able to flip a context into IMPORT mode or create exporters. ## Authentication context ACL/RBAC enforcement assumes the registry is fronted by **authentication** (Basic auth, mTLS, or OAuth/SASL-derived principals). The principal identity is what ACLs/role bindings match on. HTTPS should protect the REST API in transit. ## Edge cases & best practices - **Least privilege**: producers WRITE only their own subjects; consumers READ only; humans/ops hold MODE/COMPATIBILITY. - **Context-scoped grants** keep DR/import contexts separate from production subjects. - Lock down **global compatibility** changes — a single loosening can silently allow breaking schemas everywhere. - Treat exporter creation and IMPORT mode as **privileged, audited** actions. ## Why it matters The registry is a single point of contract truth; ACL/RBAC scoping by subject and context, with mode/compatibility/exporter operations locked to operators, prevents one team from breaking everyone's serialization.
- Why should the MODE operation be tightly restricted?MODE controls READWRITE/READONLY/IMPORT. Granting it lets a principal flip a subject/context into IMPORT mode (register explicit IDs) or READONLY, which can corrupt or freeze the contract for all consumers — it's an operator-level privilege, not an application one.
- How do you let a producer evolve only its own subjects without touching others?Grant WRITE (and READ) scoped to that producer's subject name pattern or context, and withhold global COMPATIBILITY/MODE so it can register versions for its subjects but can't alter registry-wide policy.
saying these in an interview costs you the question
- Confusing Schema Registry ACLs with Kafka broker (topic) ACLs — they are a separate authorization domain on Subject resources.
- Saying compatibility/mode changes are safe for any writer — they are privileged and can break all consumers.
- Ignoring contexts in access design — grants should be scoped per context for DR/import isolation.
- Assuming RBAC works without authentication — ACL/RBAC needs an authenticated principal (Basic/mTLS/OAuth).