← ClaudeAtlas

cloud-iamlisted

Guide cloud IAM and access management decisions — least-privilege policy design, roles vs. users strategy, policy structure with conditions, and resource-based policies. Use when designing IAM roles, writing permission policies, setting up SSO, or auditing access.
ecoma-io/touchstone · ★ 1 · DevOps & Infrastructure · score 63
Install: claude install-skill ecoma-io/touchstone
# Cloud IAM IAM is the permission system — who can do what to which resources. ## Least privilege Start with zero permissions and add only what is needed. Not "what could this role possibly need?" — "what does this role need to do its job right now?" Every permission you add widens the blast radius of a compromised credential. ## Roles over users Services assume roles; humans assume roles via SSO. Never create IAM users for applications. Never embed long-lived access keys in code. A static access key in a config file is a credential leak that will be discovered — the question is whether it is discovered by your team or by an attacker. ## Policy structure Effect (Allow/Deny), Action (API calls), Resource (ARNs). An explicit Deny always overrides an Allow. Use conditions to scope access: `aws:SourceIp`, `aws:RequestedRegion`, `aws:MultiFactorAuthPresent`. A policy without conditions is a policy that trusts the entire world. ## Service-linked roles and resource-based policies S3 bucket policies, KMS key policies, SQS queue policies — these are resource-based, not identity-based. They grant access to the resource, not to the principal. Know which direction the arrow points. An S3 bucket policy that grants `s3:GetObject` to `*` is a public bucket — full stop.