Can I create and use a custom Authorizer?

[robhoeting-kr]

Hi --

We are planning to stand up a cluster to leverage Azure AD to issue and validate JWT Tokens. We have been able to deploy Kafka into an AKS test cluster, using the OAuth capabilities in Strimzi. Thank you for the documentation and examples that helped us figure how to do this. For reference, our YAML looks like this:

spec:
kafka:
version: 2.6.0
replicas: 1
listeners:
plain: {}
tls:
authentication:
type: oauth
validIssuerUri: https://sts.windows.net/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxx/v2.0/
jwksEndpointUri: https://login.microsoftonline.com/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxx/v2.0/discovery/keys
userNameClaim: appid
tlsTrustedCertificates:
- secretName: my-cert
certificate: mycetCA.crt
checkAccessTokenType: false

The next step is to enforce authorization. While I am not 100% of this, I suspect we will likely need to create a custom authorizer (due to the security requirements). On one hand it seems like this would be possible if I do the following:

1. create a custom authorizer, perahps one that extends SimpleAclAuthorizer, or implements kafka.security.auth.Authorizer interface. Let's call this MyKafkaAuthorizer
2. create a docker image (based on a strimzi image) that copies the class/jar into libs folder
3. the new image has a modified server.properties file with a line: "authorizer.class.name=com.myco.MyKafkaAuthorizer"

At this point, I realize it might not be possible. Looking at the allowable types in kafka crd, there are only simple, opa, and keycloak. Regardless of what I have coded in my server.properties and docker image, each of these selections will force the a certain type of authorizer (just as the docs suggest). I guess my question is, is there any way to provide a custom authorizer into my cluster?

Thank you.

Rob

[scholzj]

It is not possible right now. But in the past I had some thoughts about having a custom authorizer supported in the CRD which would just let you specify the authorizer class and additional config and let you use it (after you add the JAR to the container images). That might cover the simple situation ... but would probably not work if your authorizer needs some special configs or mount some special volumes etc. So if there is some interest for it and if this would work for you, I'm sure we can open an enhancement for it and add it. It would not be so complicated.

But it would be great if you could also (if possible) describe a bit more detail about why you need custom authorizer and why are the ones we support not sufficient. Just to make sure this isn't something what we can for example implement in our authorizer instead.

[robhoeting-kr]

Hi Jakub -- Thanks for the prompt reply! It's definitely worth double checking on my end whether or not the existing mechanisms would work for our use security case. In your experience, is it out of the question to use, say KeyCloak authorizer, in conjunction with Azure AD, or is it intended to only work with Keycloak?

[scholzj]

@mstruk would be the expert on that.

But AFAIK the Keycloak Authorizer is using Keycloak Authorization Services - that is not part of OAuth 2.0. I would expect that maybe you could use Keycloak to federate to Azure AD and for example assign the rights in the Keycloak Authorization Services based on some federated roles etc. But you would need to have Keycloak as the middle layer. You cannot do it directly between Kafka and Azure AD.