Reject untrusted pool spec.apiUrl (SSRF / secret exfiltration)

[staging-devin-ai-integration]

Summary

spec.apiUrl was taken verbatim from the OutpostPool and paired with the value of whatever Secret the pool named in spec.tokenSecretRef, which the operator reads with its cluster-wide-read ServiceAccount. Anyone who could create an OutpostPool therefore made the operator a confused deputy: point apiUrl at their own host, reference any Secret in the namespace, and the first reconcile ships that Secret's plaintext value to them in the Authorization: Bearer header of the list/watch/claim/release calls (plus arbitrary SSRF from inside the cluster network).

The operator now only talks to URLs it trusts:

// OperatorConfig
pub api_url_allowlist: Vec<String>,          // DEVIN_API_URL_ALLOWLIST (comma-separated)

pub fn resolve_api_url(&self, pool_api_url: Option<&str>) -> Result<String> {
    // None => default_api_url; Some(url) must equal default_api_url or an
    // allowlist entry (compared after trim + trailing-'/' strip, the same
    // canonical form OutpostsClient requests against)
    // otherwise Error::ApiUrlNotAllowed
}

apply() and cleanup() call resolve_api_url before pool_token(), so a pool naming an untrusted URL never even triggers a Secret read (and no request is made to that host, not even a release during deletion); the pool goes Degraded with ApiUrlNotAllowed on its Ready condition. Exact-match against operator config is deliberate — it also kills the usual bypass classes (scheme downgrade, suffix hosts like api.devin.ai.attacker.tld, userinfo @, metadata IPs), which are covered in the new resolve_api_url_accepts_only_trusted_urls test.

Default behaviour is unchanged for pools that omit apiUrl or set it to the operator's default. A pool that legitimately needs another endpoint requires a cluster admin to add it to the chart's new operator.apiUrlAllowlist (rendered into DEVIN_API_URL_ALLOWLIST), which is exactly the admin approval the vulnerability was missing.

Note: the finding's other suggestions (constraining which Secrets a pool may reference, narrowing the operator's secret-read RBAC) are not in this PR — with the URL pinned to operator config, the token can only ever go to a trusted Devin endpoint, so the exfiltration path is closed; happy to follow up on those as defense in depth.

I could not compile or run the test suite locally: this session's network policy only allows the git manager, so the pinned toolchain and the crates proxy (pkg.cognition.build) are unreachable. cargo fmt was run; CI covers clippy/check/test and the CRD-up-to-date diff (the regenerated apiUrl description was hand-edited to match the doc comment since crdgen also needs to build).

Link to Devin session: https://staging.itsdev.in/sessions/988d59cf133b405aa98b86a2a854daad

---

Devin Review

Status	Commit
⚪ Not started	—

Run Devin Review

[staging-devin-ai-integration]

Prompt hidden (unlisted session)

[staging-devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

⚙️ Control Options:

• Disable automatic comment, CI, and merge conflict monitoring