31–40 of 58 posts
name: project-build
image: alpine:latest
namespace: default
egress_whitelist:
- "1.1.1.1/32" # Cloudflare DNS
- "8.8.8.8/32" # Google DNS
Malicious code just has to resolve .evil.com and Google/CF will forward that query to evil resolver.
name: project-build image: alpine:latest namespace: default egress_whitelist: - "1.1.1.1/32" # Cloudflare DNS - "8.8.8.8/32" # Google DNS This is basically a wide-open network policy as far as data exfiltration goes, right? Malicious code just has to resolve .evil.com and Google/CF will forward that query to evil resolver.
Yes, blocking DNS exfiltration requires DNS filtering at cluster level. This is what will be added with the Cilium integration which is top-3 on the roadmap (top of readme).
DNS resolution is required for basic Kubernetes functionality and hostname resolution within the cluster.
That's said explicitly in several places in the docs: "DNS to CoreDNS allowed"
One thing I could do is make it exposed in config, to allow the user to block all DNS resolutions until Cilium is integrated. LMK if desired!
Earlier quoted context omitted.
There are some providers that offer KVM nested virtualization, I think Google Cloud, Digital Ocean ... any others?
True! GCP does. I haven't tested it yet. I didn't know D.O does. If anyone knows others, I'm interested too!
If so, cool! AFAICT E2B is open-source licensed but tricky to setup.
Is this basically an open-source DIY version of E2B? If so, cool! AFAICT E2B is open-source licensed but tricky to setup.
I would really like to see a good local sandboxing solution in this space, something that is truly local-first. This is especially important since many coding models / agentic builders will eventually become lightweight enough to run them on-device instead of having to buy tokens and share user data with big LLM cloud providers.
I would really like to see a good local sandboxing solution in this space, something that is truly local-first. This is especially important since many coding models / agentic builders will eventually become lightweight enough to run them on-device instead of having to buy tokens and share user data with big LLM cloud providers.
It lets you narrow the permission scope of an executable using simple command line wrappers.
name: project-build image: alpine:latest namespace: default egress_whitelist: - "1.1.1.1/32" # Cloudflare DNS - "8.8.8.8/32" # Google DNS This is basically a wide-open network policy as far as data exfiltration goes, right? Malicious code just has to resolve .evil.com and Google/CF will forward that query to evil resolver.
That's a config example. Yes, blocking DNS exfiltration requires DNS filtering at cluster level. This is what will be added with the Cilium integration which is top-3 on the roadmap (top of readme). DNS resolution is required for basic Kubernetes functionality and hostname resolution within the cluster. That's said explicitly in several places in the docs: "DNS to CoreDNS allowed" One thing I could do is make it expo…
Yes, but it's not great for it to be an optional config option. Trivially easy to use data exfiltration methods shouldn't be possible at all in a tool like this, let alone enabled by default.
I want to recommend ppl to try this out and not have to tell them about the 5 different options they need to configure in order for it to actually be safe. It ends up defeating the purpose of the tool in my opinion.
Some use cases will require mitmproxy whitelists as well, eg default deny pulling container image except matching the container whitelist.