Implement WinRM over HTTPS and automatic bootstrapping of Amazon AMIs #39
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In order to allow the build pipeline to modify the WinRM configuration it's necessary to pass around a reference to the actual WinRMConfig object rather than extracting the username and password while constructing the pipeline itself. To achieve this we also make the VMWare builder use the common WinRMConfig structure rather than the identical but internal one it was previously using.
This commit introduces a new build step which gets the automatically generated password using the EC2 API and decrypts it using the generated private key. The following changes are necessary to support this: - A key pair must be specified for the instance - similar to builders for other operating systems this can either be auto-generated if none is specified, or a specific key pair can be nominated. - We rely on a function not yet merged into `mitchellh/goamz` in order to make the API call on EC2. There is currently an outstanding pull request for this (mitchellh/goamz#244), but for now it depends on the `jen20` fork of `goamz`. This still needs adding to the instance builder, and also needs some form of control to allow a password to be set explicitly if one has already been set for the source AMI.
This commit adds members to the WinRM configuration struct for HTTPS (defaults to true) and ignoring the certificate chain (useful if you have self-signed certificates). It also adds options to the configuration for providing a custom CA certificate to validate against, though this is not currently propagated through to the communicator. It also changes the default port if none is specified to 8956 from 8955, reflecting the change to HTTPs by default.
This commit introduces a new step into the build process which generates a user-data powershell script responsible for configuring WinRM access over HTTPS. The script does the following: - Disables the firewall rules for WinRM over HTTP for both public and domain/private profiles - Sets the maximum timeout for WinRM to 1800000ms - Sets the maximum memory per WinRM shell to 1024MB - Disallows unencrypted WinRM connections - Enables Basic authentication for WinRM - Enables CredSSP access to WinRM (necessary for using it internally) - Adds firewall rules for port 5986 to both public and domain/private profiles - Adds the given certificate to the LocalMachine\My certificate store - Configures a listener for WinRM on HTTPS using the specified certificate - Restarts the WinRM service Note that the certificate is sent base-64 encoded in the user-data and is therefore visible via the console for the period of time that the builder is running. Future work may want to involve creating an S3 bucket and an IAM role into which the instance is provisioned so this is not as accessible, though it's instance specific. The certificate and WinRM configuration are currently left installed. It would be a nice option to be able to remove them after configuration but that's not straightforward because scheduling a shutdown script in Windows is hard. In this case it would also be better to add options for a certificate chain to validate against, and the option to generate the certificate chain internally in Packer rather than relying on OpenSSL or mkcert/New-SelfSignedCertificate as we currently do. As part of this change it was necessary to move to a local custom version of StepRunInstance as the version in Packer receives all it's configuration during the pipeline build phase instead and doesn't allow modification. Not sure if there was an original design reason for that but this version seems somewhat neater anyway and involves a lot less copying around of values.
It may be desirable for users to specify a new Administrator password rather than retrieving the generated one from Amazon. To acheive this we reset the local Administrator password to a known value as part of the user data script which configures WinRM. Consequently this can only be used with the winrm_autoconfigure option turned on, though that isn't necessarily a long-term limitation.
The builder ID should be unique per builder - this commit changes it from being the same as the AWS builder included in core packer.
This commit adds a call to `Set-ExecutionPolicy RemoteSigned` if the WinRM configuration is being autogenerated. This allows provisioners to work without a custom execution command bypassing the execution policy. Ideally at some point in the future this should be a configuration option on the builders rather than hard coded.
This allows the communicator to work properly over HTTPS and honour the settings for ignoring the certificate chain validator or for the CA certificate to validate against. It relies on using the changes accepted into winrmcp in 2c6c680.
This commmit rolls the changes made in the EBS builder into the Instance builder for AWS. Since most of the changes were in common types this is confined to adding the steps into the build pipeline and changing some of the parameters to be pointer types. Changed steps are: - [Add] StepGenerateSecureWinRMUserData - [Add] StepKeyPair - [Modify] StepRunSourceInstance - we now use the version in winawscommon rather than in awscommon - [Add] StepGetPassword - [Modify] StepConnect - now requires the WinRM Configuration as a pointer rather than a copy.
Various tests were broken along the way in the VirtualBox, Parallels and Instance builders, and the WinRM Communicator as the previous work was done primarily on the EBS builder. This commit fixes all tests.
This commit changes from setting the Powershell ExecutionPolicy to RemoteSigned as part of the user data script to setting it to Bypass by default as part of the ExecuteCommand for provisioners. This seems neater as we don't change the machine more than necessary underneath the user and remove the need to override the ExecuteCommand every time a provisioner is used.
This commit renames some of the builder IDs which conflicted with the original packer versions to use the format: packercommunity.windows.<type>.<variant> For example: packercommunity.windows.amazon.ebs Some already had third party IDs from their original authors, these have been left intact as they are unlikely to conflict (though not verified).
This commit adds the plugin host for the Amazon Windows Instance builder which was previously missing.
Closed
Author
|
This has been implemented in Packer itself for quite some time so isn't really necessary anymore. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull request adds the following:
winrm_autoconfigure) to enable WinRM over HTTPS with the certificate supplied bywinrm_certificate_filenew_administrator_passwordis specifiedThere is further work to do, however it is independent of these changes:
The commit messages give a detailed account of the changes made.