Kafka-GitOPS ACL management and Strimzi

[taislapta]

Hey Chaps,

we use Kafka-gitops solution for global ACL management across all Kafka clusters MSK, vanilla Kafka and would like to join Strimzi ones. The Problem is that we use SASL with UserOperator and we unable to find out way how to disable ACL management part with simple auth. Is there any option we can tell operator not overwrite ACLs that are pushed by kafka-gitops ?

[scholzj]

It seems hacky to use different solutions for each of them. Why don't you use the other tool also for SCRAM-SHA users? Nobody is probably testing a combination like that.

Leaving that aside, you can use the option STRIMZI_ACLS_ADMIN_API_SUPPORTED to tell the User Operator when the ACL API is not supported in the broker. This is typically used when the broker uses for example OPA authroization rather than simple authorization. But I think it should work for you as well. Keep in mind that the KafkaUser resource should not have the authorization section present at all in that case.

[taislapta]

the kafka-gitops not have functionality fir user management and how strimzi it does(via KafkaUser) we like it. AWS MSK has own user management via Secret Manager and SSM.

I'm trying to use your option regards supportsAdminApi: false key in

  kafka:
    authorization:
      superUsers:
      - super-user
      supportsAdminApi: false
      type: simple

but getting that is not supported. strimzi 0.26

Message:               Contains object at path spec.kafka.authorization with an unknown property: supportsAdminApi

CRD says that is for Custom Authoriser only . and for custom we need jar .

                      supportsAdminApi:
                        type: boolean
                        description: Indicates whether the custom authorizer supports
                          the APIs for managing ACLs using the Kafka Admin API. Defaults
                          to `false`.

any other option to use supportsAdminApi ?

[scholzj]

It is not part of the Kafka CR. Maybe I misunderstood when you mentioned MSK and assumed that you are using the standalone deployment of the User Operator where you just add the environment variable. You can try to use the .spec.entityOperator.template section of the CR to set the environment variable. But I'm not sure it the Cluster Operator lets you change it.

[taislapta]

right , the cluster operator allow to change it and not complain , but value remain unchanged inside userOperator pod
declare -x STRIMZI_ACLS_ADMIN_API_SUPPORTED="true". Even after deletion of the deployment and pod recreation - no change.
It might be that type: simple overwrite it

  entityOperator:
    template:
      userOperatorContainer:
        env:
        - name: STRIMZI_ACLS_ADMIN_API_SUPPORTED
          value: "false"
      ```

[scholzj]

Yeah, I'm afraid the User Operator overwrites it with its own value which is true when you enable simple authorization. But I guess using the custom authorization and mapping it to the normal authorizer should actually work. You would basically use something liek this: https://strimzi.io/docs/operators/latest/full/configuring.html#type-KafkaAuthorizationCustom-reference ... but the authorizer class will be the regular Kafka Auhtorizer instead of something custom. It should be possible to use it to fool the operator.

[taislapta]

I scaled down strimzi operator to 0 , then modified userOperator deployment by changing env:
STRIMZI_ACLS_ADMIN_API_SUPPORTED="false". and all works as expected.

thanks will try to dig in custom authz example. need to figure out correct mapping to simple authorizer class

[scholzj]

I think reasonably recent Kafka versions use kafka.security.authorizer.AclAuthorizer.

[taislapta]

thanks , looks good wit custom and kafka.security.authorizer.AclAuthorizer