Contactez-nous

Configuration des endpoints Actuator (exposition, sécurité)

Apprenez à contrôler quels endpoints Actuator sont exposés via HTTP/JMX et comment les sécuriser efficacement avec Spring Security pour protéger votre application.

Introduction à la configuration des endpoints Actuator

Spring Boot Actuator fournit une multitude d'endpoints utiles pour surveiller et gérer votre application en production (/health, /metrics, /info, /env, etc.). Cependant, exposer tous ces endpoints sans contrôle peut présenter des risques de sécurité, car ils peuvent révéler des informations sensibles sur la configuration, l'état interne ou l'environnement de votre application.

Il est donc crucial de configurer précisément quels endpoints sont accessibles et comment ils sont protégés. Spring Boot offre des mécanismes flexibles pour gérer l'exposition des endpoints via différents canaux (principalement HTTP et JMX) et pour intégrer leur sécurisation avec Spring Security.

Cette section détaille comment utiliser les propriétés de configuration pour contrôler l'exposition et comment mettre en place des règles de sécurité adaptées pour protéger vos endpoints Actuator.

Contrôler l'exposition des endpoints

Par défaut, Spring Boot Actuator expose un nombre limité d'endpoints via HTTP pour des raisons de sécurité. Historiquement (avant Spring Boot 2.x), beaucoup plus d'endpoints étaient exposés par défaut, mais cette approche a été revue. Actuellement, seuls /health et /info sont généralement exposés sur le web par défaut. Via JMX, tous les endpoints sont exposés par défaut.

Vous pouvez contrôler finement l'exposition en utilisant les propriétés management.endpoints.web.exposure.include et management.endpoints.web.exposure.exclude pour les endpoints HTTP, et des propriétés similaires pour JMX (management.endpoints.jmx.exposure.*).

La propriété include définit la liste des IDs d'endpoints à exposer. Vous pouvez utiliser une liste séparée par des virgules ou le caractère spécial * pour les inclure tous. La propriété exclude permet de désactiver spécifiquement certains endpoints, même s'ils sont inclus par include (par exemple, si vous utilisez include: '*' mais voulez exclure env).

Voici comment configurer l'exposition dans application.properties :

# Exposer tous les endpoints web (sauf ceux explicitement exclus)
management.endpoints.web.exposure.include=*

# Exclure spécifiquement les endpoints 'env' et 'beans'
management.endpoints.web.exposure.exclude=env,beans

# Alternative : Exposer uniquement 'health', 'info', et 'metrics' via le web
# management.endpoints.web.exposure.include=health,info,metrics

# Configuration JMX (tous exposés par défaut)
# management.endpoints.jmx.exposure.include=*
# management.endpoints.jmx.exposure.exclude=

Et l'équivalent en application.yml :

management:
  endpoints:
    web:
      exposure:
        include: "*" # Ou ['health', 'info', 'metrics']
        exclude: ["env", "beans"]
    jmx:
      exposure:
        include: "*"
        # exclude:

Il est généralement recommandé d'adopter une approche d'inclusion explicite (lister uniquement ceux dont vous avez besoin) plutôt que d'inclure tout (*) puis d'exclure, pour une meilleure sécurité par défaut.

Sécurisation des endpoints Actuator avec Spring Security

Si Spring Security est présent sur le classpath de votre application (via spring-boot-starter-security), les endpoints Actuator sont automatiquement sécurisés par défaut. Cela signifie qu'un accès non authentifié renverra une erreur 401 (Unauthorized) ou redirigera vers une page de connexion, sauf pour les endpoints explicitement autorisés.

La configuration de la sécurité se fait via la configuration standard de Spring Security, généralement en définissant un bean SecurityFilterChain. Spring Boot Actuator fournit une classe utilitaire pratique, EndpointRequest, pour faciliter la création de règles de sécurité spécifiques aux endpoints Actuator.

Par exemple, vous pourriez vouloir autoriser l'accès public (non authentifié) aux endpoints /health et /info, mais exiger qu'un utilisateur soit authentifié et possède un rôle spécifique (par exemple, ACTUATOR_ADMIN) pour accéder aux autres endpoints plus sensibles (comme /metrics, /env, /loggers).

Voici un exemple de configuration d'un SecurityFilterChain pour sécuriser les endpoints Actuator :

import org.springframework.boot.actuate.autoconfigure.security.servlet.EndpointRequest;
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 filterChain(HttpSecurity http) throws Exception {
        http
            .authorizeHttpRequests(authorize -> authorize
                // Autoriser l'accès public à /health et /info
                .requestMatchers(EndpointRequest.to("health", "info")).permitAll()
                // Exiger le rôle ACTUATOR_ADMIN pour tous les autres endpoints Actuator
                .requestMatchers(EndpointRequest.toAnyEndpoint()).hasRole("ACTUATOR_ADMIN")
                // Sécuriser les autres requêtes de l'application (exemple)
                .requestMatchers("/api/public/**").permitAll()
                .anyRequest().authenticated()
            )
            .httpBasic(); // Ou .formLogin();
        return http.build();
    }

    // N'oubliez pas de configurer également comment les utilisateurs sont authentifiés
    // (par exemple, UserDetailsService, configuration JDBC/LDAP, etc.)
    // et un PasswordEncoder.
}

Dans cet exemple :

  • EndpointRequest.to("health", "info") crée un matcher pour les chemins de ces deux endpoints spécifiques.
  • EndpointRequest.toAnyEndpoint() crée un matcher pour tous les autres endpoints Actuator qui n'ont pas déjà été traités par une règle précédente.
  • hasRole("ACTUATOR_ADMIN") spécifie que l'utilisateur authentifié doit posséder ce rôle.
  • Les règles pour le reste de l'application (/api/public/**, anyRequest()) sont définies ensuite. L'ordre des règles est important.

N'oubliez pas que cette configuration suppose que vous avez défini comment les utilisateurs sont authentifiés et quels rôles leur sont attribués (par exemple, via un UserDetailsService).

Configuration spécifique à l'endpoint : exemple avec /health

Certains endpoints offrent des options de configuration supplémentaires qui interagissent avec la sécurité. L'endpoint /health en est un bon exemple avec la propriété management.endpoint.health.show-details.

Cette propriété contrôle si les détails complets des indicateurs de santé (HealthIndicator) sont affichés dans la réponse JSON. Elle peut prendre trois valeurs :

  • never : Les détails ne sont jamais affichés. Seul le statut global (UP/DOWN) est montré. C'est le comportement le plus sûr pour une exposition publique.
  • when-authorized (défaut) : Les détails sont affichés uniquement si l'utilisateur est authentifié et autorisé à accéder à l'endpoint /health (selon les règles de Spring Security). Si l'accès est public (permitAll()), les détails ne sont pas montrés.
  • always : Les détails sont toujours affichés, que l'utilisateur soit authentifié ou non. A utiliser avec prudence, car cela peut révéler des informations sur vos dépendances (base de données, espace disque, etc.).

Configuration dans application.properties :

# Afficher les détails de santé uniquement aux utilisateurs autorisés (défaut)
management.endpoint.health.show-details=when-authorized

# Ou pour toujours afficher les détails (moins sécurisé)
# management.endpoint.health.show-details=always

# Ou pour ne jamais afficher les détails
# management.endpoint.health.show-details=never

Il est essentiel de bien comprendre l'impact de ces configurations sur les informations exposées et de les aligner avec votre politique de sécurité et vos règles Spring Security.

Bonnes pratiques et résumé

La configuration des endpoints Actuator est un équilibre entre la nécessité d'obtenir des informations pour la surveillance et l'exploitation, et le besoin de protéger votre application contre l'exposition d'informations sensibles.

Voici quelques bonnes pratiques :

  • Exposition minimale : N'exposez via HTTP que les endpoints strictement nécessaires pour vos outils de monitoring ou vos besoins opérationnels. Utilisez management.endpoints.web.exposure.include pour lister explicitement les endpoints requis.
  • Sécurité robuste : Intégrez toujours Actuator avec Spring Security si ce dernier est utilisé. Définissez des règles claires pour contrôler l'accès aux différents endpoints, en utilisant des rôles spécifiques (comme ACTUATOR_ADMIN) pour les endpoints sensibles.
  • Comprendre les détails : Soyez conscient des informations potentiellement sensibles révélées par certains endpoints (/env, /loggers, détails de /health) et configurez leur accès et leur niveau de détail de manière appropriée.
  • Canaux distincts : Considérez l'utilisation de JMX pour l'accès local ou via des outils d'administration spécifiques, tout en limitant l'exposition HTTP à un sous-ensemble plus restreint et public (comme /health).
  • Chemin de base : Vous pouvez changer le chemin de base des endpoints Actuator (par défaut /actuator) avec management.endpoints.web.base-path pour les rendre moins découvrables, bien que cela ne remplace pas une véritable sécurité.

En maîtrisant la configuration de l'exposition et de la sécurité des endpoints Actuator, vous pouvez bénéficier de leurs puissantes fonctionnalités de surveillance tout en maintenant un haut niveau de sécurité pour votre application Spring Boot.