Implement uniform password "encryption/decryption" mechanism

[ppkarwasz]

Many of Log4j components require a password attribute (e.g. SslConfiguration, JdbcAppender, etc.), but only BasicAuthorizationProvider uses a pluggable PasswordDecryptor service to interpret the meaning of the password field.

I would propose to extend the usage of this service to all password fields and provide two implementations of PasswordDecryptor:

• one implementation that interprets the "password" as the path to a file that contains the password,
• one implementation that interprets the "password" as the name of an environment variable that contains the password.

This would allow us to deprecate configuration properties such as log4j2.keyStorePasswordFile and log4j2.keyStorePasswordEnvironmentVariable.

Disclaimer: I am fully aware that a real password encryption/decryption mechanism doesn't make sense, since configuration sources must be trusted anyway and I totally agree with the remarks about password encryption on Tomcat's Wiki.

However some auditors and analysis tools might have problems with plain text passwords in configuration files and this feature will allow users to provide their own workarounds.

[rgoers]

FYI, in our configurations we use something like this in our Spring application's bootstrap.yml. This allows us to retrieve our logging configuration, with overrides, from our Spring Cloud Config Service. Note that the user name and password specified in bootstrap.yml ONLY work for developer testing on their laptop. When deployed we specify the spring username and password via system property overrides on the command line.Those are stored in a vault and accessed only from the deployment scripts. SCC supports Basic authentication. In other words, in my case I would have no use for the password decryptor as whatever we do has to be supported by Spring.

spring:
  application:
    name: my-application-service
  cloud:
    config:
      uri: https://spring-configuration-server.apache.foundation
      username: my-user@serviceuser.apache.foundation
      password: 123Abc!@#


logging:
  config: classpath:log4j2-console.yml
  label: ${spring.cloud.config.label:master}
  auth:
    username: ${spring.cloud.config.username}
    password: ${spring.cloud.config.password}

---
spring:
  config:
    activate:
      on-profile: local

---
spring:
  config:
    activate:
      on-profile: dev
  cloud:
    config:
      uri: https://spring-configuration-server.apache.foundation

logging:
  config: "https://spring-configuration-server.apache.foundation/my-application-service/default/${logging.label}/log4j2-json-dev.xml"
  log4j2:
    config:
      override: "https://spring-configuration-server.apache.foundation/my-application-service/default/${logging.label}/log4j2-my-application-service-dev.xml"

[ppkarwasz]

@rgoers,

So it seems that the most uniform way to provide passwords is to either provide them literally or use a lookup?

Should we deprecate PasswordDecryptor and the alternative ways to provide a password for the key stores?