Keep identity authoritative

Use the approved execution boundary

A role must be registered/approved and bound through trusted deployment metadata. A payload cannot replace it. A dedicated Lambda role, a scoped subprocess session and a shared runner without AWS credentials have different isolation properties.

{
  "role": "arn:aws:iam::111122223333:role/example-handler",
  "isolationBoundary": "dedicated_lambda_execution_role"
}

{
  "name": "advanced-isolation",
  "version": "1.0.0",
  "lanes": {
    "inline": {
      "mode": "sync_lambda",
      "target": "lambda://local-inline"
    }
  },
  "phases": {
    "work": {
      "service": "hello",
      "lane": "inline",
      "scope": "root",
      "terminal": true,
      "role": "arn:aws:iam::111122223333:role/example-handler",
      "isolationBoundary": "dedicated_lambda_execution_role",
      "dedicatedHandlerFunctionArn": "arn:aws:lambda:us-east-1:111122223333:function:example-handler"
    }
  }
}

name: advanced-isolation
version: 1.0.0
lanes:
  inline:
    mode: sync_lambda
    target: lambda://local-inline
phases:
  work:
    service: hello
    lane: inline
    scope: root
    terminal: true
    role: arn:aws:iam::111122223333:role/example-handler
    isolationBoundary: dedicated_lambda_execution_role
    dedicatedHandlerFunctionArn: arn:aws:lambda:us-east-1:111122223333:function:example-handler

rippflow controls validate advanced-isolation.workflow.yaml --json

Use a role inside a managed handler

orders-reader is an installation-approved role alias. The runner assumes it and injects temporary credentials into a fresh handler process (core, runner). Locally (guide →), role-labeled phases fail closed unless STS AssumeRole runs via AWS_ENDPOINT_URL[_STS] or RIPPFLOW_ASSUME_PHASE_ROLES=1; reserved AWS_* manifest env keys are rejected and unroled phases scrub AWS_* env vars.

Download the Python DynamoDB handler and optional role/table template.

import boto3

# Uses the temporary credentials supplied by the runner.
result = boto3.client("dynamodb").get_item(
    TableName="app-orders", Key={"orderId": {"S": "order-123"}}
)

{
  "name": "read-order-with-approved-role",
  "version": "1.0.0",
  "default_group": "python-standard",
  "phases": {
    "read_order": {
      "service": "orders.read",
      "role": "orders-reader",
      "isolationBoundary": "hardened_subprocess_with_scoped_session",
      "inputs": {"table": "app-orders", "orderId": "order-123"},
      "terminal": true
    }
  }
}

name: read-order-with-approved-role
version: 1.0.0
default_group: python-standard
phases:
  read_order:
    service: orders.read
    role: orders-reader
    isolationBoundary: hardened_subprocess_with_scoped_session
    inputs:
      table: app-orders
      orderId: order-123
    terminal: true

rippflow controls validate advanced-scoped-iam.workflow.yaml --json

Approve access before dispatch

1. Operator: create a workload role granting only dynamodb:GetItem on the application table. Trust the installed runner for sts:AssumeRole and sts:TagSession.
2. Register orders-reader and bind its resolved ARN in the signed deployment manifest.
3. Publish the handler artifact; dispatch through that installation.

The STS guardrail preserves approved workload permissions while denying reserved infrastructure, IAM operations and role chaining. Strict principal isolation still requires a dedicated Lambda.

Full operator setup →

Do not trust caller-supplied grants

Admission verifies signed manifests/task identity and immutable artifact/binding references. Configure deployment trust and callback keys through trusted installation setup. Do not use local/test fallback signing material in a customer deployment.

Check identity and permissions first

Controller JWT tenancy and read/write/admin roles apply before business operations. Enterprise SSO maps approved groups to roles; the CLI does not bypass installation authorization. Local executables remain trusted programs with machine access.

rippflow auth status --json
rippflow whoami --json
rippflow rbac status --json
rippflow users list --json