Skip to main content

Security & Hardening

CoderFlow runs AI agents inside Docker containers that hold credentials for your source code, your IBM i systems, and your AI providers. This page covers how to deploy it safely, how to verify your setup from the outside, and how to limit the damage if a container is ever compromised.

If you read only one section, read the first one. It describes a Docker behavior that has caused real-world incidents for administrators who reasonably believed their firewall protected them.

Docker Publishes Ports Around Your Firewall​

Host firewalls do not cover Docker published ports

When Docker publishes a container port, it inserts its own rules directly into the system's packet-forwarding chain. Those rules are evaluated before host firewalls such as ufw or firewalld ever see the traffic. A port published on all interfaces is reachable from the network even when your firewall says otherwise, and ufw status will not list it.

Never rely on a host firewall alone to protect a Docker host. Verify exposure from the outside, as shown below.

CoderFlow task containers publish ports for the in-browser editor and for application-server previews. These ports have no authentication of their own. All authentication happens in the CoderFlow server, which proxies browser traffic to them. CoderFlow binds all published container ports to 127.0.0.1, so they are reachable only by the CoderFlow server on the same host and never from the network.

Verify From the Outside​

Configuration review is not verification. Test what the network can actually reach:

  1. Port scan the host from outside its network (for example from a machine on a different network, or a cloud shell):

    nmap -p- your-server.example.com

    Only the ports you intentionally expose should appear, typically SSH and the CoderFlow server or reverse-proxy port. If unexpected high-numbered ports (32768 and up) appear, container ports are exposed.

  2. Confirm authentication is enforced on everything that is reachable:

    curl -i https://your-server.example.com/tasks

    The response must be a 401 or a redirect to the login page, never task data.

Repeat this check after Docker or CoderFlow upgrades and after firewall changes.

Run the CoderFlow server on a private network, not on the public internet. Remote users should reach it through your VPN. This removes the entire class of internet-borne attacks regardless of any single component's configuration.

Some integrations need inbound traffic from the internet (Git webhooks, Slack, Microsoft Teams, inbound automation webhooks). Do not expose the whole server for them:

  • Use the dedicated webhook-only ingress listener for inbound automation webhooks, or the messaging-integrations listener for Slack and Teams. These serve only their integration endpoints on a separate port, so only that port needs to be reachable from the internet.
  • For internet-exposed webhooks, configure a signature scheme so deliveries are cryptographically verified, and restrict source IPs at your firewall or reverse proxy where practical.

If you must expose the web UI itself to the internet, put it behind a TLS-terminating reverse proxy with trusted proxy headers enabled, and require MFA or SSO for all users.

Limit What a Compromised Container Can Reach​

Task containers execute agent-driven code, including dependencies fetched from package registries. Treat them as semi-trusted: assume one could eventually run hostile code, and limit what that code can reach.

Docker provides the DOCKER-USER firewall chain for exactly this. Rules there apply to container traffic leaving the host and are not overwritten by Docker. Rules are evaluated top to bottom, so add the allows first:

# Allow the specific internal hosts your environments need
# (IBM i systems, internal Git hosts, and so on; repeat per host)
sudo iptables -A DOCKER-USER -d 203.0.113.10 -j RETURN

# Block the cloud metadata service (always safe; prevents credential
# theft from the hosting platform on AWS/Azure/GCP and similar)
sudo iptables -A DOCKER-USER -d 169.254.169.254 -j REJECT

# Block the rest of your internal address space so a compromised
# container cannot scan or pivot into the LAN
sudo iptables -A DOCKER-USER -d 10.0.0.0/8 -j REJECT
sudo iptables -A DOCKER-USER -d 172.16.0.0/12 -j REJECT
sudo iptables -A DOCKER-USER -d 192.168.0.0/16 -j REJECT

Notes:

  • DOCKER-USER affects routed traffic only. Container traffic to the CoderFlow server on the same host is delivered locally and keeps working, so credential and task services are unaffected.
  • Adjust the allow list to your environment: containers legitimately need to reach the IBM i systems and internal Git hosts configured in your environments' connections. After adding rules, run a task that uses each connection to confirm.
  • iptables rules do not survive a reboot on their own. Persist them with your distribution's mechanism (for example iptables-persistent on Debian/Ubuntu).

Credentials Inside Task Containers​

Connections marked Available For: Tasks or Deploy are injected into every task or deployment container in their environment, along with Git credentials and AI provider authentication. Any code running in such a container can read them. Plan accordingly:

  • Use Automation-only connections for background jobs. They are read by server-side automations and never injected into any container. This matters most for connections with broad IBM i authority.
  • Scope what you inject. Use IBM i profiles with the least authority the tasks actually need, and Git provider credentials limited to the repositories in the environment. Avoid injecting build or deploy credentials into interactive task environments that do not deploy.
  • Prefer separate environments over one broad one. Credentials are injected per environment, so an environment with fewer connections exposes less.

If You Suspect a Container Was Compromised​

  1. Stop the container (Administration → Containers), but keep it for investigation. Do not delete it immediately.
  2. Rotate everything that was reachable from inside it:
    • IBM i credentials (SSH keys and passwords) for the environment's connections
    • Git provider credentials and tokens
    • AI provider API keys and OAuth sessions
    • CoderFlow user passwords and API keys, if the server itself may have been reached
  3. Check other containers and the host for unexpected processes and outbound connections (docker stats and docker top help; sustained maximum CPU in an idle task is a classic sign of a crypto-miner).
  4. Re-verify network exposure from the outside, as described above, before returning to normal operation.

Host Sizing and Monitoring​

There are currently no per-container CPU or memory limits, so a runaway or abusive workload competes with everything else on the host. Size the host per Server Requirements, and watch the Administration → Health panel: sustained unexplained CPU or memory pressure with no active tasks warrants a look at docker stats.

Keep the Server Updated​

Security fixes ship as regular releases. Check Administration → Health → Check for Updates, or enable web-managed updates in Server Settings → Update Management to apply them from the browser. Review the release notes for security-relevant changes.