Compare commits
2 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
 didericis
|
7644da4280 | ||
|
didericis
|
13e4af421d |
@@ -0,0 +1,360 @@
|
||||
# Apple Container networking spike
|
||||
|
||||
Issue: https://gitea.dideric.is/didericis/bot-bottle/issues/230
|
||||
|
||||
## Summary
|
||||
|
||||
Apple Container 1.0.0 on macOS 26 can support the core two-network
|
||||
sidecar shape, but not as a drop-in Docker Compose clone.
|
||||
|
||||
The viable shape is:
|
||||
|
||||
- agent container on one `--internal` host-only network;
|
||||
- sidecar bundle container on both the NAT egress network and the
|
||||
host-only agent network;
|
||||
- sidecar network flags ordered with the NAT network first, because
|
||||
Apple Container chooses the first network as the default route;
|
||||
- explicit DNS on the sidecar, because the tested NAT gateway routed
|
||||
packets but did not resolve DNS;
|
||||
- agent talks to sidecar by the sidecar's host-only-network IP, not by
|
||||
container name or host-published loopback alias.
|
||||
|
||||
This is enough to unblock a cautious `macos-container` launch spike if
|
||||
the backend records inspect-derived IPs and avoids depending on Docker
|
||||
Compose-style aliases. It is not enough to reuse the Docker backend's
|
||||
service-name assumptions unchanged.
|
||||
|
||||
## Local Environment
|
||||
|
||||
Tested on 2026-06-10:
|
||||
|
||||
```console
|
||||
$ sw_vers
|
||||
ProductName: macOS
|
||||
ProductVersion: 26.5.1
|
||||
BuildVersion: 25F80
|
||||
|
||||
$ uname -m
|
||||
arm64
|
||||
|
||||
$ container --version
|
||||
container CLI version 1.0.0 (build: release, commit: ee848e3)
|
||||
|
||||
$ container system version --format json
|
||||
[
|
||||
{
|
||||
"appName": "container",
|
||||
"buildType": "release",
|
||||
"commit": "ee848e3ebfd7c73b04dd419683be54fb450b8779",
|
||||
"version": "1.0.0"
|
||||
},
|
||||
{
|
||||
"appName": "container-apiserver",
|
||||
"buildType": "release",
|
||||
"commit": "ee848e3ebfd7c73b04dd419683be54fb450b8779",
|
||||
"version": "container-apiserver version 1.0.0 (build: release, commit: ee848e3)"
|
||||
}
|
||||
]
|
||||
|
||||
$ container system status --format json
|
||||
{
|
||||
"apiServerAppName": "container-apiserver",
|
||||
"apiServerBuild": "release",
|
||||
"apiServerCommit": "ee848e3ebfd7c73b04dd419683be54fb450b8779",
|
||||
"apiServerVersion": "container-apiserver version 1.0.0 (build: release, commit: ee848e3)",
|
||||
"appRoot": "/Users/didericis/Library/Application Support/com.apple.container/",
|
||||
"installRoot": "/usr/local/",
|
||||
"status": "running"
|
||||
}
|
||||
```
|
||||
|
||||
Apple Container was installed from the official signed 1.0.0 GitHub
|
||||
release package, `container-1.0.0-installer-signed.pkg`. The package was
|
||||
signed by `Developer ID Installer: Apple Inc. - Containerization
|
||||
(UPBK2H6LZM)` and notarized by Apple.
|
||||
|
||||
## Commands Run
|
||||
|
||||
Create the networks:
|
||||
|
||||
```bash
|
||||
container network create bb-spike-230-agent \
|
||||
--internal \
|
||||
--label bot-bottle.spike=apple-container-networking
|
||||
|
||||
container network create bb-spike-230-egress \
|
||||
--label bot-bottle.spike=apple-container-networking
|
||||
```
|
||||
|
||||
`container network inspect bb-spike-230-agent bb-spike-230-egress`
|
||||
showed:
|
||||
|
||||
```json
|
||||
[
|
||||
{
|
||||
"configuration": {
|
||||
"labels": {"bot-bottle.spike": "apple-container-networking"},
|
||||
"mode": "hostOnly",
|
||||
"name": "bb-spike-230-agent",
|
||||
"plugin": "container-network-vmnet"
|
||||
},
|
||||
"id": "bb-spike-230-agent",
|
||||
"status": {
|
||||
"ipv4Gateway": "192.168.128.1",
|
||||
"ipv4Subnet": "192.168.128.0/24"
|
||||
}
|
||||
},
|
||||
{
|
||||
"configuration": {
|
||||
"labels": {"bot-bottle.spike": "apple-container-networking"},
|
||||
"mode": "nat",
|
||||
"name": "bb-spike-230-egress",
|
||||
"plugin": "container-network-vmnet"
|
||||
},
|
||||
"id": "bb-spike-230-egress",
|
||||
"status": {
|
||||
"ipv4Gateway": "192.168.66.1",
|
||||
"ipv4Subnet": "192.168.66.0/24"
|
||||
}
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
Repeated `--network` flags are accepted. With the agent network first,
|
||||
the sidecar got two interfaces but the default route pointed at the
|
||||
host-only gateway, so egress failed:
|
||||
|
||||
```bash
|
||||
container run --name bb-spike-230-sidecar \
|
||||
--label bot-bottle.spike=apple-container-networking \
|
||||
--network bb-spike-230-agent \
|
||||
--network bb-spike-230-egress \
|
||||
--detach --rm docker.io/python:alpine \
|
||||
sh -c 'mkdir -p /srv && printf ok >/srv/index.html && cd /srv && python3 -m http.server 80 --bind 0.0.0.0'
|
||||
|
||||
container exec bb-spike-230-sidecar sh -c 'ip route && cat /etc/resolv.conf'
|
||||
```
|
||||
|
||||
Observed:
|
||||
|
||||
```console
|
||||
default via 192.168.128.1 dev eth0
|
||||
192.168.66.0/24 dev eth1 scope link src 192.168.66.3
|
||||
192.168.128.0/24 dev eth0 scope link src 192.168.128.3
|
||||
nameserver 192.168.128.1
|
||||
```
|
||||
|
||||
With the NAT network first and explicit DNS, the sidecar can egress:
|
||||
|
||||
```bash
|
||||
container run --name bb-spike-230-sidecar \
|
||||
--label bot-bottle.spike=apple-container-networking \
|
||||
--network bb-spike-230-egress \
|
||||
--network bb-spike-230-agent \
|
||||
--dns 1.1.1.1 \
|
||||
--detach docker.io/python:alpine \
|
||||
sh -c 'mkdir -p /srv && printf ok >/srv/index.html && cd /srv && python3 -m http.server 80 --bind 0.0.0.0'
|
||||
|
||||
container exec bb-spike-230-sidecar sh -c 'ip route; cat /etc/resolv.conf; wget -T 8 -O- https://example.com'
|
||||
```
|
||||
|
||||
Observed:
|
||||
|
||||
```console
|
||||
default via 192.168.66.1 dev eth0
|
||||
192.168.66.0/24 dev eth0 scope link src 192.168.66.5
|
||||
192.168.128.0/24 dev eth1 scope link src 192.168.128.7
|
||||
nameserver 1.1.1.1
|
||||
Connecting to example.com (172.66.147.243:443)
|
||||
... 100%
|
||||
```
|
||||
|
||||
Start an agent only on the host-only network:
|
||||
|
||||
```bash
|
||||
container run --name bb-spike-230-agent \
|
||||
--label bot-bottle.spike=apple-container-networking \
|
||||
--network bb-spike-230-agent \
|
||||
--detach docker.io/alpine:latest sleep 600
|
||||
```
|
||||
|
||||
Agent network probes:
|
||||
|
||||
```bash
|
||||
container exec bb-spike-230-agent sh -c '
|
||||
ip route
|
||||
cat /etc/resolv.conf
|
||||
wget -T 5 -O- http://192.168.128.7
|
||||
wget -T 5 -O- http://bb-spike-230-sidecar || true
|
||||
ping -c 2 1.1.1.1 || true
|
||||
wget -T 5 -O- https://example.com || true
|
||||
'
|
||||
```
|
||||
|
||||
Observed:
|
||||
|
||||
```console
|
||||
default via 192.168.128.1 dev eth0
|
||||
192.168.128.0/24 dev eth0 scope link src 192.168.128.8
|
||||
nameserver 192.168.128.1
|
||||
Connecting to 192.168.128.7 (192.168.128.7:80)
|
||||
ok
|
||||
wget: bad address 'bb-spike-230-sidecar'
|
||||
2 packets transmitted, 0 packets received, 100% packet loss
|
||||
wget: bad address 'example.com'
|
||||
```
|
||||
|
||||
Host-published loopback aliases work and are constrained to the bound
|
||||
alias on the host:
|
||||
|
||||
```bash
|
||||
container run --name bb-spike-230-sidecar-alias \
|
||||
--label bot-bottle.spike=apple-container-networking \
|
||||
--network bb-spike-230-egress \
|
||||
--network bb-spike-230-agent \
|
||||
--dns 1.1.1.1 \
|
||||
--publish 127.0.0.31:18080:80 \
|
||||
--detach docker.io/python:alpine \
|
||||
sh -c 'mkdir -p /srv && printf ok >/srv/index.html && cd /srv && python3 -m http.server 80 --bind 0.0.0.0'
|
||||
|
||||
curl -fsS --max-time 5 http://127.0.0.31:18080
|
||||
curl -fsS --max-time 5 http://127.0.0.1:18080
|
||||
lsof -nP -iTCP:18080 -sTCP:LISTEN
|
||||
```
|
||||
|
||||
Observed:
|
||||
|
||||
```console
|
||||
$ curl -fsS --max-time 5 http://127.0.0.31:18080
|
||||
ok
|
||||
|
||||
$ curl -fsS --max-time 5 http://127.0.0.1:18080
|
||||
curl: (7) Failed to connect to 127.0.0.1 port 18080 after 0 ms: Couldn't connect to server
|
||||
|
||||
$ lsof -nP -iTCP:18080 -sTCP:LISTEN
|
||||
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
|
||||
container 17908 didericis 25u IPv4 ... 0t0 TCP 127.0.0.31:18080 (LISTEN)
|
||||
```
|
||||
|
||||
The guest cannot reach that host loopback-published listener through
|
||||
the host-only gateway or through its own loopback address:
|
||||
|
||||
```bash
|
||||
container exec bb-spike-230-agent sh -c '
|
||||
wget -T 5 -O- http://192.168.128.10
|
||||
wget -T 5 -O- http://192.168.128.1:18080 || true
|
||||
wget -T 5 -O- http://127.0.0.31:18080 || true
|
||||
wget -T 5 -O- http://bb-spike-230-sidecar-alias || true
|
||||
'
|
||||
```
|
||||
|
||||
Observed:
|
||||
|
||||
```console
|
||||
Connecting to 192.168.128.10 (192.168.128.10:80)
|
||||
ok
|
||||
Connecting to 192.168.128.1:18080 (192.168.128.1:18080)
|
||||
wget: can't connect to remote host (192.168.128.1): Connection refused
|
||||
Connecting to 127.0.0.31:18080 (127.0.0.31:18080)
|
||||
wget: can't connect to remote host (127.0.0.31): Connection refused
|
||||
wget: bad address 'bb-spike-230-sidecar-alias'
|
||||
```
|
||||
|
||||
## Answers
|
||||
|
||||
### 1. Does `container network create --internal` prevent outbound internet access?
|
||||
|
||||
Yes in this run. `--internal` produced a `hostOnly` network. An
|
||||
internal-only agent had a default route to the host-only gateway, but
|
||||
could not ping `1.1.1.1` and could not resolve or fetch
|
||||
`https://example.com`.
|
||||
|
||||
### 2. Can `container run` attach one container to multiple networks?
|
||||
|
||||
Yes. Repeated `--network` flags produced multiple interfaces and the
|
||||
inspect JSON preserved both network attachments.
|
||||
|
||||
Important caveat: network order matters. The first network became
|
||||
`eth0`, supplied the default route, and supplied `/etc/resolv.conf`.
|
||||
For a sidecar that needs internet egress, put the NAT network first and
|
||||
the internal agent network second.
|
||||
|
||||
### 3. Can the sidecar bundle sit on both an internal agent network and an egress-capable network?
|
||||
|
||||
Yes. The sidecar had a NAT interface and a host-only interface. With the
|
||||
NAT network first and explicit DNS, it could fetch `https://example.com`
|
||||
while the agent on only the host-only network could not.
|
||||
|
||||
### 4. Can Apple Container provide stable network aliases or service discovery equivalent to Docker Compose aliases?
|
||||
|
||||
Not by default in this run. The agent could not resolve
|
||||
`bb-spike-230-sidecar` or `bb-spike-230-sidecar-alias`, even though
|
||||
those were the container names and hostnames in inspect output. The
|
||||
agent could reach the sidecar by the sidecar's host-only-network IP.
|
||||
|
||||
The backend should not assume Docker Compose-style aliases. It should
|
||||
read the sidecar's host-only IP from `container inspect` and inject
|
||||
that concrete endpoint into the agent environment/config, or run a
|
||||
small internal DNS/hosts-file setup as an explicit backend feature.
|
||||
|
||||
### 5. Can a published sidecar port bound to a per-bottle loopback alias be reached from another Apple Container guest and constrained to that alias?
|
||||
|
||||
Host-side alias binding works and is constrained on the host:
|
||||
`127.0.0.31:18080` reached the sidecar, while `127.0.0.1:18080` failed.
|
||||
|
||||
Guest-to-host-published-loopback did not work. From the agent,
|
||||
`192.168.128.1:18080` and `127.0.0.31:18080` both failed. For
|
||||
agent-to-sidecar traffic, use the sidecar's internal network IP rather
|
||||
than a host-published loopback alias.
|
||||
|
||||
### 6. What structured output is available for robust enumeration and cleanup?
|
||||
|
||||
Confirmed structured output:
|
||||
|
||||
- `container list --all --format json`
|
||||
- `container inspect <container...>` as JSON
|
||||
- `container image inspect <image...>` as JSON
|
||||
- `container network list --format json`
|
||||
- `container network inspect <network...>` as JSON
|
||||
- `container system status --format json`
|
||||
- `container system version --format json`
|
||||
|
||||
Useful fields observed:
|
||||
|
||||
- containers: `id`, `configuration.labels`,
|
||||
`configuration.networks`, `configuration.publishedPorts`,
|
||||
`status.state`, `status.networks[].network`,
|
||||
`status.networks[].ipv4Address`, `status.networks[].ipv4Gateway`;
|
||||
- networks: `id`, `configuration.name`, `configuration.labels`,
|
||||
`configuration.mode`, `status.ipv4Gateway`, `status.ipv4Subnet`;
|
||||
- images: `id`, `configuration.name`, `configuration.descriptor`,
|
||||
`variants[].platform`, `variants[].size`.
|
||||
|
||||
### 7. Are labels supported on containers and networks enough to replace prefix-only discovery?
|
||||
|
||||
Labels are present in container and network inspect/list JSON, so they
|
||||
are sufficient as metadata if the backend lists resources and filters
|
||||
client-side. I did not find or validate a server-side label filter for
|
||||
`container list` or `container network list`.
|
||||
|
||||
## Recommendation
|
||||
|
||||
Proceed with a narrow `macos-container` launch prototype, but encode
|
||||
the Apple Container-specific constraints directly:
|
||||
|
||||
- create one host-only agent network and one NAT egress network per
|
||||
bottle;
|
||||
- start the sidecar bundle with `--network <egress>` before
|
||||
`--network <agent>`;
|
||||
- set sidecar DNS explicitly, ideally from the bottle/host policy
|
||||
rather than hardcoding a public resolver;
|
||||
- start the agent only on the host-only network;
|
||||
- discover the sidecar's host-only IP from `container inspect` and pass
|
||||
concrete URLs to the agent;
|
||||
- use host loopback publishing only for host-to-sidecar access, not
|
||||
guest-to-sidecar access;
|
||||
- enumerate and clean up by labels plus name prefixes until/unless the
|
||||
CLI adds label filters.
|
||||
|
||||
Do not implement the backend as a direct clone of Docker Compose
|
||||
service aliases. That assumption failed in this run.
|
||||
@@ -0,0 +1,476 @@
|
||||
# Apple Container transparent egress spike
|
||||
|
||||
Issue: https://gitea.dideric.is/didericis/bot-bottle/issues/230#issuecomment-1994
|
||||
|
||||
## Summary
|
||||
|
||||
Transparent egress is mechanically possible on Apple Container 1.0.0,
|
||||
but it is not a free property of the platform and it is not a drop-in
|
||||
replacement for `HTTP_PROXY` yet.
|
||||
|
||||
The spike proved two separate things:
|
||||
|
||||
- Plain routing/NAT works if the sidecar has `CAP_NET_ADMIN`, IP
|
||||
forwarding, and masquerade rules, and if the agent default route is
|
||||
changed to the sidecar's host-only-network IP.
|
||||
- Transparent mitmproxy interception works if the sidecar redirects
|
||||
agent-facing TCP 80/443 traffic to `mitmdump --mode transparent`.
|
||||
Direct HTTP was logged by mitmproxy. Direct HTTPS reached mitmproxy;
|
||||
it failed with normal certificate verification until the client
|
||||
skipped verification, which is consistent with bot-bottle's existing
|
||||
requirement that agents trust the sidecar CA.
|
||||
- Running DNS on the sidecar and pointing the agent at the sidecar's
|
||||
host-only IP also works. This is cleaner than relying on forwarded
|
||||
UDP DNS to a public resolver and gives the backend a natural place to
|
||||
enforce or observe DNS policy.
|
||||
|
||||
The hard blocker is agent routing. Apple Container 1.0.0 exposes no
|
||||
documented `--network` gateway option. An ordinary agent container
|
||||
cannot replace its default route:
|
||||
|
||||
```console
|
||||
$ container exec bb-spike-230t-agent sh -c \
|
||||
'ip route replace default via 192.168.128.2 dev eth0; ip route'
|
||||
default via 192.168.128.1 dev eth0
|
||||
192.168.128.0/24 dev eth0 scope link src 192.168.128.3
|
||||
ip: RTNETLINK answers: Operation not permitted
|
||||
```
|
||||
|
||||
The successful route-through-sidecar tests used `--cap-add
|
||||
CAP_NET_ADMIN` on the agent so the route could be changed after start.
|
||||
That is not an acceptable final design by itself: it expands the
|
||||
agent's kernel-facing privilege and lets the agent mutate its own
|
||||
network namespace. A production design needs either a backend-owned
|
||||
init/shim that sets the route then drops privilege in a way the agent
|
||||
cannot regain, a platform-supported gateway option, or a different
|
||||
network attachment layer.
|
||||
|
||||
## Environment
|
||||
|
||||
Tested on 2026-06-10:
|
||||
|
||||
```console
|
||||
$ sw_vers
|
||||
ProductName: macOS
|
||||
ProductVersion: 26.5.1
|
||||
BuildVersion: 25F80
|
||||
|
||||
$ uname -m
|
||||
arm64
|
||||
|
||||
$ container --version
|
||||
container CLI version 1.0.0 (build: release, commit: ee848e3)
|
||||
```
|
||||
|
||||
Apple Container system status:
|
||||
|
||||
```json
|
||||
{
|
||||
"apiServerAppName": "container-apiserver",
|
||||
"apiServerBuild": "release",
|
||||
"apiServerCommit": "ee848e3ebfd7c73b04dd419683be54fb450b8779",
|
||||
"apiServerVersion": "container-apiserver version 1.0.0 (build: release, commit: ee848e3)",
|
||||
"appRoot": "/Users/didericis/Library/Application Support/com.apple.container/",
|
||||
"installRoot": "/usr/local/",
|
||||
"status": "running"
|
||||
}
|
||||
```
|
||||
|
||||
## Baseline
|
||||
|
||||
Networks:
|
||||
|
||||
```bash
|
||||
container network create bb-spike-230t-agent \
|
||||
--internal \
|
||||
--label bot-bottle.spike=transparent-egress
|
||||
|
||||
container network create bb-spike-230t-egress \
|
||||
--label bot-bottle.spike=transparent-egress
|
||||
```
|
||||
|
||||
Sidecar, dual-homed with NAT first:
|
||||
|
||||
```bash
|
||||
container run --name bb-spike-230t-sidecar \
|
||||
--label bot-bottle.spike=transparent-egress \
|
||||
--network bb-spike-230t-egress \
|
||||
--network bb-spike-230t-agent \
|
||||
--dns 1.1.1.1 \
|
||||
--detach docker.io/alpine:latest sleep 1800
|
||||
```
|
||||
|
||||
Agent, host-only network:
|
||||
|
||||
```bash
|
||||
container run --name bb-spike-230t-agent \
|
||||
--label bot-bottle.spike=transparent-egress \
|
||||
--network bb-spike-230t-agent \
|
||||
--detach docker.io/alpine:latest sleep 1800
|
||||
```
|
||||
|
||||
Observed sidecar addresses:
|
||||
|
||||
```console
|
||||
eth0 192.168.66.2/24 # NAT egress network
|
||||
eth1 192.168.128.2/24 # host-only agent network
|
||||
default via 192.168.66.1 dev eth0
|
||||
nameserver 1.1.1.1
|
||||
```
|
||||
|
||||
Observed agent baseline:
|
||||
|
||||
```console
|
||||
eth0 192.168.128.3/24
|
||||
default via 192.168.128.1 dev eth0
|
||||
nameserver 192.168.128.1
|
||||
wget: bad address 'pypi.org'
|
||||
```
|
||||
|
||||
That confirms the previous spike's baseline: sidecar can egress, agent
|
||||
cannot egress directly.
|
||||
|
||||
## Plain NAT Test
|
||||
|
||||
Relaunch sidecar and agent with `CAP_NET_ADMIN`:
|
||||
|
||||
```bash
|
||||
container run --name bb-spike-230t-sidecar \
|
||||
--label bot-bottle.spike=transparent-egress \
|
||||
--network bb-spike-230t-egress \
|
||||
--network bb-spike-230t-agent \
|
||||
--dns 1.1.1.1 \
|
||||
--cap-add CAP_NET_ADMIN \
|
||||
--detach docker.io/alpine:latest sleep 1800
|
||||
|
||||
container run --name bb-spike-230t-agent \
|
||||
--label bot-bottle.spike=transparent-egress \
|
||||
--network bb-spike-230t-agent \
|
||||
--cap-add CAP_NET_ADMIN \
|
||||
--detach docker.io/alpine:latest sleep 1800
|
||||
```
|
||||
|
||||
Configure sidecar forwarding:
|
||||
|
||||
```bash
|
||||
container exec bb-spike-230t-sidecar sh -c '
|
||||
apk add --no-cache iptables iproute2
|
||||
sysctl -w net.ipv4.ip_forward=1
|
||||
iptables -t nat -A POSTROUTING -s 192.168.128.0/24 -o eth0 -j MASQUERADE
|
||||
iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT
|
||||
iptables -A FORWARD -i eth0 -o eth1 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
|
||||
'
|
||||
```
|
||||
|
||||
Point the agent at the sidecar:
|
||||
|
||||
```bash
|
||||
container exec bb-spike-230t-agent sh -c '
|
||||
ip route replace default via 192.168.128.4 dev eth0
|
||||
printf "nameserver 1.1.1.1\n" > /etc/resolv.conf
|
||||
'
|
||||
```
|
||||
|
||||
Normal direct PyPI fetch from the agent, with no proxy variables set:
|
||||
|
||||
```bash
|
||||
container exec bb-spike-230t-agent sh -c '
|
||||
for v in HTTP_PROXY HTTPS_PROXY http_proxy https_proxy ALL_PROXY all_proxy; do
|
||||
if [ -n "$(printenv "$v")" ]; then echo "$v=SET"; fi
|
||||
done
|
||||
wget -T 10 -O- https://pypi.org/simple/pip/ | head -c 120
|
||||
'
|
||||
```
|
||||
|
||||
Observed:
|
||||
|
||||
```console
|
||||
Connecting to pypi.org (151.101.0.223:443)
|
||||
<!DOCTYPE html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta name="pypi:repository-version" content="1.4">
|
||||
```
|
||||
|
||||
Sidecar NAT counters increased:
|
||||
|
||||
```console
|
||||
POSTROUTING MASQUERADE 3 packets / 168 bytes
|
||||
FORWARD eth1 -> eth0 22 packets / 2806 bytes
|
||||
FORWARD eth0 -> eth1 29 packets / 54781 bytes
|
||||
```
|
||||
|
||||
Verdict: plain transparent routing through the sidecar works, but this
|
||||
is only NAT. It does not apply bot-bottle's existing route allowlist,
|
||||
authorization stripping/injection, or DLP logic.
|
||||
|
||||
## Transparent Mitmproxy Test
|
||||
|
||||
The current sidecar launcher uses explicit proxy mode:
|
||||
|
||||
```sh
|
||||
MODE="--mode regular@9099"
|
||||
exec mitmdump $CONFDIR_FLAG $MODE $LISTEN_HOST_FLAG $TRUST_FLAG -s /app/egress_addon.py
|
||||
```
|
||||
|
||||
So transparent egress needs a launcher mode change plus iptables
|
||||
redirects.
|
||||
|
||||
Run a test mitmproxy container:
|
||||
|
||||
```bash
|
||||
container run --name bb-spike-230t-mitm \
|
||||
--label bot-bottle.spike=transparent-egress \
|
||||
--network bb-spike-230t-egress \
|
||||
--network bb-spike-230t-agent \
|
||||
--dns 1.1.1.1 \
|
||||
--cap-add CAP_NET_ADMIN \
|
||||
--detach mitmproxy/mitmproxy:11.1.3 \
|
||||
sh -c 'apt-get update >/tmp/apt.log &&
|
||||
apt-get install -y --no-install-recommends iptables iproute2 >>/tmp/apt.log &&
|
||||
echo 1 > /proc/sys/net/ipv4/ip_forward &&
|
||||
iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j REDIRECT --to-port 8080 &&
|
||||
iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 443 -j REDIRECT --to-port 8080 &&
|
||||
mitmdump --mode transparent@8080 --set showhost=true --set ssl_insecure=true --set confdir=/tmp/mitm -v'
|
||||
```
|
||||
|
||||
The container listened successfully:
|
||||
|
||||
```console
|
||||
Transparent Proxy listening at *:8080.
|
||||
```
|
||||
|
||||
It had an agent-facing address of `192.168.128.7`. Point the agent at
|
||||
it and set DNS:
|
||||
|
||||
```bash
|
||||
container exec bb-spike-230t-agent sh -c '
|
||||
ip route replace default via 192.168.128.7 dev eth0
|
||||
printf "nameserver 1.1.1.1\n" > /etc/resolv.conf
|
||||
'
|
||||
```
|
||||
|
||||
DNS also needs NAT/forwarding because only TCP 80/443 is redirected:
|
||||
|
||||
```bash
|
||||
container exec bb-spike-230t-mitm sh -c '
|
||||
iptables -t nat -A POSTROUTING -s 192.168.128.0/24 -o eth0 -j MASQUERADE
|
||||
iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT
|
||||
iptables -A FORWARD -i eth0 -o eth1 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
|
||||
'
|
||||
```
|
||||
|
||||
An alternative, and likely better, DNS shape is to run a DNS forwarder on
|
||||
the sidecar's host-only IP and point the agent at it. This was tested
|
||||
with `dnsmasq`:
|
||||
|
||||
```bash
|
||||
container exec bb-spike-230t-mitm sh -c '
|
||||
apt-get install -y --no-install-recommends dnsmasq
|
||||
cat >/tmp/dnsmasq.conf <<EOF
|
||||
no-daemon
|
||||
listen-address=192.168.128.7
|
||||
bind-interfaces
|
||||
server=1.1.1.1
|
||||
log-queries
|
||||
log-facility=-
|
||||
EOF
|
||||
(dnsmasq --conf-file=/tmp/dnsmasq.conf >/tmp/dnsmasq.log 2>&1 &)
|
||||
sleep 1
|
||||
ss -lunp | grep :53
|
||||
'
|
||||
```
|
||||
|
||||
Observed:
|
||||
|
||||
```console
|
||||
UNCONN 0 0 192.168.128.7:53 0.0.0.0:* users:(("dnsmasq",pid=515,fd=4))
|
||||
```
|
||||
|
||||
Point the agent to sidecar DNS:
|
||||
|
||||
```bash
|
||||
container exec bb-spike-230t-agent sh -c '
|
||||
printf "nameserver 192.168.128.7\n" > /etc/resolv.conf
|
||||
nslookup pypi.org
|
||||
'
|
||||
```
|
||||
|
||||
Observed:
|
||||
|
||||
```console
|
||||
Server: 192.168.128.7
|
||||
Address: 192.168.128.7:53
|
||||
|
||||
Non-authoritative answer:
|
||||
Name: pypi.org
|
||||
Address: 151.101.128.223
|
||||
Name: pypi.org
|
||||
Address: 151.101.192.223
|
||||
Name: pypi.org
|
||||
Address: 151.101.64.223
|
||||
Name: pypi.org
|
||||
Address: 151.101.0.223
|
||||
```
|
||||
|
||||
Direct HTTP from the agent worked and mitmproxy logged the request:
|
||||
|
||||
```console
|
||||
$ container exec bb-spike-230t-agent sh -c \
|
||||
'wget -T 10 -O- http://example.com | head -c 100'
|
||||
Connecting to example.com (172.66.147.243:80)
|
||||
<!doctype html><html lang="en"><head><title>Example Domain</title>
|
||||
```
|
||||
|
||||
Mitmproxy log:
|
||||
|
||||
```console
|
||||
192.168.128.5:39742: GET http://example.com/
|
||||
Host: example.com
|
||||
User-Agent: Wget
|
||||
<< 200 OK 559b
|
||||
```
|
||||
|
||||
After switching the agent to sidecar DNS, direct HTTP still hit
|
||||
mitmproxy:
|
||||
|
||||
```console
|
||||
192.168.128.5:50784: GET http://example.com/
|
||||
Host: example.com
|
||||
User-Agent: Wget
|
||||
<< 200 OK 559b
|
||||
```
|
||||
|
||||
Direct HTTPS from the agent reached mitmproxy but failed certificate
|
||||
verification, as expected when the client does not trust the mitmproxy
|
||||
CA:
|
||||
|
||||
```console
|
||||
$ container exec bb-spike-230t-agent sh -c \
|
||||
'wget -T 10 -O- https://pypi.org/simple/pip/ | head -c 100'
|
||||
Connecting to pypi.org (151.101.128.223:443)
|
||||
... certificate verify failed ...
|
||||
```
|
||||
|
||||
Mitmproxy log:
|
||||
|
||||
```console
|
||||
Client TLS handshake failed. The client does not trust the proxy's
|
||||
certificate for pypi.org (tlsv1 alert unknown ca)
|
||||
```
|
||||
|
||||
With verification disabled, the same direct URL succeeded and mitmproxy
|
||||
logged the full HTTPS request:
|
||||
|
||||
```console
|
||||
$ container exec bb-spike-230t-agent sh -c \
|
||||
'wget --no-check-certificate -T 10 -O- https://pypi.org/simple/pip/ | head -c 100'
|
||||
Connecting to pypi.org (151.101.128.223:443)
|
||||
<!DOCTYPE html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta name="pypi:repository-version" content="1.4">
|
||||
```
|
||||
|
||||
Mitmproxy log:
|
||||
|
||||
```console
|
||||
192.168.128.5:32802: GET https://pypi.org/simple/pip/
|
||||
Host: pypi.org
|
||||
User-Agent: Wget
|
||||
<< 200 OK 103k
|
||||
```
|
||||
|
||||
After switching the agent to sidecar DNS, direct HTTPS still hit
|
||||
mitmproxy:
|
||||
|
||||
```console
|
||||
192.168.128.5:50254: GET https://pypi.org/simple/pip/
|
||||
Host: pypi.org
|
||||
User-Agent: Wget
|
||||
<< 200 OK 103k
|
||||
```
|
||||
|
||||
Verdict: transparent mitmproxy mode works in this topology. The bot
|
||||
agent would still need the egress CA installed, which bot-bottle already
|
||||
does for explicit proxy mode.
|
||||
|
||||
## Answers
|
||||
|
||||
### Can the sidecar become the agent network's default gateway?
|
||||
|
||||
Not directly through Apple Container's documented CLI. The installed
|
||||
`container run --help` documents `--network
|
||||
<name>[,mac=XX:XX:XX:XX:XX:XX][,mtu=VALUE]`; it does not document a
|
||||
gateway option.
|
||||
|
||||
The route can be changed after container start only if the agent has
|
||||
`CAP_NET_ADMIN`. Without it, `ip route replace default via <sidecar>`
|
||||
fails with `Operation not permitted`.
|
||||
|
||||
### Can Apple Container support sidecar forwarding/NAT/transparent proxying?
|
||||
|
||||
Yes. A dual-homed sidecar with `CAP_NET_ADMIN` can enable IP forwarding,
|
||||
set iptables NAT/forwarding rules, and route agent traffic out through
|
||||
the NAT network.
|
||||
|
||||
Transparent mitmproxy interception also works with `PREROUTING`
|
||||
redirects to `mitmdump --mode transparent`.
|
||||
|
||||
### What capabilities/custom image are required?
|
||||
|
||||
At minimum:
|
||||
|
||||
- sidecar needs `CAP_NET_ADMIN`;
|
||||
- sidecar image needs `iptables`/`iproute2` or equivalent nftables
|
||||
tooling;
|
||||
- sidecar should run a DNS listener on its host-only IP, or otherwise
|
||||
provide a controlled resolver path for the agent;
|
||||
- sidecar launcher needs a transparent mode variant;
|
||||
- agent route must be changed to the sidecar's host-only IP;
|
||||
- agent DNS should point to the sidecar DNS listener;
|
||||
- agent must trust the sidecar CA for HTTPS interception.
|
||||
|
||||
The tested agent route mutation required agent `CAP_NET_ADMIN`, which
|
||||
should not be accepted as the final design without a privilege-dropping
|
||||
init/shim story.
|
||||
|
||||
### Can host-level `pf` or vmnet rules replace agent route mutation?
|
||||
|
||||
Not tested. The successful transparent paths did not use host `pf`;
|
||||
they used container-local routing and iptables. Host-level `pf` remains
|
||||
a possible escape hatch if Apple Container cannot set a custom gateway
|
||||
and we reject agent `CAP_NET_ADMIN`.
|
||||
|
||||
### Can existing route policy and DLP semantics be preserved?
|
||||
|
||||
Likely, but not fully validated in this spike. Mitmproxy transparent
|
||||
mode produced normal HTTP flows with correct `Host` values for both
|
||||
HTTP and HTTPS. The existing `egress_addon.py` hooks should still see
|
||||
`flow.request.pretty_host`, method, path, headers, and response bodies.
|
||||
|
||||
But the current sidecar entrypoint only starts `mitmdump` in regular
|
||||
explicit-proxy mode. A real implementation must add a transparent mode
|
||||
launcher and then run the existing egress addon test suite against
|
||||
transparent flows.
|
||||
|
||||
## Recommendation
|
||||
|
||||
Do not switch `macos-container` to transparent egress yet, but keep it
|
||||
as a plausible implementation path.
|
||||
|
||||
The next implementation spike should focus on removing the agent
|
||||
`CAP_NET_ADMIN` requirement. Acceptable options:
|
||||
|
||||
- find or add an Apple Container-supported default-gateway setting;
|
||||
- start the agent through a tiny root init that sets route/DNS, drops
|
||||
capabilities, and then execs the agent as the normal user;
|
||||
- include a sidecar DNS service and set the agent resolver to the
|
||||
sidecar's host-only IP as part of that init/setup path;
|
||||
- avoid routing mutation by using host/vmnet-level packet redirection;
|
||||
- explicitly decide that route mutation is only a convenience layer and
|
||||
keep explicit proxy env vars for v1.
|
||||
|
||||
Bluntly: transparent egress is feasible, but not production-ready until
|
||||
the agent route can be controlled without leaving network-admin power in
|
||||
the agent runtime.
|
||||
Reference in New Issue
Block a user