See the discussion here. Specifically this comment from @dsyer
Another example. To secure only the actuator endpoints used to be a one liner in a config file: security.basic.enabled=false. Now I need this (in addition to the UserDetails bean):
@Configuration
public class ActuatorSecurityConfigurer extends WebSecurityConfigurerAdapter {
@Override
public void configure(HttpSecurity http) throws Exception {
http
.authorizeRequests()
.requestMatchers(EndpointRequest.to("status")).permitAll()
.requestMatchers(EndpointRequest.to("info")).permitAll()
.requestMatchers(EndpointRequest.toAnyEndpoint()).hasRole("ACTUATOR")
.antMatchers("/**").permitAll()
.and()
.httpBasic();
}
}
It's too much boilerplate IMO.
I don't think we should go back to the situation where we have a separate WebSecurityConfigurerAdapter for management endpoints. That being said, we can provide a simpler way to restore what the previous defaults which essentially means reducing this to something simpler.
.authorizeRequests()
.requestMatchers(EndpointRequest.to("status", "info")).permitAll()
.requestMatchers(EndpointRequest.toAnyEndpoint()).hasRole("ACTUATOR")
Copying my comment https://github.com/spring-projects/spring-boot/issues/7958#issuecomment-343193239 from the previous issue to ensure it is remembered when this issue is looked at:
how about an
@EnableActuatorSecurityannotation
If we do provide deeper integration with Actuator and Security, I would not do this via an annotation as this provides little value as soon as the user needs to provide any sort of customization. Instead, I'd lean towards providing something that hooks into the Spring Security DSL. In its simplest form it might look something like this:
http
.apply(actuatorSecurity()).and()
... any customization ...;
Likely under the covers actuatorSecurity() would use the same RequestMatcher implementations that already exist. There would be properties on actuatorSecurity() to customize the defaults. Since users also have access to HttpSecurity they would have full control over how security was configured.
Not sure if I should hijack this issue or create a new one, but please also make it easy to intercept (and thus secure) requests to actuator endpoints.
I use a HandlerInterceptor to secure access to the regular api endpoints of my app, running on 2.0.0-M7 (using custom security, not based on spring-security). For a reason that I can't explain (and that the doc doesn't seem to explain), the interceptor is not called for actuator endpoints. And I haven't found any way to add an interceptor for actuator endpoints. Why don't these endpoints behave as regular MVC endpoints? How can I intercept them?
Not sure if I should hijack this issue or create a new one
Create a new one please, this arguably is an unrelated topic.
Thanks @snicoll. See #11234
@ronanquillevere we don't use the tracker for questions. Please ask on StackOverflow or join us on Gitter.
On the topic of simplifying actuator config, EndpointRequest.toAnyEndpoint() doesn't include the base-path (/actuator), which lists all the available endpoints. Could the base-path be included in toAnyEndpoint()?
@merusso I've created a new issue for this. See #12353
Hi All,
I am trying to build a rest api with spring boot, I want to secure only the actuator end points keeping others open. I am trying to do that with below code but itdoesnot seem to work. It is not asking for username/password. or doesnot throw 403 if I donot pass the credentials. What is the exact configuration I am missing here.
Spring boot: 2.1.2.RELEASE
application.yml
security:
user:
name: admin
password: admin
roles:
- ENDPOINT_ADMIN
management:
endpoints:
web:
exposure:
include: "*"
endpoint:
health:
show-details: when-authorized
ActuatorSecurity:
@Override
protected void configure(HttpSecurity http) throws Exception {
http.authorizeRequests().requestMatchers(EndpointRequest.to("status")).permitAll()
.requestMatchers(EndpointRequest.to("info")).permitAll()
.requestMatchers(EndpointRequest.toAnyEndpoint()).hasRole("ENDPOINT_ADMIN").antMatchers("/**")
.permitAll().and().httpBasic();
}
@nagsRepo Please ask questions on StackOverflow or join us on gitter. When you do, it would be helpful if you had a small, minimal sample that we could use to reproduce the problem.
We're cleaning out the issue tracker and closing issues that we've not seen much demand to fix. Feel free to comment with additional justifications if you feel that this one should not have been closed.