Skip to content

security: harden AWS Windows bake credentials (encrypted WinRM, no GetPasswordData) - #2533

Open
Brad-Edwards wants to merge 2 commits into
devfrom
security/aws-winrm-tls
Open

Brad-Edwards wants to merge 2 commits into
devfrom
security/aws-winrm-tls

Conversation

@Brad-Edwards

@Brad-Edwards Brad-Edwards commented Oct 7, 2026 •

Copy link
Copy Markdown
Owner

The AWS windows, dc and dc-prebaked Packer templates enabled WinRM Basic auth over unencrypted HTTP (AllowUnencrypted=true), and Packer's temporary security group opened the WinRM port to 0.0.0.0/0. Every Windows bake therefore sent the instance's Administrator password across the internet in clear while the port was open to anyone.

Each builder's user data now creates a self-signed HTTPS listener, removes the plaintext listener that winrm quickconfig creates, and keeps AllowUnencrypted off. Packer connects with winrm_use_ssl = true, and temporary_security_group_source_public_ip = true limits the temporary group to the builder's public IP. This matches the GCE templates, which already use TLS-only WinRM.

A regression test asserts the three templates stay TLS-only and source-restricted.

Verification

  • tests/test_packer.py passes (114) and packer validate -var-file=dev.pkrvars.hcl . is clean.
  • Live: a dc-prebaked bake in aws-dev connected over WinRM HTTPS from the operator IP only, promoted the forest across the reboot, ran finalize.ps1 and registered the AMI.
  • windows and dc carry the identical change but have not been rebaked; they are covered by Windows and DC images still bake Claude Code #2521.

No ec2:GetPasswordData

Packer fetched each Windows builder's generated Administrator password by polling ec2:GetPasswordData, which tripped security monitoring. The builder's user data now sets the built-in Administrator password to a per-build winrm_bootstrap_password before WinRM starts, and Packer connects and elevates with it, so the call is never made. A Windows build without the secret fails packer validate instead of falling back to the call; Linux builds do not need it. packer.yml generates the secret (masked, via GITHUB_ENV) for windows, dc and dc-prebaked before validation, as packer-gcp.yml already does for GCE.

…ws bakes

The AWS windows, dc and dc-prebaked templates enabled WinRM Basic auth over
unencrypted HTTP, and Packer's temporary security group opened the WinRM port
to 0.0.0.0/0, so each bake sent the Administrator password across the internet
in clear. The builders now bind a self-signed HTTPS listener, drop the
plaintext listener, keep AllowUnencrypted off, and admit WinRM only from the
builder's public IP. This matches the GCE templates' TLS-only WinRM.
…om EC2

The AWS windows, dc and dc-prebaked bakes let Packer fetch the AMI's generated
Administrator password with ec2:GetPasswordData, polling until it appeared.
Security monitoring flags those calls. Each builder's user data now sets the
built-in Administrator password to a per-build winrm_bootstrap_password before
WinRM starts, and Packer connects and elevates with it, so GetPasswordData is
never called. A Windows build without the secret fails validation instead of
falling back. The AMI build workflow generates the secret for Windows builds
before validation, as the GCE workflow already does.
@Brad-Edwards Brad-Edwards changed the title security: encrypted WinRM from the builder only for AWS Windows bakes security: harden AWS Windows bake credentials (encrypted WinRM, no GetPasswordData) Oct 7, 2026
@sonarqubecloud

sonarqubecloud Bot commented Oct 7, 2026

Copy link
Copy Markdown

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant