Secure secrets configuration properties
Starting from Jira 10.2, we're using the secret storage to secure the database password.
On this page:
Secure 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.xmlfile 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.
OpenSearch basic authentication credentials
Starting from Jira 11.2, OpenSearch credentials are secured using secret storage.
When you use basic authentication to connect Jira to OpenSearch, the username and password are stored in the jira-config.properties file. After you upgrade Jira, or during a zero-downtime upgrade (ZDU), Jira reads the username and password from the jira-config.properties file, encrypts them, and stores them in secret storage. Jira then replaces the username and password in the jira-config.properties file with the placeholder {ATL_SECURED}.
Jira must have write access to the jira-config.properties file in the local Jira home directory on each node for this feature to work. How to edit the jira-config.properties file in Jira Data Center