Apicurio Registry Read Access Models

This guide explains the two models Apicurio Registry offers for reading a schema, what each one exposes to a caller, why a production installation moves off anonymous reads, and what each model costs. No commands appear here: How to Configure Apicurio Authentication holds the procedure.

Type

Explanation

Goal

Understand which read access model an installation runs, and what changes for its clients when it moves from one to the other.

Audience

Platform Operators and infrastructure engineers who decide how registry clients authenticate.

When to use

Read before configuring registry authentication, and when deciding whether an installation can turn anonymous reads off.

The sections below cover each area of the subject:

Where an installation starts
Anonymous read access
Authenticated read access with the sr-readonly role
What each model costs
What a production installation runs

Where an installation starts

The Axual Streaming chart ships Apicurio Registry with authentication switched off. The bundled Keycloak and its MySQL datastore are off too, so there is nothing for the registry to authenticate against. In that state the registry applies no identity check at all: any caller that can reach it views, registers and deletes artifacts. That suits an installation being evaluated, where every client sits on the same trusted network and no schema matters yet. It stops being viable once the registry holds schemas an application depends on, because deleting one takes nothing more than network access.

Switching authentication on is what makes the two read models below distinct. Once the registry authenticates, writing to an artifact goes through role-based authorisation, and reading becomes a separate decision: reads either stay open to anonymous callers, or they require credentials of their own.

Anonymous read access

One property governs anonymous read access. With apicurio.auth.anonymous-read-access.enabled: "true", any caller that reaches the registry fetches any artifact without presenting credentials. Writes are unaffected, so registering, changing or deleting an artifact still needs an authenticated identity holding a role that permits it.

The model exists because of how the platform’s clients used to be configured. Before Axual Platform 2026.1 there was no read-only registry role, so an application that only resolves schemas had no identity to present and relied on anonymous reads. Kafka Streams applications were the exception: they hold sr-developer, which they need for schema management.

Apicurio evaluates the anonymous read check before role-based authorisation. While the property is true, no role assignment narrows what a caller reads.

That ordering has two consequences. Granting a client the read-only role and treating it as the client’s ceiling still leaves a registry that answers an unauthenticated request for the same artifact. Remapping roles to freeze writes leaves anonymous reads working throughout, because the property is the only switch over them.

Authenticated read access with the sr-readonly role

From Axual Platform 2026.1 the Platform Manager assigns the sr-readonly role to applications that are not based on Kafka Streams when it generates their registry credentials. A standard producer or consumer then has an identity of its own at the registry, which is what lets an operator turn anonymous read access off.

The role an application receives follows what it does with schemas:

sr-readonly goes to applications that are not based on Kafka Streams, which is every standard producer and consumer. It permits reads and nothing else.
sr-developer goes to Kafka Streams applications, including KSML, so they can manage schemas as well as read them.

The role has to exist as a realm-level role in the Apicurio Keycloak realm before the Platform Manager can assign it. A realm imported before 2026.1 does not carry it, so on an upgraded installation someone adds the role by hand first. Apicurio Keycloak Realm describes the realm the chart imports.

What each model costs

Both models let an application resolve a schema id, and they differ in what the registry knows about the caller:

Aspect	Anonymous read	Authenticated read
Credentials a reading application carries	None.	A username and password pair, or an OAuth principal, generated per application and environment in Self-Service.
Callers that can read an artifact	Every caller with network access to the registry.	Only applications holding a role that permits reads.
Effect of a role assignment on reads	None, because the anonymous check runs first.	Decides what the caller reads.
What the registry knows about a read	Nothing that identifies the caller.	The authenticated client behind the request.
What breaks the read path	Loss of network reachability.	A missing or revoked credential, or a realm without the read-only role.

Aspect

Anonymous read

Authenticated read

Credentials a reading application carries

None.

A username and password pair, or an OAuth principal, generated per application and environment in Self-Service.

Callers that can read an artifact

Every caller with network access to the registry.

Only applications holding a role that permits reads.

Effect of a role assignment on reads

None, because the anonymous check runs first.

Decides what the caller reads.

What the registry knows about a read

Nothing that identifies the caller.

The authenticated client behind the request.

What breaks the read path

Loss of network reachability.

A missing or revoked credential, or a realm without the read-only role.

The trade-off is where the work sits. Anonymous read needs no setup: a client needs a URL, and an application added to the platform reads schemas as soon as it starts. The model gives up knowing who its readers are, because an unlisted caller and a registered application look identical to the registry, so a read cannot be attributed to either.

Authenticated read moves the work onto every reading application and onto whoever operates the realm. Each application carries credentials that someone generates, distributes and rotates. The password is shown once at generation time, so losing it means generating a new pair rather than looking the old one up. In exchange, the set of callers that can read the schemas becomes a list an operator maintains instead of a property of the network.

What a production installation runs

A production installation combines three settings, and the first two are what make the third meaningful:

Role-based authorisation, so what an identity does to an artifact follows the roles it holds.
HTTP Basic authentication, so an application authenticates with the credentials Self-Service generated for it.
One of the two read models: authenticated read, available from 2026.1, or anonymous read where clients cannot yet carry credentials.

For an installation that predates 2026.1, the two models mark the start and the end of one migration. The installation keeps anonymous read while applications that read schemas still have no registry credentials, and turns it off once every one of them has been reissued. Turning it off first leaves every standard producer and consumer unable to resolve a schema.

How to Configure Apicurio Authentication holds the values for all three settings. Upgrading Streaming and Governance Charts to 2026.2 sets out the order for an installation that is already running.