@kensio/yulin 1.20.16 → 1.20.17

package/docs/services/iam/README.md

@@ -220,6 +220,21 @@ Creating a duplicate Policy name in the same path throws an error, while the sam
 paths is allowed. Stored Policies can be inspected with `GetPolicyCommand` and
 `ListPoliciesCommand`.
 
+## Policy document character limits
+
+IAM caps a policy document by where it is going. A managed policy takes 6,144 characters, an inline
+policy on a Role or a User takes 10,240, and a Role trust policy takes 2,048. `CreatePolicy`,
+`PutRolePolicy`, `PutUserPolicy` and `CreateRole` refuse a document past the cap with
+`LimitExceeded`, in IAM's own wording. An `AWS::IAM::ManagedPolicy` or an `AWS::IAM::Policy`
+carrying one fails its Resource.
+
+IAM leaves whitespace out of the count, and so does the check here. A document indented for a
+reader measures the same as the one line `JSON.stringify` writes.
+
+A policy that has outgrown its cap cannot be deployed. The account keeps whichever version last
+fit, and the permission the policy was grown to grant goes missing weeks later, against a
+repository that still says it is there.
+
 ## Policy conditions
 
 Policy statements can carry `Condition` blocks. Sim IAM currently supports the `StringEquals`,
@@ -558,37 +573,37 @@ const simAws = new SimAws({
   },
 });
 
-// The Role is created as the Account root. A simulation with a default caller
-// attributes these commands to it, and it holds no policy until they are done.
-const root = simAws.account().rootPrincipal;
+// The Role is created inside a run as the Account root. A simulation with a
+// default caller attributes these commands to it, and it holds no policy until
+// they are done.
 const simIam = simAws.iam();
 
-await simIam.createRole(
-  new CreateRoleCommand({
-    RoleName: "Administrator",
-    AssumeRolePolicyDocument: JSON.stringify({
-      Version: "2012-10-17",
-      Statement: {
-        Effect: "Allow",
-        Principal: { AWS: "arn:aws:iam::123456789012:root" },
-        Action: "sts:AssumeRole",
-      },
+await simAws.runAs(simAws.account().rootPrincipal, async () => {
+  await simIam.createRole(
+    new CreateRoleCommand({
+      RoleName: "Administrator",
+      AssumeRolePolicyDocument: JSON.stringify({
+        Version: "2012-10-17",
+        Statement: {
+          Effect: "Allow",
+          Principal: { AWS: "arn:aws:iam::123456789012:root" },
+          Action: "sts:AssumeRole",
+        },
+      }),
     }),
-  }),
-  { caller: root },
-);
+  );
 
-await simIam.putRolePolicy(
-  new PutRolePolicyCommand({
-    RoleName: "Administrator",
-    PolicyName: "Administer",
-    PolicyDocument: JSON.stringify({
-      Version: "2012-10-17",
-      Statement: { Effect: "Allow", Action: "*", Resource: "*" },
+  await simIam.putRolePolicy(
+    new PutRolePolicyCommand({
+      RoleName: "Administrator",
+      PolicyName: "Administer",
+      PolicyDocument: JSON.stringify({
+        Version: "2012-10-17",
+        Statement: { Effect: "Allow", Action: "*", Resource: "*" },
+      }),
     }),
-  }),
-  { caller: root },
-);
+  );
+});
 
 const decision = simAws.iam().authorize({
   action: "s3:GetObject",
@@ -605,7 +620,8 @@ Account that issued a key can authenticate it, and a default is held for a whole
 
 The default reaches a direct sim service call, an intercepted SDK Command, a CloudFormation
 deployment and STS. Three things outrank it, each of them a caller stated for the request in hand.
-An operation's own `caller` wins, as does the ambient caller of a `runAs` block and the `caller` a
+An operation's own `caller` wins, as does the ambient caller of a `runAs` block (covered in
+[Run a block of calls as one caller](#run-a-block-of-calls-as-one-caller)) and the `caller` a
 deployment is given.
 
 A simulation told no `defaultCaller` decides an unattributed call as the Account root, which is what
@@ -617,6 +633,86 @@ The reason to name one is a service control policy denying the Account root.
 [Simulated Organizations](https://yulinsim.dev/services/organizations/) covers that case, where
 every unattributed read is otherwise denied on a message about the root.
 
+## Run a block of calls as one caller
+
+`simAws.runAs(caller, run)` sets an ambient caller for the length of a run. Everything called during
+the run is attributed to that principal, and the code being tested says nothing about it.
+
+```typescript sim-iam-run-as
+/**
+ * Attributing a block of calls to one simulated caller.
+ */
+
+import { CreateRoleCommand, PutRolePolicyCommand } from "@aws-sdk/client-iam";
+import { SimAws } from "@kensio/yulin";
+
+const simAws = new SimAws({ defaultAccountId: "123456789012" });
+const simIam = simAws.iam();
+
+await simIam.createRole(
+  new CreateRoleCommand({
+    RoleName: "Reporter",
+    AssumeRolePolicyDocument: JSON.stringify({
+      Version: "2012-10-17",
+      Statement: {
+        Effect: "Allow",
+        Principal: { AWS: "arn:aws:iam::123456789012:root" },
+        Action: "sts:AssumeRole",
+      },
+    }),
+  }),
+);
+
+await simIam.putRolePolicy(
+  new PutRolePolicyCommand({
+    RoleName: "Reporter",
+    PolicyName: "ReadParameters",
+    PolicyDocument: JSON.stringify({
+      Version: "2012-10-17",
+      Statement: { Effect: "Allow", Action: "ssm:GetParameter", Resource: "*" },
+    }),
+  }),
+);
+
+await simAws.ssm().putParameter({
+  input: { Name: "/reports/last-run", Type: "String", Value: "done" },
+});
+
+const reporter = "arn:aws:iam::123456789012:role/Reporter";
+
+await simAws.runAs({ kind: "arn", arn: reporter }, async () => {
+  // The read is a direct sim service call, decided as the Reporter Role.
+  const read = await simAws
+    .ssm()
+    .getParameter({ input: { Name: "/reports/last-run" } });
+
+  const write = simIam.authorize({
+    action: "ssm:PutParameter",
+    resource: "*",
+  });
+
+  console.log(read.Parameter?.Value); // "done"
+  console.log(write.caller.arn); // "arn:aws:iam::123456789012:role/Reporter"
+  console.log(write.isDenied); // true
+});
+```
+
+The ambient caller reaches a direct sim service call and an intercepted SDK Command. An operation's
+own `caller` still wins, and `deployTemplate` and `deployCdkOut` take a `caller` of their own. Runs
+nest, and the innermost caller applies.
+
+A run belongs to the `SimAws` instance it was started on. Two simulations in one test file are two
+simulated universes, and a run on one leaves the other's calls where they were.
+
+Simulated Lambda and ECS set an ambient caller the same way. A Lambda handler runs as the function's
+execution Role and an ECS container runs as its task Role. A direct sim service call from inside
+either is decided as that Role, matching what the deployed code has credentials for.
+
+This is also how a simulation bootstraps the principal its own `defaultCaller` names. That Role has
+to be created before it can decide anything, and the creation therefore runs as something else.
+Wrapping it in `runAs(simAws.account().rootPrincipal, ...)` is the shape for that, since sim IAM
+gives the Account root unrestricted access.
+
 ## Callers of HTTP requests
 
 An in-process SDK call can be told who its caller is. A request arriving over HTTP, through
@@ -840,6 +936,186 @@ action, resource, and caller for diagnostics, before the service mutates any sta
 caller defaults to the Account root. The Account root is allowed within its own Account, and a test
 that never mentions IAM keeps working.
 
+## Passing a Role to a service
+
+A simulated service handed a Role keeps it and uses it later, under its own identity. AWS asks two
+questions about that. The first is whether the caller may create the thing. The second is whether the
+caller may hand that Role over, and its resource is the Role.
+
+Six simulated services ask the second question. A caller allowed the create action and refused
+`iam:PassRole` fails the request with an access-denied error naming the Role and the caller. A scoped
+deployment role refused `iam:PassRole` is one of the commoner ways a real deployment stops, and a
+deployment through
+[simulated CloudFormation](https://yulinsim.dev/services/cloudformation/ "Simulated CloudFormation usage docs")
+carries the same decision to every Resource it creates.
+
+| Request                                                | The Role it hands over                   | `iam:PassedToService`     |
+| ------------------------------------------------------ | ---------------------------------------- | ------------------------- |
+| Lambda `CreateFunction`, `UpdateFunctionConfiguration` | `Role`                                   | `lambda.amazonaws.com`    |
+| Scheduler `CreateSchedule`, `UpdateSchedule`           | `Target.RoleArn`                         | `scheduler.amazonaws.com` |
+| EventBridge `PutTargets`                               | a target's `RoleArn`                     | `events.amazonaws.com`    |
+| Step Functions `CreateStateMachine`                    | `roleArn`                                | `states.amazonaws.com`    |
+| ECS `RegisterTaskDefinition`                           | `taskRoleArn` and `executionRoleArn`     | `ecs-tasks.amazonaws.com` |
+| Firehose `CreateDeliveryStream`                        | the destination Role and the source Role | `firehose.amazonaws.com`  |
+
+Each Role is a separate decision, so a caller allowed one of an ECS task definition's two Roles is
+refused on the other. A request leaving an optional Role out passes nothing and is asked nothing.
+
+The condition key `iam:PassedToService` carries the service principal the Role goes to. A
+CDK-generated deployment policy commonly conditions its `iam:PassRole` statement on that key, and a
+policy written that way matches here.
+
+```typescript sim-iam-pass-role
+/**
+ * Authorizing the execution role a Lambda function is created with.
+ */
+
+import { CreateRoleCommand, PutRolePolicyCommand } from "@aws-sdk/client-iam";
+import { CreateFunctionCommand } from "@aws-sdk/client-lambda";
+import { SimAws } from "@kensio/yulin";
+import { makeLambdaZipFileInput } from "@kensio/yulin/lambda";
+
+const simAws = new SimAws({ defaultAccountId: "123456789012" });
+const simIam = simAws.iam();
+
+const deployerCreation = await simIam.createRole(
+  new CreateRoleCommand({
+    RoleName: "Deployer",
+    AssumeRolePolicyDocument: JSON.stringify({
+      Version: "2012-10-17",
+      Statement: {
+        Effect: "Allow",
+        Principal: { Service: "cloudformation.amazonaws.com" },
+        Action: "sts:AssumeRole",
+      },
+    }),
+  }),
+);
+
+await simIam.putRolePolicy(
+  new PutRolePolicyCommand({
+    RoleName: "Deployer",
+    PolicyName: "DeployFunctions",
+    PolicyDocument: JSON.stringify({
+      Version: "2012-10-17",
+      Statement: [
+        { Effect: "Allow", Action: "lambda:CreateFunction", Resource: "*" },
+        {
+          Effect: "Allow",
+          Action: "iam:PassRole",
+          Resource: "arn:aws:iam::123456789012:role/ReportsExecutionRole",
+          Condition: {
+            StringEquals: { "iam:PassedToService": "lambda.amazonaws.com" },
+          },
+        },
+      ],
+    }),
+  }),
+);
+
+const asDeployer = {
+  caller: { kind: "arn", arn: deployerCreation.Role.Arn },
+} as const;
+
+await simAws.lambda().createFunction(
+  new CreateFunctionCommand({
+    FunctionName: "reports",
+    Role: "arn:aws:iam::123456789012:role/ReportsExecutionRole",
+    Code: { ZipFile: makeLambdaZipFileInput(() => null) },
+  }),
+  asDeployer,
+);
+
+try {
+  await simAws.lambda().createFunction(
+    new CreateFunctionCommand({
+      FunctionName: "invoices",
+      Role: "arn:aws:iam::123456789012:role/AdminRole",
+      Code: { ZipFile: makeLambdaZipFileInput(() => null) },
+    }),
+    asDeployer,
+  );
+} catch (error) {
+  console.error("Passing AdminRole to Lambda was refused", error);
+}
+
+await simAws.backgroundTasksComplete();
+```
+
+A request naming no caller is decided as the Account root, which may pass any Role. A test that never
+mentions IAM keeps working.
+
+## A Role for a CloudFormation deployment
+
+`makeDeployRole(...)` creates a Role from a policy document and hands back a caller. Pass it as
+`caller` to `deployTemplate(...)`, `deployTemplateFile(...)` or `deployCdkOut(...)`, and every
+resource the deployment creates is authorized against the document.
+
+```typescript sim-iam-make-deploy-role
+/**
+ * Making a deploy Role from a policy document a project already holds.
+ */
+
+import { SimAws } from "@kensio/yulin";
+
+const simAws = new SimAws({ defaultAccountId: "123456789012" });
+
+const deployer = await simAws.iam().makeDeployRole({
+  roleName: "cdk-exec",
+  policyDocument: {
+    Version: "2012-10-17",
+    Statement: {
+      Effect: "Allow",
+      Action: ["s3:*", "kms:*"],
+      Resource: "*",
+    },
+  },
+});
+
+console.log(deployer.arn); // "arn:aws:iam::123456789012:role/cdk-exec"
+
+await simAws
+  .cloudFormation()
+  .deployCdkOut({ directoryPath: "cdk.out", caller: deployer });
+```
+
+The Role trusts `cloudformation.amazonaws.com` and holds the document as an inline policy. A
+deployment that asks for something the document leaves out fails the resource, with the Role's ARN in
+the message.
+
+`policyDocument` also takes the JSON a synthesized policy is carried as, and a list of documents for
+a policy split in two to stay under IAM's size cap. Each document goes on the Role as its own inline
+policy, and the Role is allowed the union of them.
+
+```typescript sim-iam-deploy-role-documents
+/**
+ * A deploy Role from a policy split across two documents.
+ */
+
+import { SimAws } from "@kensio/yulin";
+
+const simAws = new SimAws({ defaultAccountId: "123456789012" });
+
+const deployer = await simAws.iam().makeDeployRole({
+  roleName: "cdk-exec",
+  policyDocument: [
+    JSON.stringify({
+      Version: "2012-10-17",
+      Statement: { Effect: "Allow", Action: "s3:*", Resource: "*" },
+    }),
+    {
+      Version: "2012-10-17",
+      Statement: { Effect: "Allow", Action: "kms:*", Resource: "*" },
+    },
+  ],
+});
+
+console.log(deployer.kind); // "arn"
+```
+
+Making the Role is two ordinary IAM commands. A simulation with a restrictive default caller has to
+be allowed them, or the call wrapped in `simAws.runAs(...)`.
+
 ## CloudFormation IAM resources
 
 Sim CloudFormation can create IAM resources from `AWS::IAM::Role`, `AWS::IAM::User`,
@@ -860,6 +1136,18 @@ is created (the attachment `AttachRolePolicy` records). A name no simulated Role
 answers to fails the resource. Deleting the stack takes the policy back off the Roles still
 carrying it, and then deletes the policy.
 
+A Role with no `RoleName`, a User with no `UserName` and a Managed Policy with no
+`ManagedPolicyName` are each named from the stack name, the logical ID and a tail derived from both.
+A `ServiceRole` in `iam-stack` becomes `iam-stack-ServiceRole-` and twelve more characters, where
+real CloudFormation ends the name in twelve random ones. The case is kept as it was written, the way
+IAM keeps it. A Role name and a User name are trimmed to 64 characters and a policy name to 128, and
+[the CloudFormation docs](https://yulinsim.dev/services/cloudformation/#names-cloudformation-generates "Names CloudFormation generates")
+cover how the stack name and the logical ID share what is left.
+
+That name is what an IAM policy scoped by name prefix matches. A deploy Role allowed `iam:CreateRole`
+on `arn:aws:iam::123456789012:role/iam-stack-*` covers the Roles its own stack creates, here and in
+an account.
+
 ```typescript sim-iam-cloudformation
 /**
  * Creating IAM resources through simulated CloudFormation.
@@ -1231,10 +1519,12 @@ instance when a test should exercise real IAM enforcement.
 
 Sim IAM currently supports:
 
+- `makeDeployRole(...)`, creating a Role for a CloudFormation deployment to run as
 - `CreateRoleCommand`, including trust-policy validation
 - `GetRoleCommand` and `ListRolesCommand`, with pagination
 - `PutRolePolicyCommand`, for inline Role policies
 - `CreatePolicyCommand`, `GetPolicyCommand` and `ListPoliciesCommand`, for managed Policies
+- Refusing a policy document over IAM's character limit, with `LimitExceeded`
 - `AttachRolePolicyCommand`
 - `CreateUserCommand`, `DeleteUserCommand`, `PutUserPolicyCommand` and `AttachUserPolicyCommand`
 - `CreateLoginProfileCommand`, for a User's console password
@@ -1242,6 +1532,8 @@ Sim IAM currently supports:
 - Allow/deny authorization decisions with `authorize(...)`, evaluating identity policies,
   service-supplied resource policies, and policy conditions with explicit-deny precedence
 - IAM authorization at simulated service boundaries, such as Route53 actions
+- `iam:PassRole` authorization of a Role handed to simulated Lambda, Scheduler, EventBridge, Step
+  Functions, ECS or Firehose, with `iam:PassedToService` supplied
 - Resolving the caller of an HTTP request, from an `x-sim-aws-caller` header or a verified SigV4
   signature, defaulting to anonymous, and the resource it is made on behalf of from
   `x-sim-aws-source-arn` and `x-sim-aws-source-account`
@@ -1262,6 +1554,9 @@ Sim IAM models the policy behaviour that multi-service tests most commonly need.
 - Permissions boundaries and session policies are not evaluated. Service control policies are, and
   are attached through [simulated Organizations](https://yulinsim.dev/services/organizations/ "Simulated Organizations service control policies usage docs")
 - Managed Policies have a single version, and the policy version commands are absent
+- A policy document is measured against IAM's character limit one document at a time. The
+  20,480-character cap on the sum of a User's inline policies is absent, and so is the cap on how
+  many managed policies a Role may carry
 - `DeleteUserPolicy` and `DetachUserPolicy` are absent, along with `DeleteAccessKey` and
   `DeleteLoginProfile`. `DeleteUserCommand` refuses a User that still holds a policy, and
   CloudFormation teardown clears a User's policies before deleting it

package/docs/services/kinesis/README.md

@@ -275,8 +275,9 @@ await simAws.kinesis().putRecord(
 ```
 
 `Name`, `ShardCount`, `RetentionPeriodHours`, `StreamModeDetails` and `Tags` are read. A stream the
-template does not name is named after the stack and the logical ID, as real CloudFormation names
-one.
+template does not name is named after the stack, the logical ID and a tail derived from both, as
+[the CloudFormation docs](https://yulinsim.dev/services/cloudformation/#names-cloudformation-generates "Names CloudFormation generates")
+describe.
 
 `RetentionPeriodHours` is applied after the stream is created, because `CreateStream` takes no
 retention on real Kinesis either. It only ever goes up: a new stream keeps records for 24 hours,

package/docs/services/kms/README.md

@@ -351,13 +351,18 @@ customer default:
 - The account root is allowed to read the key's metadata. That is the whole of what this policy
   delegates to IAM.
 
-That is why a role holding only `ssm:GetParameter` reads a decrypted `SecureString` under `aws/ssm`,
-and why a role holding `kms:Decrypt` on that key still cannot use it by calling KMS itself.
+That is why a role holding `kms:Decrypt` on such a key cannot use it by calling KMS itself.
 
 `kms:ViaService` is set by the service making the call on the caller's behalf. Sim SSM does this for
 `SecureString` parameters. Code calling simulated KMS directly sets it with the `viaService` request
 option, naming the service on its own (`ssm`), since the region is the key's.
 
+A service passing on the caller's own KMS permissions sets `withCallerPermissions` alongside it.
+What the policy above admits is the service a request came through. A request carrying this option
+is allowed only where IAM allows the caller the KMS action too, and a key policy naming the caller
+allows it on its own. Sim SSM sets the option when it decrypts a `SecureString`. A role holding
+`ssm:GetParameter` and no `kms:Decrypt` is refused the decrypted value.
+
 ```typescript sim-kms-aws-managed-key
 /**
  * An AWS managed key, usable only through the service that owns it.

package/docs/services/lambda/README.md

@@ -4,7 +4,10 @@ Yulin includes a simulated AWS Lambda service for tests and local development. F
 and invoked in-process and in memory, with no containers and no real AWS infrastructure.
 
 Handlers run with their execution role as the simulated caller, so AWS calls made inside a handler
-are authorized by simulated IAM, as on real Lambda.
+are authorized by simulated IAM, as on real Lambda. Creating a function and changing its role are
+authorized as well, both against `lambda:` actions and against `iam:PassRole` on the execution role
+the request names. See [passing a Role to a service](https://yulinsim.dev/services/iam/#passing-a-role-to-a-service)
+in the IAM docs.
 
 Lambda-specific helpers are imported from the `@kensio/yulin/lambda` subpath. Real `LambdaClient`
 instances can be routed into sim Lambda with
@@ -81,6 +84,13 @@ The invoke call itself returns normally.
 
 ## Zip-packaged code and the vm runtime
 
+A real in-process handler is the one to reach for first. `makeLambdaZipFileInput(...)` backs a
+function created through the SDK with one, and an [executable binding](#executable-bindings) backs
+one a template declares. The handler stops on a breakpoint and can close over the test's own state.
+Run the packaged code where the test is about the bundle a deployment ships, its imports and its
+bundling included. Both paths invoke through simulated Lambda, and simulated IAM authorizes the
+handler's own AWS calls under the execution role either way.
+
 Real Lambda receives function code as a zip archive. `makeLambdaCodeZip(...)` builds real zip
 bytes from a source string (which becomes a single `index.js` module) or from a files map keyed by
 archive path (like a bundled deployment package). The archive runs in a Node.js `vm` context with
@@ -276,6 +286,62 @@ console.log(logged.events?.map((event) => event.message));
 await simAws.backgroundTasksComplete();
 ```
 
+### When a handler throws
+
+An invocation that ends in an error nothing caught leaves an `ERROR Invoke Error` line in the
+function's log group, as it does in an account. The line carries a JSON document holding the error's
+type, its message and its stack, with one array element per stack frame. Whatever the handler
+printed before it failed is recorded above it. A handler bound in-process and one packaged as zip
+code are both recorded this way.
+
+```typescript sim-lambda-unhandled-error-output
+/**
+ * Reading why an invocation failed out of the function's log group.
+ */
+
+import { FilterLogEventsCommand } from "@aws-sdk/client-cloudwatch-logs";
+import { CreateFunctionCommand, InvokeCommand } from "@aws-sdk/client-lambda";
+
+import { SimAws } from "@kensio/yulin";
+import { makeLambdaZipFileInput } from "@kensio/yulin/lambda";
+
+const simAws = new SimAws();
+
+await simAws.lambda().createFunction(
+  new CreateFunctionCommand({
+    FunctionName: "orders",
+    Role: "arn:aws:iam::111111111111:role/OrdersRole",
+    Code: {
+      ZipFile: makeLambdaZipFileInput(() => {
+        console.log("INFO handling order-1");
+
+        throw new Error("order has no items");
+      }),
+    },
+  }),
+);
+
+await simAws.lambda().invoke(new InvokeCommand({ FunctionName: "orders" }));
+
+const failure = await simAws.logs().filterLogEvents(
+  new FilterLogEventsCommand({
+    logGroupName: "/aws/lambda/orders",
+    filterPattern: '"Invoke Error"',
+  }),
+);
+
+// ERROR Invoke Error {"errorType":"Error","errorMessage":"order has no items",...}
+console.log(failure.events?.at(0)?.message);
+
+await simAws.backgroundTasksComplete();
+```
+
+The caller still hears about it too. `Invoke` answers with `FunctionError` set to `Unhandled` and
+the same error document in its response payload.
+
+Real Lambda writes `START`, `END` and `REPORT` lines around every invocation. Simulated Lambda
+writes none of those.
+
 ## Function code from S3
 
 Function code can also be fetched from a zip object stored in sim S3, as SAM and CDK deployments
@@ -2772,7 +2838,7 @@ For `AWS::Lambda::Function`, `Ref` returns the function name and `Fn::GetAtt` su
 
 Supported function properties:
 
-- `FunctionName` (defaults to the logical ID)
+- `FunctionName` (a function with none is named after the stack and the logical ID)
 - `Role` (typically a `Ref`/`Fn::GetAtt` to a same-stack `AWS::IAM::Role`, both resolving to the
   role's ARN)
 - `Code` (inline `ZipFile` source string, or `S3Bucket`/`S3Key` fetched from same-scope sim S3)
@@ -2785,6 +2851,12 @@ Supported function properties:
 - `DeadLetterConfig`, whose `TargetArn` names a queue or a topic. See
   [retries and destinations in templates](#retries-and-destinations-in-templates)
 
+A function with no `FunctionName` is named from the stack name, the logical ID and a tail derived
+from both. A `RatesFunction` in `orders-stack` becomes `orders-stack-RatesFunction-` and twelve more
+characters, where real CloudFormation ends the name in twelve random ones. The name is trimmed to
+the 64 characters a function name allows, and [the CloudFormation docs](https://yulinsim.dev/services/cloudformation/#names-cloudformation-generates "Names CloudFormation generates")
+cover how the stack name and the logical ID share what is left.
+
 Code in a missing bucket fails the deploy AWS-style with a `NoSuchBucket` diagnostic.
 
 ### CDK asset code
@@ -3439,6 +3511,8 @@ Sim Lambda currently supports:
   event to a simulated SQS queue or SNS topic
 - Function URLs, created with `CreateFunctionUrlConfigCommand` and served over HTTP on localhost
   with `serveSimAws`
+- `iam:PassRole` authorization of the execution role named by `CreateFunctionCommand` and
+  `UpdateFunctionConfigurationCommand`, with `iam:PassedToService` supplied
 - `AuthType: "AWS_IAM"` Function URLs, authorizing `lambda:InvokeFunctionUrl` against the caller
   resolved from the request, and `lambda:InvokeFunction` as well for a CloudFront origin access
   control

package/docs/services/logs/README.md

@@ -260,6 +260,11 @@ The output still reaches the terminal as well. Real Lambda sends it to CloudWatc
 else, but a test tool that swallowed it would make a failing test harder to debug. Recording is a
 tee.
 
+An invocation that ends in an error nothing caught leaves an `ERROR Invoke Error` line in the group
+after whatever it printed, carrying the error's type, its message and its stack. The
+[simulated Lambda docs](https://yulinsim.dev/services/lambda/ "Simulated Lambda usage docs") show
+one.
+
 Each invocation's `context.logGroupName` and `context.logStreamName` name the group and stream that
 were actually written to. Stream names use the real `YYYY/MM/DD/[$LATEST]<hash>` format. The hash
 identifies the execution environment, and one environment serves more than one request. Match the
@@ -736,6 +741,14 @@ exactly as on real AWS.
 `DescribeLogGroups` names no particular group. It authorizes against every log group in the account
 and region, and a policy scoped to one group cannot describe them all.
 
+A Stack deploying the three delivery Resource types authorizes the actions CloudFormation names.
+Each handler reads its own resource back before it writes. `AWS::Logs::DeliverySource` therefore
+needs `logs:GetDeliverySource` alongside `logs:PutDeliverySource`, and the destination and the
+delivery need `logs:GetDeliveryDestination` and `logs:GetDelivery` the same way. The `Describe` actions cover
+the three listing operations an SDK caller reaches, and a deployment goes near none of them. A
+CloudFormation execution Role therefore carries the same policy here that a real deploy of the
+template needs.
+
 ```typescript sim-logs-permissions
 /**
  * A simulated IAM policy allowing a Role to write one function's logs.
@@ -847,8 +860,9 @@ console.log(described.logGroups?.[0]?.logGroupArn);
   log group and the three delivery resource types are what simulated CloudFormation deploys here.
 - **Nothing is actually delivered.** A delivery records that a source was joined to a destination
   and how the records would be written. No access log file ever reaches the bucket.
-- **`GetDeliverySource`, `GetDeliveryDestination` and `GetDelivery`.** Absent. The three `Describe`
-  operations report the same resources.
+- **`GetDeliverySource`, `GetDeliveryDestination` and `GetDelivery`.** Absent as SDK operations. The
+  three `Describe` operations report the same resources. The three action names are authorized where
+  CloudFormation reads a delivery Resource back.
 - **Delivery resource tags and cross-account delivery.** `PutDeliverySource`,
   `PutDeliveryDestination` and `CreateDelivery` refuse tags outright. `DeliveryDestinationPolicy` in
   a template is recorded and acted on by nothing.

package/docs/services/s3/README.md

@@ -1697,8 +1697,13 @@ writes fall outside it. Without that, the simulation stops after a thousand deli
 An `AWS::S3::Bucket` resource carries five properties simulated S3 acts on. Those are `BucketName`,
 `LifecycleConfiguration`, `NotificationConfiguration`, `PublicAccessBlockConfiguration` and
 `WebsiteConfiguration`. See [Lifecycle configuration](#lifecycle-configuration) for the parts of a
-rule that are read. Without `BucketName` the Bucket is named after the resource's logical id,
-lowercased, where real CloudFormation invents a generated name.
+rule that are read.
+
+A Bucket with no `BucketName` is named from the stack name, the logical ID and a tail derived from
+both, lower cased as a bucket name has to be. A `SiteBucket` in `orders-stack` becomes
+`orders-stack-sitebucket-` and twelve more characters, where real CloudFormation ends the name in
+twelve random ones. The name is trimmed to the 63 characters a bucket name allows, and [the CloudFormation docs](https://yulinsim.dev/services/cloudformation/#names-cloudformation-generates "Names CloudFormation generates")
+cover how the stack name and the logical ID share what is left.
 
 Any other property is left out and recorded in
 [`stack.ignoredProperties`](https://yulinsim.dev/services/cloudformation/#properties-a-resource-was-created-without),

package/docs/services/scheduler/README.md

@@ -510,7 +510,12 @@ no group with nowhere to go.
 
 ## Permissions
 
-Every operation is authorized against the schedule ARN, which carries the group:
+Every operation is authorized against the schedule ARN, which carries the group. A Create or an
+Update also hands Scheduler the `Target.RoleArn` the schedule fires as, and authorizes `iam:PassRole`
+against that Role. See [passing a Role to a service](https://yulinsim.dev/services/iam/#passing-a-role-to-a-service)
+in the IAM docs.
+
+The schedule ARN is what an operation authorizes against:
 
 ```typescript sim-scheduler-iam-policy
 /**
@@ -678,7 +683,9 @@ console.log(simAws.scheduler().deliveryFailures.length); // 0
 
 `Ref` returns the schedule's **name** and `Fn::GetAtt ... Arn` its ARN, which carries the schedule
 group as it always does. A schedule the template leaves unnamed gets one generated from the stack
-name and the logical ID.
+name, the logical ID and a tail derived from both, as
+[the CloudFormation docs](https://yulinsim.dev/services/cloudformation/#names-cloudformation-generates "Names CloudFormation generates")
+describe.
 
 A property this simulation leaves out is refused at deploy time, naming the Resource. Deploying a
 schedule that behaves differently from the one declared would be worse. Tearing the stack down
@@ -735,8 +742,8 @@ console.log(stack.output("GroupArn"));
 ```
 
 `Ref` returns the group's **name** and `Fn::GetAtt` answers `Arn`, `State`, `CreationDate` and
-`LastModificationDate`. A group the template leaves unnamed gets one generated from the stack name
-and the logical ID.
+`LastModificationDate`. A group the template leaves unnamed gets one generated from the stack name,
+the logical ID and a tail derived from both, as a schedule does.
 
 `Tags` on a group are recorded as an ignored property and the group deploys without them. The CDK
 puts a stack's tags on every taggable Resource in it, so a template gains them without asking.
@@ -763,6 +770,7 @@ Resources of the same stack.
 - Creation and modification timestamps from the simulation's clock, and prefix-narrowed,
   state-narrowed, paged listings.
 - IAM authorization against the schedule ARN.
+- `iam:PassRole` authorization of the `Target.RoleArn` a Create or an Update hands over.
 - SDK interception of `SchedulerClient`.
 
 ## Limitations