Restricted networks

Everything on this page is optional and off by default. A cluster with ordinary outbound internet access needs none of it.

What the agent actually needs

	Value
Direction	Outbound only. The agent dials out; nothing ever connects to it. There is no Service, no Ingress and no container port
Destination	Seylo’s host — the one in the server URL
Port	443 for wss://
Protocol	HTTPS upgraded to a WebSocket (GET /agent/connect)
Connections	One, long-lived, re-established with backoff when it drops
Also needed	In-cluster DNS for Seylo’s hostname, and the Kubernetes API server via the ServiceAccount
Not needed	Any inbound rule, any public API endpoint, any cloud credential, any registry access at runtime — only at image pull

A single egress allow-rule to portal.seylo.in:443 is sufficient.

If you use NetworkPolicies, the agent’s namespace needs an egress policy permitting that host plus DNS to CoreDNS on 53.

Through an HTTP forward proxy

The agent honours the conventional variables and tunnels its WebSocket through the proxy with CONNECT.

Variable	Helm value	Meaning
AGENT_PROXY_URL	proxy.url or proxy.existingSecret	Explicit override. Wins over the ambient variables, so the chart can set it without fighting a cluster-wide HTTPS_PROXY injected by a webhook
HTTPS_PROXY / https_proxy	—	Standard. Uppercase wins over lowercase
HTTP_PROXY / http_proxy	—	Standard, used when neither of the above is set
NO_PROXY / no_proxy	proxy.noProxy	Bypass list. A match wins over everything, including the explicit override

Precedence, exactly:

1. NO_PROXY matches the server host → direct connection. This beats every proxy variable, because “do not proxy this host” is the more specific instruction.
2. AGENT_PROXY_URL
3. HTTPS_PROXY, then https_proxy
4. HTTP_PROXY, then http_proxy
5. Nothing set → direct connection.

A proxy value that cannot be parsed as an http(s) URL is not silently ignored. It is reported as config-proxy-url-malformed, and the agent says it is connecting directly instead.

NO_PROXY grammar

Comma- or whitespace-separated, case-insensitive.

Entry	Matches
*	Everything — never use the proxy
tool.corp.local	That exact host and any subdomain of it
.corp.local	corp.local and every subdomain
corp.local	corp.local and tool.corp.local, but not notcorp.local — the label boundary is respected
tool.corp.local:8443	That host only on that port
10.1.2.3, [fd00::1]	IP literals, exact
10.0.0.0/8, fd00::/8	CIDR — only when the target host is itself an IP literal
empty / whitespace	Nothing

Host names are never resolved to decide a bypass

A DNS lookup inside a bypass rule would be a surprising side effect, and it would change behaviour whenever DNS changed. A CIDR entry therefore applies only when the target is written as an IP address.

Proxy authentication

Taken from the userinfo in the proxy URL and sent as Proxy-Authorization:

--set proxy.url='http://svc-agent:s3cr3t@proxy.corp.local:3128'

Prefer an existing Secret. A Deployment’s environment is readable by anyone who can read the Deployment, which is a wider set of people than you think:

--set proxy.existingSecret=agent-proxy-url

TLS inspection and private certificate authorities

If your egress proxy terminates and re-signs TLS, the agent sees a certificate signed by your CA, not a public one. That produces tls-unknown-ca.

The fix is to give the agent your CA bundle:

# Let the chart create the Secret from a local file.
--set-file ca.pem=/path/to/corp-ca.pem

# Or reference one that already exists, e.g. managed by an external secret store.
--set ca.existingSecret=corp-ca-bundle

Do not disable verification instead

Turning TLS verification off makes the symptom go away and leaves you unable to detect the next problem. Mounting the CA bundle establishes trust; disabling verification removes the check. The agent logs a standing warning in the second case for exactly this reason.

Air-gapped clusters

A fully air-gapped cluster — no egress to Seylo at all — cannot be managed by the agent. The agent’s whole design is one outbound connection; with no path out, there is nothing to invert.

Mirroring the image into an internal registry solves the image pull, not the connection. If your cluster can reach Seylo through a proxy, you are not air-gapped in the sense that matters here, and the proxy configuration above is what you need.

Mirroring the image

If policy requires images to come from your own registry, the image and chart can both be mirrored. The digest is what makes this safe to verify: copy the image, record the digest, and confirm it is unchanged on the far side before installing.

Pass your mirror to the chart with --set image.repository=…, plus an image pull secret if your registry requires authentication. The published upstream image is public specifically so that a mirror is a choice rather than a requirement.