Allow JNDI as a mpConfig configuration source to allow encryption of secrets

[bmarwell]

Describe the use case that you want to enable:

Currently, it is not clean whether any configuration source can benefit from the liberty encryption. If this was possible, the secrets could be stored on disk in an encrypted way.

I know JNDI properties can be encrypted, so let's add JNDI to the existing ones:

• 600 - server.xml -> appProperties -> property
• 500 - server.xml -> variable
• 400 - jvm.options
• 300 - server.env
• 100 - File META-INF/microprofile-config.properties
• 1- server.xml -> variable with defaultValue

Source: https://openliberty.io/docs/latest/external-configuration.html

The idea is to add two things:

First idea

• 550 - server.xml -> jndiEntry

e.g.:

<server>
   <jndiEntry jndiName="schoolOfAthens/defaultAdminPassword" value="{aes}encryptedValue=" />
</server>

Then make it available via:

@Dependent
class SomeService {

  @Inject
  @ConfigurationProperty( ... )
  private  byte[] password;

}

Example taken from: https://openliberty.io/docs/latest/reference/feature/jndi-1.0.html

second idea

Add a column to https://openliberty.io/docs/latest/external-configuration.html whether values can be stored encrypted or not.

Describe why this is important to you:

Currently, the docs (https://openliberty.io/docs/latest/external-configuration.html) don't mention whether any of those can be stored encrypted (e.g. using securityUtility encode).

While this is not a sufficient encryption to stop hackers, it is better to not store passwords in plain text anyway. The docs should also link to: https://openliberty.io/docs/latest/password-encryption.html

Additional context

./.

[tevans78]

@bmarwell Are you requesting to specifically create a built in Config Source for JNDI Entries? Or is this a generic enhancement request that any Liberty server.xml Config Source should be able to handle encoded values?

Note that the server.xml docs already state if a value can be encoded. If the docs do not mention encoding then it isn't supported. jndiEntry has a decode attribute but many others call it out in their description (e.g. containerAuthData password).

[bmarwell]

@bmarwell Are you requesting to specifically create a built in Config Source for JNDI Entries? Or is this a generic enhancement request that any Liberty server.xml Config Source should be able to handle encoded values?

No, my idea is to make it only mpConfig-related and add it as a mpConfig resource.

create a built in Config Source

... can I create one myself without creating a user feature?

but many others call it out in their description

Maybe there should be an overview page where attributes can be encrypted/encoded/hashed, i.e. which configuration items support this. But that would be another issue and not part of this one, which merely requests to add a built-in mpConfig source.

[tevans78]

OK so this issue is going to be for

• Adding a built-in MicroProfile Config Source which makes JNDI Entries available from Liberty's server.xml configuration
• If the decode attribute is true then the value will be decoded before use

[bmarwell]

Yes! Here's some more context about the idea.

• system properties are potentially visible to other users
• in the past, the same was true for environment variables (not anymore, luckily). But they are still for root or might be exposed by security scanners, APMs etc.
• neither of those are encryptable/decodable
• The file is somewhat hard to patch because it is shipped with the application.
• server variables and application variables are neither easy to set via includes (am I right here?) nor encryptable/decodable
• ... nor are they accessible via other means, as are the other options (System.getProperty, System.env etc.).

JNDI variables would solve all of those problems:

• encryptable/decodable
• easy to set via include (top level)
• easy to set in both legacy and container environments
• they are not exposed in the process list nor in the environment

Does that make sense? If so, maybe we could make this a blog entry. This is only possible because Eclipse mpConfig was designed to allow different config sources, which is brilliant (in this case).

Let me know whether my assumptions are correct :)