Vault supports only SASL_SSL. This means that in addition to selecting SASL-OAUTHBEARER for authentication, you must provide a CA or CA chain in order to successfully establish the connection between Vault services and Kafka over TLS. This can be either a CA certificate/CA chain or a supported Public CA.

(Optional, skip this step if you are using a Public CA)

If you are using Vault-installed Kafka, create the certificates using the PKI engine or the same way as you would for mTLS. This is so that the brokers have certificates and clients have the CA chain.

If you are using Vault-installed Kafka, you only need to provide a CA certificate. You have two options:

Add a CA certificate to the secret manager. If you are using HashiCorp Vault, add it at the path secret/{SECRET_PREFIX};/kafka-ca/ca-certificates.crt; if you are using AWS Secrets Manager, add it at the path {TM_IAM_PREFIX}/{SECRET_PREFIX}/kafka-ca/ca-certificates.crt. Then proceed to step 2.

Inject it with the CA Injector webhook and proceed to step 3.

If Vault has already been installed, replace any existing certificates by running the command:

kubectl exec -it -n tm-system vault-installer -- /deployment-tools/rotate-certs kafka_certs

Run the Vault Installer with the --skip_crown_k8s flag to generate client credentials in your secrets manager.

Discover the client credentials in the secrets manager. To do this, iterate over all secrets ending in /kafka under the secrets path set up for Vault to use, then check if they have fields "oauth_client_id" and "oauth_client_secret".

Register the client IDs and secrets stored in the secrets manager to the OAuth server using the admin endpoint. There are multiple ways of doing this and it depends on the OAuth server that you use.

If this is not supported, then replace the client IDs and secrets in the secret manager with credentials generated by the OAuth server. Please take care with this, as our ACLs assume that the principal of access tokens is the client ID and matches the service name. If your Kafka cluster uses a different part of the access token as a principal, ensure that this matches the service name.

You need to repeat step 4 and step 5 for every Vault upgrade, as new services requiring SASL-OAUTHBEARER credentials to access Kafka may be introduced.

You may wish to keep a historical record of credentials registered to aid with deregistering credentials from the OAuth server when they no longer appear in the release.json artifact. We recommended that you only de-register credentials after the Vault installation process is complete in order to avoid downtime.