Spring Boot recognizes that there are many reasons and it needs to be able to provide separate configuration for the way management endpoints and other actuator components work, which is different from the main application. The first level of such configurations can be achieved by setting the myriad of available properties that intuitively start with management.*. We have used one such property, management.server.port, to set the port for the management interface to be 8081. We could also set things like the SSL configuration, security settings, or network IP interface address to bind the listener to. We also have the capability to configure each individual actuator endpoint by setting their corresponding properties, which start with management.endpoint.<name>.* and have a variety of settings, depending on the specific endpoint goals.

For security reasons, the data that is exposed by the various management endpoints, especially the ones from sensitive ones such as /health, /env, and others can be very lucrative for malicious people on the outside. To prevent this from happening, Spring Boot provides us with the ability to configure if we want the endpoints to be available via management.endpoint.<name>.enabled=false. We can specify which individual endpoints we want to disable by setting an appropriate management.endpoint<name>.enabled=false property as well, or using management.endpoints.web.exposure.exclude=<name> to tell Spring Boot if this endpoint should be enabled, but not exposed via the WEB HTTP API method of access.

Alternatively, we can set management.server.port=-1 to disable the HTTP exposure of these endpoints or use a different port number in order to have the management endpoints and live services on different ports. If we want to enable access only via a localhost, we can achieve this by configuring management.server.address=127.0.0.1 to prevent external access. Even the context URL path can be configured to something else, say /admin, via management.server.context-path=/admin. This way, to get access to a /health endpoint, we would go to http://127.0.0.1/admin/health instead of the default /actuator context path. This can be useful if you want to control and restrict access via the firewall rules, so you can just add a filter to block external access to anything, /admin/*, for all the applications from the outside. With the addition of Spring Security, an authentication can also be configured to require a user login to get access to the endpoints.

In situations when controlling behavior using properties is not enough, Spring Boot provides a mechanism to provide alternative application context configuration via the use of spring.factories and the accompanying ManagementContextConfiguration annotation. This enables us to tell Spring Boot which configurations should be automatically loaded when management context is being created. The intended use of this annotation is to have the configuration live in a separate, sharable dependency library, outside of the main application's code.

In our example, because we put it in the same codebase (for simplicity), we had to do an extra step and define the exclusion filter in the BookPubApplication.java file to exclude the ManagementContextConfiguration classes from component scan when setting up the main application. The reason we had to do that is simple—if we look inside the ManagementContextConfiguration annotation definition, we will see that it is a meta-annotation with the @Configuration annotation inside it. What this means is that when our main application is being configured, the component scan will automatically detect all the classes in the classpath tree of the application code that are annotated with @Configuration, and as such, it will put all the configurations marked with ManagementContextConfiguration in the main context as well. We have avoided that using the exclusion filter. Alternatively, a better way is to have those configurations in a separate library using a different package hierarchy, which would prevent the component scan picking them up, but the autoconfiguration will still works because of the spring.factories entry for org.springframework.boot.actuate.autoconfigure.web.ManagementContextConfiguration telling Spring Boot to automatically add those configurations to the management context.

In order to have the management context separate from the main application, it is necessary to configure it to run on a separate port using the management.server.port property. Without this setting, all of the objects will be using shared application context.