cmd

Overview ¶

Command adofake serves test/entrafake AND test/adofake from ONE process, behind a TLS-terminating forward proxy, so the kind walk's Azure DevOps profile (scripts/lib/kind-sso-walk-ado.sh) can reach "login.microsoftonline.com" and "dev.azure.com" by their real names on a cluster with no Microsoft tenant.

It is a TEST BINARY, not a product one: it is built only by deploy/kind/sso/overlay.sh into wardyn/test-adofake:local, never by `make agent-images`, never published by release.yml, and it belongs only on a throwaway cluster (deploy/kind/sso/adofake.yaml).

THE SHAPE, and why each part exists:

• ONE listener that is a forward proxy. wardynd reaches it as its WARDYN_DAEMON_PROXY_URL, a run's proxy sidecar as site-config's upstream_proxy_url, and the walk's curl through a port-forward. A CONNECT to one of the two names is answered by terminating TLS with a leaf the walk's own CA signs (the CA every Wardyn component trusts through WARDYN_TRUSTED_CA_FILE); any other name is refused. That is the corporate TLS-inspecting middlebox Wardyn already supports, so no product code learns a test-only way to re-point either Microsoft name.
• BOTH FAKES IN ONE PROCESS, so the question "which tokens does Azure DevOps trust" has an answer reachable only in-process: every access token entrafake mints is registered with adofake at mint time (entrafake.OnIssue) together with the SUBJECT it was minted for. Nothing on the network can register a token.
• /_seen, a read-only count of what reached Azure DevOps, per caller SUBJECT. It is the walk's one observation that is not Wardyn asserting about itself.