Manage grant to create a KafkaAccess in a namespace

[albundy83]

Hello,

creating KafkaAccess in any namespace is a great feature.

I was thinking about the problem of whether to allow certain destination namespaces.

Here is a way to allow a KafkaAccess from a KafkaUser, using a ReferenceGrant object.
This is the approach used with cross-namespace storage data sources or with gateway api.

For example, in my-beloved-kafka-namespace, you have your cluster, node pool and everything, and you create a KafkaUser albundy83-kafkauser:

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaUser
metadata:
  name: albundy83-kafkauser
  namespace: my-beloved-kafka-namespace
  labels:
    strimzi.io/cluster: my-beloved-kafka-cluster
spec:
  authentication:
    type: tls
  authorization:
    type: simple
    acls:
      - resource:
          type: cluster
        operations:
          - Create
          - Describe
          - DescribeConfigs
        host: '*'
      - resource:
          type: topic
          name: '*'
          patternType: literal
        operations:
          - Describe
          - Read
          - DescribeConfigs
        host: '*'
      - resource:
          type: group
          name: albundy83-group
          patternType: literal
        operations:
          - Read
          - Describe
        host: '*'
      - resource:
          type: topic
          name: albundy83-topic
          patternType: literal
        operations:
          - Create
          - Describe
          - Read
          - Write
          - DescribeConfigs
        host: '*'

You want a KafkaAccess in my-secure-namespace, so it could look like this:

apiVersion: access.strimzi.io/v1alpha1
kind: KafkaAccess
metadata:
  name: albundy83-kafkaaccess
  namespace: my-secure-namespace
spec:
  kafka:
    name: my-beloved-kafka-cluster
    namespace: my-beloved-kafka-namespace
    listener: external
  user:
    apiGroup: kafka.strimzi.io
    kind: KafkaUser
    name: albundy83-kafkauser
    namespace: my-beloved-kafka-namespace

To ensure that your KafkaAccess can only be created in my-secure-namespace, you also need to create a ReferenceGrant in the source namespace my-beloved-kafka-namespace:

apiVersion: gateway.networking.k8s.io/v1beta1
kind: ReferenceGrant
metadata:
  name: allow-to-create-albundy83-kafkaaccess
  namespace: my-beloved-kafka-namespace
spec:
  from:
    - group: access.strimzi.io
      kind: KafkaAccess
      namespace: my-secure-namespace
  to:
    - group: kafka.strimzi.io
      kind: KafkaUser
      name: albundy83-kafkauser

Of course, it's just an idea, but I found some similarities.

[katheris]

Hi @albundy83, this does look interesting, thank you for sharing. Just to make sure I am clear on what you are suggesting, we would need to update the Access Operator so that if it sees a KafkaAccess CR that references a KafkaUser or Kafka CR in a different namespace it validates that there is a relevant ReferenceGrant resource present before creating the Secret, is that right? It's something that is checked at the operator level, not something that Kubernetes itself would enforce?

[albundy83]

Hello,

my example was more to alert you on the fact that a malicious (or just curious) user that is scoped to a dedicated namespace without access to kafka could be able to create a KafkaAccess object (if of course he know an existing KafkaUser) and the access operator will create for him the Secret with all the needed credentials in his namespace.

And this kind of security concern across namespaces reminds me how the problem has been solved with ReferenceGrant object to allow or not some destinations namespaces.

I'm not sure that ReferenceGrant is the right answer for moment, as the futur of this object is not sure unfortunately.
It should have been migrated to a more neutral api group but not planned for moment kubernetes/enhancements#3766

I don't have the correct answer, but I think that an object in the same namespace that contains the KafkaUser that allow some destinations namespaces for KafkaAccess could be a way :)

[scholzj]

I'm not sure if the reference grant is the right path forward. It does solve the problem you describe. And it would be pretty easy to implement it even without any Kube effort - for example through some annotations etc. But it would still leave the cluster exposed because the Access Operator will have access to the users and secrets. And if you control the access operator, you can bypass the reference grant check.

I wonder if a fundamental change of the model that would address it. The Access operator was based on the Service Binding model. That led to the pull-based design. But AFAIK, service binding is dead anyway (and was dead way before we finished the access operator). Would a push based model work better for the Access Operator? I.e. it would run locally where the KafkaUsers / Kafka clusters exist. And it would be based on an annotation on the Kafka / KafkaUser CRs copy the credentails / information outside to where they are needed? That way, it would be the owner of the custom resource at the source who owns the credentials deciding where they should be delivered.

You could that way also much better control the access rights to the remote side. Because you know much better what right it will need and can give it the access right to create/update/delete a single specific secret for a specific user instead of giving it wide access to all users and all secrets to let it pick what is needed.

The downside of course is that it has nothing to do with today's access operator anymore and we would dump all of that if we decide to change the direction 😉

[albundy83]

Ah you are right but maybe a simple annotation at KafkaUser level with the list of allowed namespaces... :)

[katheris]

Hey @scholzj I've been thinking about this, and re-reading your comment. I wonder if this could be addressed within the existing Kafka Access Operator by changing the API to allow the Kafka Access CR to include a single, or maybe even list of namespaces. So as you say running the Kafka Access Operator right where the Kafka and KafkaUser CRs are, but then specifying in the Kafka Access which namespace to push credentials to.

For users that aren't using the KafkaUser CR this would work well, and for those that are using the KafkaUser CR we could additionally consider an annotation on the KafkaUser CR that the Access Operator reacts to. I don't think this would necessarily require a big change to the operator, since it already watches all the relevant resources, but if the community thought this was a good idea we could investigate.

Also once the work to support remote cluster is done the Access Operator could even push credentials out to a remote cluster.

What do you think?

[albundy83]

I like this idea :)

[katheris]

Triaged on 19.2.2026: The general consensus in the community is that changes to for example do a more push based model could be useful, however non of the maintainers have capacity to pick this up at the moment, so we will leave this issue open for the future or for a community member to pick up.

This would need a proposal for any changes.