@kensio/yulin 1.20.16 → 1.21.0

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

package/docs/services/secretsmanager/README.md

@@ -577,9 +577,12 @@ The other generation options behave as they do on real AWS, being `PasswordLengt
 `IncludeSpace`, and `RequireEachIncludedType`. The last is on unless turned off, and a generated
 password carries one of every character type it was not told to exclude.
 
-A secret with no `Name` is named after its logical ID. Real CloudFormation names it after the stack
-and appends its own random characters. A template cannot rely on the exact generated name either
-way.
+A secret with no `Name` is named from the stack name, the logical ID and a tail derived from both.
+An `ApiSecret` in `db-stack` becomes `db-stack-ApiSecret-` and twelve more characters, where real
+CloudFormation ends the name in twelve random ones. Simulated Secrets Manager then appends its own
+six characters to the ARN, as it does for a secret named by hand. The name is trimmed to the 512
+characters a secret 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.
 
 ## Inside a simulated Lambda handler
 

package/docs/services/ses/README.md

@@ -515,7 +515,9 @@ CloudFormation is creating an identity that is already there.
 `FromEmailAddress`. `Ref` on a template, and its `Id` attribute, both return the template name.
 `Ref` on a configuration set returns its name. That Resource type has no `Fn::GetAtt` attributes at
 all, so reading one fails the deploy rather than answering something AWS would not. A set with no
-`Name` is named after the stack and the logical ID, as real CloudFormation names one.
+`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.
 
 Deleting the stack removes all three.
 

package/docs/services/sns/README.md

@@ -1688,11 +1688,11 @@ const { Messages } = await simAws
 console.log(Messages?.[0]?.Body); // "order-1"
 ```
 
-A topic with no `TopicName` is named from the stack name and the logical ID. The topic above with its
-name left out would be `orders-stack-OrdersTopic`. Real CloudFormation adds random characters to
-that, which a template cannot predict either way. The generated name is trimmed to the 256 characters
-a topic name allows, ending in a hash of the untrimmed name so two long names that start the same
-stay apart.
+A topic with no `TopicName` is named from the stack name, the logical ID and a tail derived from
+both. The topic above with its name left out would be `orders-stack-OrdersTopic-` and twelve more
+characters, where real CloudFormation ends the name in twelve random ones. The name is trimmed to
+the 256 characters a topic 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.
 
 A topic can also declare its subscriptions inside itself, with the `Subscription` property. That is
 how a hand-written template usually writes them. Each entry is a `Protocol` and an `Endpoint`, and

package/docs/services/sqs/README.md

@@ -1052,11 +1052,11 @@ The properties applied to the queue are `VisibilityTimeout`, `DelaySeconds`,
 `MessageRetentionPeriod`, `MaximumMessageSize` and `ReceiveMessageWaitTimeSeconds`. Each is passed to
 `CreateQueue`, and a value outside the range real SQS accepts fails the resource.
 
-A queue with no `QueueName` is named from the stack name and the logical ID. The queue above with its
-name left out would be `orders-stack-OrdersQueue`. Real CloudFormation adds random characters to
-that, which a template cannot predict either way. The generated name is trimmed to the 80 characters
-a queue name allows, ending in a hash of the untrimmed name so two long names that start the same
-stay apart.
+A queue with no `QueueName` is named from the stack name, the logical ID and a tail derived from
+both. The queue above with its name left out would be `orders-stack-OrdersQueue-` and twelve more
+characters, where real CloudFormation ends the name in twelve random ones. The name is trimmed to
+the 80 characters a queue 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.
 
 `FifoQueue: true` fails the resource. Only standard queues are simulated, and a FIFO queue is named
 `<name>.fifo`, a name simulated SQS refuses to an SDK caller as well. There is no queue to create

package/docs/services/ssm/README.md

@@ -361,9 +361,13 @@ console.log(read.Parameter?.Value); // "db.internal"
 console.log(read.Parameter?.Version); // 1
 ```
 
-A parameter with no `Name` is named after its logical ID. Real CloudFormation generates a name from
-the stack name and its own random characters. A template cannot rely on the exact generated name
-either way.
+A parameter with no `Name` is named from the stack name, the logical ID and a tail derived from
+both. A `FeatureFlags` in `config-stack` becomes `config-stack-FeatureFlags-` and twelve more
+characters, where real CloudFormation ends the name in twelve random ones. The name carries no
+leading slash, putting the parameter at the top of the hierarchy where real CloudFormation puts one
+it names itself. Parameter Store counts the ARN prefix towards the 1011 characters a name may use,
+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.
 
 An IAM policy granting access to a template-created parameter needs the ARN rather than the `Ref`.
 Build it with `Fn::Sub`, remembering that the ARN drops the name's leading slash:
@@ -468,9 +472,10 @@ recorded the same way.
 references use, so a reference can sit inside a longer value and inside `Fn::Sub`.
 
 Decryption goes to simulated KMS under the key the parameter was written with, as the caller
-deploying the stack. A caller lacking `kms:Decrypt` on that key fails the resource with the
-`AccessDenied` a decrypting `GetParameter` raises (see
+deploying the stack. A caller lacking `kms:Decrypt` on a customer managed key fails the resource with
+the `AccessDenied` a decrypting `GetParameter` raises (see
 [A customer managed key needs its own permission](#a-customer-managed-key-needs-its-own-permission)).
+A parameter under the `aws/ssm` managed key needs no KMS permission of the caller.
 
 CDK writes one of these from `SecretValue.ssmSecure`, from
 `ssm.StringParameter.fromSecureStringParameterAttributes` and from the deprecated
@@ -911,15 +916,27 @@ try {
 }
 ```
 
-### The aws/ssm managed key needs no permission
+### The aws/ssm managed key allows the read itself
 
-A parameter naming no key is encrypted under the `aws/ssm` AWS managed key, and that key asks the
-caller for nothing. Parameter Store supplies `kms:ViaService`, and the managed key's policy allows
-the account's principals to use it through Systems Manager. A role holding only `ssm:GetParameter`
-therefore reads the decrypted value, as it does on real AWS.
+A parameter naming no key is encrypted under the `aws/ssm` AWS managed key. That key's policy allows
+the cryptographic actions to a wildcard principal under `kms:ViaService` and `kms:CallerAccount`
+conditions, and Parameter Store satisfies both. A grant of that shape delegates nothing to IAM. A
+role holding `ssm:GetParameter` and nothing on KMS reads the decrypted value, as it does in an
+account, and withholding that access takes an explicit `Deny`.
 
-The same role cannot take the ciphertext to KMS itself, because that policy allows nothing to a
-request arriving directly.
+`GetParameters` and `GetParametersByPath` decrypt through the same path and on the same permission.
+A `SecureString` write under the managed key asks for no KMS permission either.
+
+A `kms:Decrypt` grant scoped with a `kms:ViaService` condition (the shape a stack writes when the
+key is chosen after synthesis) still works, and it is what a customer managed key wants.
+
+The key stays out of reach of anything calling KMS directly. The same role handed the stored
+ciphertext cannot decrypt it through `Decrypt`, because the policy's `kms:ViaService` condition
+matches only a request that arrived through Systems Manager. A caller in another account is refused
+by the `kms:CallerAccount` condition.
+
+An ECS task resolves a `secrets` entry through this path. An execution role holding
+`ssm:GetParameter` alone reads a managed key `SecureString` into a container's environment.
 
 ```typescript sim-ssm-secure-string-managed-key
 /**
@@ -956,18 +973,14 @@ const role = await simAws.iam().createRole(
   }),
 );
 
-// The parameter, and no KMS permission at all.
+// The parameter, and nothing on KMS.
 await simAws.iam().putRolePolicy(
   new PutRolePolicyCommand({
     RoleName: "ConfigReader",
     PolicyName: "ReadDbPassword",
     PolicyDocument: JSON.stringify({
       Version: "2012-10-17",
-      Statement: {
-        Effect: "Allow",
-        Action: "ssm:GetParameter",
-        Resource: "*",
-      },
+      Statement: { Effect: "Allow", Action: "ssm:GetParameter", Resource: "*" },
     }),
   }),
 );
@@ -1031,6 +1044,10 @@ Current documented limitations:
   without complaint.
 - `KeyId` on a `String` or `StringList` parameter is refused, since nothing would encrypt a value
   stored in the clear.
+- Reading and writing a `SecureString` under the `aws/ssm` managed key ask the caller for no KMS
+  permission, which follows that key's policy and the Parameter Store setup page. AWS's SecureString
+  encryption page documents `kms:Encrypt` and `kms:Decrypt` for either kind of key, and the two
+  disagree. A parameter under a customer managed key does need them.
 - `DataType` other than `text` is refused. Real Parameter Store validates an `aws:ec2:image` value
   against EC2, which this simulation cannot do.
 - Filters are refused outright. `GetParametersByPath` refuses `ParameterFilters`, and

package/docs/services/stepfunctions/README.md

@@ -1181,8 +1181,10 @@ created. A location this simulation holds no object for drops that one state mac
 where it looked.
 
 `StateMachineName`, `RoleArn`, `StateMachineType` and `Tags` are carried across. A state machine the
-template does not name is named after the stack and the logical ID (`enrolment-Workflow`), the way
-CloudFormation names one. `Ref` answers with the ARN and `Fn::GetAtt` answers `Arn` and `Name`. Real
+template does not name is named after the stack, the logical ID and a tail derived from both
+(`enrolment-Workflow-8d267c9d4ae1`), the way CloudFormation names one, and
+[the CloudFormation docs](https://yulinsim.dev/services/cloudformation/#names-cloudformation-generates "Names CloudFormation generates")
+cover the tail. `Ref` answers with the ARN and `Fn::GetAtt` answers `Arn` and `Name`. Real
 CloudFormation publishes this one that way round too. Deleting the stack deletes the state machine.
 
 A definition holding a state type this simulator does not run drops that one state machine. The
@@ -1250,6 +1252,13 @@ rooted at `$`, since the context object is read rather than written.
 `States.UUID` and `States.MathRandom` are left out on purpose. Both answer differently on every call.
 A test asserting on the output of a state machine that used one could only assert on its shape.
 
+## Passing the execution role
+
+A state machine keeps the `roleArn` it is created with and runs every execution as it, so
+`CreateStateMachine` authorizes `iam:PassRole` against that Role as well as `states:CreateStateMachine`
+against the state machine. A caller allowed to create state machines and refused `iam:PassRole` fails
+the creation. See [passing a Role to a service](https://yulinsim.dev/services/iam/#passing-a-role-to-a-service) in the IAM docs.
+
 ## Where this differs from real Step Functions
 
 - **`StartExecution` runs the execution as far as it goes before it answers.** Real Step Functions

package/docs/services/wafv2/README.md

@@ -1060,9 +1060,11 @@ A web ACL nothing coherent could be deployed from still fails the stack. A `Scop
 `REGIONAL` and `CLOUDFRONT`, a `Rules` written as an object, a `Name` written as a number. The
 failure names the logical ID.
 
-`Name` is optional on all three named types. An unnamed resource is named after the stack and the
-logical ID, as real CloudFormation names one, so `orders-acl` above would have deployed as
-`orders-OrdersAcl`.
+`Name` is optional on all three named types. An unnamed resource is named after the stack, the
+logical ID and a tail derived from both, as real CloudFormation names one. The web ACL above sets a
+`Name` and keeps `orders-acl`. With that property left out it would have deployed as
+`orders-OrdersAcl-5615bd3c857f`, and [the CloudFormation docs](https://yulinsim.dev/services/cloudformation/#names-cloudformation-generates "Names CloudFormation generates")
+cover where the tail comes from.
 
 ### Putting a deployed web ACL in front of something
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@kensio/yulin",
-  "version": "1.20.16",
+  "version": "1.21.0",
   "description": "AWS system behaviour simulation for isolated unit testing",
   "repository": "https://github.com/KensioSoftware/yulin",
   "homepage": "https://yulinsim.dev/",

package/dist/service/stepfunctions/command/machine/sim-state-machine-writes.d.ts

@@ -1,25 +0,0 @@
-import type { BackgroundScheduler } from "../../../../util/background/background.js";
-import type { SimStatesExecutionStore } from "../../execution/sim-states-execution-store.js";
-import type { SimStateMachineStore } from "../../machine/sim-state-machine-store.js";
-import type { SimDeleteStateMachineCommand, SimDeleteStateMachineCommandOutput, SimUpdateStateMachineCommand, SimUpdateStateMachineCommandOutput } from "./machine.command.js";
-interface SimStateMachineWritesProperties {
-    readonly stateMachines: SimStateMachineStore;
-    readonly executions: SimStatesExecutionStore;
-    readonly background: BackgroundScheduler;
-}
-/**
- * The commands that change and delete state machines.
- */
-export declare class SimStateMachineWrites {
-    #private;
-    constructor(properties: SimStateMachineWritesProperties);
-    /**
-     * Change a state machine's definition or role.
-     */
-    update(command: SimUpdateStateMachineCommand): SimUpdateStateMachineCommandOutput;
-    /**
-     * Delete a state machine and forget its executions.
-     */
-    delete(command: SimDeleteStateMachineCommand): SimDeleteStateMachineCommandOutput;
-}
-export {};