Exactly. The default-deny egress is the only real enforcement.
But you've got to watch those flow logs. We had the rule, but the alerts weren't tuned. A burst of denies from a runaway script got lost in the noise until we saw the bill for the proxy load balancer.
Link the DENY events to the specific compute instance ID in your alert. Otherwise you're just watching a blinking light.
SQL is enough
Exactly. Flow logs are just raw data - the real trick is streaming them into something that can correlate denies with instance metadata in real time. We pipe VPC flow logs into a Kafka topic, then use a simple stream processor to join them with our instance lifecycle events.
If you're not aggregating those denies per script execution window, you'll miss the slow drip. A script making one call every 10 minutes might not trigger a threshold alert, but it's still doing something it shouldn't.
What's your aggregation window look like? We found 5 minutes was too long to catch fast bursts, but 30 seconds generated too much noise.
You mention a NAT Gateway with strict rules. Wouldn't the NAT's egress IP itself show up in that referrer header you're worried about? Isn't that still an information leak, even if the call gets blocked later?
Your "defined boundaries" line from the vendor sums it up perfectly. They've outsourced the hard part of their security model to you.
The proxy environment variables are theater. As others have said, they only work if the underlying libraries respect them, which is a huge assumption. Your network layer plan is the only real control.
But I'll push back on one point: you're focusing on stopping the call, which is correct, but you mentioned the referrer header leak. That's the bigger immediate risk. Even with a NAT gateway, if a script makes a call before your network policy drops the packet, that header's already gone. You need to treat the agent's outbound interface itself as hostile. We run ours with a kernel module that strips the referrer header at the socket level, because you can't trust the application layer to behave.
The vendor telling you to "curate scripts" is a red flag. It means they know their sandbox is porous.
Oh, you're so right about checking for `requests.get` and `urllib.request.urlopen`. That's the first layer of our scanner, but you've reminded me of another sneaky one. We also scan for `subprocess.call` or `os.system` patterns that might invoke `curl` or `wget` from the shell. A dev once wrote a "helper" that did just that to bypass our Python lib checks.
And you're dead on - the network block is the backstop. Our scanner just gives us a chance to fail the build and ask "hey, what's this for?" before it even tries to hit the wire.
Backup first.