JBoss EAP simplifies a lot of server configuration by consolidating all subsystem configurations into a single XML file (standalone.xml or domain.xml). This, however, can expose sensitive information to any user that has access to the configuration files. For example, datasource credentials are by default stored in plain text in the XML file. In this blog I will show you how to protect your passwords!
What is the vault password?
The vault encrypts sensitive strings, stores them in an encrypted keystore, and decrypts them for applications and verification systems. To avoid leaving sensitive credentials readable in the standalone.xml or domain.xml files, you can store passwords or other attributes in the vault and then reference the vault from within the server configuration file.
Using a vault creates a level of abstraction and obfuscates data which could otherwise be read by anyone who has access to the configuration files. Please note that the access to the configuration files should be anyway restricted.
Create a Java Keystore to store sensitive strings
The vault utilizes a keystore by using the certificate stored in the keystore as an encryption key for the vault as a whole. To initialize the vault, users need to first create the JavaSE keystore. The following is the syntax used to create a private key, a certificate and to store them in a keystore:
keytool -genseckey -alias <alias> -keyalg <algorithm> -storetype <type> -keysize size -keystore <filepath>
- alias: The alias is a unique identifier for the vault or other data stored in the keystore.
- keyalg: The algorithm to use for encryption.
- storetype: The keystore type. jceks is the recommended type.
- keysize The size of the encryption key which determines the difficulty in brute forcing the
key. - keystore: The file path and file name in which the keystore’s values are stored.
The below is an example:
[jboss@vmjboss jboss]# keytool -genseckey -alias vault -keyalg AES -storetype jceks -keysize 128 -keystore /app/jboss/vault.keystore
Enter keystore password:
Re-enter new password:
Enter key password for <vault>
(RETURN if same as keystore password):
Warning:
The JCEKS keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is an industry standard format using "keytool -importkeystore -srckeystore /app/jboss/vault.keystore -destkeystore /app/jboss/vault.keystore -deststoretype pkcs12".
[jboss@vmjboss jboss]# ls -rtl /app/jboss/
total 4
-rw-r--r-- 1 jboss jboss 500 Sep 4 10:56 vault.keystore
After running the command, you will be prompted for a keystore password and a keystore file will be created at /app/jboss/vault.keystore.
Using the vault
The vault can be initialized either interactively, by providing each parameter one at a time, or by providing all of the parameters initially.
The following is an example of the syntax used to initialize the vault:
vault.sh --keystore KEYSTORE_URL --keystore-password KEYSTORE_PASSWORD --alias KEYSTORE_ALIAS --vault-block VAULT_BLOCK --attribute ATTRIBUTE --sec-attr SEC-ATTR --enc-dir ENC_FILE_DIR --iteration ITERATION_COUNT --salt SALT
The following parameters are required to initialize the vault:
- KEYSTORE_URL: The path to the previously created keystore file.
- KEYSTORE_PASSWORD: The password to access the keystore that was used at the keystore’s
creation. - SALT: A random string of eight characters used to encrypt the attribute stored in the vault.
- KEYSTORE_ALIAS: The alias that identifies the certificate stored in the keystore.
- ITERATION_COUNT: The number of times encryption is run.
- ENC_FILE_DIR: The path where the encrypted files are stored.
- VAULT_BLOCK: The name to be given to the block in the vault.
- ATTRIBUTE: The name of the attribute being stored. For example, “password” as an attribute
name when storing a password value. - SEC-ATTR: The value being stored.
The following is an example with the parameters populated:
[jboss@vmjboss bin]# vault.sh --keystore /app/jboss/vault.keystore --keystore-password password --alias vault --vault-block blog --attribute password --sec-attr blogpass --enc-dir /app/jboss/ --iteration 50 --salt 12345678
After running the vault.sh command, an XML definition of the vault is displayed, which needs to be added to the server configuration files. The following is an example of the XML that needs to be added to either the standalone.xml or host.xml configuration file directly before the section:
<vault>
<vault-option name="KEYSTORE_URL" value="/app/jboss/vault.keystore"/>
<vault-option name="KEYSTORE_PASSWORD" value="MASK-31x/z0Xn83H4JaL0h5eK/N"/>
<vault-option name="KEYSTORE_ALIAS" value="vault"/>
<vault-option name="SALT" value="12345678"/>
<vault-option name="ITERATION_COUNT" value="50"/>
<vault-option name="ENC_FILE_DIR" value="/app/jboss/"/>
</vault>
The final step is to replace the sensitive data with a reference to the attribute in the vault. The vault.sh command provides the exact syntax necessary to reference the secured attribute after all of the parameters are provided. Using the previous example, the vault command generated the following:
VAULT::blog::password::1
In order to use this reference, use the following syntax within the server configuration:
${VAULT::VAULT_BLOCK::ATTRIBUTE_NAME::1}
The following can replace the previous password in the server configuration for the blog datasource password:
${VAULT::blog::password::1}
After replacing the password for the datasource, the server configuration for the datasource will look similar to the following:
<datasource jndi-name="java:jboss/datasources/blogope" ...>
<connection-url>...</connection-url>
<driver>mysql</driver>
<security>
<user-name>blogadmin</user-name>
<password>${VAULT::blog::password::1}</password>
</security>
</datasource>
In this blog we saw how to protect passwords or any sensitive data in configuration files. Don’t forget to restrict the access to your configuration files also!
Don’t hesitate to comment this blog, for any question or to share your experience with vault within JBoss EAP.
Some blogs around JBoss EAP:
Terry
18.09.2024Hi David,
I have clarification that need your help on the genseckey parameter below. This just generated a secret key with keyalg AES and keysize of 128 with alias vault in the keystore. and did not encrypted the whole vault.keystore yet. Am I correct?
[jboss@vmjboss jboss]# keytool -genseckey -alias vault -keyalg AES -storetype jceks -keysize 128 -keystore /app/jboss/vault.keystore
Only thru this vault command that the clear-text passwords / credentials that are currently stored in the vault.keystore got encrypted with the secret key and can only be decrypted via the same secret key?
[jboss@vmjboss bin]# vault.sh --keystore /app/jboss/vault.keystore --keystore-password password --alias vault --vault-block blog --attribute password --sec-attr blogpass --enc-dir /app/jboss/ --iteration 50 --salt 12345678
Sample output from other website, it showed a shared key, why is it so as from your example there is no shared key?
Vault Block:blockName
Attribute Name:mysql
Shared Key:N2NhZDYzOTMtNWE0OS00ZGQ0L
Configuration should be done as follows:
VAULT::blockName::mysql::N2NhZDYzOTMtNWE0OS00ZGQ0L
Also i want to clarify on the new jboss EAP KeyStoreCredentialStore (credential-store) and PropertiesCredentialStore (secret-key-credential-store) as we can create secret key in KeyStoreCredentialStore (credential-store) similar to PropertiesCredentialStore (secret-key-credential-store). My qns is, this secret key created in credential-store does not encrypt contents in the credential-store and is used as initial key for unlock server resources? The credential-store is not encrypted by this secret key and it is used to secure senstive string with encryted expressions?
As the legacy vault allows the encryption of clear-text passwords using vault.sh command above, why is the newer credential-store like a step backward in term of encryption of passwords?
Kindly assist to clear my doubts as i have been looking for explanations in redhat and wildfly websites but seems not able to get it.
Cheers
David Diab
18.09.2024Hi Terry,
There is a lot of confusion regarding this topic in the documentation, so I understand your point.
Fortunately, I have experience on this topic and I can help you without issue.
Which JBoss EAP version you have?
Following your question, for me you are mixing two ways to encrypt sensitive strings outside of configuration files. These strings can be stored in a keystore, and subsequently decrypted for applications and verifications systems. Sensitive strings can be stored in either of the following:
Credential Store - Introduced in JBoss EAP 7.1, a credential store can safely secure sensitive and plain text strings by encrypting them in a storage file. Each JBoss EAP server can contain multiple credential stores. This one hasn't been explained in my blog.
Password Vault - Primarily used in legacy configurations, a password vault uses a Java Keystore to store sensitive strings outside of the configuration files. Each JBoss EAP server can only contain a single password vault. My blog is based on this method.
The credential Store has been introduced with 7.1 version, with Elytron subsytem.
Don't hesitate to contact me directly on LinkedIn to discuss more about this topic.
Cheers,
David