`lambda policies user` output is missing `s3:PutEncryptionConfiguration` — `lambda deploy` fails on SAM's managed bucket

[beeneta-stack]

Summary

The IAM policy generated by hyperframes lambda policies user does not include s3:PutEncryptionConfiguration, but hyperframes lambda deploy runs sam deploy --resolve-s3, and recent SAM CLI versions set default encryption (SSE) on the managed artifacts bucket they create (aws-sam-cli-managed-default). A deploy user provisioned exactly per the generated policy therefore cannot complete a first deploy: the managed-resources stack fails on SamCliSourceBucket and rolls back.

Environment

• hyperframes CLI: 0.7.48 (npm install), repo checkout at the matching revision for HYPERFRAMES_REPO_ROOT
• SAM CLI: 1.163.0
• Region: us-east-1
• IAM: dedicated deploy user whose only permissions are the hyperframes lambda policies user output

Steps to reproduce

1. Create an IAM user and attach exactly the policy printed by npx hyperframes lambda policies user.
2. With that user's credentials and no pre-existing aws-sam-cli-managed-default stack, run npx hyperframes lambda deploy.

Expected

Stack deploys.

Actual

SAM's managed-resources stack rolls back and the deploy exits 1:

Error: Failed to create managed resources: Waiter StackCreateComplete failed:
Waiter encountered a terminal failure state: For expression "Stacks[].StackStatus"
we matched expected path: "ROLLBACK_COMPLETE" at least once

CloudFormation stack events for aws-sam-cli-managed-default show the root cause:

SamCliSourceBucket — Resource handler returned message:
"User: arn:aws:iam::<account>:user/<deploy-user> is not authorized to perform:
s3:PutEncryptionConfiguration on resource:
"arn:aws:s3:::aws-sam-cli-managed-default-samclisourcebucket-…"
because no identity-based policy allows the s3:PutEncryptionConfiguration action
(Service: S3, Status Code: 403 …)"

A second deploy attempt then fails differently because the dead stack is stuck in ROLLBACK_COMPLETE and must be deleted first — worth a hint in the error output, since first-time users hit both in sequence.

Suggested fix

Add to the s3Bucket action list in packages/cli/src/commands/lambda/policies.ts (the list currently ends at s3:PutPublicAccessBlock, around line 119–134):

"s3:PutEncryptionConfiguration",
"s3:GetEncryptionConfiguration",

(Get is included because CloudFormation's S3 resource handler reads bucket encryption state on updates/drift detection; only Put was observed failing.)

Workaround (confirmed working)

Skip SAM's managed bucket entirely — create an artifacts bucket with the deploy user (plain s3:CreateBucket works, since the failure is CloudFormation setting encryption, not bucket creation) and run SAM directly with --s3-bucket:

aws s3 mb s3://<artifacts-bucket> --region us-east-1
cd "$HYPERFRAMES_REPO_ROOT/examples/aws-lambda"
sam deploy --stack-name hyperframes-default --region us-east-1 \
  --s3-bucket <artifacts-bucket> --capabilities CAPABILITY_IAM \
  --no-confirm-changeset --no-fail-on-empty-changeset \
  --parameter-overrides ChromeSource=sparticuz ReservedConcurrency=-1

Note for anyone using this workaround: hyperframes lambda render then refuses to run because the deploy didn't go through the CLI, which writes .hyperframes/lambda-stack-<stack>.json. Hand-writing that file from the CloudFormation outputs (stackName, region, bucketName, stateMachineArn, functionName, lambdaMemoryMb, deployedAt) unblocks it — perhaps lambda deploy could offer a --skip-sam/adopt-existing-stack mode, or render could fall back to reading the stack outputs directly.