[Security/MSA] Define authenticated service-registry authority for Eureka

[seonghobae]

Enterprise security gap

Protected develop@622e5e6c3d534f230c390f10e3832efadfc01825 ships a standalone Netflix Eureka server with no Spring Security dependency or application authentication configuration, while ETL, CDC, and gateway clients use an unauthenticated http://${EUREKA_HOST:localhost}:8761/eureka/ registry endpoint. The local Compose stack also publishes Eureka to the host; #180 separately owns safer loopback publication.

Service discovery is an authority boundary, not only an availability feature. An actor that can register or alter service instances can influence gateway/service routing and can create confusing or malicious east-west destinations even when the public gateway itself verifies callers correctly.

RCA

• Immediate cause: Eureka registration/query endpoints have no application-layer client/server authentication contract in the repository.
• Technical root cause: service discovery is treated as trusted ambient infrastructure; clients know a registry URL but do not carry a reviewed service identity or transport-security contract.
• Control failure: protected configuration/tests verify that Eureka exists and is reachable, not who may register/query instances, how instance identity is bound to workload identity, or how credentials/certificates rotate and fail closed.
• Architectural interaction: [Product/Security Gap] Replace direct ETL HTTP Basic trust boundary #161 already shows that edge JWT does not establish direct ETL east-west service identity. Securing Eureka cannot substitute for endpoint authorization, but an unauthenticated registry can undermine routing trust before an endpoint is reached.

Distinct remediation options / feasibility

Preferred production architecture — deployment-owned authenticated/tunneled registry boundary

Define one explicit supported production profile in which registry traffic is authenticated and encrypted, with workload/service identity supplied by the deployment platform rather than hard-coded into source. Viable implementations must be proved against the actual target runtime before selection, for example:

• mTLS/service-mesh or platform workload identity around Eureka;
• Spring Security protection of Eureka plus deployment-managed per-service/rotatable credentials;
• replacement of Eureka by a deployment-native service-discovery mechanism under a separately reviewed ADR if that materially reduces trust/certificate/credential complexity.

The repository must not invent usernames/passwords, certificates, a secret manager, or a service mesh merely because a secure registry is needed.

Local development

Local Compose may remain credential-light only if it is explicitly local-only (see #180), never presented as the production trust profile, and cannot silently become externally reachable by default.

Reject

• embedding Eureka Basic credentials in Git-tracked YAML/URLs;
• treating host firewall/loopback as the complete production registry-authentication story;
• relying on gateway JWT as proof that service registration is trusted;
• allowing arbitrary Eureka metadata/URLs to become downstream authority without validation;
• adding a guessed secret or external identity provider without proving deployment ownership and lifecycle.

Acceptance

1. canonical Security/Threat Model/Architecture/TRD/Operability identifies the service registry as a trust boundary and distinguishes local vs production profiles;
2. the chosen supported production profile proves authenticated service registration/query and encrypted transport, or an accepted replacement discovery mechanism;
3. workload identity/credential/certificate ownership, issuance, rotation, revocation, expiry and degraded behavior are explicit and do not rely on Git-tracked secrets;
4. unauthorized/invalid/stale registrations fail closed and are covered by realistic integration/security tests;
5. gateway/clients validate allowed service/discovery destinations rather than accepting attacker-controlled registry metadata as unrestricted egress authority;
6. registry compromise is represented in the threat model and does not automatically grant application endpoint authorization ([Product/Security Gap] Replace direct ETL HTTP Basic trust boundary #161 remains independently required);
7. local Compose remains usable under an explicitly local-only exposure profile without being mislabeled production-secure;
8. no secrets, certificate roots, reviewer identities or platform integrations are invented to satisfy the issue;
9. exact-source CI/security/non-vacuous coverage/review and protected-develop operational proof pass before any production-ready claim.

Current classification

planned / known_gap. The exact production mechanism is a deployment/security architecture decision that must be selected from actual runtime/platform evidence. Repository-owned threat-model, local-profile, destination-validation and test contracts can advance independently while infrastructure-owned identity material remains external.

Relationships: #161 direct ETL service authentication; #180 local Compose host exposure; #179 Config Server remote authority; #159 canonical architecture/security traceability.

[seonghobae]

Test-harness follow-through — 2026-08-10

Draft PR #206 now gives the previously untested eureka-server bootstrap a real source-backed test boundary without claiming this security issue is solved. Its current source head f96369312ffcb6ec0581bdfe463e2a9fb43ab395 preserves @EnableEurekaServer / Spring Boot startup and adds beginner-readable public Javadoc. Hosted CI runs 3/3 Eureka bootstrap tests green on the current synthetic integration preview.

This is deliberately not service-registry authentication evidence. The production class Javadoc explicitly says bootstrap ownership and production authentication/service-identity policy are separate controls. Protected eureka-server/pom.xml still contains Eureka Server + Actuator only, and protected application.yml still has no authenticated registration/query contract. #185 therefore remains known_gap.

When the production identity mechanism is eventually selected, reuse/extend this real module test harness rather than reverting to source-text-only claims: add fail-first application-context / HTTP integration tests proving unauthorized registration/query is denied and authorized workload identity succeeds under the selected deployment profile. #206 itself should remain path-disjoint and Draft; do not broaden it into the unresolved security architecture.