Lección 116: Seguridad de métricas: restricción de acceso a Actuator

¿Por qué proteger las métricas?

Vale, imagina... Has configurado Actuator con orgullo en tu proyecto de práctica (o en uno real) y por fin puedes ver /metrics, /health y otros endpoints en acción. Te sientes todo un genio del monitoring, pero de repente descubres que... cualquiera puede acceder a esos datos. ¡Sorpresa!

Actuator da acceso a información bastante sensible sobre tu aplicación: estado de salud, carga de la CPU, uso de memoria, número de threads y un montón de otros datos. Ahora imagina que un atacante usa esa información para atacar tu aplicación. ¡Amenazante!

Amenazas potenciales

1. Fuga de información del sistema: las métricas pueden mostrar información crítica, por ejemplo, una versión obsoleta de la JVM o dependencias que pueden contener vulnerabilidades.
2. Reconocimiento antes del ataque: los datos sobre el estado del sistema pueden usarse para elegir el mejor momento para atacar.
3. Sobrecarga del sistema: un atacante podría lanzar muchas peticiones a los endpoints de Actuator, lo que provocaría carga extra.

En resumen: restringir el acceso a los endpoints de Actuator no es solo una recomendación, es una necesidad absoluta. Vamos a ver cómo hacerlo bien.

Configuración de seguridad para Actuator

Por defecto, Spring Boot Actuator proporciona endpoints que pueden estar abiertos para todos (dependiendo del nivel de configuración). Protejámoslos usando Spring Security.

1. Añadir la dependencia de Spring Security

Si en tu proyecto aún no tienes Spring Security, añádelo. Para Maven se vería así:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-security</artifactId>
</dependency>

Para Gradle:

implementation 'org.springframework.boot:spring-boot-starter-security'

2. Habilitar seguridad básica

En cuanto tengas Spring Security, el acceso a la mayoría de endpoints de Actuator quedará cerrado por defecto. Ahora se requerirá autenticación para acceder.

Prueba entrar a cualquier endpoint de Actuator, por ejemplo, /actuator/health. Verás que el navegador te pedirá usuario y contraseña. ¡Enhorabuena, el primer nivel de seguridad está configurado!

Spring Security crea automáticamente un usuario con login user y una contraseña que se genera al arrancar la aplicación. Esa contraseña puedes verla en los logs:

Using generated security password: 2a9c2b52-4f3d-4937-b5d0-8b0fe9ed8702

3. Cambiar las credenciales

Usar la contraseña generada solo sirve temporalmente. Vamos a poner credenciales más claras en el archivo application.properties:

spring.security.user.name=admin
spring.security.user.password=supersecurepassword

Ahora podrás iniciar sesión con el usuario y la contraseña que has configurado.

4. Control de acceso granular

¿Y si quieres que distintas métricas solo estén disponibles para ciertos roles? Por ejemplo, el endpoint /actuator/health puede ser público, pero /actuator/metrics solo para el administrador.

Configuración de acceso mediante HttpSecurity

Para eso hace falta configurar un SecurityFilterChain:

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.web.SecurityFilterChain;

@Configuration
public class SecurityConfig {

    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        http
            .authorizeHttpRequests()
                .requestMatchers("/actuator/health").permitAll() // Acceso abierto a /health
                .requestMatchers("/actuator/**").hasRole("ADMIN") // Acceso al resto solo para el administrador
                .and()
            .httpBasic(); // Usamos autenticación básica
        return http.build();
    }
}

Configuración de roles de usuarios

Al usar Spring Security con roles, necesitas crear usuarios con sus roles. Por ejemplo:

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.security.core.userdetails.User;
import org.springframework.security.core.userdetails.UserDetailsService;
import org.springframework.security.provisioning.InMemoryUserDetailsManager;

@Configuration
public class MyUserDetailsService {

    @Bean
    public UserDetailsService userDetailsService() {
        var user1 = User.withDefaultPasswordEncoder()
                        .username("user")
                        .password("password")
                        .roles("USER")
                        .build();

        var admin = User.withDefaultPasswordEncoder()
                        .username("admin")
                        .password("adminpassword")
                        .roles("ADMIN")
                        .build();

        return new InMemoryUserDetailsManager(user1, admin);
    }
}

Ahora el usuario admin tendrá acceso a los endpoints de Actuator, y el usuario user no.

Configuración vía application.properties

Si no quieres escribir código, Spring Boot permite simplificar la configuración de seguridad mediante application.properties:

management.endpoints.web.exposure.include=health,info,metrics
management.endpoint.health.probes.enabled=true

# Protección de todos los endpoints
spring.security.user.name=admin
spring.security.user.password=supersecurepassword

Errores típicos al configurar la seguridad

Desajuste de roles

Si creas un usuario sin el rol correspondiente (ROLE_ADMIN para Actuator), no podrá acceder aunque el usuario y la contraseña sean correctos. Asegúrate de que los roles estén bien configurados tanto en el código como en los datos.

Desactivar la seguridad por completo

Algunos desarrolladores, por comodidad, simplemente desactivan la autenticación y dejan Actuator abierto para todos. Esto puede ser aceptable solo en desarrollo local, pero nunca en producción. Siempre protege las métricas en proyectos reales.

¿Cuándo y qué endpoints abrir?

A veces puede ser útil dejar parte de las métricas abiertas. Por ejemplo, el endpoint /health puede estar abierto para sistemas de monitoring como Kubernetes para comprobar el estado de la aplicación.

Pero siempre limita el acceso a endpoints más detallados como /metrics o /env solo para administradores.

Después de esta clase no solo habrás aprendido a proteger las métricas, sino que también habrás entendido la importancia de este paso para la seguridad de tus aplicaciones.