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.
Instrucciones de origen · Vista previa de solo lectura
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.
When deploying new Lambda functions and defining their IAM execution roles
When remediating overly permissive Lambda roles discovered during security audits
When implementing least-privilege access patterns for serverless architectures
When building reusable IAM templates for Lambda functions across teams
When Security Hub or Prowler reports Lambda functions with excessive permissions
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).
Common Misconfigurations & Verification
CloudTrail-generated policies miss rare code paths: monthly batch jobs and error handlers may not appear in a 30-day window, so the generated least-privilege policy omits needed actions. Cross-read the function code and test in staging before cutover.
Scoped policy attached but broad one left behind:AWSLambdaBasicExecutionRole or a wildcard inline policy still attached = still over-privileged. Enumerate both list-attached-role-policies and list-role-policies.
Permission boundary Deny gaps: with Resource: "*" on the Allow block, the Deny block must actually cover escalation (iam:*, lambda:CreateFunction, sts:AssumeRole, iam:PassRole). Prove the Deny wins with aws iam simulate-principal-policy.
Confused-deputy trust policy: missing aws:SourceAccount/aws:SourceArn in the lambda.amazonaws.com trust condition. Confirm the condition is present and matches the account.
SCP name-pattern bypass: the rule requiring iam:PermissionsBoundary only matches role/lambda-*; a role named otherwise skips the guardrail. Enforce the naming convention.
Missing scoped logs:* to the function's log group breaks logging silently - the function runs but emits nothing.
Verify it actually works:aws accessanalyzer validate-policy --policy-type IDENTITY_POLICY returns no errors; simulate-principal-policy shows required actions Allow and escalation actions Deny; and the function still passes integration tests after the role swap (invoke it and confirm CloudWatch logs appear).
Prerequisites
IAM permissions for policy creation, role modification, and Access Analyzer operations
AWS IAM Access Analyzer enabled in the account
CloudTrail data events enabled for Lambda to capture actual API usage
Existing Lambda functions to audit and scope permissions for
Understanding of each function's required AWS service interactions
Workflow
Step 1: Audit Current Lambda Execution Role Permissions
Enumerate all Lambda functions and their associated IAM roles to identify over-privileged functions.
# List all Lambda functions with their execution roles
aws lambda list-functions \
--query 'Functions[*].[FunctionName,Role]' --output table
# For each function, analyze attached policiesfor func in $(aws lambda list-functions --query 'Functions[*].FunctionName' --output text); do
role_arn=$(aws lambda get-function-configuration --function-name "$func" --query 'Role' --output text)
role_name=$(echo"$role_arn" | awk -F'/''{print $NF}')
echo"=== $func -> $role_name ==="# Check for AWS managed policies (often too broad)
aws iam list-attached-role-policies --role-name "$role_name" \
--query 'AttachedPolicies[*].[PolicyName,PolicyArn]' --output table
# Check inline policiesfor policy in $(aws iam list-role-policies --role-name "$role_name" --query 'PolicyNames' --output text); doecho" Inline: $policy"
aws iam get-role-policy --role-name "$role_name" --policy-name "$policy" \
--query 'PolicyDocument' --output json
donedone
Step 2: Analyze Actual API Usage with CloudTrail
Use CloudTrail and IAM Access Analyzer to determine which API actions the function actually uses.
# Query CloudTrail for actual API calls made by a Lambda execution role
aws cloudtrail lookup-events \
--lookup-attributes AttributeKey=Username,AttributeValue=LAMBDA_ROLE_NAME \
--start-time 2026-01-23T00:00:00Z \
--end-time 2026-02-23T00:00:00Z \
--query 'Events[*].[EventTime,EventName,EventSource]' \
--output table | sort -k2 | uniq -f1
# Use IAM Access Analyzer policy generation (based on CloudTrail activity)
aws accessanalyzer start-policy-generation \
--policy-generation-details '{
"principalArn": "arn:aws:iam::ACCOUNT:role/lambda-execution-role",
"cloudTrailDetails": {
"trailArn": "arn:aws:cloudtrail:us-east-1:ACCOUNT:trail/management-trail",
"startTime": "2026-01-23T00:00:00Z",
"endTime": "2026-02-23T00:00:00Z"
}
}'# Check the generated policy
aws accessanalyzer get-generated-policy \
--job-id JOB_ID \
--query 'generatedPolicyResult.generatedPolicies[*].policy'
Step 3: Create Least-Privilege Execution Policies
Build scoped IAM policies that grant only the specific actions and resources each function needs.
IAM role assumed by Lambda during function execution that defines all AWS API actions the function can perform
Least Privilege
Security principle of granting only the minimum permissions required for a function to perform its intended operations
Permission Boundary
IAM policy that sets the maximum permissions an execution role can have, even if identity policies grant broader access
IAM Access Analyzer
AWS service that generates least-privilege policies based on actual CloudTrail usage and validates policies for security issues
Resource-Scoped Policy
IAM policy that specifies exact resource ARNs rather than wildcards, limiting access to only the specific resources needed
Confused Deputy Prevention
Adding aws:SourceAccount or aws:SourceArn conditions to trust policies to prevent cross-account role assumption attacks
Tools & Systems
IAM Access Analyzer: Generates least-privilege policies from CloudTrail data and validates policy security
IAM Policy Simulator: Tests effective permissions for a role against specific API actions before deployment
CloudTrail: Audit log of all API calls used to determine actual function permission usage
Prowler: Security tool with Lambda-specific checks for role permissions and configuration
Checkov: Infrastructure-as-code scanner that validates Lambda IAM policies in CloudFormation/Terraform
Common Scenarios
Scenario: Reducing a Lambda Function from AdministratorAccess to Least Privilege
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.
Approach:
Enable CloudTrail data events for Lambda to capture actual API usage per function
Wait 30 days to collect a representative sample of API calls
Use IAM Access Analyzer policy generation for each function's role usage
Create individual scoped policies for each function based on actual API usage
Apply permission boundaries to cap maximum permissions
Deploy scoped roles to staging and run integration tests
Roll out to production with canary deployment and rollback plan
Validate with IAM Policy Simulator before removing the old broad role
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.
Output Format
Lambda Execution Role Security Report
========================================
Account: 123456789012
Review Date: 2026-02-23
Functions Audited: 34
ROLE PERMISSION SUMMARY:
Functions with AdministratorAccess: 3 (CRITICAL)
Functions with PowerUserAccess: 5 (HIGH)
Functions with wildcard actions: 12 (MEDIUM)
Functions with scoped policies: 14 (OK)
REMEDIATION PROGRESS:
[x] payment-processor: Scoped to DynamoDB + S3 + KMS (3 actions)
[x] order-notification: Scoped to SNS + SES (2 actions)
[ ] data-pipeline: Generating policy from 30-day CloudTrail data
[ ] image-resizer: Awaiting staging validation
PERMISSION BOUNDARY STATUS:
Functions with boundary applied: 14 / 34
Functions without boundary: 20 / 34
POLICY VALIDATION RESULTS:
Policies with security warnings: 4
Policies with errors: 0
Policies with suggestions: 12
