Iac Scripts
You write iac scripts to set up cloud servers, networks, and databases using plain text files. Teams run these files through automated pipelines to build and update systems in a repeatable way. Most teams start by giving their build tool a broad cloud admin role. That wide role makes setup fast, but it creates a huge security risk. Anyone who can trigger a run can change or delete live data. How iac scripts work with cloud roles and state When you run iac scripts, the tool reads your text fil
IaC Scanning (Checkov, tfsec, KICS): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You write iac scripts to set up cloud servers, networks, and databases using plain text files. Teams run these files through automated pipelines to build and update systems in a repeatable way. Most teams start by giving their build tool a broad cloud admin role. That wide role makes setup fast, but it creates a huge security risk. Anyone who can trigger a run can change or delete live data.
How iac scripts work with cloud roles and state
When you run iac scripts, the tool reads your text files and compares them to a state file. This state file tracks every server, network rule, and database your team already built. The tool then calls your cloud provider API to add, change, or remove resources so reality matches your text files.
To make those API calls, the tool must log in to the cloud account. Teams usually set up a machine role or save static API keys inside the build system. The tool uses this role to check current settings and write new changes across the account.
State files also hold sensitive values like database passwords, private keys, and network details. Teams store these state files in shared cloud buckets so every engineer works from the same record. They also lock the state file during each run so two engineers do not write conflicting changes at the same time.
Where native permissions for iac scripts fall short
Native cloud roles decide who can log in and start a build run. They also control which cloud services the build machine can touch. This setup works well when every change goes through a strict code review pipeline.
Still, real work often requires engineers to run local checks or fix broken state files by hand. During an outage, an engineer may need to run a command from a laptop to fix a bad rule. To do this, teams often grant broad cloud roles directly to human engineers.
Once an engineer holds that role, the cloud login cannot tell safe commands apart from dangerous ones. Native cloud roles check identity at login, not what individual commands or queries do in flight. Also, if a state query returns raw text with emails, phone numbers, or card numbers, native cloud roles do not rewrite matched fields in results. Teams also lack a clear log of every single command an engineer runs during a manual fix.
IaC Scanning (Checkov, tfsec, KICS): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Steps to tighten manual runs and state checks
First, separate the roles used for read-only plan checks from the roles used to write changes. Give most engineers the read role so they can test changes without touching live systems. Keep the write role restricted to automated build jobs or approved break-glass sessions.
Second, remove static keys from laptops and build servers. Use short-lived federated logins so credentials expire right after the job finishes. This stops leaked keys from giving attackers permanent control over your cloud account.
Third, encrypt your state storage bucket and restrict who can read the raw state file. Even with these steps in place, you still need a way to inspect live commands and protect sensitive output when engineers run manual fixes.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
Why do iac scripts need such broad cloud permissions?
These tools build and update many different cloud resources, including IAM roles, networks, and databases. Because one run might touch ten services, teams often attach a single admin role instead of scoping narrow rules.
How can we stop engineers from running destructive changes from their laptops?
Give engineers read-only roles for local testing and require peer approval before any write command runs. You can also restrict write actions so they only run through controlled sessions with full command logging.
Why is the state file a major security risk?
The state file stores a plain record of your setup, which often includes database passwords, API keys, and private details. Anyone who can read the state file can extract those secrets and use them elsewhere.