Slicer Proxy¶
Slicer's proxy lets you inspect and filter HTTP requests egressing your microVMs, and keep secrets away from workloads.
Features¶
- Log and audit outgoing HTTP(s) requests
- Inject credentials into outgoing requests - Basic Auth, Bearer Token, OAuth - Claude, Claude Code, and GitHub Copilot
- Block specific domains, URLs, paths, and methods
- Rule expiry - set a TTL for rules to automatically expire after a certain time
- Passthrough mode for unmodified requests, or TCP access such as Postgresql or SSH
- Transparent proxying helper, for when proxy variables cannot be set or programs do not honour them
Rules can be driven through the CLI, REST API, or with code using the SDKs.
Concepts¶
Slicer separates the nouns. Register a client, register secrets, then bind them for a period and let them expire. Clients are identified by the auth header they send to the proxy — no fake secrets, no source-IP heuristics.
┌─ client ──────────┐ ┌─ secret ─────────────┐
│ name │ │ name │
│ token │ │ type bearer │
└─────────┬─────────┘ │ basic-auth │
│ │ oauth │
│ owns │ value │
│ └──────────┬───────────┘
│ │
│ │ optional
│ │
┌─────────▼──────────────────────────────▼───────────┐
│ allow rule │
│ │
│ host │
│ paths │
│ methods │
│ ports │
│ ttl │
└────────────────────────────────────────────────────┘
Conceptual workflow¶
In the diagram below, we see a microVM that has been booted up, and given a HTTPS_PROXY value with a specific authentication token for the proxy. This is how we identify the microVM and client.
┌─ Host ──────────────────────────────────────────────────────────────┐
│ │
│ ┌─ Slicer + API ─────┐ ┌─ Slicer Proxy ─────────────────────┐ │
│ │ Control plane │ │ Dummy adapter 192.168.222.1 │ │
│ │ │ │ │ │
│ │ │ │ :3128 HTTP_PROXY │ │
│ │ │ │ :3129 HTTPS_PROXY │ │
│ └────────────────────┘ └────────────────────────────────────┘ │
│ ▲ │
└────────────────────────────────────────────┼────────────────────────┘
│ egress
┌─ Network namespace · isolated mode ────────┼────────────────────────┐
│ │ │
│ ┌─ microVM ──────────────────────────────┴─────────────────────┐ │
│ │ │ │
│ │ Drop 0.0.0.0/0 │ │
│ │ Allow 192.168.222.1:3128, 192.168.222.1:3129 │ │
│ │ │ │
│ │ HTTPS_PROXY=https://proxy:spi_REDACTED@192.168.222.1:3129 │ │
│ │ │ │
│ └──────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────┘
This gives us the following workflow when we want to launch a microVM with filtered egress policy:
- Define a client and keep track of its token
- Define any secrets it may need i.e. an LLM token
- Grant the client access to specific websites, and optionally reference the secret
- Then boot up the VM, and pass in the proxy reference such as
HTTPS_PROXY=https://proxy:spi_REDACTED@192.168.222.1:3129
For more dynamic workloads, the grants can be made during execution and are effective immediately.
Passthrough mode¶
Slicer Proxy can also be used to passthrough TCP traffic without TLS termination.
This is required for:
- Programs which pin a TLS certificate or to a specific CA at build time
- Traffic which breaks for some reason when proxied through "slicer proxy"
- Traffic which is not HTTP(s) i.e. SSH and Postgresql
To create a passthrough rule, run the following command, assuming client1 already exists:
slicer proxy allow client1 \
--host ssh-host.example.com \
--port 22 \
--passthrough
Then configure the host in .ssh/config to use the proxy:
Host ssh-host.example.com
ProxyCommand nc -x 192.168.222.1:3129 %h %p
Then you can connect to the host using SSH:
ssh ssh-host.example.com