You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Rounds out Phase 6 (IMDSv2 landed in #24, EBS encryption deferred
until a per-AMI root-device lookup could be done safely).
## Change
New 'encrypt-ebs' input on action.yml, default 'false' (opt-in).
When 'true', the action:
1. Fetches the AMI's DescribeImages result (already needed to
resolve image IDs when 'ec2-image-filters' is set).
2. Finds the BlockDeviceMapping matching the AMI's RootDeviceName.
3. Clones that mapping, drops SnapshotId (AWS uses the AMI's
snapshot automatically), sets 'Encrypted: true'.
4. Passes the cloned mapping as RunInstances.BlockDeviceMappings.
Result: root volume launches with SSE-EBS, key 'alias/aws/ebs' in
the launch account. VolumeSize / VolumeType / IOPS / DeleteOnTermination
preserved from the AMI — only the encryption bit is new.
## Why opt-in
The launch account (not necessarily the AMI owner account) must
have either default EBS encryption enabled, or at minimum permission
to use the default AWS-managed KMS key. If the AMI's snapshot is
encrypted with a customer-managed key that doesn't have a cross-
account grant, RunInstances fails. Defaulting to 'true' would
regress every consumer whose IAM / KMS policy isn't set up for
this. Default 'false' lets each consumer opt in after verifying
their account can handle it.
## Why not account-level default encryption
AWS supports 'aws ec2 enable-ebs-encryption-by-default' at the
account level — and that's the preferred belt-and-suspenders. But
not every consumer runs in an AWS account they control (e.g.,
Namecheap's CI runs in a shared org account). Action-side opt-in
is the only portable control.
## Refactor alongside
resolveImageId -> resolveImage: now returns both the ID and the
full Image metadata. Callers that only need the ID use .id; the
EBS-encryption code path uses .image.BlockDeviceMappings to build
the encrypted clone.
## Tests
tests/ebs.test.js — 6 new cases for buildEncryptedRootMapping:
happy path with full EBS config + non-EBS sibling mapping, volume
type / size / iops preservation, and five null-return paths for
exotic AMI shapes (no RootDeviceName, no mappings, non-EBS root,
orphan RootDeviceName).
tests/config.test.js — 2 new cases for the encrypt-ebs input
(default fallback + override).
Total: 44 -> 52 tests.
## Consumer dogfood
Separate PR on terraform-provider-namecheap rotates the pin and
enables 'encrypt-ebs: true' on the CI job. If the dogfood fails
with a KMS / IAM permissions error, we know the account needs
policy work before enabling; action-side code is fine either way.
Signed-off-by: yuriyryabikov <22548029+kurok@users.noreply.github.com>
0 commit comments