[Security/MSA] Authenticate Config Server read access and configuration clients

[seonghobae]

Buyer-visible security gap

Protected develop@622e5e6c3d534f230c390f10e3832efadfc01825 contains a real Spring Cloud Config Server module on port 8888. Its module POM includes Config Server, Actuator, and Eureka Client but no Spring Security dependency, and its application configuration defines no inbound client-authentication or authorization boundary. Issue #179 / PR #189 separately fixes the outbound Git repository authority by removing the fake repository fallback; that does not authenticate clients reading configuration from the Config Server itself.

A supported Config Server can expose deployment configuration, feature flags, endpoint coordinates and, depending on the external repository, secret-adjacent or operationally sensitive values. Protecting the Git backend while leaving inbound Config Server reads ambiently trusted is not a complete production trust model.

Status: planned / known_gap. Do not invent credentials merely to make the server appear secure.

RCA

• Immediate cause: the Config Server module has no registered application security boundary for configuration-resource requests.
• Technical root cause: outbound configuration-source trust and inbound configuration-consumer trust were modeled as one implicit infrastructure assumption rather than two independent authorities.
• Control failure: current tests can prove repository URI behavior/startup, but do not prove who may read application/profile/label configuration, how client identity maps to allowed applications/environments, or how credentials/certificates rotate and fail closed.
• Architectural interaction: [Operability/Supply chain] Remove fake Config Server Git fallback from supported runtime #179/fix(config): require explicit Config Server repository authority #189 owns approved Git source selection; [Security/MSA] Define authenticated service-registry authority for Eureka #185 owns Eureka registry identity; [Product/Security Gap] Replace direct ETL HTTP Basic trust boundary #161/[Security/MSA] Authenticate CDC control-plane endpoints independently of gateway routing #187 own direct ETL/CDC service identity. None substitutes for authenticating Config Server clients.

Distinct architecture options / feasibility

Preferred production class — deployment-owned service identity

Select one supported production mechanism from the actual deployment environment and prove it end-to-end, for example:

• mTLS/platform workload identity around Config Server;
• Spring Security with deployment-managed rotatable client/service credentials;
• a deployment-native configuration service replacing Spring Cloud Config under a separately reviewed ADR if that materially simplifies trust and lifecycle.

The repository must not invent a username/password, certificate authority, secret manager, issuer, client secret, or service mesh. The chosen mechanism must work for both standalone and composed MSA deployment profiles that claim Config Server support.

Bounded local development

A credential-light local profile may exist only if it is explicitly local-only, loopback/private by default, isolated from production claims, and cannot silently become an externally reachable supported profile.

Reject

• Git-tracked Config Server usernames/passwords;
• placing credentials in Config Server URLs committed to source;
• assuming Eureka registration authenticates Config clients;
• relying solely on host firewall/loopback for a production identity claim;
• hiding secret values in docs while leaving the runtime endpoint unauthenticated;
• treating fix(config): require explicit Config Server repository authority #189's outbound Git URI fix as inbound client authorization.

Required product/security contract

Before production mutation, decide and document:

1. whether Config Server is supported, reference-only/planned, or removed from production profiles;
2. which endpoint classes are public, if any (health/info may be separately scoped), and which configuration-resource endpoints require authenticated service identity;
3. how workload/client identity is issued, rotated, revoked, and mapped to application/profile/label authority;
4. whether one client may read multiple application/environment namespaces and how least privilege is enforced;
5. TLS trust, certificate/key/token provenance, expiry and degraded behavior;
6. startup/runtime behavior when identity infrastructure is unavailable;
7. audit/metrics that record bounded success/failure classifications without config values, tokens, credentials or high-cardinality principals;
8. compatibility/rollback for deployments that historically assumed anonymous Config Server reads.

TDD / acceptance

Add fail-first tests against the actual registered Config Server web/security chain before implementation. Final acceptance must prove, as applicable:

• unauthenticated/invalid/stale identities cannot read configuration resources;
• authorized clients can read only the application/profile/label scope granted by the chosen contract;
• health/info exposure is narrowly intentional and reveals no repository credentials or configuration values;
• client identity cannot be spoofed by caller-controlled headers;
• tokens/passwords/certificates/config values never enter ordinary logs/metrics;
• TLS/identity rotation and unavailable identity infrastructure fail according to the documented contract;
• Config Server Git repository authority from [Operability/Supply chain] Remove fake Config Server Git fallback from supported runtime #179/fix(config): require explicit Config Server repository authority #189 remains independently fail-closed;
• standalone and modular MSA deployment behavior is explicit;
• machine-readable deployment/security documentation and canonical Security/Threat Model/Architecture/TRD/Operability/Traceability are updated;
• exact-source CI, dependency/SBOM/SAST/security, non-vacuous coverage, current review and protected operational acceptance pass before a production-ready claim.

Sequencing / writer safety

Do not race #189's active Config Server repository-authority branch. A future implementation can preferably use a path-disjoint security configuration/new dependency boundary, but any shared POM/application configuration change must be re-evaluated against #189's exact integrated state first. Do not modify separately leased repositories or fabricate external identity material.

Relationships: #179/#189 outbound Config Git authority; #185 Eureka registry authority; #161 ETL service identity; #187 CDC control-plane identity; #180 deployment exposure; #159 canonical documentation/traceability.