EGRESS_PROXY_DEFAULT and EGRESS_PROXY_<BOT> are documented in docs/configuration.md:194-195 as how a Bot gets a stable outbound address. The chart added in #235 names neither, anywhere: grep -rn EGRESS_PROXY charts/ returns nothing, and rendering any of the five ci/ targets produces no egress variable in the computer's environment. A Helm deployment therefore resolves every Bot to no proxy and leaves directly, and nothing in the chart or its README says the setting exists.
They are settable, which makes this narrower than it first looks. computers.extraEnv is concatenated into the computer's env in both arrangements, and I confirmed each by rendering:
- shared,
charts/openbot/templates/computer/statefulset.yaml:138 -> EGRESS_PROXY_DEFAULT lands in the StatefulSet
- sandbox,
_helpers.tpl openbot.sandboxPodTemplate -> EGRESS_PROXY_SALES_BOT lands in the mounted pod template
Per-Bot still works in sandbox mode even though every pod gets the same list, because egressFor keys on the Bot named in the request (agent-computer/src/egress.ts:42). So the chart's plumbing is fine and the gap is that nobody is told about it.
The second half is worse than the first. With networkPolicy.enabled, the computer's egress rules allow ports 80 and 443 to 0.0.0.0/0 minus 10/8, 172.16/12, 192.168/16 and 169.254/16 (charts/openbot/templates/networkpolicy.yaml:115-136). Proxies do not generally live there: they sit on a private address, or on 3128 or 8080, or both. So an operator who works out computers.extraEnv for themselves gets a Bot that fails on every page, which reads as a broken browser rather than as a network rule, unless they also find networkPolicy.computerExtraEgress. Both ci/self-hosted-values.yaml and ci/eks-sandbox-values.yaml enable the policy and neither sets that list, so the deployments most likely to want per-Bot egress are exactly the ones that hit this.
Two smaller notes from the same read. The chart never deploys supervisor/, so the EGRESS_PROXY passthrough at supervisor/src/index.ts:71 is Docker-only and has no Kubernetes counterpart, which is correct but worth stating. And docs/configuration.md has no Kubernetes section at all, so the chart README is the only place this can be documented.
This is the Kubernetes counterpart of #249, not a duplicate: there the variables reached no process at all, here they reach the right process once you know the incantation.
I have a branch that documents both settings in values.yaml and the README with a worked example, and refuses at install a proxy the policy provably blocks, by port or by literal private address, naming networkPolicy.computerExtraEgress. A private DNS name on 443 is blocked the same way and cannot be told from a public one at template time, so that case is deliberately missed rather than guessed at. PR to follow.
EGRESS_PROXY_DEFAULTandEGRESS_PROXY_<BOT>are documented indocs/configuration.md:194-195as how a Bot gets a stable outbound address. The chart added in #235 names neither, anywhere:grep -rn EGRESS_PROXY charts/returns nothing, and rendering any of the fiveci/targets produces no egress variable in the computer's environment. A Helm deployment therefore resolves every Bot to no proxy and leaves directly, and nothing in the chart or its README says the setting exists.They are settable, which makes this narrower than it first looks.
computers.extraEnvis concatenated into the computer's env in both arrangements, and I confirmed each by rendering:charts/openbot/templates/computer/statefulset.yaml:138->EGRESS_PROXY_DEFAULTlands in the StatefulSet_helpers.tplopenbot.sandboxPodTemplate->EGRESS_PROXY_SALES_BOTlands in the mounted pod templatePer-Bot still works in sandbox mode even though every pod gets the same list, because
egressForkeys on the Bot named in the request (agent-computer/src/egress.ts:42). So the chart's plumbing is fine and the gap is that nobody is told about it.The second half is worse than the first. With
networkPolicy.enabled, the computer's egress rules allow ports 80 and 443 to0.0.0.0/0minus10/8,172.16/12,192.168/16and169.254/16(charts/openbot/templates/networkpolicy.yaml:115-136). Proxies do not generally live there: they sit on a private address, or on 3128 or 8080, or both. So an operator who works outcomputers.extraEnvfor themselves gets a Bot that fails on every page, which reads as a broken browser rather than as a network rule, unless they also findnetworkPolicy.computerExtraEgress. Bothci/self-hosted-values.yamlandci/eks-sandbox-values.yamlenable the policy and neither sets that list, so the deployments most likely to want per-Bot egress are exactly the ones that hit this.Two smaller notes from the same read. The chart never deploys
supervisor/, so theEGRESS_PROXYpassthrough atsupervisor/src/index.ts:71is Docker-only and has no Kubernetes counterpart, which is correct but worth stating. Anddocs/configuration.mdhas no Kubernetes section at all, so the chart README is the only place this can be documented.This is the Kubernetes counterpart of #249, not a duplicate: there the variables reached no process at all, here they reach the right process once you know the incantation.
I have a branch that documents both settings in
values.yamland the README with a worked example, and refuses at install a proxy the policy provably blocks, by port or by literal private address, namingnetworkPolicy.computerExtraEgress. A private DNS name on 443 is blocked the same way and cannot be told from a public one at template time, so that case is deliberately missed rather than guessed at. PR to follow.