A Confluent access token, in practice a Confluent Cloud API key and its secret, lets whoever holds it connect to your managed Kafka clusters and act as the service account or user it belongs to. That can mean reading topics that carry customer events, writing false messages into a pipeline that other systems trust, or changing how the cluster is administered if the key has broad rights. Replace the key first, then check what it touched.
Check your GitHub account for leaked secrets — free
- Provider
- Confluent
- Severity
- High
- Impact
- SaaS account access and billing
- Checked live by LeakWatch
- No
What a Confluent Access Token looks like
The value LeakWatch looks for is a short alphanumeric string that sits next to the word confluent in a line of configuration, such as a variable called CONFLUENT_API_KEY or a property with a Confluent label. It has no fixed prefix of its own, so the format alone says little. Masked, the shape is:
CONFLUENT_API_KEY=…XXXX Confluent access token (masked)
Because the string has no vendor prefix, the context does the work. A bare sixteen-character value in a file that never mentions Confluent is not the same finding as the same value sitting beside confluent. Confluent Cloud also issues a second value, the API secret, which travels with the key. A leaked file often contains both, and the secret is the half that cannot be recovered from the console later. Handle the pair as one credential.
How Confluent Access Tokens get leaked
- Client configuration committed with the cluster details. A
client.propertiesor a producer config file that holds the key next to the bootstrap server address. - Environment files. A
.envfile for a streaming service, copied into a repository because nobody added it to.gitignore. - Infrastructure code. Terraform or Helm values where the key is written in plain text instead of being read from a secret store.
- Notebooks and scripts. A quick consumer script used to test a topic, pushed along with its output.
- Build logs. A connection string printed by a debug step in a pipeline.
What to do in the first hour
- Create a replacement key first. Sign in to Confluent Cloud, open the API keys for the service account or user the leaked key belonged to, and create a new key. Confluent lets a service account hold several keys at once, so you can overlap the two while you switch over.
- Deploy the new key to your secret manager or environment variables, and confirm that producers and consumers reconnect.
- Delete the exposed key. Open it in the same API keys list and delete it. Deleting ends the key at once; any client still using it stops working, which is the point. Do not keep it around in case something breaks.
- Audit what it did. Check the cluster’s audit and metrics views for the period since the exposure. Look for connections from unknown addresses, consumer groups you do not recognize, reads from topics the service never uses, and sudden throughput spikes.
- Check the rights the key had. Look at the role bindings on the service account behind it. If it could manage topics or access control, review those permissions and remove what it did not need.
- Review other credentials in the same place. Look for database passwords, cloud keys and webhook URLs stored next to the Confluent value.
- Clean the repository. Remove the value and rewrite history if you want to. See I accidentally pushed an API key to GitHub, and use deep-scan your whole git history to catch older copies.
Not sure what else leaked? Run a free scan.
Revoke it at Confluent
Open the API keys page for your Confluent Cloud account, find the key by its name or its key ID, and delete it. Confluent treats deletion as the revocation step: there is no separate revoke action, and the key cannot be restored afterwards. Check that you are in the right environment and organization first, because a key you cannot find is often in another one. If you manage keys from the command line or through infrastructure code, delete the key there too, so the next apply does not recreate it. Confluent’s own documentation describes the same delete step for each route.
How LeakWatch detects it
The rule is called Confluent Access Token. It looks for the word confluent in a line, allows a short label and a separator such as = or :, and then expects exactly sixteen letters or digits, optionally quoted. The match is not case-sensitive. A value with the wrong length, or one with no confluent word close to it, is not reported. The severity is high. This type is not checked live: LeakWatch does not send any request to Confluent with the value it found, so a finding tells you that a value of the right shape sits next to the word, not that it still works.
LeakWatch detects this format but does not check it live: it can tell you the key is exposed, not whether it still works. Assume it does until you have revoked it.
FAQ
Does deleting the key also delete my topics or data?
No. Deleting a key only removes that credential. Topics, messages and consumer offsets stay in the cluster. What the key could do is what you lose access to.
I see only a key and no secret in the file. Is that still a problem?
Yes. The key identifies the credential, and some clients use only that value with a second secret held elsewhere. Treat the leaked value as a live credential until you have deleted it.
Will rotating the key interrupt my pipelines?
Only if you delete the old key before the new one is deployed. Create the replacement, roll it out to every producer and consumer, then delete the exposed key.