Actuator의 loggers를 HTTP로 조회만 허용하려면 management.endpoint.loggers.access=read-only와 management.endpoints.web.exposure.include=loggers를 함께 설정합니다. 여기에 Spring Security로 조회할 사용자를 제한합니다. 엔드포인트 접근 수준은 허용할 작업을, HTTP 노출은 공개할 통신 경로를, 인증·인가는 요청자의 접근 자격을 결정합니다.
조회 전용 설정과 사용자 권한을 구분해야 하는 이유
loggers는 로거 설정을 조회하고 변경하는 엔드포인트입니다. 운영자에게 현재 설정을 확인하게 하면서 변경 기능은 제공하지 않으려면 엔드포인트 자체를 조회 전용으로 제한해야 합니다. HTTP 노출 목록에 추가하는 것만으로는 변경 작업을 제한할 수 없습니다.
| 설정 계층 | 결정하는 내용 | 이 작업의 설정 |
|---|---|---|
| 엔드포인트 접근 수준 | 어떤 작업을 제공할지 | loggers를 read-only로 제한 |
| HTTP 노출 | 어떤 엔드포인트를 HTTP로 제공할지 | web exposure에 loggers 포함 |
| Spring Security | 누가 요청할 수 있는지 | 인증된 사용자 중 지정 역할만 허용 |
read-only는 사용자 역할 이름이 아닙니다. 또한 unrestricted도 Spring Security의 인증을 면제한다는 뜻이 아닙니다. 엔드포인트의 작업 범위와 HTTP 요청자의 권한은 별도로 적용됩니다.
loggers만 허용하고 HTTP에 노출하는 설정
다음 예제는 Actuator가 구성된 웹 애플리케이션을 전제로 합니다. 사용하는 Spring Boot 버전에서 아래의 access 속성을 지원하는지 먼저 확인해야 합니다. 지원 여부를 확인하지 않은 다른 버전에 그대로 적용하는 예제는 아닙니다.
# application.properties
management.endpoints.access.default=none
management.endpoint.loggers.access=read-only
management.endpoints.web.exposure.include=loggersaccess.default=none: 다른 개별 허용 설정이 없다면 모든 엔드포인트의 접근을 차단합니다.loggers.access=read-only: loggers의 읽기 작업만 허용합니다. 일반적인 Actuator 엔드포인트에서 읽기는@ReadOperation에 해당하며 HTTP에서는 GET으로 매핑됩니다.web.exposure.include=loggers: HTTP 노출 대상으로 loggers를 지정합니다.
접근이 허용되고 해당 기술로 노출되어야 엔드포인트를 사용할 수 있습니다. 따라서 read-only만 설정하고 HTTP 노출을 빠뜨리면 HTTP 조회 목적을 달성하지 못합니다. 반대로 노출만 추가해도 엔드포인트 접근이 차단되어 있다면 사용할 수 없습니다.
이 예제는 health도 기본 차단합니다. 기존 상태 점검이 health를 사용한다면 health의 개별 접근 수준과 HTTP 노출도 별도로 허용해야 합니다. 또한 web 노출 설정은 JMX 노출을 제어하지 않습니다. HTTP로만 제공해야 한다는 요구가 있다면 JMX의 include·exclude 설정도 따로 확인해야 합니다.
구체적인 예: 지정 역할의 운영자에게 조회 허용하기
위 속성 설정에 더해 조회자를 ENDPOINT_ADMIN 역할로 제한한다고 가정하겠습니다. Servlet 기반 애플리케이션의 Actuator용 SecurityFilterChain을 구성하는 메서드 안에서는 다음과 같은 규칙을 사용할 수 있습니다.
http.securityMatcher(EndpointRequest.toAnyEndpoint());
http.authorizeHttpRequests(requests ->
requests.anyRequest().hasRole("ENDPOINT_ADMIN"));
http.httpBasic(withDefaults());
return http.build();이 코드는 보안 설정의 일부입니다. HttpSecurity, SecurityFilterChain, EndpointRequest와 withDefaults를 사용하는 구성이 필요하며, import 경로는 사용하는 Spring Boot 버전의 문서에 맞춰야 합니다. HTTP Basic으로 인증할 사용자와 역할을 제공하는 인증 구성도 별도로 필요합니다. 이 규칙 자체가 계정을 생성하지는 않습니다.
기본 관리 경로를 사용한다면 조회 요청의 예는 다음과 같습니다. 인증 정보는 위 보안 구성에 맞춰 전달한다고 가정합니다.
GET /actuator/loggers| 확인 조건 | 기대하는 해석 |
|---|---|
| 인증 성공, 지정 역할 보유 | 설정 충돌이 없다면 로거 설정을 조회할 수 있음 |
| 인증 실패 또는 역할 미보유 | Spring Security 규칙에 따라 조회 접근이 제한됨 |
| 지정 역할로 변경 요청 시도 | 인증·인가를 통과해도 read-only 범위 밖의 변경 작업은 제공되지 않음 |
사용자 정의 SecurityFilterChain을 등록하면 Spring Boot의 보안 자동 설정은 물러납니다. 위 체인은 Actuator 요청만 대상으로 하므로, 나머지 애플리케이션 요청을 보호할 별도의 체인도 구성해야 합니다. 기존 체인이 있다면 예제를 단순히 추가하기 전에 요청 매칭 범위를 함께 검토해야 합니다.
조회 실패와 변경 차단을 확인하는 순서
- 실제로 적용된 속성부터 확인합니다. 프로파일별 파일, 외부 설정, 환경변수, 명령행 인자가 파일의 값을 덮어쓸 수 있습니다. 작성한 파일과 실행 환경의 최종 설정을 구분합니다.
- 전체 접근 상한을 확인합니다.
management.endpoints.access.max-permitted는 기본값과 개별 접근 수준보다 우선합니다. 값이none이면 loggers를 read-only로 지정해도 사용할 수 없습니다. 값이read-only이면 애플리케이션 전체 엔드포인트에 읽기 상한이 적용됩니다. - HTTP 노출 제외 목록을 확인합니다.
management.endpoints.web.exposure.exclude에 loggers가 있으면 include보다 우선하여 HTTP에서 제외됩니다. - 조회 요청의 인증·인가와 경로를 확인합니다. 실제 관리 경로와 해당 요청에 적용되는 보안 체인을 확인합니다. 접근 수준 설정을 완화하기 전에 요청자가 조회 권한을 갖고 있는지 살펴봅니다.
변경 요청에서 403을 받았다는 사실만으로 read-only 설정이 적용되었다고 판단해서는 안 됩니다. Spring Security의 기본 CSRF 보호도 POST 요청을 차단할 수 있기 때문입니다. 변경 요청의 정확한 오류 코드를 read-only의 판정 기준으로 고정하지 말고, 최종 접근 속성과 노출 설정을 함께 확인해야 합니다. 조회 전용이라는 목적을 위해 CSRF 보호를 끌 필요는 없습니다.
실무에서는 허용 작업, HTTP 노출 대상, 조회자 권한을 각각 명시하고 검토하면 됩니다. 로거 설정을 읽을 수 있다는 것과 변경 작업이 제공되지 않는다는 것을 별개의 조건으로 확인하세요.