This is the second of the two part blog on managing secrets in Kubernetes with Vault. In this blog, we explore dynamic secrets.
Secrets support updates. Take your password; it is a good practice to periodically change it. How does your application know that the secret (password) has changed? Kubernetes will refresh the secret for you, but there is no built-in mechanism to indicate to the application that the secret has changed. You can roll some of these features yourself, such as doing checksum, and bouncing or deleting a Pod and then re-creating it. Especially in the high availability world, that is not usually desired for a lot of applications. This is where a dynamic secret engine helps you to auto rotate your secret.
Vault’s database secrets engine generates database credentials dynamically based on user-defined roles. The database administrator can pre-define the time-to-live (TTL) of the database credentials to enforce its validity and automatically revoke when they expire or are no longer in use.
docker run -d
-p 0.0.0.0:27017:27017 -p 0.0.0.0:28017:28017
–name=mongodb
-e MONGO_INITDB_ROOT_USERNAME=”mdbadmin”
-e MONGO_INITDB_ROOT_PASSWORD=”hQ97T9JJKZoqnFn2NXE”
mongo
Login inside Vault server with root
Give root token from cluster master key file.
We will configure the MongoDB secrets engine and create a “tester” role with read and write permissions.
The database secrets engine is enabled at mongodb/.
The database secrets engine supports many databases through a plugin interface. To use a MongoDB database with the secrets engine requires further configuration with the mongodb-database-plugin plugin and connection information.
vault write mongodb/config/mongo-test
plugin_name=mongodb-database-plugin
allowed_roles=”tester” connection_url=”mongodb://{{username}}:{{password}}@127.0.0.1:27017/admin?tls=false”
username=”mdbadmin”
password=”hQ97T9JJKZoqnFn2NXE”
A role is a logical name within Vault that maps to database credentials. In this step, we are creating a “tester” role with TTL set to 1 hour, and the maximum TTL is 24 hours. This allows Vault to revoke the credentials automatically once they reach the TTL.
Create the role named tester.
Verify that the tester role exists.
To connect to the MongoDB, Vault clients request Vault to dynamically generate the database credentials based on its role, in this case, the tester role.
Read credentials from the tester database role.
We can validate this by logging into mongodb with these credentials for the admin database.
Validation
mongodb://mongo-test-tester-6W3YLBNE:-uRGuXdpTck0OIgAzMpe@localhost:27017/?authSource=admin
Create a clients policy.
vault policy write clients -<<EOF
# Required: Get credentials from the database secrets engine for ‘tester’ role.
path “mongodb/creds/tester” {
capabilities = [ “read”, “update”]
}
Create a token with the clients policy attached.
Update the mongo-test connection configuration to specify that the generated database username should have the format of mongo-<role_name>-<random_char_length_8>.
vault write mongodb/config/mongo-test
plugin_name=mongodb-database-plugin
allowed_roles=”tester” connection_url=”mongodb://{{username}}:{{password}}@13.127.237.6:27017/admin?tls=false”
username=”mdbadmin”
password=”hQ97T9JJKZoqnFn2NXE”
username_template=”mongo-test-{{.RoleName}}-{{random 8}}”
The username_template parameter specifies the username format (“mongo-test-{{.RoleName}}-{{random 8}}”). The {{.RoleName}} returns the role name (tester) used to request a lease. The {{random 8}} returns 8 random characters.
Request a new set of credentials.
Follow us on our LinkedIn Page. To know more about our services, visit our website.
CloudifyOps Pvt Ltd, Ground Floor, Block C, DSR Techno Cube, Survey No.68, Varthur Rd, Thubarahalli, Bengaluru, Karnataka 560037
Indiqube Vantage, 3rd Phase, No.1, OMR Service Road, Santhosh Nagar, Kandhanchavadi, Perungudi, Chennai, Tamil Nadu 600096.
CloudifyOps Inc.,
200, Continental Dr Suite 401,
Newark, Delaware 19713,
United States of America
