Repository navigation
Security/document apiserver authn risk - #9875
Calvin S. (calvin197) wants to merge 3 commits into
Conversation
The AgentBaker apiserver registers HTTP handlers with only timeout and
panic-recovery middleware - no JWT/mTLS/API-key check - and serves over
plaintext HTTP (ListenAndServe, not ListenAndServeTLS).
This is intentional and risk-accepted (By-Design), not an oversight:
- Internal-only: this is a sidecar invoked solely by the AKS RP control
plane over the cluster-internal network, never exposed publicly.
- Boundary enforced elsewhere: the real security control is network
isolation (pod/cluster network policy) configured in the RP deployment,
outside this repo - not application-layer auth.
- Low impact surface: handlers are stateless template generators that do
not read tenant secrets from a backend store.
- Real auth (mTLS/token-based) would require a cert/token issuance and
rotation mechanism plus a coordinated change on the RP caller side (a
different repo) - out of scope for a point fix here.
Adds explanatory comments at NewRouter (middleware chain) and
ListenAndServe (TLS) so the decision is discoverable in place and
revisited if this service's network exposure ever changes.
Addresses Mythos findings: ADO 37518917 (primary, CWE-306) and ADO 37518903
(duplicate of 37518917, CWE-306/CWE-319).
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 350c2577-7031-4d0d-adc1-e99d053fc981
…server-authn-risk
…server-authn-risk
PR Title Lint Failed ❌Current Title: Your PR title doesn't follow the expected format. Please update your PR title to follow one of these patterns: Conventional Commits Format:
Guidelines:
Examples:
Please update your PR title and the lint check will run again automatically. |
Windows Unit Test Results 3 files 18 suites 52s ⏱️ Results for commit 085709f. |
There was a problem hiding this comment.
🔵 Needs a closer look
Deployment and security owners must confirm the external isolation, boundary TLS/authentication, and risk-acceptance claims.
No open issues 🎉
What changed in this PR
Documents the security risk-acceptance rationale for the AgentBaker apiserver sidecar’s lack of application-layer authentication and use of plaintext HTTP. Changes are comment-only; runtime behavior is unchanged.
Changes:
- Explains reliance on externally configured RP network isolation.
- Requires authentication middleware if the router is exposed beyond the trusted boundary.
- Adds the stated boundary TLS/authentication rationale beside
ListenAndServe.
| File | Description |
|---|---|
| apiserver/routers.go | Documents authentication rationale and requirements for broader exposure. |
| apiserver/apiserver.go | Documents intentional plaintext HTTP and stated external security controls. |
Review effort: Balanced
What this PR does / why we need it:
Documents a risk-accepted, by-design security decision for the AgentBaker apiserver sidecar. Addresses Mythos security findings (tracked under ADO 37518878):
• No application-layer authentication (ADO 37518903) and plaintext HTTP / no TLS (ADO 37518917) —
apiserver/routers.goregisters handlers with only timeout and panic-recovery middleware (no JWT/mTLS/API-key check), andapiserver/apiserver.goserves viaListenAndServe(notListenAndServeTLS). These are the same underlying root cause, reported twice by different scanner passes.This is not fixed in code because it's intentional: the apiserver is an internal-only sidecar invoked solely by the AKS RP control plane over the cluster-internal network, never exposed publicly. The enforced security boundary is network isolation (pod/cluster network policy) configured in the RP deployment — outside this repo, not app-layer auth. The handlers are stateless template generators that don't read tenant secrets. Adding real auth (mTLS/token-based) would require a cert/token issuance-and-rotation mechanism plus a coordinated change on the RP caller side (a different repo/system) — out of scope for a security-hardening pass.
This PR adds in-place code comments at
NewRouterandListenAndServedocumenting the risk-acceptance rationale and a clear instruction that authentication middleware must be added if this router is ever exposed beyond the trusted RP-only network boundary. No functional/behavioral change. Validated withgo build,go vet, andgo test ./apiserver/...(all pass).Which issue(s) this PR fixes:
Fixes #
ADO work items (msazure/CloudNativeCompute): 37518903, 37518917 (parent: 37518878)