You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This will I think be an enhancement request somewhat related but different from #6876 (and #6903).
As mentioned on the Spring Cloud Gitter, I would like to mask the password for MongoDB in the /env and /configprops Actuator endpoints. Mongo essentially requires using the spring.data.mongodb.uri for multiple hosts, so spring.data.mongodb.password cannot be used.
Since I am using Spring Cloud Config and want to encrypt the MongoDB password, I am using a separate property for that (mongo.password in the snippets below). I then use this variable as a placeholder in spring.data.mongodb.uri. This works well, but I would still need to add uri to the list of keys to sanitize to avoid leaking the password as shown below.
It would be a useful enhancement if placeholders of properties to be sanitized were not resolved and instead masked.
Here is a snippet from GET /env
The mongo.password property is sanitized since it ends in password, and from here placeholders are not resolved, so everything is fine.
When retrieving the value for a specific property from the /env endpoint, currently the placeholders are unconditionally resolved as follows. GET /env/spring.data.mongodb.uri
With this ticket's requested enhancement, the placeholder ${mongo.password} will be masked because it is a key to be sanitized (endpoints.env.keys-to-sanitize) GET /env/spring.data.mongodb.uri
I think it should be possible to improve this for the env endpoint, and it may be something that we want to look at in a maintenance release.
I'm not sure what we can do for a @ConfigurationProperties bean as the fact that placeholders were involved in configuring a property's value is lost by the time the beans are being queried. We are hoping to provide some provenance for configuration properties in 2.0 so this may become possible as part of that, although I'm not sure how likely that is.
Can you please open a separate issue for /configprops so that we can consider these two changes individually?
wilkinsona
changed the title
Mask sensitive placeholders in /env and /configprops endpoints
Mask sensitive placeholders in for specific properties in /env endpoint
Feb 14, 2017
wilkinsona
changed the title
Mask sensitive placeholders in for specific properties in /env endpoint
Mask sensitive placeholders for specific properties in /env endpoint
Feb 14, 2017
Uh oh!
There was an error while loading. Please reload this page.
This will I think be an enhancement request somewhat related but different from #6876 (and #6903).
As mentioned on the Spring Cloud Gitter, I would like to mask the password for MongoDB in the
/env
and/configprops
Actuator endpoints. Mongo essentially requires using thespring.data.mongodb.uri
for multiple hosts, sospring.data.mongodb.password
cannot be used.Since I am using Spring Cloud Config and want to encrypt the MongoDB password, I am using a separate property for that (
mongo.password
in the snippets below). I then use this variable as a placeholder inspring.data.mongodb.uri
. This works well, but I would still need to adduri
to the list of keys to sanitize to avoid leaking the password as shown below.It would be a useful enhancement if placeholders of properties to be sanitized were not resolved and instead masked.
Here is a snippet from
GET /env
The
mongo.password
property is sanitized since it ends inpassword
, and from here placeholders are not resolved, so everything is fine.When retrieving the value for a specific property from the
/env
endpoint, currently the placeholders are unconditionally resolved as follows.GET /env/spring.data.mongodb.uri
With this ticket's requested enhancement, the placeholder
${mongo.password}
will be masked because it is a key to be sanitized (endpoints.env.keys-to-sanitize
)GET /env/spring.data.mongodb.uri
The above applies to the
/configprops
endpoint also.The text was updated successfully, but these errors were encountered: