fix(security): never send a remoteControl.tls bearer token to a publicly-trusted host

[thc1006]

Addresses part of #251. Default-on, unlike the two existing controls for this path.

The review is right, but it is the same ground as ADR-0009 — except for one clause

Everything the review lists (label-only opt-in, SA/bootstrap-token refusal, same-namespace, uniform error, and the three "known limits" the code comment itself admits) is already written down in ADR-0009 and #219, in the same terms. Its severity conditioning matches the ADR's. So on its own it does not move the position.

One clause does: "在使用 system roots 或攻擊者能提供受信任憑證的情況下". That sent me to the trust-anchor code, and it is a real, concrete, default-on hole that ADR-0009 does not mention:

// Trust a private CA when provided; otherwise fall back to the system roots.
if ca := secret.Data["ca.crt"]; len(ca) > 0 { … cfg.RootCAs = pool }

ca.crt absent → RootCAs nil → Go uses the system trust store. And remoteControl.endpoint is CR-author controlled, with ServerName derived from it.

Why that completes the attack with stock settings

A principal holding the shipped ntncellconfig-editor-role (NTNCellConfig write, no secrets get):

1. references any opted-in Secret carrying a token but no ca.crt,
2. sets endpoint to a host they own,
3. presents an ordinary publicly-trusted certificate for it (any ACME CA will issue one for a domain you control),
4. and is handed the token verbatim.

None of the label gate needs to be bypassed — the label governs which Secret may be named, never where its contents may be sent. And both controls that do cover this path ship off by default: the endpoint allow-list (#300, empty = permit-all) and the credential-reference admission policy. The private-IP SSRF guard does not apply here either — it inverts on this path, since a legitimate gNB target is private.

So the review's "release blocker" framing is defensible for the default configuration, and this PR is the part that can be fixed without asking the operator to turn anything on.

Change

A Secret carrying token must now also pin ca.crt, or the push is refused as a permanent credential error.

mode: mtls without ca.crt stays permitted — it proves a key rather than sending one, so a misdirected mTLS dial is identity misuse (and leaks the pushed config), not credential theft. That is the line ADR-0009 already draws between the two modes, so this PR does not redraw it. A deployment that genuinely fronts its gNB with a publicly-trusted certificate opts in explicitly by putting that CA bundle in ca.crt.

Upstream precedent: kubeadm pins a CA public key (RFC 7469 style) for token-based discovery rather than trusting the system store before sending its bootstrap token — the same "we are about to transmit a token, so the destination must be unforgeable" reasoning.

What this does NOT claim

It is not the authorization boundary #251 asks for, and the resolveRemoteControlTLS comment still says "partial mitigation", because it still is. This bounds where a named credential may be sent; it does not change who may name it. The three known limits from #219 are untouched.

Adversarial pass on my own change

• No new oracle. The refusal wraps errRemoteControlCredentialInvalid, and the controller surfaces only the uniform errRemoteControlCredentialUnavailable on the CR while logging the specific cause for the operator. Verified at the call site, not assumed.
• Self-heals. It is a deterministic credential error, so it takes the 5m poll (fix(ntncellconfig): self-heal-requeue a RemoteControlConfigInvalid push failure #282): adding ca.crt recovers without a spec edit.
• No behaviour change for the no-token cases. ca.crt present but invalid PEM still fails in the existing branch (it does not fall through to the new one); no token and no ca.crt is unchanged.
• Ordering. The gate sits after the type and label gates, so an unlabelled Secret still fails on the label first — no reordering of what a caller can learn.
• The new tests are a separate top-level function because adding them inline tripped gocyclo on an already-large table — which is also just better placement.

Verification

• go build, go vet, golangci-lint v2.12.2: 0 issues; gofmt clean.
• go test ./internal/controller/... ./pkg/... green (envtest 1.36.2).
• No test covered token without ca.crt at all — every existing case supplied ca.crt, which is exactly why the fallback went unnoticed. Beyond the direct case, the new test states the invariant once: any successful resolution that returns a token must have pinned roots, so a future key or mode cannot reopen this case-by-case.
• Mutation-verified: removing the gate reddens both the direct case (must be refused: the endpoint is caller-controlled…) and the invariant (a token was returned for "token only" with RootCAs=nil).

Two things a reviewer should look at deliberately

1. Breaking change, with an upgrade note and a detection one-liner in the CHANGELOG: any Secret with token and no ca.crt starts failing. Worth confirming that matches your deployments.
2. docs/api-reference.md carries pre-existing drift. Regenerating it (unavoidable, since I changed an API field doc) also pulled in lastPushedSatSwitchDigest from fix(ntncellconfig): send sat_switch_with_resync only on intent change, not every heartbeat #285, EphemerisSelectionAmbiguous, and the minTerrestrialDwell CEL bounds. That file is generated but no CI step checks it is current. I deliberately did not add that gate here — bundling a CI-policy change into a security fix makes the fix harder to review — but it is worth a follow-up.

Merge skew with #296

#296 deletes errRemoteControlCredentialInvalid and routes every credential failure to a single RemoteControlCredentialUnavailable reason. The new return here wraps that sentinel and sits in a block #296 rewrites, so whichever lands second drops the wrap — after #296 the uniform reason already applies. One-identifier resolution, in code #296 is touching anyway.

---

Skew note refreshed (main @ 3ca522c). This PR's own merged HEAD against current main is green — build, go vet, and ./internal/controller/... ./pkg/... (8 packages, no failures).

The #296 resolution written above was derived against d83de6e and is stale: #296 no longer compiles against main on its own, because #300 added a new use of the constant #296 deletes (see #296 for the one-line fix). The resolution here will be re-derived once #296 is rebased. Nothing to do on this branch.