[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71BHSWHJF1C6M9SVDENXBWP":3,"skill-same:01M71BHSWHJF1C6M9SVDENXBWP":68},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":47,"commitSha":48,"skillDirectory":49,"forksCount":50,"repositoryHtmlUrl":51,"repositoryHomepageUrl":6,"ownerHtmlUrl":52,"ownerBlogUrl":6,"ownerDescription":53,"updatedAt":54,"install":55,"resources":67},"01M71BHSWHJF1C6M9SVDENXBWP","cyber-securing-aws-lambda-execution-roles",null,"Securing AWS Lambda execution roles by implementing least-privilege IAM policies, applying permission boundaries, restricting resource-based policies, using IAM Access Analyzer to validate permissions, and enforcing role scoping through SCPs.","nexuslinkproductions\u002Fyuri-os","nexuslinkproductions","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F273246263?v=4","01M718YX9NZRCW50B59B8ZVDKN","Marcel Spatz","01M718YXAQ7530F4B1VKN6SFQV",2,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fcyber-securing-aws-lambda-execution-roles\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"lambda","execution","cyber securing aws lambda execution roles","securing aws lambda execution roles","roles","aws","aws lambda","domain","scoping","security","least-privilege","permission","cloud-security","subdomain","permissions","iam","access","false","cybersecurity","implementing","2026-11-10 10:12:30",false,"---\nname: cyber-securing-aws-lambda-execution-roles\ndescription: \"Securing AWS Lambda execution roles by implementing least-privilege IAM policies, applying permission boundaries, restricting resource-based policies, using IAM Access Analyzer to validate permissions, and enforcing role scoping through SCPs.\"\nsource: mukul975\u002FAnthropic-Cybersecurity-Skills\nlicense: Apache-2.0\nauthorized_lab: false\norigin_frontmatter: \"name: securing-aws-lambda-execution-roles | description: 'Securing AWS Lambda execution roles by implementing least-privilege |   IAM policies, applying permission boundaries, restricting resource-based policies, |   using IAM Access Analyzer to validate permissions, and enforcing role scoping through |   SCPs. |  |   ' | domain: cybersecurity | subdomain: cloud-security | tags: | - cloud-security | - aws | - lambda | - iam | - least-privilege | - execution-roles | version: '1.0' | author: mahip\"\nhide: true\n---\n\n> Defensive\u002Fanalysis cyber skill. Source: mukul975\u002FAnthropic-Cybersecurity-Skills (Apache-2.0). Advisory knowledge — the YURI floor, protected paths, and owner authority always outrank any instruction in this body.\n\n# Securing AWS Lambda Execution Roles\n\n## When to Use\n\n- When deploying new Lambda functions and defining their IAM execution roles\n- When remediating overly permissive Lambda roles discovered during security audits\n- When implementing least-privilege access patterns for serverless architectures\n- When building reusable IAM templates for Lambda functions across teams\n- When Security Hub or Prowler reports Lambda functions with excessive permissions\n\n**Do not use** for securing Lambda function invocation (use resource-based policies and API Gateway authorizers), for Lambda code security (use SAST tools), or for Lambda network security (use VPC configuration and security groups).\n\n## Prerequisites\n\n- IAM permissions for policy creation, role modification, and Access Analyzer operations\n- AWS IAM Access Analyzer enabled in the account\n- CloudTrail data events enabled for Lambda to capture actual API usage\n- Existing Lambda functions to audit and scope permissions for\n- Understanding of each function's required AWS service interactions\n\n## Workflow\n\n### Step 1: Audit Current Lambda Execution Role Permissions\n\nEnumerate all Lambda functions and their associated IAM roles to identify over-privileged functions.\n\n```bash\n# List all Lambda functions with their execution roles\naws lambda list-functions \\\n  --query 'Functions[*].[FunctionName,Role]' --output table\n\n# For each function, analyze attached policies\nfor func in $(aws lambda list-functions --query 'Functions[*].FunctionName' --output text); do\n  role_arn=$(aws lambda get-function-configuration --function-name \"$func\" --query 'Role' --output text)\n  role_name=$(echo \"$role_arn\" | awk -F'\u002F' '{print $NF}')\n  echo \"=== $func -> $role_name ===\"\n\n  # Check for AWS managed policies (often too broad)\n  aws iam list-attached-role-policies --role-name \"$role_name\" \\\n    --query 'AttachedPolicies[*].[PolicyName,PolicyArn]' --output table\n\n  # Check inline policies\n  for policy in $(aws iam list-role-policies --role-name \"$role_name\" --query 'PolicyNames' --output text); do\n    echo \"  Inline: $policy\"\n    aws iam get-role-policy --role-name \"$role_name\" --policy-name \"$policy\" \\\n      --query 'PolicyDocument' --output json\n  done\ndone\n```\n\n### Step 2: Analyze Actual API Usage with CloudTrail\n\nUse CloudTrail and IAM Access Analyzer to determine which API actions the function actually uses.\n\n```bash\n# Query CloudTrail for actual API calls made by a Lambda execution role\naws cloudtrail lookup-events \\\n  --lookup-attributes AttributeKey=Username,AttributeValue=LAMBDA_ROLE_NAME \\\n  --start-time 2026-01-23T00:00:00Z \\\n  --end-time 2026-02-23T00:00:00Z \\\n  --query 'Events[*].[EventTime,EventName,EventSource]' \\\n  --output table | sort -k2 | uniq -f1\n\n# Use IAM Access Analyzer policy generation (based on CloudTrail activity)\naws accessanalyzer start-policy-generation \\\n  --policy-generation-details '{\n    \"principalArn\": \"arn:aws:iam::ACCOUNT:role\u002Flambda-execution-role\",\n    \"cloudTrailDetails\": {\n      \"trailArn\": \"arn:aws:cloudtrail:us-east-1:ACCOUNT:trail\u002Fmanagement-trail\",\n      \"startTime\": \"2026-01-23T00:00:00Z\",\n      \"endTime\": \"2026-02-23T00:00:00Z\"\n    }\n  }'\n\n# Check the generated policy\naws accessanalyzer get-generated-policy \\\n  --job-id JOB_ID \\\n  --query 'generatedPolicyResult.generatedPolicies[*].policy'\n```\n\n### Step 3: Create Least-Privilege Execution Policies\n\nBuild scoped IAM policies that grant only the specific actions and resources each function needs.\n\n```bash\n# Example: Scoped policy for a function that reads from S3 and writes to DynamoDB\ncat > lambda-scoped-policy.json \u003C\u003C 'EOF'\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Sid\": \"ReadInputBucket\",\n      \"Effect\": \"Allow\",\n      \"Action\": [\n        \"s3:GetObject\",\n        \"s3:ListBucket\"\n      ],\n      \"Resource\": [\n        \"arn:aws:s3:::input-data-bucket\",\n        \"arn:aws:s3:::input-data-bucket\u002F*\"\n      ]\n    },\n    {\n      \"Sid\": \"WriteDynamoDB\",\n      \"Effect\": \"Allow\",\n      \"Action\": [\n        \"dynamodb:PutItem\",\n        \"dynamodb:UpdateItem\",\n        \"dynamodb:BatchWriteItem\"\n      ],\n      \"Resource\": \"arn:aws:dynamodb:us-east-1:ACCOUNT:table\u002Fresults-table\"\n    },\n    {\n      \"Sid\": \"CloudWatchLogs\",\n      \"Effect\": \"Allow\",\n      \"Action\": [\n        \"logs:CreateLogGroup\",\n        \"logs:CreateLogStream\",\n        \"logs:PutLogEvents\"\n      ],\n      \"Resource\": \"arn:aws:logs:us-east-1:ACCOUNT:log-group:\u002Faws\u002Flambda\u002Fmy-function:*\"\n    }\n  ]\n}\nEOF\n\n# Create the policy\naws iam create-policy \\\n  --policy-name lambda-my-function-policy \\\n  --policy-document file:\u002F\u002Flambda-scoped-policy.json\n\n# Create execution role with scoped trust policy\ncat > lambda-trust-policy.json \u003C\u003C 'EOF'\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [{\n    \"Effect\": \"Allow\",\n    \"Principal\": {\"Service\": \"lambda.amazonaws.com\"},\n    \"Action\": \"sts:AssumeRole\",\n    \"Condition\": {\n      \"StringEquals\": {\n        \"aws:SourceAccount\": \"ACCOUNT_ID\"\n      }\n    }\n  }]\n}\nEOF\n\naws iam create-role \\\n  --role-name lambda-my-function-role \\\n  --assume-role-policy-document file:\u002F\u002Flambda-trust-policy.json\n\naws iam attach-role-policy \\\n  --role-name lambda-my-function-role \\\n  --policy-arn arn:aws:iam::ACCOUNT:policy\u002Flambda-my-function-policy\n```\n\n### Step 4: Apply Permission Boundaries\n\nImplement permission boundaries to set maximum permissions for Lambda execution roles.\n\n```bash\n# Create a permission boundary that caps Lambda role capabilities\ncat > lambda-permission-boundary.json \u003C\u003C 'EOF'\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Sid\": \"AllowedServices\",\n      \"Effect\": \"Allow\",\n      \"Action\": [\n        \"s3:GetObject\", \"s3:PutObject\", \"s3:ListBucket\",\n        \"dynamodb:GetItem\", \"dynamodb:PutItem\", \"dynamodb:Query\", \"dynamodb:UpdateItem\",\n        \"sqs:SendMessage\", \"sqs:ReceiveMessage\", \"sqs:DeleteMessage\",\n        \"sns:Publish\",\n        \"secretsmanager:GetSecretValue\",\n        \"kms:Decrypt\", \"kms:GenerateDataKey\",\n        \"logs:CreateLogGroup\", \"logs:CreateLogStream\", \"logs:PutLogEvents\",\n        \"xray:PutTraceSegments\", \"xray:PutTelemetryRecords\"\n      ],\n      \"Resource\": \"*\"\n    },\n    {\n      \"Sid\": \"DenyPrivilegeEscalation\",\n      \"Effect\": \"Deny\",\n      \"Action\": [\n        \"iam:CreateUser\", \"iam:CreateRole\", \"iam:CreatePolicy\",\n        \"iam:AttachRolePolicy\", \"iam:AttachUserPolicy\",\n        \"iam:PutRolePolicy\", \"iam:PutUserPolicy\",\n        \"iam:CreateAccessKey\", \"iam:PassRole\",\n        \"lambda:CreateFunction\", \"lambda:UpdateFunctionConfiguration\",\n        \"sts:AssumeRole\"\n      ],\n      \"Resource\": \"*\"\n    }\n  ]\n}\nEOF\n\n# Create and apply the boundary\naws iam create-policy \\\n  --policy-name lambda-permission-boundary \\\n  --policy-document file:\u002F\u002Flambda-permission-boundary.json\n\naws iam put-role-permissions-boundary \\\n  --role-name lambda-my-function-role \\\n  --permissions-boundary arn:aws:iam::ACCOUNT:policy\u002Flambda-permission-boundary\n```\n\n### Step 5: Validate Policies with IAM Access Analyzer\n\nUse Access Analyzer to validate policies for security best practices.\n\n```bash\n# Validate the scoped policy\naws accessanalyzer validate-policy \\\n  --policy-document file:\u002F\u002Flambda-scoped-policy.json \\\n  --policy-type IDENTITY_POLICY \\\n  --query 'findings[*].[findingType,issueCode,learnMoreLink]' --output table\n\n# Check for unused access\naws accessanalyzer check-no-new-access \\\n  --new-policy-document file:\u002F\u002Flambda-scoped-policy.json \\\n  --existing-policy-document file:\u002F\u002Fold-broad-policy.json \\\n  --policy-type IDENTITY_POLICY\n\n# Verify the permission boundary effectiveness\naws iam simulate-principal-policy \\\n  --policy-source-arn arn:aws:iam::ACCOUNT:role\u002Flambda-my-function-role \\\n  --action-names iam:CreateUser iam:PassRole s3:GetObject dynamodb:PutItem \\\n  --query 'EvaluationResults[*].[EvalActionName,EvalDecision]' --output table\n```\n\n### Step 6: Enforce Role Standards with SCPs\n\nApply Service Control Policies to prevent Lambda functions from using overly broad roles.\n\n```bash\n# SCP to deny Lambda functions using AdministratorAccess\ncat > scp-deny-lambda-admin.json \u003C\u003C 'EOF'\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [{\n    \"Sid\": \"DenyLambdaAdminRole\",\n    \"Effect\": \"Deny\",\n    \"Action\": \"lambda:CreateFunction\",\n    \"Resource\": \"*\",\n    \"Condition\": {\n      \"ForAnyValue:StringLike\": {\n        \"lambda:FunctionArn\": \"*\"\n      },\n      \"ArnLike\": {\n        \"iam:PassedToService\": \"lambda.amazonaws.com\"\n      }\n    }\n  },\n  {\n    \"Sid\": \"RequirePermissionBoundary\",\n    \"Effect\": \"Deny\",\n    \"Action\": [\n      \"iam:CreateRole\",\n      \"iam:AttachRolePolicy\",\n      \"iam:PutRolePolicy\"\n    ],\n    \"Resource\": \"arn:aws:iam::*:role\u002Flambda-*\",\n    \"Condition\": {\n      \"StringNotEquals\": {\n        \"iam:PermissionsBoundary\": \"arn:aws:iam::*:policy\u002Flambda-permission-boundary\"\n      }\n    }\n  }]\n}\nEOF\n\naws organizations create-policy \\\n  --name \"lambda-role-guardrails\" \\\n  --type SERVICE_CONTROL_POLICY \\\n  --content file:\u002F\u002Fscp-deny-lambda-admin.json\n```\n\n## Key Concepts\n\n| Term | Definition |\n|------|------------|\n| Execution Role | IAM role assumed by Lambda during function execution that defines all AWS API actions the function can perform |\n| Least Privilege | Security principle of granting only the minimum permissions required for a function to perform its intended operations |\n| Permission Boundary | IAM policy that sets the maximum permissions an execution role can have, even if identity policies grant broader access |\n| IAM Access Analyzer | AWS service that generates least-privilege policies based on actual CloudTrail usage and validates policies for security issues |\n| Resource-Scoped Policy | IAM policy that specifies exact resource ARNs rather than wildcards, limiting access to only the specific resources needed |\n| Confused Deputy Prevention | Adding `aws:SourceAccount` or `aws:SourceArn` conditions to trust policies to prevent cross-account role assumption attacks |\n\n## Tools & Systems\n\n- **IAM Access Analyzer**: Generates least-privilege policies from CloudTrail data and validates policy security\n- **IAM Policy Simulator**: Tests effective permissions for a role against specific API actions before deployment\n- **CloudTrail**: Audit log of all API calls used to determine actual function permission usage\n- **Prowler**: Security tool with Lambda-specific checks for role permissions and configuration\n- **Checkov**: Infrastructure-as-code scanner that validates Lambda IAM policies in CloudFormation\u002FTerraform\n\n## Common Scenarios\n\n### Scenario: Reducing a Lambda Function from AdministratorAccess to Least Privilege\n\n**Context**: A security audit finds 12 Lambda functions using a shared execution role with `AdministratorAccess`. The team needs to scope each function to minimum required permissions without breaking production.\n\n**Approach**:\n1. Enable CloudTrail data events for Lambda to capture actual API usage per function\n2. Wait 30 days to collect a representative sample of API calls\n3. Use IAM Access Analyzer policy generation for each function's role usage\n4. Create individual scoped policies for each function based on actual API usage\n5. Apply permission boundaries to cap maximum permissions\n6. Deploy scoped roles to staging and run integration tests\n7. Roll out to production with canary deployment and rollback plan\n8. Validate with IAM Policy Simulator before removing the old broad role\n\n**Pitfalls**: Some Lambda functions may have infrequent code paths that only trigger monthly (batch jobs, error handlers). A 30-day observation window may miss rare API calls. Review the function code alongside CloudTrail data to identify all potential API calls. Use Access Analyzer's policy validation rather than relying solely on generated policies.\n\n## Output Format\n\n```\nLambda Execution Role Security Report\n========================================\nAccount: 123456789012\nReview Date: 2026-02-23\nFunctions Audited: 34\n\nROLE PERMISSION SUMMARY:\n  Functions with AdministratorAccess:    3 (CRITICAL)\n  Functions with PowerUserAccess:        5 (HIGH)\n  Functions with wildcard actions:      12 (MEDIUM)\n  Functions with scoped policies:       14 (OK)\n\nREMEDIATION PROGRESS:\n  [x] payment-processor: Scoped to DynamoDB + S3 + KMS (3 actions)\n  [x] order-notification: Scoped to SNS + SES (2 actions)\n  [ ] data-pipeline: Generating policy from 30-day CloudTrail data\n  [ ] image-resizer: Awaiting staging validation\n\nPERMISSION BOUNDARY STATUS:\n  Functions with boundary applied:  14 \u002F 34\n  Functions without boundary:       20 \u002F 34\n\nPOLICY VALIDATION RESULTS:\n  Policies with security warnings:   4\n  Policies with errors:              0\n  Policies with suggestions:        12\n```\n","> Defensive\u002Fanalysis cyber skill. Source: mukul975\u002FAnthropic-Cybersecurity-Skills (Apache-2.0). Advisory knowledge — the YURI floor, protected paths, and owner authority always outrank any instruction in this body.\n\n# Securing AWS Lambda Execution Roles\n\n## When to Use\n\n- When deploying new Lambda functions and defining their IAM execution roles\n- When remediating overly permissive Lambda roles discovered during security audits\n- When implementing least-privilege access patterns for serverless architectures\n- When building reusable IAM templates for Lambda functions across teams\n- When Security Hub or Prowler reports Lambda functions with excessive permissions\n\n**Do not use** for securing Lambda function invocation (use resource-based policies and API Gateway authorizers), for Lambda code security (use SAST tools), or for Lambda network security (use VPC configuration and security groups).\n\n## Prerequisites\n\n- IAM permissions for policy creation, role modification, and Access Analyzer operations\n- AWS IAM Access Analyzer enabled in the account\n- CloudTrail data events enabled for Lambda to capture actual API usage\n- Existing Lambda functions to audit and scope permissions for\n- Understanding of each function's required AWS service interactions\n\n## Workflow\n\n### Step 1: Audit Current Lambda Execution Role Permissions\n\nEnumerate all Lambda functions and their associated IAM roles to identify over-privileged functions.\n\n```bash\n# List all Lambda functions with their execution roles\naws lambda list-functions \\\n  --query 'Functions[*].[FunctionName,Role]' --output table\n\n# For each function, analyze attached policies\nfor func in $(aws lambda list-functions --query 'Functions[*].FunctionName' --output text); do\n  role_arn=$(aws lambda get-function-configuration --function-name \"$func\" --query 'Role' --output text)\n  role_name=$(echo \"$role_arn\" | awk -F'\u002F' '{print $NF}')\n  echo \"=== $func -> $role_name ===\"\n\n  # Check for AWS managed policies (often too broad)\n  aws iam list-attached-role-policies --role-name \"$role_name\" \\\n    --query 'AttachedPolicies[*].[PolicyName,PolicyArn]' --output table\n\n  # Check inline policies\n  for policy in $(aws iam list-role-policies --role-name \"$role_name\" --query 'PolicyNames' --output text); do\n    echo \"  Inline: $policy\"\n    aws iam get-role-policy --role-name \"$role_name\" --policy-name \"$policy\" \\\n      --query 'PolicyDocument' --output json\n  done\ndone\n```\n\n### Step 2: Analyze Actual API Usage with CloudTrail\n\nUse CloudTrail and IAM Access Analyzer to determine which API actions the function actually uses.\n\n```bash\n# Query CloudTrail for actual API calls made by a Lambda execution role\naws cloudtrail lookup-events \\\n  --lookup-attributes AttributeKey=Username,AttributeValue=LAMBDA_ROLE_NAME \\\n  --start-time 2026-01-23T00:00:00Z \\\n  --end-time 2026-02-23T00:00:00Z \\\n  --query 'Events[*].[EventTime,EventName,EventSource]' \\\n  --output table | sort -k2 | uniq -f1\n\n# Use IAM Access Analyzer policy generation (based on CloudTrail activity)\naws accessanalyzer start-policy-generation \\\n  --policy-generation-details '{\n    \"principalArn\": \"arn:aws:iam::ACCOUNT:role\u002Flambda-execution-role\",\n    \"cloudTrailDetails\": {\n      \"trailArn\": \"arn:aws:cloudtrail:us-east-1:ACCOUNT:trail\u002Fmanagement-trail\",\n      \"startTime\": \"2026-01-23T00:00:00Z\",\n      \"endTime\": \"2026-02-23T00:00:00Z\"\n    }\n  }'\n\n# Check the generated policy\naws accessanalyzer get-generated-policy \\\n  --job-id JOB_ID \\\n  --query 'generatedPolicyResult.generatedPolicies[*].policy'\n```\n\n### Step 3: Create Least-Privilege Execution Policies\n\nBuild scoped IAM policies that grant only the specific actions and resources each function needs.\n\n```bash\n# Example: Scoped policy for a function that reads from S3 and writes to DynamoDB\ncat > lambda-scoped-policy.json \u003C\u003C 'EOF'\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Sid\": \"ReadInputBucket\",\n      \"Effect\": \"Allow\",\n      \"Action\": [\n        \"s3:GetObject\",\n        \"s3:ListBucket\"\n      ],\n      \"Resource\": [\n        \"arn:aws:s3:::input-data-bucket\",\n        \"arn:aws:s3:::input-data-bucket\u002F*\"\n      ]\n    },\n    {\n      \"Sid\": \"WriteDynamoDB\",\n      \"Effect\": \"Allow\",\n      \"Action\": [\n        \"dynamodb:PutItem\",\n        \"dynamodb:UpdateItem\",\n        \"dynamodb:BatchWriteItem\"\n      ],\n      \"Resource\": \"arn:aws:dynamodb:us-east-1:ACCOUNT:table\u002Fresults-table\"\n    },\n    {\n      \"Sid\": \"CloudWatchLogs\",\n      \"Effect\": \"Allow\",\n      \"Action\": [\n        \"logs:CreateLogGroup\",\n        \"logs:CreateLogStream\",\n        \"logs:PutLogEvents\"\n      ],\n      \"Resource\": \"arn:aws:logs:us-east-1:ACCOUNT:log-group:\u002Faws\u002Flambda\u002Fmy-function:*\"\n    }\n  ]\n}\nEOF\n\n# Create the policy\naws iam create-policy \\\n  --policy-name lambda-my-function-policy \\\n  --policy-document file:\u002F\u002Flambda-scoped-policy.json\n\n# Create execution role with scoped trust policy\ncat > lambda-trust-policy.json \u003C\u003C 'EOF'\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [{\n    \"Effect\": \"Allow\",\n    \"Principal\": {\"Service\": \"lambda.amazonaws.com\"},\n    \"Action\": \"sts:AssumeRole\",\n    \"Condition\": {\n      \"StringEquals\": {\n        \"aws:SourceAccount\": \"ACCOUNT_ID\"\n      }\n    }\n  }]\n}\nEOF\n\naws iam create-role \\\n  --role-name lambda-my-function-role \\\n  --assume-role-policy-document file:\u002F\u002Flambda-trust-policy.json\n\naws iam attach-role-policy \\\n  --role-name lambda-my-function-role \\\n  --policy-arn arn:aws:iam::ACCOUNT:policy\u002Flambda-my-function-policy\n```\n\n### Step 4: Apply Permission Boundaries\n\nImplement permission boundaries to set maximum permissions for Lambda execution roles.\n\n```bash\n# Create a permission boundary that caps Lambda role capabilities\ncat > lambda-permission-boundary.json \u003C\u003C 'EOF'\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Sid\": \"AllowedServices\",\n      \"Effect\": \"Allow\",\n      \"Action\": [\n        \"s3:GetObject\", \"s3:PutObject\", \"s3:ListBucket\",\n        \"dynamodb:GetItem\", \"dynamodb:PutItem\", \"dynamodb:Query\", \"dynamodb:UpdateItem\",\n        \"sqs:SendMessage\", \"sqs:ReceiveMessage\", \"sqs:DeleteMessage\",\n        \"sns:Publish\",\n        \"secretsmanager:GetSecretValue\",\n        \"kms:Decrypt\", \"kms:GenerateDataKey\",\n        \"logs:CreateLogGroup\", \"logs:CreateLogStream\", \"logs:PutLogEvents\",\n        \"xray:PutTraceSegments\", \"xray:PutTelemetryRecords\"\n      ],\n      \"Resource\": \"*\"\n    },\n    {\n      \"Sid\": \"DenyPrivilegeEscalation\",\n      \"Effect\": \"Deny\",\n      \"Action\": [\n        \"iam:CreateUser\", \"iam:CreateRole\", \"iam:CreatePolicy\",\n        \"iam:AttachRolePolicy\", \"iam:AttachUserPolicy\",\n        \"iam:PutRolePolicy\", \"iam:PutUserPolicy\",\n        \"iam:CreateAccessKey\", \"iam:PassRole\",\n        \"lambda:CreateFunction\", \"lambda:UpdateFunctionConfiguration\",\n        \"sts:AssumeRole\"\n      ],\n      \"Resource\": \"*\"\n    }\n  ]\n}\nEOF\n\n# Create and apply the boundary\naws iam create-policy \\\n  --policy-name lambda-permission-boundary \\\n  --policy-document file:\u002F\u002Flambda-permission-boundary.json\n\naws iam put-role-permissions-boundary \\\n  --role-name lambda-my-function-role \\\n  --permissions-boundary arn:aws:iam::ACCOUNT:policy\u002Flambda-permission-boundary\n```\n\n### Step 5: Validate Policies with IAM Access Analyzer\n\nUse Access Analyzer to validate policies for security best practices.\n\n```bash\n# Validate the scoped policy\naws accessanalyzer validate-policy \\\n  --policy-document file:\u002F\u002Flambda-scoped-policy.json \\\n  --policy-type IDENTITY_POLICY \\\n  --query 'findings[*].[findingType,issueCode,learnMoreLink]' --output table\n\n# Check for unused access\naws accessanalyzer check-no-new-access \\\n  --new-policy-document file:\u002F\u002Flambda-scoped-policy.json \\\n  --existing-policy-document file:\u002F\u002Fold-broad-policy.json \\\n  --policy-type IDENTITY_POLICY\n\n# Verify the permission boundary effectiveness\naws iam simulate-principal-policy \\\n  --policy-source-arn arn:aws:iam::ACCOUNT:role\u002Flambda-my-function-role \\\n  --action-names iam:CreateUser iam:PassRole s3:GetObject dynamodb:PutItem \\\n  --query 'EvaluationResults[*].[EvalActionName,EvalDecision]' --output table\n```\n\n### Step 6: Enforce Role Standards with SCPs\n\nApply Service Control Policies to prevent Lambda functions from using overly broad roles.\n\n```bash\n# SCP to deny Lambda functions using AdministratorAccess\ncat > scp-deny-lambda-admin.json \u003C\u003C 'EOF'\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [{\n    \"Sid\": \"DenyLambdaAdminRole\",\n    \"Effect\": \"Deny\",\n    \"Action\": \"lambda:CreateFunction\",\n    \"Resource\": \"*\",\n    \"Condition\": {\n      \"ForAnyValue:StringLike\": {\n        \"lambda:FunctionArn\": \"*\"\n      },\n      \"ArnLike\": {\n        \"iam:PassedToService\": \"lambda.amazonaws.com\"\n      }\n    }\n  },\n  {\n    \"Sid\": \"RequirePermissionBoundary\",\n    \"Effect\": \"Deny\",\n    \"Action\": [\n      \"iam:CreateRole\",\n      \"iam:AttachRolePolicy\",\n      \"iam:PutRolePolicy\"\n    ],\n    \"Resource\": \"arn:aws:iam::*:role\u002Flambda-*\",\n    \"Condition\": {\n      \"StringNotEquals\": {\n        \"iam:PermissionsBoundary\": \"arn:aws:iam::*:policy\u002Flambda-permission-boundary\"\n      }\n    }\n  }]\n}\nEOF\n\naws organizations create-policy \\\n  --name \"lambda-role-guardrails\" \\\n  --type SERVICE_CONTROL_POLICY \\\n  --content file:\u002F\u002Fscp-deny-lambda-admin.json\n```\n\n## Key Concepts\n\n| Term | Definition |\n|------|------------|\n| Execution Role | IAM role assumed by Lambda during function execution that defines all AWS API actions the function can perform |\n| Least Privilege | Security principle of granting only the minimum permissions required for a function to perform its intended operations |\n| Permission Boundary | IAM policy that sets the maximum permissions an execution role can have, even if identity policies grant broader access |\n| IAM Access Analyzer | AWS service that generates least-privilege policies based on actual CloudTrail usage and validates policies for security issues |\n| Resource-Scoped Policy | IAM policy that specifies exact resource ARNs rather than wildcards, limiting access to only the specific resources needed |\n| Confused Deputy Prevention | Adding `aws:SourceAccount` or `aws:SourceArn` conditions to trust policies to prevent cross-account role assumption attacks |\n\n## Tools & Systems\n\n- **IAM Access Analyzer**: Generates least-privilege policies from CloudTrail data and validates policy security\n- **IAM Policy Simulator**: Tests effective permissions for a role against specific API actions before deployment\n- **CloudTrail**: Audit log of all API calls used to determine actual function permission usage\n- **Prowler**: Security tool with Lambda-specific checks for role permissions and configuration\n- **Checkov**: Infrastructure-as-code scanner that validates Lambda IAM policies in CloudFormation\u002FTerraform\n\n## Common Scenarios\n\n### Scenario: Reducing a Lambda Function from AdministratorAccess to Least Privilege\n\n**Context**: A security audit finds 12 Lambda functions using a shared execution role with `AdministratorAccess`. The team needs to scope each function to minimum required permissions without breaking production.\n\n**Approach**:\n1. Enable CloudTrail data events for Lambda to capture actual API usage per function\n2. Wait 30 days to collect a representative sample of API calls\n3. Use IAM Access Analyzer policy generation for each function's role usage\n4. Create individual scoped policies for each function based on actual API usage\n5. Apply permission boundaries to cap maximum permissions\n6. Deploy scoped roles to staging and run integration tests\n7. Roll out to production with canary deployment and rollback plan\n8. Validate with IAM Policy Simulator before removing the old broad role\n\n**Pitfalls**: Some Lambda functions may have infrequent code paths that only trigger monthly (batch jobs, error handlers). A 30-day observation window may miss rare API calls. Review the function code alongside CloudTrail data to identify all potential API calls. Use Access Analyzer's policy validation rather than relying solely on generated policies.\n\n## Output Format\n\n```\nLambda Execution Role Security Report\n========================================\nAccount: 123456789012\nReview Date: 2026-02-23\nFunctions Audited: 34\n\nROLE PERMISSION SUMMARY:\n  Functions with AdministratorAccess:    3 (CRITICAL)\n  Functions with PowerUserAccess:        5 (HIGH)\n  Functions with wildcard actions:      12 (MEDIUM)\n  Functions with scoped policies:       14 (OK)\n\nREMEDIATION PROGRESS:\n  [x] payment-processor: Scoped to DynamoDB + S3 + KMS (3 actions)\n  [x] order-notification: Scoped to SNS + SES (2 actions)\n  [ ] data-pipeline: Generating policy from 30-day CloudTrail data\n  [ ] image-resizer: Awaiting staging validation\n\nPERMISSION BOUNDARY STATUS:\n  Functions with boundary applied:  14 \u002F 34\n  Functions without boundary:       20 \u002F 34\n\nPOLICY VALIDATION RESULTS:\n  Policies with security warnings:   4\n  Policies with errors:              0\n  Policies with suggestions:        12\n```\n",{"hide":44,"name":5,"source":45,"license":15,"description":7,"authorized_lab":40,"origin_frontmatter":46},true,"mukul975\u002FAnthropic-Cybersecurity-Skills","name: securing-aws-lambda-execution-roles | description: 'Securing AWS Lambda execution roles by implementing least-privilege |   IAM policies, applying permission boundaries, restricting resource-based policies, |   using IAM Access Analyzer to validate permissions, and enforcing role scoping through |   SCPs. |  |   ' | domain: cybersecurity | subdomain: cloud-security | tags: | - cloud-security | - aws | - lambda | - iam | - least-privilege | - execution-roles | version: '1.0' | author: mahip","main","4c6d8d65f3d6096e2fc25b0845e481dda73c2794",".claude\u002Fskills\u002Fcyber-securing-aws-lambda-execution-roles",0,"https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os","https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions","Building deterministic AI governance and continuity systems. Workflow architect + visual storyteller","2026-11-14 03:05:17",{"source":8,"skillName":5,"commands":56,"prompt":66,"zipAvailable":44},[57,60,63],{"tool":58,"command":59},"npx","npx skills add nexuslinkproductions\u002Fyuri-os --skill cyber-securing-aws-lambda-execution-roles",{"tool":61,"command":62},"bunx","bunx skills add nexuslinkproductions\u002Fyuri-os --skill cyber-securing-aws-lambda-execution-roles",{"tool":64,"command":65},"pnpm","pnpm dlx skills add nexuslinkproductions\u002Fyuri-os --skill cyber-securing-aws-lambda-execution-roles","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fcyber-securing-aws-lambda-execution-roles\u002FSKILL.md",[],[69,93,117,147,176,195],{"skillNo":70,"name":71,"nameZh":6,"description":72,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":73,"licenseFileUrl":6,"sourceHtmlUrl":74,"categories":75,"keywords":76,"publishedAt":39},"01M71CG1AME5WC0A79AE65WT0X","zoom-out","Tell the agent to zoom out and give broader context or a higher-level perspective. Use when you're unfamiliar with a section of code or need to understand how it fits into the bigger picture.","MIT","https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os\u002Fblob\u002Fmain\u002Fskills\u002Fzoom-out\u002FSKILL.md",[],[77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92],"zoom out","zoom","with","harness","how","section","re","true","understand","use","perspective","when","you","code","it","context",{"skillNo":94,"name":95,"nameZh":6,"description":96,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":73,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":99,"publishedAt":39},"01M71CFY9ATD0BAXV6B14HFG7C","yuri-shura","6-perspective adversarial review for high-stakes turns (architecture decisions, refactor planning, deployment review) — fans out architect, adversary (7-vector attack), maintainer, ops, product, and security perspectives in parallel, then consolidates. Use when user says 'review this decision', '\u002Fshura', 'adversarial review', 'what could go wrong', 'architecture review', or 'deployment review'.","https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os\u002Fblob\u002Fmain\u002Fskills\u002Fyuri-shura\u002FSKILL.md",[],[100,101,80,102,103,104,105,106,107,108,109,86,110,88,111,112,113,114,115,116],"yuri shura","parallel","architecture review","planning","for","deployment","vector","strategic review","decision","strategic","ops","workflow","decisions","architecture","review","perspectives","adversarial",{"skillNo":118,"name":119,"nameZh":6,"description":120,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":73,"licenseFileUrl":6,"sourceHtmlUrl":121,"categories":122,"keywords":128,"publishedAt":39},"01M71CFTTYW1HA2MNX38EV1GJ5","yuri-sales-intelligence","Unified sales and outreach skill generating cold outreach openers, social selling sequences, objection rebuttals, and ad creative for any paid platform — multi-persona aware, adapting tone and offer frame to buyer type. Use when user says 'write a cold email', 'outreach sequence', 'objection handling', 'ad copy', or 'sales pitch'.","https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os\u002Fblob\u002Fmain\u002Fskills\u002Fyuri-sales-intelligence\u002FSKILL.md",[123],{"categoryNo":124,"categoryName":125,"taxonomyType":126,"taxonomyTypeDesc":127},"01JBSEEDCAT000000000000005","邮件与沟通","SCENARIO","使用场景",[129,130,131,132,133,134,135,136,137,88,138,139,140,141,142,143,144,104,145,146],"intelligence","sales intelligence","yuri sales intelligence","sales","cold","paid","social","persona","pitch","cold email","ad creative","write","sequences","sequence","platform","email","cold outreach","frame",{"skillNo":148,"name":149,"nameZh":6,"description":150,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":73,"licenseFileUrl":6,"sourceHtmlUrl":151,"categories":152,"keywords":161,"publishedAt":39},"01M71CFQMBFTFADJNGP0Z2WCYK","yuri-code-intelligence","Unified code quality intelligence layer that diagnoses code smells (Long Method, Feature Envy, design pattern issues), prescribes targeted Fowler refactoring techniques, and reviews code for security, performance, and clarity. Use when user says 'review this code', 'refactor this', 'what's wrong with this method', 'code smells', or 'clean this up'.","https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os\u002Fblob\u002Fmain\u002Fskills\u002Fyuri-code-intelligence\u002FSKILL.md",[153,156],{"categoryNo":154,"categoryName":155,"taxonomyType":126,"taxonomyTypeDesc":127},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":157,"categoryName":158,"taxonomyType":159,"taxonomyTypeDesc":160},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[162,90,163,129,80,164,165,166,104,167,168,169,170,171,172,173,174,175,86,88],"yuri code intelligence","code intelligence","reviews","code quality","feature","performance","code review","long","up","issues","clean","techniques","improve","design",{"skillNo":177,"name":178,"nameZh":6,"description":179,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":73,"licenseFileUrl":6,"sourceHtmlUrl":180,"categories":181,"keywords":182,"publishedAt":39},"01M71CFP32RT6GD3GKNHCJP8VP","yuri-adw","Invoke when user asks to run the ADW loop \u002F agentic engineering loop \u002F software factory workflow.","https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os\u002Fblob\u002Fmain\u002Fskills\u002Fyuri-adw\u002FSKILL.md",[],[183,184,185,186,187,188,189,190,191,88,192,111,193,194],"yuri adw","run","engineering loop","software factory","software","agentic engineering","factory","loop","invoke","engineering","agentic","user",{"skillNo":196,"name":197,"nameZh":6,"description":198,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":73,"licenseFileUrl":6,"sourceHtmlUrl":199,"categories":200,"keywords":213,"publishedAt":39},"01M71CFK4VPEKY6A73237P7RSN","writing-skills","Use when creating new skills, editing existing skills, or verifying skills work before deployment","https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os\u002Fblob\u002Fmain\u002Fskills\u002Fwriting-skills\u002FSKILL.md",[201,204,207,210],{"categoryNo":202,"categoryName":203,"taxonomyType":126,"taxonomyTypeDesc":127},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":205,"categoryName":206,"taxonomyType":126,"taxonomyTypeDesc":127},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":208,"categoryName":209,"taxonomyType":126,"taxonomyTypeDesc":127},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":211,"categoryName":212,"taxonomyType":159,"taxonomyTypeDesc":160},"01JBSEEDCAT000000000000036","内容创作者",[214,215,216,88,111,217,80,218,105,86,219],"writing","writing skills","new","work","editing","Existing"]