Securing a database password

For additional security, you can protect the database password that Jira uses to access your database, which is stored in the configuration file. We’ve prepared different encryption methods from basic to advanced. Additionally, you can create your own encryption mechanism based on our SecretStore interface.

Secret storage

Starting from Jira 10.2, we're using the secret storage to secure the database password.

After the upgrade, or during the zero-downtime upgrade (ZDU), we'll read the password from the dbconfig.xml file, encrypt it, store it in the secret storage and replace the password in the dbconfig.xml file with the placeholder: {ATL_SECURED}. If the password was previously stored in plaintext, you can expect the following logs:

 main INFO      [c.a.j.config.database.DatabaseConfigHandler] Secret Service is enabled
 main INFO      [c.a.j.config.database.DatabaseConfigHandler] Detected new password in the xml file, that hadn't been encrypted by Secret Service
 main INFO      [c.a.j.config.database.DatabaseConfigHandler] Trying to get password from xml and decrypt it with legacy Secret Store Provider
 main INFO      [c.a.j.config.database.DatabaseConfigHandler] Database password decryption not performed.
 main INFO      [c.a.j.config.database.DatabaseConfigHandler] Getting plaintext password from config, encrypting it and storing in Secret Service.
 main INFO      [c.a.j.config.database.DatabaseConfigHandler] Secret Service is enabled
 main INFO      [c.a.j.config.database.DatabaseConfigHandler] Storing encrypted database password in Secret Service
 main INFO      [c.a.j.config.database.DatabaseConfigHandler] Replacing the password in config with {ATL_SECURED}

and the dbconfig.xml file will contain: <password>{ATL_SECURED}</password>

In case of a ZDU rollback, you need to edit the dbconfig.xml file on every node that was upgraded and change the password back to the plaintext password.

If the password was secured with the Secret Store Provider, we store the secret in the secret storage, but we don’t replace the password in the dbconfig.xml file and we use the secret store provider to encrypt and decrypt password.

Since Jira 10.2.1:

• If the password was encrypted with the Secret Store Provider, the AES encryption, or a custom implementation, we'll decrypt the password, store it in the secret storage and replace the password in the dbconfig.xml file with {ATL_SECURED}.
• If the password was encrypted with the Secret Store Provider, the AWS Secrets Manager, or HashiCorp Vault, we'll keep it as the encryption method and won’t use the secret storage for handling the password.

AWS Secrets Manager

AWS Secrets Manager provides a high-level secure storage option for your database credentials. This service retrieves credentials through a runtime call, eliminating hard-coded credentials, such as keys and tokens, altogether.

Learn more about AWS Secrets Manager for encryption

HashiCorp Vault

HashiCorp Vault is a tool that secures, stores, and controls access to sensitive data such as passwords, tokens, and keys. It acts like a digital safe, keeping your secrets locked away from unauthorized users while being readily available to services with the right permissions.

Learn more about HashiCorp Vault for encryption