…gres.urlSecretName); require encryption key (#331)
* fix(rr): stop agentSandbox externalSecret.name from hijacking postgres; require its encryption key
setting rr.agentSandbox.externalSecret.name (intended for the JWT keypair) silently
(a) routed the agent sandbox postgres connection to that secret's postgres-url key
and (b) coupled the encryption key to it. an existing deployment that just wanted to
reuse its backend postgres crashed at runtime with getaddrinfo ENOTFOUND.
- postgres now only reads from externalSecret when postgres.fromExternalSecret: true
(default false); otherwise it inherits the backend's config.postgresql connection,
even when externalSecret.name is set for the JWT
- require the agent sandbox encryption key (validateSecrets, mirroring the JWT keys):
the proxy derives the sandbox-iframe asset-token HMAC key from AGENT_SANDBOX_ENCRYPTION_KEY
and throws when serving a sandbox without it (agent_executor/proxy/src/config.ts
getAssetTokenHmacSecret), so 'optional' would surface as a green pod that fails at
first sandbox use. fail loudly at render instead.
- updated both validateSecrets fail hints to mention postgres.fromExternalSecret: true
- values.yaml (both copies): add postgres.fromExternalSecret, mark encryptionKey required, note 64 hex
- bump chart 6.11.1 -> 6.11.2; update ci fixtures to supply the now-required encryption key
and add fromExternalSecret: true to the Option-4 sandbox fixture
* Respect postgres.passwordSecretName in presence of rr.agentSandbox.externalSecret
(cherry picked from commit 38304c0)
* refactor(rr): replace postgres.fromExternalSecret with postgres.urlSecretName
the fromExternalSecret boolean was redundant with the existing Option-3
postgres.urlSecretName/urlSecretKey: 'read postgres-url from externalSecret.name'
is identical to pointing urlSecretName at that same secret (urlSecretKey already
defaults to postgres-url). drop the bespoke flag and the externalSecret postgres
branch entirely, so externalSecret.name covers ONLY the JWT/encryption keys and
never sources postgres.
- remove rr.agentSandbox.postgres.fromExternalSecret (both values.yaml copies)
- postgresUrlEnv: delete the externalSecret postgres branch; move the
passwordSecretName PGPASSWORD support (#332) into the urlSecretName branch, so
'DSN from a secret + auto-rotated password from another secret' uses Option 3
- validateSecrets: drop the externalSecret term from $explicitPg; repoint both
fail hints to postgres.urlSecretName
- ci: test-agent-sandbox-enabled-option uses postgres.urlSecretName (Option 3)
pointed at its JWT secret instead of the removed flag
* fix(rr): render blobStorage env onto the workflow worker
the agentExecutor / snapshotRetention temporal activities run on the
WORKFLOW_TEMPORAL_WORKER (registered in workflowsExecutor/onpremWorker) and read
snapshot blob storage via getBlobStoreForSnapshots (RR_SNAPSHOTS_* with an
RR_DEFAULT_* fallback). but gitServer.commonEnv was only injected onto the main
backend and the standalone git-server pod, so the worker had no RR_DEFAULT_*
and snapshot blob access failed there -- forcing operators to hand-plumb
RR_SNAPSHOTS_* via env.
include gitServer.commonEnv on the worker when rr.gitServer.enabled (no
git-server host/port split -- the worker is a blob-storage client, not the git
server). self-guards on rr.blobStorage being set, so it no-ops otherwise.
* chore(rr): bump chart version to 6.11.3 (rebased past #333)
---------
Co-authored-by: Ryan Artecona <ryanartecona@gmail.com>
Adds typed MCP configuration for AGENT_SANDBOX_JWT_PRIVATE_KEY, supporting both inline values and Kubernetes Secret references. Documents the new mcp.config keys in both synced values files and adds CI overlays for inline and secret-backed rendering. Bumps the chart patch version to 6.11.2. Validated with Helm render checks, targeted helm lint, a full CI option render sweep, and the values sync diff.