Hey folks,

We have a use case where we would like to exclude a property source containing decrypted secrets from the EnvironmentEndpoint output. Currently the only exclusion predicate is "anything not EnumerablePropertySource" which is a bit limiting for this use case (we need to keep this property source enumerable).

Do you think its a valid feature request ?

Comment From: wilkinsona

I think you could do what you want today by giving the endpoint a custom environment with the unwanted property source(s) filtered out. Something like this:

@Configuration(proxyBeanMethods = false)
class FilteredEnvironmentEndpointConfiguration {

    @Bean
    EnvironmentEndpoint environmentEndpoint(ConfigurableEnvironment environment,
            EnvironmentEndpointProperties properties,
            EnvironmentEndpointPropertySourceExcludeFilter excludeFilter) {
        MutablePropertySources propertySources = environment.getPropertySources();
        MutablePropertySources filteredPropertySources = new MutablePropertySources();
        for (PropertySource<?> propertySource : propertySources) {
            if (!excludeFilter.isExcluded(propertySource)) {
                filteredPropertySources.addLast(propertySource);
            }
        }
        EnvironmentEndpoint endpoint = new EnvironmentEndpoint(new AbstractEnvironment(filteredPropertySources) {
        });
        String[] keysToSanitize = properties.getKeysToSanitize();
        if (keysToSanitize != null) {
            endpoint.setKeysToSanitize(keysToSanitize);
        }
        String[] additionalKeysToSanitize = properties.getAdditionalKeysToSanitize();
        if (additionalKeysToSanitize != null) {
            endpoint.keysToSanitize(additionalKeysToSanitize);
        }
        return endpoint;
    }

}

interface EnvironmentEndpointPropertySourceExcludeFilter {

    boolean isExcluded(PropertySource<?> propertySource);

}

You'd also need to provide an EnvironmentEndpointPropertySourceExcludeFilter bean that did the required filtering. It's quite a bit of code, particularly as you have to mess around with the keys to sanitize configuration as well which isn't really related, so I can see some merit in making the endpoint support this sort of thing directly.

If the endpoint itself supported filtering, it could be auto-configured with any exclude filter beans. Alternatively, we could offer simple named-based filtering of property sources that could be configured via a property. It could be implemented directly by the endpoint, or via a filter implementation. Let's see what the rest of the team thinks.

Comment From: smaldini

The solution is elegant thanks @wilkinsona ! For us its a bit more complicated as we actually mutate the propSourceList quite a bit during context setup so we would have to make sure the endpoint is the last thing configured. The alternative solution was to clone the current EnvironmentEndpoint to do the filtering inline (subclassing is not enough as most of the stuff is encapsulated).

Comment From: philwebb

We discussed this a bit today on our call and we're a bit worried that removing a property source entirely could be confusing for users. @smaldini Do you want to remove the source because the property names are sensitive, or is it primarily about masking the values? If it's the latter then we wondered is some kind of pluggable Sanitizer interface might be better? We were thinking of a callback that gets given the existing source, name and value and can return true to sanitize the value.

We already support this approach, but you can currently only configure name based patterns.

Comment From: philwebb

Something else to watch out for is /actuator/configprops. I think that might display bound values which could be from the encrypted source.

Comment From: spring-projects-issues

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

Comment From: spring-projects-issues

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.

Comment From: philwebb

@smaldini have you had a chance to consider if the custom sanitizer hook idea would work for you?

Comment From: spring-projects-issues

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

Comment From: spring-projects-issues

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.