dockerproserv/sbx-tls-public-kit

By dockerproserv

•Updated about 12 hours ago

A Docker Sandboxes kit that makes a sandbox trust your company's TLS-inspection CA

Sandbox Kit

Overview Tags

dockerproserv/sbx-tls-public-kit repository overview

Tag

Digest

sha256:b766cd4d279e…

Size

15.3 kB

Schema

Pushed

about 12 hours ago

Specificationspec.yaml

MIXIN

Installs corporate CA certificates from a read-only mounted folder at every start, plus the docker wrapper

Arguments

Name	Required	Default	Description
`caDir`	Optional	`/Users/Shared/corporate-ca`	Path of the certificate folder inside the sandbox (.crt and .pem files, mounted read-only)
`dockerWrapper`	Optional	`true`	Put the docker wrapper ahead of the real docker (true), or leave docker alone (false)

CapabilitiesExpand a row to see its full configuration. See the full spec for the complete descriptor.

	Type	Required	Description
	`com.docker.sandbox/lifecycle@1`	Required	—

Apply this mixin to a sandbox

sbx run <agent> --kit dockerproserv/sbx-tls-public-kit:0.1.0

Make sure you have docker sbx installed

Run the following command to install sbx on your machine.

macOS

brew install docker/tap/sbx

Windows

winget install Docker.sbx

Learn more about docker sbx⁠

⁠sbx TLS public kit

A Docker Sandboxes kit that makes a sandbox trust your company's TLS-inspection CA (Netskope, Zscaler, Palo Alto Prisma Access, Cloudflare WARP, Forcepoint). IT puts the CA files in a folder on each laptop. The sandbox mounts the folder read-only, and the kit installs the certificates at every start. The kit holds no certificates.

It works with Claude Code, Codex, Copilot, Cursor and Devin. It also puts a docker wrapper in the sandbox, so docker build and docker run that the agent starts trust the same CA.

⁠Start a sandbox

sbx run docker.io/docker/sbx-kit-claude:2.1.267 \
  --kit docker.io/dockerproserv/sbx-tls-public-kit:0.1.0 \
  . /Users/Shared/corporate-ca:ro

The last argument mounts the certificate folder read-only. Change the first line for another agent:

Agent	Workload kit
Claude Code	`docker.io/docker/sbx-kit-claude:2.1.267`
Codex	`docker.io/docker/sbx-kit-codex:0.164.0`
Copilot	`docker.io/docker/sbx-kit-copilot:1.0.86`
Cursor	`docker.io/docker/sbx-kit-cursor:2026.10.22`
Devin	`docker.io/docker/sbx-kit-devin:0.1.0`

⁠Arguments

Pass an argument with --kit-arg name=value.

Argument	Default	Allowed values	What it does
`caDir`	`/Users/Shared/corporate-ca`	An absolute path of letters, digits and `. _ / + -`	Where the certificate folder is inside the sandbox. Mount the same path read-only.
`dockerWrapper`	`true`	`true` or `false`	`true` puts the `docker` wrapper ahead of the real docker. `false` leaves docker alone.

A different folder, for example:

sbx run docker.io/docker/sbx-kit-claude:2.1.267 \
  --kit docker.io/dockerproserv/sbx-tls-public-kit:0.1.0 \
  --kit-arg caDir=/opt/corp-ca \
  . /opt/corp-ca:ro

⁠The certificate folder

Files end in .crt or .pem. One file can hold one or several certificates.
No private keys.
Readable by everyone, writable only by admins. The kit warns at every start if the agent user can write to it.
When the CA rotates, replace the files and restart the sandbox. An empty folder at a restart keeps what is installed. An empty folder at creation stops the sandbox with a message.

⁠Check it

Inside the sandbox:

verify-ca            # each certificate, its expiry, and whether it is trusted
verify-ca pypi.org   # opens a real connection through the inspection

Then have the agent make a request. verify-ca shows that the sandbox trusts the CA, not that the agent's own runtime does.

⁠Verify the signature

sbx kit verify \
  --certificate-identity [email protected] \
  --certificate-oidc-issuer https://github.com/login/oauth \
  docker.io/dockerproserv/sbx-tls-public-kit:0.1.0

⁠Not tested yet

A real sbx host, Windows, and real TLS inspection. Docker's pages don't say how each agent's own runtime handles CAs.

Full guide, Windows notes and the private-kit and image alternatives: https://github.com/Docker-Pro-Serv/tls-inspection-sandbox-kit⁠