So, we've locked down chat, images, and comments. But what about the Config Server itself? Seeing how critical it is with each microservice's configuration details, we need to insulate ourselves from a malevolent Config Server being stood up in its place.
The simplest thing to do is to add Spring Security to our Config Server. So, let's do it!
compile('org.springframework.boot:spring-boot-starter-security')
By default, Spring Security will set username to user and password to something random. Since we can't be updating the other services every time we restart, let's override that with a fixed password, as follows:
@Bean
UserDetailsService userDetailsService() {
return new InMemoryUserDetailsManager(
User
.withUsername("user")
.password("password")
.roles("USER").build());
}
In Spring Boot 1.x, there was a security.password property to override. In the spirit of simplification, this property has been removed in Spring Boot 2.x. The new approach is to inject a UserDetailsService bean, as shown in the previous code fragment (which can be added to LearningSpringBootConfigServer). This code shows a single user, user/password, defined.
That's all it takes to secure our Config Server!
To signal the other services, we need to adjust their bootstrap.yml files. Let's start with the Eureka Server, like this:
spring: application: name: eureka cloud: config: label: session password: password
This change shown in the last code adds spring.cloud.config.password set to the same password we just chose.
Let's continue with chat:
spring: application: name: chat cloud: config: label: session password: password
In the preceding code, we have spring.cloud.config.password and spring.cloud.config.label properly set.
We can make the same changes to images, as follows:
spring: application: name: images cloud: config: label: session password: password
This will secure things with the exact same settings.
And finally, let's make the following changes to comments:
spring: application: name: comments cloud: config: label: session password: password
This will lock things down, preventing others from getting access to our settings. If someone attempted to stand up a bogus Config Server, they would have to somehow secure it with the same password on the same network address. (Not likely!).