Lambda Over-Privileged Roles and Secrets

Description

Lambda functions often run with overly broad IAM roles and store secrets in environment variables or layers, enabling data access or lateral movement on compromise. Additional risks include public function URLs without auth, permissive resource‑based policies, VPC egress that allows exfiltration, and missing encryption/KMS on environment variables and logs.

Examples

Inspect Role and Env Vars

aws lambda get-function-configuration --function-name <name>
aws iam get-role --role-name <role>
aws lambda get-policy --function-name <name>
aws lambda list-function-url-configs --function-name <name>

Look for Action: "*" or broad resource wildcards and plaintext secrets.

Check environment encryption and logging

aws lambda get-function-configuration --function-name <name> \
  --query '{KMSKeyArn:KMSKeyArn,TracingConfig:TracingConfig,DeadLetterConfig:DeadLetterConfig}'

Remediation

  1. Use least-privilege roles scoped to function resources; avoid wildcards.
  2. Store secrets in AWS Secrets Manager/SSM Parameter Store and inject at runtime; encrypt env vars with a dedicated KMS key.
  3. Restrict exposure
    • Remove public function URLs unless required; lock resource policies to specific principals; place functions in private subnets and restrict egress via NAT/Network Firewall/VPC endpoints.
  4. Observability and resilience
    • Enable X‑Ray tracing, structured logging, DLQs, and alarms for error spikes and permission failures.