← Back to Labs L2 Intermediate

AWS · Compute · Workload Identity Risk

AWS Lambda Execution Role Risk

Intermediate LAB for understanding how Lambda execution roles, function management permissions, iam:PassRole, Secrets Manager access, and KMS decrypt authority combine into workload identity risk.

Status Intermediate
Cloud AWS
Domain Compute
Track L2 Applied

Overview

Lambda execution role risk appears when a principal can influence code or configuration that runs under a stronger role. This is workload identity risk: the workload performs actions the caller may not be able to perform directly.

L2 Intermediate Workload identity iam:PassRole bridge No live mutation

Concept Deep Dives

Expand these concepts when studying Lambda workload identity or explaining applied privilege paths.

What is a Lambda execution role?

A Lambda execution role is the IAM role assumed by the Lambda service when a function runs. The function's runtime permissions come from this role, not from the caller who created or invoked the function.

Why does iam:PassRole matter?

iam:PassRole controls whether a principal can attach an IAM role to a service such as Lambda. If a principal can pass a powerful role and create or update a function, a workload identity path may emerge.

What is workload identity risk?

Workload identity risk occurs when an application, function, job, or service runs with permissions that can access sensitive resources, especially when lower-privilege users can influence that workload.

How do Secrets Manager and KMS connect?

Lambda functions often retrieve secrets and decrypt data. If the execution role has Secrets Manager and KMS authority, function code may access sensitive values at runtime.

What should executives understand?

Serverless risk is identity risk. The important question is not only who can call a function, but who can change what it runs as and what protected systems that role can access.

Visual Lambda Workload Identity Model

Lambda execution role risk is easiest to understand as a caller-to-workload identity path.

Caller / CI Principal User, pipeline, or automation with Lambda permissions
→
Function Control Create, update code, update config, or invoke
→
Execution Role Runtime authority assumed by Lambda
→
Workload Risk Access secrets, decrypt data, read storage, or call APIs
Can Update Code Caller controls function behavior
+
Role Has Sensitive Access Secrets Manager, KMS, S3, or admin APIs
→
Risk Possible Workload may perform sensitive actions
Can Create Function Caller can define new workload
+
PassRole Denied Caller cannot attach stronger role
→
Path Reduced Execution-role escalation is blocked
Learning rule: Lambda risk is not only "who can invoke?" It is also "who can control code or configuration that runs under this role?"

Example Scenario

A developer can update Lambda code. The function's execution role can retrieve a production secret and decrypt it. 

Caller permission: lambda:UpdateFunctionCode allowed
Execution role: secretsmanager:GetSecretValue allowed
Execution role: kms:Decrypt allowed
Function behavior: controlled by caller
Final result: WORKLOAD IDENTITY RISK POSSIBLE

Authorization Layers

This lab connects workload identity risk to the broader L2 authorization model.

IAM Policy Evaluation Can the caller create, update, pass, or invoke? iam:PassRole Privilege Escalation Can the caller attach a stronger role to Lambda? Secrets Manager Access Evaluation Can the execution role retrieve sensitive secrets? KMS Key Policy Evaluation Can the execution role decrypt protected data?

Bridge to Principal LABs

Lambda execution role risk is an applied bridge into Principal LABs because it demonstrates how workload identity can expand authority through role attachment, function code, and runtime permissions.

iam:PassRole Privilege Escalation Passing a stronger role to Lambda is a classic workload escalation path. Cross-Account Role Escalation Lambda execution roles may access cross-account resources when trust permits. Role Chaining Escalation Lambda-managed identities can participate in downstream role assumptions.

Governance Boundary

This lab is read-only and deterministic. 

Runtime = source of truth
OPA = decision authority
Aegis = bounded intelligence
Frontend = rendering only
  • Does not exploit AWS
  • Does not mutate infrastructure
  • Does not deploy Lambda functions
  • Does not update real function code
  • Does not pass IAM roles
  • Does not invoke AWS APIs against customer accounts
  • Does not retrieve secrets or decrypt data
  • Does not override OPA

Source Artifacts

  • metadata.json
  • architecture.md
  • index.html