Skip to Main Content

SASL Authentication

Refer to Overview▸, the AutoMQ data plane service is built on the Kafka API and includes SASL authentication features. This document provides guidance on configuring SASL authentication for your instance, along with a client access example.

Enable SASL_PLAINTEXT​

The SASL_PLAINTEXT protocol allows users to upload access credentials through non-encrypted transmission. The server then performs authentication and verification, followed by ACL access control checks on the authenticated identities.

The SASL_PLAINTEXT protocol provided by AutoMQ supports the following authentication mechanisms: PLAIN, SCRAM-SHA-256, SCRAM-SHA-512.

Step 1: Server Configuration​

  1. To use SASL_PLAINTEXT, click Advanced Options >> Enable the following parameters when creating an instance. Refer to the interface in the figure below:

    • TransitEncryption option: Enable Plaintext.

    • Authentication Method: Enable SASL authentication.

  1. After enabling SASL_PLAINTEXT, access the instance details page to view the corresponding access point information.
  1. After obtaining the access point, you must create an ACL user for the Kafka client and the corresponding ACL authorizations. The client will then use the ACL user credentials to access the server. For operational instructions, refer to Manage Kafka ACLs▸.

Step 2: Client Configuration​

Kafka clients utilize the SASL_PLAINTEXT protocol to connect to the server. Please consult the Apache Kafka documentation for detailed examples and be sure to configure the following parameters. The username and password should correspond to the ACL user information you created earlier.

Before connecting using SASL_PLAINTEXT, ensure that the ACL user has been granted the necessary resource operation permissions.


# Configure SASL_PLAINTEXT
security.protocol=SASL_PLAINTEXT
# Configure Mechanism, Support PLAIN, SCRAM-SHA-256, SCRAM-SHA-512
sasl.mechanism=SCRAM-SHA-512
# Configure the Jaas Config,set LoginModule,UserName,Password
sasl.jaas.config=org.apache.kafka.common.security.scram.ScramLoginModule required \  username="XXXX" \  password="XXXX";

Enable SASL_SSL​

The SASL_SSL protocol facilitates the transmission of access credentials over a TLS-encrypted communication channel. This enables the server to perform identity authentication and verification. Once identities are successfully authenticated, they undergo ACL access control verification.

To enable TLS transport encryption in an AutoMQ BYOC environment, users must provide a CA and server certificate, ensuring that the certificate matches the domain name. Additionally, users are required to periodically review the certificates to prevent service disruption due to expired certificates.

Step 1: Create CA and Certificate​

If your organization cannot obtain certificates issued by a trusted CA, you can refer to the documentation below to self-sign and maintain a private CA and certificate. Furthermore, for production environments, it is recommended to manage CA and certificates using AWS Private CA Product.

  1. Configure the CA signing policy file ca.cnf.

[ ca ]
default_ca = CA_AutoMQ_Default

[ CA_AutoMQ_Default ]
default_days    = 3650
database        = index.txt
serial          = serial.txt
default_md      = sha256
copy_extensions = copy
unique_subject  = no
policy          = signing_policy

[ req ]
prompt             = no
distinguished_name = distinguished_name
x509_extensions    = extensions

[ distinguished_name ]
organizationName = <Replace with your Orgnaization Name>
commonName       = <Replace with your Common Name>

[ extensions ]
keyUsage         = critical,digitalSignature,nonRepudiation,keyEncipherment,keyCertSign
basicConstraints = critical,CA:true,pathlen:1

[ signing_policy ]
organizationName = supplied
commonName       = optional

  1. Generate the CA private key ca.key and set file access permissions.

openssl genrsa -out ca.key 2048
chmod 400 ca.key

  1. Generate the CA public certificate ca.crt .

openssl req -new -x509 -config ca.cnf -key ca.key -days 3650 -batch -out ca.crt

The command above will generate the ca.crt file as the CA public certificate, which needs to be deployed to both AutoMQ instances and Kafka clients afterwards.

  1. Create the broker certificate configuration file broker.cnf .

In the AutoMQ BYOC environment, the broker provides services externally by directly using the IP address, thus domain name verification is not currently supported. Therefore, it is advised to retain the SAN information at its default value and disable domain name verification on the client side.


[ req ]
prompt             = no
distinguished_name = distinguished_name
req_extensions     = extensions

[ distinguished_name ]
organizationName = <Replace with your Organization>

[ extensions ]
subjectAltName = @alt_names

[ alt_names ]
DNS.1 = localhost

  1. Generate the broker's private key broker.key .

openssl genrsa -out broker.key 2048

  1. Generate the Broker Certificate Signing Request (CSR) broker.csr.

openssl req -new -key broker.key -out broker.csr -nodes -config broker.cnf

  1. Use the previously mentioned CA private key to sign the CSR and generate the Broker certificate broker.crt.

openssl x509 -req -CA ca.crt -CAkey ca.key -in broker.csr -out broker.crt -days 3650 -CAcreateserial

The output file broker.crt is the signed Broker public certificate. It is recommended to set it as read-only. For subsequent deployment, the files broker.crt, broker.key, and ca.crt are needed.

Step 2: Server Configuration​

  1. Using SASL_SSL requires clicking on Advanced Options >> Enable the following parameters when creating the instance. Refer to the interface depicted in the diagram below:

    • TransitEncryption: Enable TLS Encryption.

    • Authentication Method: Enable SASL authentication.

    • Upload CA: Upload the CA certificate file obtained in the previous step, ca.crt.

    • Upload Server Cert: Upload the Broker certificate file obtained in the previous step, broker.crt.

    • Upload Private Key: Upload the private key file for the Broker certificate obtained in the previous step, broker.key.

  1. After enabling SASL_SSL, access the instance details page to view the endpoint information.
  1. After obtaining the access point, you must create an ACL user for the Kafka client and the corresponding ACL authorizations. The client will then use the ACL user credentials to access the server. For operational instructions, refer to Manage Kafka ACLs▸.

Note: The SASL_SSL and mTLS protocols can only be enabled during instance creation and do not currently support enabling transport encryption for existing instances.

Step 3: Client Access Configuration​

The Kafka client accesses the server using the SASL_SSL protocol. Refer to the Apache Kafka documentation examples to configure the necessary parameters.

  1. Convert the previously generated CA certificate into a JKS trustStore. Ensure you replace the command parameters below based on your specific situation.

    1. alias: Specify the alias for the CA certificate.

    2. file: Indicate the CA certificate file obtained in the previous step.

    3. keystore: Specify the name of the JKS, necessary for Kafka client configurations later on.

    4. storepass: Provide the access password for the JKS, required for Kafka client configurations later on.


keytool -importcert -alias automq-ca -file ca.crt -keystore truststore.jks -storepass changeit

  1. Add the following configuration parameters to the Kafka client configuration properties. Before using the SASL_SSL protocol to access the server, ensure that ACL users have been granted the appropriate resource operation permissions.

# Configure SASL_SSL
security.protocol=SASL_SSL
# Configure Mechanism, Support PLAIN, SCRAM-SHA-256, SCRAM-SHA-512
sasl.mechanism=SCRAM-SHA-512
# Configure the Jaas Config,set LoginModule,UserName,Password
sasl.jaas.config=org.apache.kafka.common.security.scram.ScramLoginModule required \  username="Replace with your ACL UserName" \  password="Replace with your ACL Password";
# Set Trust Store Type to JKS
ssl.truststore.type=JKS
# Set the Location of Jks
ssl.truststore.location=/path/to/truststore.jks
# Set the Password of Jks
ssl.truststore.password=changeit
# Disable Ssl Hostname Validation, set the Algorithm to Empty
ssl.endpoint.identification.algorithm=

Note:

When signing private CAs and certificates, matching the IP of the AutoMQ cluster is not possible. Therefore, in the client SSL configuration, domain name verification needs to be disabled, which means setting the ssl.endpoint.identification.algorithm parameter to an empty string.

Certificate Expiry Monitoring​

In the BYOC environment, TLS certificates are provided by the user, so users need to monitor the certificate's validity period and ensure renewal and rotation before expiration. The AutoMQ server provides the following metrics for monitoring the expiry time of server certificates:

  • kafka_stream_cert_expiry_timestamp_milliseconds: Displays the current certificate expiration timestamp in milliseconds.

  • kafka_stream_cert_days_remaining: Counts the remaining days from the current time until the certificate expires.

It is recommended that customers refer to the Monitoring & Alert via Prometheus▸ configuration guide and use tools like Prometheus or CloudWatch to monitor certificate expiration dates and mitigate risks.