ACL manifest for super-user

[cloudcafetech]

I want user (super-user) who can do every thing in my cluster and I want to use external (cert,truststore,keystore generation will take cake.)

Looking user manifest file with ACL for that user (super-user) who can do every thing in kafka cluster

[scholzj]

I'm not sure why it needed new issue instead of following the comment you found there?

---

1. Set the user as super user:

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
spec:
  kafka:
    # ...
    authorization:
      type: simple
      superUsers:
        - CN=super-user
    # ...
  zookeeper:
    # ...

2. Create the user with authentication only:

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaUser
metadata:
  name: super-user
  labels:
    strimzi.io/cluster: my-cluster
spec:
  authentication:
    type: tls

[cloudcafetech]

It's not working as expected because when I saw user "kubectl get ku"

In super-user authorization is coming blank, rest users are coming as simple.

[scholzj]

The super user configuration is in the Kafka CR. Not in the KafkaUser CR.

[cloudcafetech]

Then after generating certificate truststore keystore of super-user and using it outside of cluster not working.

[scholzj]

Then you have to share your resources and your logs.

[cloudcafetech]

which containers (pod) logs ?

[scholzj]

I think probably from Kafka brokers, Cluster operator, User operator and from the client. Plus the used Kafka and KafkaUser custom resources.

[scholzj]

So why do you think this has anything to do with ACLs? There does not seem to be any authorization errors in any of the logs. If it is just the topics, then this is probably the issue:

2020-09-29 00:52:09,481 INFO [Admin Manager on Broker 0]: Error processing create topic request CreatableTopic(name='sales', numPartitions=10, replicationFactor=3, assignments=[], configs=[]) (kafka.server.AdminManager) [data-plane-kafka-request-handler-5]
org.apache.kafka.common.errors.InvalidReplicationFactorException: Replication factor: 3 larger than available brokers: 1.
2020-09-29 00:52:09,488 INFO [Admin Manager on Broker 0]: Error processing create topic request CreatableTopic(name='shipments', numPartitions=10, replicationFactor=2, assignments=[], configs=[]) (kafka.server.AdminManager) [data-plane-kafka-request-handler-4]
org.apache.kafka.common.errors.InvalidReplicationFactorException: Replication factor: 2 larger than available brokers: 1.
2020-09-29 00:52:09,499 INFO [Admin Manager on Broker 0]: Error processing create topic request CreatableTopic(name='users', numPartitions=10, replicationFactor=3, assignments=[], configs=[]) (kafka.server.AdminManager) [data-plane-kafka-request-handler-1]
org.apache.kafka.common.errors.InvalidReplicationFactorException: Replication factor: 3 larger than available brokers: 1.

You are trying to create the topics with replication factor higher than the number of brokers you have so they cannot be created.

[cloudcafetech]

Yes, apart from time-tracking all topics are created using topic operator and only time-tracking I created using external tool with same super-user.

But in GUI screen I am not view all topics with super-user.

That's why I little interested.

[scholzj]

Right, but apart from time-tracking, all the topics have replication factor 2 or 3 which is not possible with a single broker. So the topics do not exist. That is what the errors are telling you. You have to change them to have replication-factor=1. This does not look like any kind of ACL issue.

[cloudcafetech]

yes, correct ...

That means when creating topic its not validating by topic operator number of broker with replication factor.

But officially it should be, maybe it should added as enhancement in feature release. (let me know should I close this thread or open with new as a enhancement)

Got it, thanks for explanation.

[scholzj]

When you create the custom resource, you do not talk with Strimzi. You just talk with the Kube API which takes it and stores it in Etcd. Only later the Strimzi operator picks it up - so there is not much space for validating it. You can try to do oc get kt -o yaml and check the .status sections which should contain the error. If it doesn't contain the error, we can open a new bug issue.

[cloudcafetech]

Thank you ...