oidc-discovery-provider: allow_insecure_scheme WARN is misleading and unsuppressible behind a TLS-terminating load balancer

Summary

Since #6968 / #6970, oidc-discovery-provider logs a WARN on every startup when allow_insecure_scheme = true, stating the setting "must only be used in development environments."

Terminating TLS at a load balancer / reverse proxy and forwarding plaintext to the provider is a legitimate production topology, but there is no way to acknowledge that intent or downgrade the warning, and the pattern is undocumented for a TCP insecure_addr backend.

Version

• SPIRE oidc-discovery-provider 1.15.2

Deployment

The provider runs behind an AWS ALB that terminates TLS and forwards plaintext to the pod:

• ALB listener: HTTPS :443 with an ACM certificate
• backend-protocol: HTTP, target-type: ip → forwards to the pod's :8080
• Only the ALB→pod hop is plaintext; it is inside the VPC and carries only public JWKS / OIDC-discovery data

allow_insecure_scheme = true
insecure_addr         = ":8080"

Current behavior

On each process start the provider logs at WARN:

{"level":"warning","msg":"allow_insecure_scheme is enabled. JWKS keys will be served over HTTP. ..
...This setting must only be used in development environments."...}

• The message asserts the setting is dev-only.
• There is no config option to acknowledge intent, downgrade the level, or suppress it.

Expected behavior

An operator running behind a trusted TLS-terminating proxy / load balancer can declare that intent so the provider does not emit a production WARN on every boot, while still leaving an audit trail that the insecure scheme is active. Or, a softer WARN message.

Proposed solutions

Any one of these would resolve it:

1. Acknowledgement flag. Add a config field, e.g. insecure_scheme_acknowledged = true (or behind_tls_terminating_proxy = true). When set alongside allow_insecure_scheme, log the same content once at INFO instead of WARN — preserves the audit signal, stops tripping WARN alerts, and requires an explicit opt-in.
2. Soften the wording. Change "This setting must only be used in development environments." to e.g. "Only enable this when the network path to the provider is trusted end-to-end (for example, TLS terminated at a trusted reverse proxy or load balancer on a private network)."

Happy to send a PR for based on the agreed approach.

References

• #6968 — feature request that introduced the warning
• #6970 — implementation (fixes #6968)