Securing a database password in Jira Service Management
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.
The solutions outlined below provide a level of protection for encrypting database values, but do not offer complete security. The configuration files will still contain the necessary data to decrypt the values, which means that an attacker with access to these files could potentially decrypt the property values.
These approaches are intended to provide an additional layer of protection against accidental exposure of sensitive data but should not be relied upon as a comprehensive security solution.
We recommend that you secure the server where Jira and the database reside.
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.