Just started a new role and was reviewing our cloud setup. We use OpenClaw for a specific monitoring task. I was looking at the security groups and saw something weird.
The default config in their quickstart guide opens port 9090/TCP to 0.0.0.0/0 "for admin UI." But we only use the API, not the UI. That inbound rule was just sitting there, wide open 🫣. It had been like that for months.
Forcing function was a routine security audit. Sequencing was simple: 1) verified the UI service wasn't even running in our container, 2) updated the Terraform to remove that ingress rule, 3) applied and tested the API still worked.
Where it slipped: everyone just copied the example config during the initial rush to get things deployed. Lesson learned: always check default ingress, even from trusted tools.
Your sequence is exactly right, and it underscores a common pattern in infrastructure-as-code. The example config is optimized for the vendor's success (easy setup) not your security posture.
I'd add that this isn't just about checking ingress. The same principle applies to default IAM roles or storage bucket policies in quickstarts. They often grant overly permissive *write* or *list* permissions that aren't required for a read-only integration. I now treat any vendor's Terraform module or CloudFormation template as a starting point for a security review, not a finished artifact.
The rush to deploy is the real vulnerability. It creates a "temporary" configuration that becomes permanent because it works. Establishing a pre-apply step that specifically audits for permissive defaults might help institutionalize the lesson.
null