[Enhancement] Allow configuring SCRAM 512 + mTLS together at the same listener

[vepo]

Suggestion / Problem There is no documentation of how to configure SCRAM 512 with mTLS.

Documentation Link We are using for test the following Kafka configuration, but we cannot create a similar configuration using Strimzi.

  kafka-broker-1:
    image: confluentinc/cp-enterprise-kafka:5.5.0
    hostname: kafka-broker-1
    container_name: kafka-broker-1
    ports:
      - "19093:19093"
      - "19094:19094"
    depends_on:
      - zookeeper-1
      - zookeeper-2
      - zookeeper-3
    environment:
      KAFKA_BROKER_ID: 1
      KAFKA_ZOOKEEPER_CONNECT: zookeeper-1:22181,zookeeper-1:32181,zookeeper-1:42181
      KAFKA_ADVERTISED_LISTENERS: SSL://kafka-broker-1:19093,SASL_SSL://kafka-broker-1:19094
      KAFKA_SSL_KEYSTORE_FILENAME: kafka.broker-1.keystore.jks
      KAFKA_SSL_KEYSTORE_CREDENTIALS: broker-1_keystore_creds
      KAFKA_SSL_KEY_CREDENTIALS: broker-1_sslkey_creds
      KAFKA_SSL_TRUSTSTORE_FILENAME: kafka.broker-1.truststore.jks
      KAFKA_SSL_TRUSTSTORE_CREDENTIALS: broker-1_truststore_creds
      CONFLUENT_METRICS_REPORTER_SSL_TRUSTSTORE_LOCATION: /etc/kafka/secrets/kafka.broker-1.truststore.jks
      CONFLUENT_METRICS_REPORTER_SSL_TRUSTSTORE_PASSWORD: confluent
      CONFLUENT_METRICS_REPORTER_SSL_KEYSTORE_LOCATION: /etc/kafka/secrets/kafka.broker-1.keystore.jks
      CONFLUENT_METRICS_REPORTER_SSL_KEYSTORE_PASSWORD: confluent
      KAFKA_SSL_ENDPOINT_IDENTIFICATION_ALGORITHM: "HTTPS"
      KAFKA_SSL_CLIENT_AUTH: requested
      KAFKA_MIN_INSYNC_REPLICAS: ${KAFKA_MIN_INSYNC_REPLICAS}
      KAFKA_SASL_ENABLED_MECHANISMS: SCRAM-SHA-512
      KAFKA_SECURITY_INTER_BROKER_PROTOCOL: SASL_SSL
      KAFKA_SASL_MECHANISM_INTER_BROKER_PROTOCOL: SCRAM-SHA-512
      KAFKA_AUTO_CREATE_TOPICS_ENABLE: "true"
      CONFLUENT_METRICS_REPORTER_SECURITY_PROTOCOL: SASL_SSL
      CONFLUENT_METRICS_REPORTER_SASL_MECHANISM: SCRAM-SHA-512
      CONFLUENT_METRICS_REPORTER_BOOTSTRAP_SERVERS: ${CONFLUENT_METRICS_REPORTER_BOOTSTRAP_SERVERS}
      KAFKA_OFFSETS_RETENTION_MINUTES: 172800
      KAFKA_LOG4J_LOGGERS: "kafka.authorizer.logger=INFO,kafka.controller=INFO"
      KAFKA_LOG4J_ROOT_LOGLEVEL: "INFO"
      KAFKA_SUPER_USERS: ${KAFKA_SUPER_USERS}
      KAFKA_ZOOKEEPER_SASL_ENABLED: "true"
      KAFKA_ZOOKEEPER_SET_ACL: "true"
      KAFKA_AUTHORIZER_CLASS_NAME: kafka.security.auth.SimpleAclAuthorizer
      KAFKA_ALLOW_EVERYONE_IF_NO_ACL_FOUND: "false"
      KAFKA_OPTS: -Dzookeeper.sasl.client=true
        -Dzookeeper.sasl.clientconfig=Client
        -Djava.security.auth.login.config=/etc/kafka/secrets/conf/kafka_server_jaas.conf
    volumes:
      - ./broker-1:/etc/kafka/secrets
      - ./kafka_server_jaas.conf:/etc/kafka/secrets/conf/kafka_server_jaas.conf
    networks:
      - kafka-cluster-network

[scholzj]

We do not support mixing SASL and TLS client authentication together.

[vepo]

Is there any open ticket to support it?

[scholzj]

No, I do not think anyone else asked for this. From my experience, it is rare that people want to mix different kinds of authentication together as it is often not seen as something improving security. So I guess if you want, you can open one to have it tracked (or update this one).

Also, my guess is that in your example above the TLS authentication is anyway optional (requested not required) - so not sure what is the added value of combining optional TLS authentication with mandatory SASL authentication. (assuming this does not work differently in Confluent Platform compared to Apache Kafka which is what Strimzi uses)

[scholzj]

@vepo So, do you want to convert this into enhancement? Or should we close this? I'm not sure when and if anyone gets to implement it if we change it to enhancement. But it will be tracked.

[vepo]

@vepo So, do you want to convert this into enhancement? Or should we close this? I'm not sure when and if anyone gets to implement it if we change it to enhancement. But it will be tracked.

Sure @scholzj, I can contribute with the solution when I have some time.

[scholzj]

Triaged on 28. 4. 2022: This is non-trivial from the API perspective, where only one authentication type is currently supported. Proposal would be needed to design the API changes required for this.