Mask DB Passwords With WildFly Elytron

September 20, 2019

By default, passwords for datasources in WildFly are stored in cleartext in the config file. If the server on which WildFly is running has limited access, this may be acceptable. However, if portions of a config file like standlone.xml end up being passed around or stored in configuration management, this can expose sensitive data. This article presents a strategy for dealing with the mishandling of the XML that might expose a password.

A WildFly Elytron Credential Store in WildFly is a Java Keystore that contains protected name / value pairs. This data is encrypted and unlocked with a password that is set in the configuration file like standalone.xml. With Elytron, you can create the Keystore, add name/value pairs, update values, retrieve values, and list keys. This last capability is a big help in troubleshooting. "Legacy Vault" forced you to for specific values so it was tough to check misspellings.

Since the Credential Store password is in cleartext and the Keystore is likely close by, this does not help much with unauthorized access. There are some mechanisms to mask the password. The value in this article is to prevent an exposure of a database password to those who might come into contact with the WildFly config file (say a snippet posted to an online forum).

The procedure starts with creating the Credential Store. There is a dedicated tool for working with Credential Stores. This can be useful to make out-of-band edits to the Credential Store outside of WildFly. We'll work with the Management Console. Navigate to Configuration > Security Elytron > Other Settings > View.

Next, press the Add button. Name the Credential Store, specify a file name (Location) and directory (Relative To), set the cleartext password. Remember to also flip the Create switch to ON.

To add a name / value pair to the Credential Store, you'll need to switch to the Runtime Security Elytron screen from Configuration Security Elytron Screen. Go to Runtime > Security Elytron > View.

Select the Credential Store and press Aliases.

Press the Add button and set the name / value pair. Remember the name used for Alias as you'll be applying it in the next step.

Navigate back to Configuration, this time to Datasources & Drivers. Select your datasource and press the View button. Go to the Security tab and Edit and remove the contents of the password field. Don't Reload (yet) if prompted.

Go to the Credential Reference tab. Press the Add button in the center of the screen. Select your Credential Store and specify the alias key created in the previous step. (In my case, this is a user-created value "db-password").

Finally, test the data source by backing up and selecting the Test Connection button on the datasource. If the test passes, you can reload your app server.

These procedures don't directly prevent an unauthorized user from getting access to a database password. While you can't read values from a Keystore from Java keytool, it's trivial to write a program that can. An unauthorized user can easily parlay the cleartext Credential Store credential taken from a config file into a database password stored in a Keystore nearby.

However, there is value to using a Credential Store. If external consultants or other people are brought in to troubleshoot a WildFly configuration, say on a video conference, they can review the actual WildFly configuration without seeing a database password. These viewers might see the cleartext Credential Store password, but unlike a remotely accessible database server, the store file access is restricted. The level of effort in this sequence of steps is small and WildFly support for maintaining the external source is much better than Legacy Vault.

---