skip to content

How do you control detail visibility (show-details / show-components) independently for a single health group?

level: middleimportance: should knowfreq 22%

answer

  1. never / when-authorized / always
  2. group.<name>.show-details overrides global
  3. show-components = list; show-details = the detail map
  4. when-authorized + .roles needs Spring Security
  5. public probe = never; internal = always

basics

~10 s

Each group accepts its own management.endpoint.health.group.<name>.show-details and .show-components set to never, when-authorized, or always. These override the global management.endpoint.health.show-details for that group only.

solid answer

~40 s

The main health endpoint has global `management.endpoint.health.show-details` (default `never`) and `show-components`, each taking `never`, `when-authorized`, or `always`. A group can override both just for itself: `management.endpoint.health.group.<name>.show-details=always`. `show-details` controls whether each contributor's detail map (e.g. db validation query, free disk bytes) is rendered; `show-components` controls whether the per-component status entries appear at all. `when-authorized` reveals details only to authenticated users in the roles listed in `.roles` (defaulting to any authenticated user). This matters because you often want an internal group to show full diagnostics (`always`) while a group probed by Kubernetes or a public load balancer shows just an overall status (`never`) to avoid leaking topology or dependency details.

code

yaml · 13 lines
yaml
management:
  endpoint:
    health:
      show-details: never          # global default: lock everything down
      group:
        probe:                        # scraped by k8s / LB -> stay opaque
          include: readinessState, db
          show-details: never
        internal:                     # ops-only deep view
          include: "*"
          show-details: when-authorized
          show-components: always
          roles: OPS, ADMIN

go deeper

for a junior

Know the three values and that never is the default (status only).

for a middle

Explain per-group override, the show-details vs show-components distinction, and when-authorized+roles.

for a senior

Treat public-group detail exposure as an explicit information-disclosure security decision.

for a principal

Design a policy where probe groups stay opaque and internal groups are role-gated, accounting for the no-Security degradation.

## The three visibility values Actuator exposes two orthogonal knobs, each accepting one of `never` / `when-authorized` / `always`: - **`show-components`** — whether the response lists each contributor and its individual status (the `components` map: `db: {status: UP}`, `diskSpace: {status: UP}`). - **`show-details`** — whether each contributor's `details` sub-map is rendered (the actual diagnostics: validation query, free/total disk bytes, error messages). Globally these are set on the endpoint: `management.endpoint.health.show-details` (default `never`) and `management.endpoint.health.show-components` (defaults to the same value as show-details). With `never`, `/actuator/health` returns just `{"status":"UP"}`. ## Per-group override Every group can override both, scoped only to that group: ``` management.endpoint.health.group.internal.show-details=always management.endpoint.health.group.internal.show-components=always management.endpoint.health.group.probe.show-details=never ``` If a group does NOT specify a value, it inherits the endpoint-level setting. So you can have a globally-locked-down `show-details=never` and open up exactly one internal group. ## `when-authorized` and roles `when-authorized` renders details only when the caller is authenticated AND (if roles are configured) holds one of the required roles. Configure roles per group with `management.endpoint.health.group.<name>.roles=ADMIN,OPS` (or globally with `management.endpoint.health.roles`). With no roles configured, any authenticated user sees details. Unauthenticated callers get just the status. This requires Spring Security to be present so Actuator can resolve the principal from the `SecurityContext`. ## Why isolate per group A readiness/liveness group scraped by Kubernetes or an external load balancer should reveal nothing beyond the aggregate status — showing dependency names, error strings, or disk figures is an information-disclosure risk. Meanwhile an `internal`/`debug` group hit only from inside the cluster can safely use `always` for fast troubleshooting. Per-group settings let one endpoint serve both audiences. ## Gotchas - `show-details=always` in a public group can leak stack traces and dependency URLs — treat it as a security decision, not a convenience toggle. - `when-authorized` silently degrades to status-only when Spring Security isn't on the classpath (no principal to authorize), which can surprise you in tests. - Setting `show-details` without `show-components` still hides the per-component list unless components is also raised — details live inside components. - Group settings only inherit the endpoint default when omitted; an explicit value fully replaces it (no merging).

  • A group sets show-details=when-authorized but the app has no Spring Security on the classpath. What do callers see?
    Only the aggregated status — with no security context there is no authorized principal to satisfy 'when-authorized', so details are withheld for everyone.
  • Why is show-details=always risky on a publicly reachable group?
    The details map can expose dependency URLs, validation queries, disk figures, and exception messages — information disclosure that helps an attacker map your infrastructure.

saying these in an interview costs you the question

  • Claiming show-details defaults to always (it defaults to never)
  • Thinking a group cannot override the global show-details
  • Believing when-authorized works without any security integration

context

resolving links…