AWS Cloudformation Iam Agent Skill
Provides AWS CloudFormation patterns for IAM roles, policies, managed policies, permission boundaries, and trust relationships. Use when modeling least-privilege access, cross-account assumptions, service roles, or reusable IAM stacks that other CloudFormation templates consume.
Install
one command, takes just this skill from the repositorynpx skills add https://github.com/giuseppe-trisciuoglio/developer-kit --skill aws-cloudformation-iamThe instruction itself
16 sections, as written by the authorAWS CloudFormation IAM Security
Overview
Use this skill to model IAM with CloudFormation in a way that stays secure, auditable, and maintainable.
The most important design concerns are:
- separating trust policies from permission policies
- preferring roles over long-lived users wherever possible
- keeping least-privilege boundaries readable and reusable
Do not treat SKILL.md as a full IAM encyclopedia. Use the bundled references for larger policy examples and service-specific variants.
When to Use
- Creating IAM roles for Lambda, ECS, EC2, Step Functions, or other AWS services
- Defining inline policies, managed policies, and permission boundaries in CloudFormation
- Modeling cross-account assume-role access with constrained trust policies
- Exporting IAM role ARNs or managed policy ARNs to downstream stacks
- Reviewing wildcard permissions, boundary drift, or role replacement risk
- Creating reusable IAM stacks for platform or application teams
Instructions
1. Define the trust boundary first
Identify who or what assumes the role (service principal, cross-account principal, or federated identity), then write the trust policy with explicit principals and conditions before adding permissions.
2. Grant the minimum permission set
Use inline policies for role-specific access; use managed policies for shared patterns across principals. Scope actions and resources tightly, and use conditions where possible.
3. Apply permission boundaries for delegated role creation
Use permission boundaries when teams create or extend roles in their own stacks, when guardrails are needed around privileged services (IAM, KMS, Organizations), or to separate maximum allowed permissions from application-specific policies.
Name roles and policies consistently so stack outputs and audits remain easy to trace.
4. Model cross-account access
For cross-account roles: trust only the exact source account or principal, add sts:ExternalId conditions when appropriate, keep permission and trust policies separate, and export only the ARNs that consuming accounts need.
5. Validate the template and policy behavior
Before rollout, use these commands to verify the template and IAM behavior:
# Validate CloudFormation template syntax
aws cloudformation validate-template --template-body file://template.yaml
# Preview changes before applying
aws cloudformation create-change-set \
--stack-name <stack-name> \
--template-body file://template.yaml \
--change-set-type CREATE
# Simulate whether a principal can perform specific actions
aws iam simulate-principal-policy \
--policy-source-arn arn:aws:iam::123456789012:role/LambdaExecutionRole \
--action-names dynamodb:GetItem dynamodb:PutItem
# Check for wildcards in IAM policies within the template
aws cloudformation list-stack-resources --stack-name <stack-name>
After deployment, confirm policy attachments and stack outputs match the intended security model.
Examples
Example 1: Service role for Lambda with tightly scoped permissions
Resources:
LambdaExecutionRole:
Type: AWS::IAM::Role
Properties:
AssumeRolePolicyDocument:
Version: "2012-10-17"
Statement:
- Effect: Allow
Principal:
Service: lambda.amazonaws.com
Action: sts:AssumeRole
Policies:
- PolicyName: DynamoDbWritePolicy
PolicyDocument:
Version: "2012-10-17"
Statement:
- Effect: Allow
Action:
- dynamodb:GetItem
- dynamodb:PutItem
Resource: !GetAtt OrdersTable.Arn
Example 2: Cross-account role with an external ID condition
Resources:
PartnerReadRole:
Type: AWS::IAM::Role
Properties:
AssumeRolePolicyDocument:
Version: "2012-10-17"
Statement:
- Effect: Allow
Principal:
AWS: arn:aws:iam::123456789012:role/partner-reader
Action: sts:AssumeRole
Condition:
StringEquals:
sts:ExternalId: partner-contract-001
Keep the trust relationship narrow and pair it with a separate read-only permission policy.
Best Practices
- Prefer IAM roles over long-lived IAM users for application and automation access.
- Separate trust policies from permission policies when reviewing or refactoring templates.
- Use permission boundaries when delegating role creation to other teams.
- Scope resources, actions, and conditions as tightly as the workload allows.
- Export stable ARNs and names only when another stack truly consumes them.
- Keep expanded policy libraries and edge cases in
references/instead of bloating the root skill.
Constraints and Warnings
- Overly broad wildcards in IAM are easy to deploy and hard to notice later.
- Named IAM resources can be hard to replace safely once other systems depend on them.
- IAM changes may appear successful in CloudFormation before eventual consistency settles across AWS services.
- Some Identity Center or organization-wide access patterns need complementary tooling outside a single CloudFormation stack.
- Misconfigured trust policies are often a bigger risk than missing permissions.
References
references/examples.mdreferences/reference.md
Related Skills
aws-cloudformation-securityaws-cloudformation-ec2aws-cloudformation-ecsaws-cloudformation-lambda
Other skills for the same job
different authors, same section of the catalogue
Assess Kubernetes workloads and cluster configuration for AKS Automatic compatibility. Identifies incompatibilities, generates fixes, and guides migration from AKS Standard to AKS Automatic. WHEN: migrate to AKS Automatic, check AKS Automatic readiness, validate manifests for Automatic, assess cluster for Automatic compatibility, fix deployment for Automatic compatibility, identify AKS Automatic migration blockers, is my cluster ready for AKS Automatic.
Discovers available Azure OpenAI model capacity across regions and projects. Analyzes quota limits, compares availability, and recommends optimal deployment locations based on capacity requirements. USE FOR: find capacity, check quota, where can I deploy, capacity discovery, best region for capacity, multi-project capacity search, quota analysis, model availability, region comparison, check TPM availability. DO NOT USE FOR: actual deployment (hand off to preset or customize after discovery), quota increase requests (direct user to Azure Portal), listing existing deployments.
Interactive guided deployment flow for Azure OpenAI models with full customization control. Step-by-step selection of model version, SKU (GlobalStandard/Standard/ProvisionedManaged), capacity, RAI policy (content filter), and advanced options (dynamic quota, priority processing, spillover). USE FOR: custom deployment, customize model deployment, choose version, select SKU, set capacity, configure content filter, RAI policy, deployment options, detailed deployment, advanced deployment, PTU deployment, provisioned throughput. DO NOT USE FOR: quick deployment to optimal region (use preset).
Unified Azure OpenAI model deployment skill with intelligent intent-based routing. Handles quick preset deployments, fully customized deployments (version/SKU/capacity/RAI policy), and capacity discovery across regions and projects. USE FOR: deploy model, deploy gpt, create deployment, model deployment, deploy openai model, set up model, provision model, find capacity, check model availability, where can I deploy, best region for model, capacity analysis. DO NOT USE FOR: listing existing deployments (use foundry_models_deployments_list MCP tool), deleting deployments, agent creation (use agent/create), project creation (use project/create).
Intelligently deploys Azure OpenAI models to optimal regions by analyzing capacity across all available regions. Automatically checks current region first and shows alternatives if needed. USE FOR: quick deployment, optimal region, best region, automatic region selection, fast setup, multi-region capacity check, high availability deployment, deploy to best location. DO NOT USE FOR: custom SKU selection (use customize), specific version selection (use customize), custom capacity configuration (use customize), PTU deployments (use customize).
This skill should be used when working with LaminDB, an open-source data framework for biology that makes data queryable, traceable, reproducible, and FAIR. Use when managing biological datasets (scRNA-seq, spatial, flow cytometry, etc.), tracking computational workflows, curating and validating data with biological ontologies, building data lakehouses, or ensuring data lineage and reproducibility in biological research. Covers data management, annotation, ontologies (genes, cell types, diseases, tissues), schema validation, integrations with workflow managers (Nextflow, Snakemake) and MLOps platforms (W&B, MLflow), and deployment strategies.
Latch platform for bioinformatics workflows. Build pipelines with Latch SDK, @workflow/@task decorators, deploy serverless workflows, LatchFile/LatchDir, Nextflow/Snakemake integration.
Run Python code in the cloud with serverless containers, GPUs, and autoscaling. Use when deploying ML models, running batch processing jobs, scheduling compute-intensive tasks, or serving APIs that require GPU acceleration or dynamic scaling.
How to use it
Take giuseppe-trisciuoglio/aws-cloudformation-iam from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.