Quick Commands

# edit + deploy
git status
git add -A
git commit -m "docs: update"
git push

# rebuild static blog output (local)
cd site
npm ci --no-audit --no-fund
npm run build

# VPS: pull only
# (on server)
git pull --ff-only

Container networking options

Short answer: No — not fully exhaustive. This covers the most important patterns, plus a few variants you’ll see in practice. Below is an expanded map (with terminology) and a note on what you’re already using.

Rootful (containers run as root, classic CNI)

Code Pattern Core idea Pros Cons When to use
R1 LAN bind + DNS ports: <NIC-IP>:22300:8200, clients use https://vault.lan:22300 Simple, stable, clean SNI/SAN Exposed to the network → firewall + mTLS required On‑prem/LAN, clear segmentation
R2 Shared CNI bridge Vault + apps in the same CNI network; access via container DNS No host ports, clear segment isolation Workloads must share the same network One ops domain/team
R3 MACVLAN/IPVLAN Vault gets its own L2/L3 IP Strong network isolation Complex; requires network know‑how Datacenter / network teams
R4 Host networking --network host No NAT overhead Weak isolation, risky Special cases / air‑gapped
R5 L7 reverse proxy Host Nginx/HAProxy/Envoy in front of Vault Central mTLS/ACL/rate limit More components Strict gateways/auditing
R6 systemd-socket-proxyd Host socket accepts and proxies to Vault Very lightweight L4 only, no ACLs Minimalistic proxies
R7 nftables REDIRECT Host port redirect → local Vault Kernel‑fast, no userspace proxy Rules need care If you already manage FW via nft
R8 Podman pod Multiple containers share a netns Native sidecar pattern Pod boundary is “hard” Intra‑pod sidecars (agent/gateway)

Rootless (each Unix user has its own NAT network; netavark/slirp/pasta)

Code Pattern Core idea Pros Cons When to use
L1 Host forwarder + DNS (recommended) Vault stays on 127.0.0.1, host forwarder on :22300; apps use https://vault.lan:22300 Not truly exposed; scales across users Subnet FW unreliable → mTLS required VPS / multiple Unix users
L2 host.containers.internal Host alias reachable from containers Zero setup Not available everywhere If you know it exists
L3 Per-app forwarder/port Per app: own forwarder (22301/02/…) Separation per port/policy More moving parts Strong tenant separation
L4 Public bind + strict FW Forwarder binds NIC IP, FW allows only approved Simple access point Internet attack surface Only with mTLS + strict FW
L5 Overlay (WireGuard/Tailscale) Vault on WG IP; apps via WG sidecar No public surface, good ACLs Extra overlay ops Zero-trust/VPN standard
L6 pasta backend Alternative to slirp; different NAT semantics Sometimes better connectivity Compatibility varies Special rootless setups
L7 Host L7 proxy (Envoy/Nginx stream) Use L4/L7 features instead of socat ACL, terminate mTLS, etc. More complex When you need gateway features

Vault AuthN/AuthZ patterns (combinable)

  • mTLS (mutual TLS): server requires a client certificate (EKU=clientAuth). Hard network gatekeeper.
  • AppRole: machine login with role_id/secret_id; policies enforce least privilege.
  • OIDC/JWT: e.g. Kubernetes SA tokens, cloud IAM (AWS/GCP/Azure).
  • Response wrapping: safely pass SecretIDs/tokens.
  • CIDR restrictions: often unreliable in rootless NAT → rely on mTLS.

Secret delivery patterns

  • Vault Agent (sidecar) with templates → files (tmpfs, 0400) → app reads via *_FILE.
  • Env vars: avoid (show up in dumps/proc).
  • Unix socket / exec sink: rarer, special integrations.

Security hardening (baseline)

  • TLS everywhere, mTLS on Vault.
  • Minimal policies, short TTLs, rotation.
  • Containers: read_only, no-new-privileges, cap_drop=ALL, tmpfs for secrets, SELinux/seccomp enabled.

What you already have (based on current state)

  • Rootless, multiple Unix users, each with its own network ✅
  • Sidecar pattern (shared netns) ✅
  • Vault TLS via scripts ✅ (mTLS can be added)
  • Option L1 (host forwarder + DNS name) in progress ✅
  • host.containers.internal not available ❌

Recommendation

➡ L1: Host forwarder + DNS name + mTLS (mandatory)

  • A forwarder on the host (e.g. socat or nginx stream).
  • Vault stays bound locally; mTLS enforces a client cert.
  • Each app uses an agent sidecar + extra_hosts: ["vault.lan:<host-ip>"] + its own AppRole/policy.

This covers ~95% of real-world cases in a VPS/rootless setup—securely and maintainably.

Glossary (short)

  • CNI: Container Network Interface (bridge/MACVLAN/IPVLAN).
  • NetNS: Linux network namespace (separate stacks per container/pod).
  • Pod (Podman): group of containers sharing a netns.
  • netavark/slirp/pasta: rootless network backends (NAT-based).
  • SNI/SAN: TLS hostname routing / SubjectAltName.
  • Sidecar: helper container in the same netns (TLS gateway/agent).

If you want, I can mark 2–3 realistic alternatives to L1 for a multi-user VPS setup—but L1 remains the best fit in most cases.