Skip to main content
The Kafka dynamic secret creates a Kafka user with a username and password for each lease, and gives the user the ACLs you configure, such as read and write access to one topic. Use it when an application or a person needs short-lived access to a self-managed Kafka cluster, and you don’t want to share a long-lived password. Lease users log in with SCRAM-SHA-256 or SCRAM-SHA-512. To learn how leases work across providers, see Dynamic secrets.

​
Prerequisites

  • A self-managed Kafka cluster running Kafka 2.7 or later with ZooKeeper, or Kafka 3.5 or later with KRaft (Confluent Platform 6.1 or later with ZooKeeper, or 7.5 or later with KRaft)
  • A broker listener that accepts SCRAM-SHA-256 or SCRAM-SHA-512 logins, which lease users connect to
  • An authorizer enabled on every broker, so that Kafka enforces the ACLs
  • An admin user that can create SCRAM users and ACLs, such as a user listed in the brokers’ super.users setting, and the admin user’s password
  • Network access from Infisical to your brokers, because Kafka dynamic secrets don’t support gateways
  • If you self-host Infisical and your brokers have private IP addresses, DYNAMIC_SECRET_ALLOW_INTERNAL_IP set to true
  • A role in the Infisical project that lets you create dynamic secrets

​
Step 1: Create the dynamic secret

1
In your project, go to the environment and folder where you want the dynamic secret, then select Add New > Add Dynamic Secret.
2
Select Kafka.
3
Fill in the form:
​
string
required
The name you use to refer to the dynamic secret.
​
string
required
How long a lease lasts if the person creating it doesn’t choose a TTL (for example, 1h).
​
string
The longest TTL anyone can request for a lease (for example, 24h).
​
list
required
The brokers Infisical connects to, each with a Host and Port (for example, kafka-1.example.com and 9092). Select Add Server to add another broker. Infisical tries the brokers in order and uses the first one that accepts the connection.
​
string
required
How Infisical logs in as the admin user: PLAIN, SCRAM-SHA-256, or SCRAM-SHA-512. This setting doesn’t affect lease users, who can log in with either SCRAM mechanism.
​
string
required
The admin user that Infisical logs in as to create and delete lease users.
​
string
required
The admin user’s password.
​
list
required
The permissions each lease user gets. Kafka denies anything these ACLs don’t allow. For each ACL, set:
  • Resource Type: Topic, Group (a consumer group), Cluster, or Transactional ID
  • Pattern: Literal to match the exact Resource Name, or Prefixed to match every resource whose name starts with it
  • Resource Name: the name or prefix, or * for every resource of that type (a Cluster ACL must use kafka-cluster)
  • Operation: what the lease user can do with the resource, such as Read or Write (see Kafka’s list of operations)
  • Permission: Allow or Deny (a Deny ACL overrides any Allow ACL for the same resource)
Select Add ACL to add another. For ACLs that common clients need, see ACL examples.
Under Advanced, you can also set:
​
string
default:"{{randomUsername}}"
Specifies a template for generating usernames. This field allows customization of how usernames are automatically created.Allowed template variables are:
  • {{randomUsername}}: Random username string.
  • {{unixTimestamp}}: Current Unix timestamp at the time of lease creation.
  • {{identity.name}}: Name of the identity that is generating the lease.
  • {{dynamicSecret.name}}: Name of the associated dynamic secret.
  • {{dynamicSecret.type}}: Type of the associated dynamic secret.
  • {{random N}}: Random string of N characters.
Allowed template functions are:
  • truncate: Truncates a string to a specified length.
  • replace: Replaces a substring with another value.
  • uppercase: Converts a string to uppercase.
  • lowercase: Converts a string to lowercase.
Examples:
Infisical adds a hyphen and 8 random characters to every username the template generates, so each lease gets a new Kafka user. For example, {{identity.name}} generates a username such as jane-x7Kp2QmA.
​
boolean
default:"false"
Connect to the brokers over TLS. Turn this on if the listener uses SASL_SSL.
​
string
The PEM-encoded certificate of the CA that signed your brokers’ certificates. You only need it if your brokers use a private CA. Appears when Enable SSL is on.
​
boolean
default:"true"
If on, Infisical checks each broker’s certificate against the CA and the broker’s hostname. Turn this off only to test with a self-signed certificate. Appears when Enable SSL is on.
4
Select Submit.Before Infisical saves the dynamic secret, it logs in as the admin user. Then it checks that your Kafka version supports managing SCRAM users and that the brokers have an authorizer enabled. If a check fails, Infisical shows an error and doesn’t save the dynamic secret. To fix the most common errors, see Troubleshooting.

​
Step 2: Create a lease

1
In the row for the dynamic secret, select Generate Lease.
2
Enter a Default TTL for the lease, then select Provision Lease.
3
Copy the Username and Password.
Infisical shows the credentials only once. Copy them before you close the dialog.
4
Configure your Kafka client to log in with the credentials. For example, in a Java client’s properties file:
If your listener doesn’t use TLS, set security.protocol to SASL_PLAINTEXT. If it only accepts SCRAM-SHA-256, set sasl.mechanism to SCRAM-SHA-256.

​
Renew or revoke a lease

In the row for the dynamic secret, select View Leases. Next to a lease, you can:
  • Select Renew lease to extend the lease, up to the Max TTL
  • Select Revoke lease to delete the lease user before the lease expires
When you revoke a lease or it expires, Infisical deletes the user’s ACLs, then the user’s credentials. If a client is already connected as that user, it stays connected but can’t read or write anything, because Kafka checks the ACLs on every request.

​
ACL examples

These examples show the ACLs to add in Step 1 for common clients, using a topic named orders.
The second ACL lets the lease user join any consumer group whose name starts with orders-, such as orders-billing.

​
Troubleshooting

The broker closed the connection while Infisical was logging in. This usually means Enable SSL doesn’t match the listener on that port:
  • If the listener uses SASL_SSL, turn Enable SSL on
  • If the listener uses SASL_PLAINTEXT, turn Enable SSL off
Changing the SASL Mechanism doesn’t fix this error.
The brokers have no authorizer, so Kafka would ignore every ACL that Infisical creates. Set authorizer.class.name on every broker, then save the dynamic secret again:
  • With KRaft: org.apache.kafka.metadata.authorizer.StandardAuthorizer
  • With ZooKeeper: kafka.security.authorizer.AclAuthorizer
Your cluster runs a Kafka version that can’t manage SCRAM users through the Kafka protocol. Upgrade the cluster to a supported version.
A private CA signed the brokers’ certificates, and Infisical doesn’t trust that CA. Paste the CA’s certificate into CA Certificate.
The broker rejected the admin user’s login. Check the Password, and check that the admin user has a credential for the SASL Mechanism you selected. For example, a user defined only in the brokers’ JAAS configuration for PLAIN has no SCRAM credential.
With ZooKeeper, only the controller broker accepts changes to SCRAM users, so Infisical connects to the controller at the address the controller advertises. Any broker can become the controller, so make sure Infisical can reach every broker’s advertised address.
If a broker sets allow.everyone.if.no.acl.found to true, any user can access a resource that has no ACLs. Infisical can’t detect this setting, so set it to false on every broker.