-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement uniform password "encryption/decryption" mechanism #2558
Comments
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.
|
So it seems that the most uniform way to provide passwords is to either provide them literally or use a lookup? Should we deprecate |
@ppkarwasz Sorry, I should have replied sooner. In the case of Spring the passwords are encrypted in the configuration and specified as {cipher}some_encrypted_string. When the app gets them all the ciiphers have been converted to clear text. But Spring certainly isn't the only thing around and not everyone uses Spring Cloud Config. But this is also about more than configuration. If you look at PostMan's authorization tab it lists a dozen or so mechanism for authenticating. This is why we have an AuthorizationProvider. In the default case we just populate the Authorization header using Basic Auth with the credentials. But other mechanisms might do much more than that. For example, with OAuth a token will have to be retrieved using the client's credentials, client id, and client secret. along with a couple of urls. My suggestion would be to a) ensure AuthorizationProvider has sufficient methods and b) ensure it is being used wherever authentication needs to be performed. |
[I remember writing a longer comment on this issue but I might have forgotten to press the "Comment" button] I agree that
|
Many of Log4j components require a password attribute (e.g.
SslConfiguration
,JdbcAppender
, etc.), but onlyBasicAuthorizationProvider
uses a pluggablePasswordDecryptor
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
:This would allow us to deprecate configuration properties such as
log4j2.keyStorePasswordFile
andlog4j2.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.
The text was updated successfully, but these errors were encountered: