Streaming

Manage Schema Registry ACLs with the Redpanda Operator

With the Redpanda Operator, you can declaratively manage Schema Registry ACLs alongside standard Kafka ACLs using the existing User, RedpandaRole, and Group custom resources. This allows you to control which users and roles perform specific operations within Schema Registry.

For Schema Registry Authorization concepts and the available operations, see Schema Registry Authorization.

Prerequisites

You must have the following:

Schema Registry ACL resource types

The Redpanda Operator supports two Schema Registry ACL resource types in addition to the standard Kafka ACL resource types (topic, group, cluster, transactionalId):

  • subject: Controls ACL access for specific Schema Registry subjects. Specify the subject name in resource.name. Supports both literal and prefixed pattern types.

  • registry: Controls access to global Schema Registry operations. The registry resource type does not require a name because it applies to all global registry operations.

For a full list of supported operations by resource type, see Supported operations.

Define Schema Registry ACLs in a User resource

The User resource supports Schema Registry ACLs alongside standard Kafka ACLs.

user-with-sr-acls.yaml
---
apiVersion: cluster.redpanda.com/v1alpha2
kind: User
metadata:
  name: travis
spec:
  cluster:
    clusterRef:
      name: sasl
  authentication:
    type: scram-sha-512
    password:
      valueFrom:
        secretKeyRef:
          name: travis-password
          key: password
  authorization:
    acls:
    - type: allow
      resource:
        type: topic
        name: some-topic
        patternType: prefixed
      operations: [Read]
    - type: allow
      resource:
        type: subject
        name: some-topic
        patternType: prefixed
      operations: [Read]

In this example, the User resource creates ACLs for an existing user called travis in the cluster called sasl. The first ACL rule grants read access to all topics whose names start with some-topic using a prefixed pattern type. The second ACL rule grants read access to Schema Registry subjects matching the same prefix.

When both Kafka and Schema Registry ACLs are defined in the same User resource, the operator syncs them independently. Kafka ACLs are applied through the Kafka API and Schema Registry ACLs are applied through the Schema Registry API.

Define Schema Registry ACLs in a RedpandaRole resource

The RedpandaRole resource groups Schema Registry ACLs into reusable permission sets for multiple users.

role-with-sr-acls.yaml
---
apiVersion: cluster.redpanda.com/v1alpha2
kind: RedpandaRole
metadata:
  name: read-only-role
spec:
  cluster:
    clusterRef:
      name: sasl
  principals:
    - User:charlie
  authorization:
    acls:
      - type: allow
        resource:
          type: topic
          name: public-
          patternType: prefixed
        operations: [Read, Describe]
      - type: allow
        resource:
          type: subject
          name: public-
          patternType: prefixed
        operations: [Read, Describe]

In this example, a RedpandaRole called read-only-role is created in the cluster called sasl. The user charlie is assigned as a principal. The authorization rules grant Read and Describe access to all topics with names starting with public- using a prefixed pattern type, and the same Read and Describe access to Schema Registry subjects matching the same prefix.

Define Schema Registry ACLs in a Group resource

The Group resource supports Schema Registry ACLs for OIDC groups.

In this example, ACLs are created for an OIDC group called engineering in the cluster called sasl. The authorization rules grant Read and Describe access to all topics with names starting with team- using a prefixed pattern type, and the same Read and Describe access to Schema Registry subjects matching the same prefix.

group-with-sr-acls.yaml
# In this example manifest, ACLs are created for an OIDC group called "engineering"
# in a cluster called "sasl". The group is granted read access to topics matching "team-"
# and read access to Schema Registry subjects matching "team-".
---
apiVersion: cluster.redpanda.com/v1alpha2
kind: Group
metadata:
  name: engineering
spec:
  cluster:
    clusterRef:
      name: sasl
  authorization:
    acls:
      - type: allow
        resource:
          type: topic
          name: team-
          patternType: prefixed
        operations: [Read, Describe]
      - type: allow
        resource:
          type: subject
          name: team-
          patternType: prefixed
        operations: [Read, Describe]

Common use cases

The following examples show common patterns for configuring Schema Registry ACLs using the User resource.

Grant a user read access to a subject

This example gives a consumer application read access to the orders topic and its associated Schema Registry subject orders-value. Both ACLs use a literal pattern type to match exact resource names.

consumer-app.yaml
---
apiVersion: cluster.redpanda.com/v1alpha2
kind: User
metadata:
  name: consumer-app
spec:
  cluster:
    clusterRef:
      name: redpanda
  authorization:
    acls:
      - type: allow
        resource:
          type: topic
          name: orders
          patternType: literal
        operations: [Read]
      - type: allow
        resource:
          type: subject
          name: orders-value
          patternType: literal
        operations: [Read]

Grant a producer write access using prefix patterns

This example creates a user called producer-app with both authentication credentials and authorization rules. The ACLs grant Write and Describe access to all topics and Schema Registry subjects whose names start with events- using a prefixed pattern type. This allows the producer to register new schema versions for any subject matching the prefix.

producer-app.yaml
---
apiVersion: cluster.redpanda.com/v1alpha2
kind: User
metadata:
  name: producer-app
spec:
  cluster:
    clusterRef:
      name: redpanda
  authentication:
    type: scram-sha-512
    password:
      valueFrom:
        secretKeyRef:
          name: producer-app-secret
          key: password
  authorization:
    acls:
      - type: allow
        resource:
          type: topic
          name: events-
          patternType: prefixed
        operations: [Write, Describe]
      - type: allow
        resource:
          type: subject
          name: events-
          patternType: prefixed
        operations: [Write, Describe]

Grant global Schema Registry access

This example gives a schema administrator full access to all Schema Registry operations. The first ACL rule uses the registry resource type, which applies to global operations such as getting or setting the global compatibility level. The registry resource type does not require a name field. The second ACL rule uses a subject resource type with an empty name and prefixed pattern type to match all subjects.

schema-admin.yaml
---
apiVersion: cluster.redpanda.com/v1alpha2
kind: User
metadata:
  name: schema-admin
spec:
  cluster:
    clusterRef:
      name: redpanda
  authorization:
    acls:
      - type: allow
        resource:
          type: registry
        operations: [Read, Write, Delete, Describe, DescribeConfigs, AlterConfigs]
      - type: allow
        resource:
          type: subject
          name: ""
          patternType: prefixed
        operations: [Read, Write, Delete, Describe, DescribeConfigs, AlterConfigs]

Partial sync behavior

When a resource includes both Kafka and Schema Registry ACLs, the operator syncs them independently. If the Kafka ACLs sync successfully but the Schema Registry ACLs fail (for example, if Schema Registry Authorization is not enabled), the resource enters a PartiallySynced state. Check the resource status conditions for details:

kubectl get user <user-name> -o jsonpath='{.status.conditions}' --namespace <namespace>

Deploy and verify

To deploy a resource with Schema Registry ACLs, apply the manifest to the same namespace as your Redpanda cluster:

kubectl apply -f <manifest-filename>.yaml --namespace <namespace>

After deploying, verify that the Redpanda Operator reconciled the resource:

kubectl logs -l app.kubernetes.io/name=operator -c manager --namespace <namespace>

Next steps

Suggested labs

Search all labs