Simple Authentication and Security Layer (SASL)

This authentication method is commonly used with an EventHub such as Kafka.

Synopsis

apiVersion: kannika.io/v1alpha
kind: Credentials
metadata:
  name: kafka-sasl-plain-creds
spec:
  sasl:
    mechanism: PLAIN # or SCRAM-SHA-256 or SCRAM-SHA-512
    usernameFrom:
      secretKeyRef:
        name: kafka-sasl-creds
        key: username
    passwordFrom:
      secretKeyRef:
        name: kafka-sasl-creds
        key: password
    # sslConf below is optional.
    # If it is defined, then SASL_SSL will be configured
    sslConf:
      # Explicitly set, but assumed 'true' if not present.
      enabled: true
      # Optional. Configure an explicit CA for server authentication.
      caCertificatePemFrom:
        secretKeyRef:
          name: tls-secret
          key: ca.crt
      # Optional. Set a client certificate if the server requires it.
      certificatePemFrom:
        secretKeyRef:
          name: tls-secret
          key: tls.crt
      # Optional. Set a client key if the server requires it
      privateKeyPemFrom:
        secretKeyRef:
          name: tls-secret
          key: tls.key
      # Optional. Set the password to unlock the client's private key
      privateKeyPasswordFrom:
        secretKeyRef:
          name: tls-key-password
          key: password

SASL/PLAIN

To use the SASL/PLAIN authentication method, set the mechanism field to PLAIN.

SASL/SCRAM

To use the SASL/SCRAM authentication method, set the mechanism field to SCRAM-SHA-256 or SCRAM-SHA-512.

Using SSL/TLS

Using SASL for authentication alone doesn’t mean the resulting connection between Armory and the EventHub is encrypted. To enable SSL/TLS, you need to define the sslConf property in accordance with your particular situation.

Note

In Kafka-parlance, this enables the SASL_SSL security.protocol.

Using the default CA

In the most simple case, define sslConf with an enabled: true property:

apiVersion: kannika.io/v1alpha
kind: Credentials
metadata:
  name: creds
spec:
  sasl:
    mechanism: PLAIN # or SCRAM-SHA-256 or SCRAM-SHA-512
    usernameFrom:
      secretKeyRef:
        name: kafka-sasl-creds
        key: username
    passwordFrom:
      secretKeyRef:
        name: kafka-sasl-creds
        key: password
    sslConf:
      enabled: true

This is enough when:

• the server doesn’t require additional authentication from the client (through a client certificate),
• the server’s certificate can be validated with the ca-certificates package included in Kannika Armor’s image,

Server authentication

If the server’s certificate needs to be validated with a custom CA (self-signed certificate), then use the caCertificatePemFrom field to reference a secret in PEM format.

apiVersion: kannika.io/v1alpha
kind: Credentials
metadata:
  name: kafka-sasl-plain-creds
spec:
  sasl:
    mechanism: PLAIN # or SCRAM-SHA-256 or SCRAM-SHA-512
    usernameFrom:
      secretKeyRef:
        name: kafka-sasl-creds
        key: username
    passwordFrom:
      secretKeyRef:
        name: kafka-sasl-creds
        key: password
    sslConf:
      enabled: true
      caCertificatePemFrom:
        secretKeyRef:
          name: tls-secret
          key: ca.crt

Client authentication

In some rare cases, the server may require TLS authentication from the client. In this situation, load the certificate and key in a secret and configure sslConf accordingly:

apiVersion: kannika.io/v1alpha
kind: Credentials
metadata:
  name: kafka-sasl-plain-creds
spec:
  sasl:
    mechanism: PLAIN # or SCRAM-SHA-256 or SCRAM-SHA-512
    usernameFrom:
      secretKeyRef:
        name: kafka-sasl-creds
        key: username
    passwordFrom:
      secretKeyRef:
        name: kafka-sasl-creds
        key: password
    sslConf:
      enabled: true
      certificatePemFrom:
        secretKeyRef:
          name: tls-secret
          key: tls.crt
      privateKeyPemFrom:
        secretKeyRef:
          name: tls-secret
          key: tls.key

• explicitly set using a secret in PEM format with caCertificatePemFrom.