Trust injected CA certificate on sandbox startup#550
Conversation
🦋 Changeset detectedLatest commit: bb24fd1 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
commit: |
🐳 Docker Images Published
Usage: FROM cloudflare/sandbox:0.0.0-pr-550-bb24fd1Version: 📦 Standalone BinaryFor arbitrary Dockerfiles: COPY --from=cloudflare/sandbox:0.0.0-pr-550-bb24fd1 /container-server/sandbox /sandbox
ENTRYPOINT ["/sandbox"]Download via GitHub CLI: gh run download 24091022254 -n sandbox-binaryExtract from Docker: docker run --rm cloudflare/sandbox:0.0.0-pr-550-bb24fd1 cat /container-server/sandbox > sandbox && chmod +x sandbox |
|
/bonk review this PR |
|
UnknownError: ProviderInitError |
|
@scuffi Bonk workflow was cancelled. View workflow run · To retry, trigger Bonk again. |
scuffi
force-pushed
the
load-runtime-intercept-ca-cert
branch
from
57c223d to
441043a
Compare
|
/bonk review this PR |
|
UnknownError: ProviderInitError |
scuffi
requested review from
aron-cf,
ghostwriternr and
whoiskatrin
as code owners
|
|
||
| export async function trustRuntimeCert(): Promise<void> { | ||
| // Default to the Cloudflare containers injected CA certificate | ||
| const certPath = |
There was a problem hiding this comment.
Let's be careful on polling this certificate. I really recommend the sandbox accepting a flag that enables the trustRuntimeCert call (the user is opting in to https intercept).
If the container runtime is not calling HTTPS interception this file is not created.
There was a problem hiding this comment.
Also, in production polling is not necessary, if interceptOutboundHttps is called before the start() call, there is not a chance the file does not exist when the container runs.
There was a problem hiding this comment.
We're only polling here to ensure parity between local & production. As I don't think we can check if we're in production or local development here, we run through the exists file check, which should immediately return true if we're in production as the file will always exist as you mention, however, may be slightly delayed in local development but still ensures parity as we block startup until the certificate is injected, wdyt?
scuffi
force-pushed
the
load-runtime-intercept-ca-cert
branch
from
c3c515a to
982d49e
Compare
|
/bonk review this PR |
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
ghostwriternr
left a comment
ghostwriternr
left a comment
There was a problem hiding this comment.
Nice, thanks for adding a bunch of tests too! Have some minor comments
Yeah this is what I thought, however, I think this is only true for production and maybe Docker engine locally has some constraints? I've noticed in my testing approx ~200ms delay here when running locally which is why I've had to add the polling. The method does immediately check & return to minimise overhead in production, but I think if we want exact parity here we're going to need this polling due to local constraints |
|
Thanks for explaining, that makes sense! We can resolve that thread then |
scuffi
force-pushed
the
load-runtime-intercept-ca-cert
branch
from
7643bdf to
a81cc9d
Compare
scuffi
force-pushed
the
load-runtime-intercept-ca-cert
branch
from
e59f91a to
bb24fd1
Compare
3 participants
Summary
To support HTTPS egress interception, we must trust an injected CA certificate into external requests. This PR adds a blocking loader to fetch & trust this certificate during container server startup. In production, this certificate will exist at startup, so there should be minimal overhead introduced. The polling/blocking mechanism is for local development to ensure parity as the certificate cannot be assumed to exist at startup due to Docker API limitations.
Request Support
We are doing a 'best-effort' approach here by populating commonly used CA certificate environment variables, however, this approach is always going to be limited by packages or processes that ignore common system CA certificates, which we won't be able to intercept.