4. Manage passwords¶
This is a part of the Charmed Apache Kafka Tutorial.
Passwords help to secure the Apache Kafka cluster and are essential for security.
Over time it is a good practice to change the password frequently.
Here we will go through setting and changing the password both for the built-in user
and external Charmed Apache Kafka users managed by the data-integrator.
The built-in user¶
The built-in admin user (operator) password management is handled directly by the charm,
by using Juju actions.
Retrieve the password¶
As a reminder, the admin password is stored in a Juju secret that was created and managed by
the Charmed Apache Kafka application. The password in in the operator-password field.
Get the current value of the admin user password from the secret:
juju show-secret --reveal cluster.kafka.app | yq -r '.[].content["operator-password"]'
Change the password¶
You can change the admin password to a new password by creating a new Juju secret, and updating the Charmed Apache Kafka application of the correct secret to use.
First, create the Juju secret with the new password you wish to use:
juju add-secret internal-kafka-users admin=mynewpassword
Note the generated secret ID that you see as a response.
It will look something like secret:d5nc29hlshbc45lnf07g.
Now, grant Charmed Apache Kafka access to the new secret:
juju grant-secret internal-kafka-users kafka
Finally, inform Charmed Apache Kafka of the new secret to use for it’s internal system users using the secret ID saved earlier:
juju config kafka system-users=secret:d5nc29hlshbc45lnf07g
Now, Charmed Apache Kafka will be able to read the new admin password from the correct secret, and will proceed to apply the new password on each unit with a rolling-restart of the services with the new configuration.
External Apache Kafka users¶
Unlike internal user management of the built-in admin user, the password management for external Apache Kafka users is instead managed using relations. Let’s see this into play with the Data Integrator charm, that we have deployed in the previous part of the tutorial.
Retrieve the password¶
The data-integrator exposes an action to retrieve the credentials:
juju run data-integrator/leader get-credentials
Output example
Running the command should output:
kafka:
consumer-group-prefix: relation-8-
data: '{"resource": "test-topic", "salt": "yOIRb9uVUuJuKFVc", "extra-user-roles":
"producer,consumer", "provided-secrets": ["mtls-cert"], "requested-secrets": ["username",
"password", "tls", "tls-ca", "uris", "read-only-uris", "entity-name", "entity-password"]}'
endpoints: 10.157.174.225:9092,10.157.174.59:9092,10.157.174.62:9092
password: RdRjZkXUC3dAb5VRFw2470fnoKrsRIXU
resource: test-topic
salt: W34UoIPzckdMJ6DU
tls: disabled
topic: test-topic
username: relation-8
version: v0
ok: "True"
Rotate the password¶
The easiest way to rotate user credentials using the data-integrator is by removing
and then re-integrating the data-integrator with the kafka charm:
juju remove-relation kafka data-integrator
Wait for the relation to be torn down and add integration again:
juju integrate kafka data-integrator
The successful credential rotation can be confirmed by retrieving the new password
with the action get-credentials:
juju run data-integrator/leader get-credentials
Output example
Running the command should now output a different password:
kafka:
consumer-group-prefix: relation-9-
data: '{"resource": "test-topic", "salt": "iGWWWoUwCy39ou6f", "extra-user-roles":
"producer,consumer", "provided-secrets": ["mtls-cert"], "requested-secrets": ["username",
"password", "tls", "tls-ca", "uris", "read-only-uris", "entity-name", "entity-password"]}'
endpoints: 10.157.174.225:9092,10.157.174.59:9092,10.157.174.62:9092
password: EEiI2gboTp2dF0NOcogtbrOWBTxkd5YB
resource: test-topic
salt: 7WqLjlZjeUvlEWrA
tls: disabled
topic: test-topic
username: relation-9
version: v0
ok: "True"
To rotate external passwords with no or limited downtime, see the how-to guide on app management.
Remove the user¶
Removing the relation automatically removes the user that was created when the relation was created. To remove the user, remove the relation:
juju remove-relation kafka data-integrator
Output example
The output of the Juju model should be something like this:
Model Controller Cloud/Region Version SLA Timestamp
tutorial overlord localhost/localhost 3.6.20 unsupported 17:12:02Z
App Version Status Scale Charm Channel Rev Exposed Message
data-integrator blocked 1 data-integrator latest/stable 362 no Please relate the data-integrator with the desired product
kafka 4.1.1 active 3 kafka 4/stable 248 no
kraft 4.1.1 active 3 kafka 4/stable 248 no
Unit Workload Agent Machine Public address Ports Message
data-integrator/0* blocked idle 6 10.157.174.36 Please relate the data-integrator with the desired product
kafka/0* active executing 0 10.157.174.225 9092,19093/tcp
kafka/1 active executing 1 10.157.174.62 9092,19093/tcp
kafka/2 active executing 2 10.157.174.59 9092,19093/tcp
kraft/0* active idle 3 10.157.174.228 9098/tcp
kraft/1 active idle 4 10.157.174.127 9098/tcp
kraft/2 active idle 5 10.157.174.24 9098/tcp
Machine State Address Inst id Base AZ Message
0 started 10.157.174.225 juju-29b29f-0 ubuntu@24.04 kafka-test Running
1 started 10.157.174.62 juju-29b29f-1 ubuntu@24.04 kafka-test Running
2 started 10.157.174.59 juju-29b29f-2 ubuntu@24.04 kafka-test Running
3 started 10.157.174.228 juju-29b29f-3 ubuntu@24.04 kafka-test Running
4 started 10.157.174.127 juju-29b29f-4 ubuntu@24.04 kafka-test Running
5 started 10.157.174.24 juju-29b29f-5 ubuntu@24.04 kafka-test Running
6 started 10.157.174.36 juju-29b29f-6 ubuntu@24.04 kafka-test Running
Note
The operations above would also apply to charmed applications that implement
the kafka_client relation, for which password rotation and user deletion
can be achieved in the same consistent way.
What’s next?¶
In the next part, we will now see how easy it is to enable encryption across the board, to make sure no one is eavesdropping, sniffing or snooping your traffic by enabling TLS.