Common cloud misconfigurations include public storage buckets, root user access keys, instance metadata left on its older version, wildcard IAM permissions, short log retention, exposed Kubernetes APIs and secrets in Terraform state. Each has a specific setting you can check and a fix you can apply today.
Key takeaways
- Most misconfigurations are defaults left unchanged or one broad permission added in a hurry.
- A posture scanner finds them. Guardrails stop them returning.
- Fix the ones that expose data or grant admin first.
- Put the fix in code so it survives the next deployment.
What is a cloud misconfiguration?
A cloud misconfiguration is a setting that leaves a resource more exposed than intended, such as a public bucket or an over broad role. Microsoft's CSPM documentation describes recommendations that "help you identify and reduce cloud misconfigurations and security risks."
Example 1: What does a public S3 bucket look like and how do you fix it?
A bucket becomes public through an ACL or a bucket policy that grants access to everyone. AWS treats a policy as public when it grants access using a wildcard principal with no limiting condition.
{
"Principal": "*",
"Resource": "*",
"Action": "s3:PutObject",
"Effect": "Allow"
}
Fix: turn on all four S3 Block Public Access settings at the account level, as AWS recommends, and use IAM Access Analyzer for S3 to review buckets that grant public or cross-account access. If you need a public website, scope an exception to that one bucket.
Example 2: What is wrong with root user access keys?
The root user has full access to everything, including billing. AWS says it strongly recommends you do not create access keys for the root user.
Fix: delete any root access keys, enable MFA, and use AWS Config or Security Hub CSPM to alert on root keys and missing root MFA.
Example 3: Why is instance metadata version 1 a risk?
By default an EC2 instance accepts both IMDSv1 and IMDSv2. IMDSv2 requires a session token created with a PUT request, which blocks simple request forwarding abuse.
Fix: require tokens.
aws ec2 modify-instance-metadata-options \
--instance-id i-0123456789abcdef0 \
--http-tokens required
Kubernetes teams should also block pod access to the metadata address 169.254.169.254 if workloads do not need it, as the official Kubernetes checklist advises.
Example 4: What does a wildcard IAM policy do?
It grants more actions or resources than the task needs. AWS says to grant "only the permissions required to perform a task" and notes managed policies may not be least privilege for your case.
Fix: run IAM Access Analyzer policy generation from CloudTrail activity, test the generated policy, deploy it, and review last accessed information to remove unused permissions.
Example 5: Why is relying on default log retention a problem?
CloudTrail Event history is enabled by default but keeps only 90 days of management events. Data events such as S3 object access are not included.
Fix: create an organization trail that is multi-region and writes to a bucket in a separate logging account.
Example 6: What happens when the Kubernetes API or kubelet is exposed?
The Kubernetes security checklist says the API server, kubelet API and etcd should not be exposed publicly, and notes many managed distributions expose the API server by default. It also says kubelet defaults are overly permissive when no config file is specified.
Fix: restrict API access to known networks or a bastion, apply default deny NetworkPolicies, and enforce Pod Security Standards.
Example 7: Why are secrets in Terraform state dangerous?
HashiCorp states that if you add secret values directly to configuration, Terraform stores them in state and plan files. The sensitive argument does not keep them out of state.
Fix: use ephemeral values where supported, store state in an encrypted remote backend with restricted access. Our guide to securing Terraform state has the full setup.
How do you find misconfigurations at scale?
Use one scanner for deployed state and one for code.
| Where | Free option | What it reads |
|---|---|---|
| Deployed cloud accounts | Prowler, Scout Suite | Provider APIs |
| Infrastructure code | Checkov, Trivy | Terraform, CloudFormation, Kubernetes manifests |
| Clusters | Kubescape, kube-bench | Cluster state and CIS benchmark |
Scanning code catches the mistake before it ships. Scanning accounts catches changes made by hand in the console.
How do you stop misconfigurations coming back?
Fix them in code, then add guardrails.
- Put infrastructure in Terraform or CloudFormation so fixes are reviewed.
- Run an IaC scanner in every pull request.
- Use service control policies in AWS Organizations to deny risky actions across accounts.
- Enable continuous posture checks so drift is reported.
- Assign each finding to an owner with a due date.
Frequently asked questions
What is the most common cloud misconfiguration?
We have not found a primary source that ranks them, so we do not claim one. Public storage and over broad IAM permissions are the examples cloud providers document most.
Does Block Public Access change existing policies?
No. AWS says the settings do not alter existing policies or ACLs. Removing a setting makes a bucket with a public policy public again.
Can a scanner fix misconfigurations automatically?
Some tools offer remediation or automation rules. Review fixes first, since a blocked public setting can break a static website.
How often should I scan for misconfigurations?
Continuously for deployed accounts, and on every pull request for infrastructure code.
Sources
- Blocking public access to Amazon S3
- Root user best practices
- Instance metadata service
- Security best practices in IAM
- Kubernetes security checklist
- Terraform sensitive data in state
- Microsoft Defender for Cloud, CSPM
Last reviewed: 19 October 2026.
