How to bootstrap WinRM for Windows Amazon EBS builder?

[jen20]

Is the consensus that user-data be used to enable WinRM when creating Windows AMIs using the amazon-windows-ebs builder, or am I missing something clever that the builder does?

[mefellows]

Pretty much yep. Something like is sufficient: https://gist.github.com/mefellows/0373408377337ab62ff5

[jen20]

Is it possible to use client cert authentication?

[mefellows]

Unfortunately not yet. The downstream WinRM library has just added support but we haven't started on an implementation yet. Feel free to help us out! :)

For now best practise is to setup WinRM in user data with networking heavily locked down and then unset hard coded users etc when done.

[jen20]

I've been looking into this, and it seems that it would be very difficult to use the amazon key pair for WinRM authentication as it would need wrapping etc.

Instead I think it might be better to change the builder to use the Amazon API for decrypting the instance password using the key pair, though that would have the unfortunate effect of slowing it down since the passwords take some time to appear.

Any thoughts on this as an approach?

[mefellows]

I have put a bit of thought into this. In my mind the two things address different requirements: one secures our transport and another simplifies authentication.

I think the former is more important than the latter and also is more broadly applicable (eg. Useful for other public clouds should we support it). That being said, and i haven't fully figured it out yet, but it should be possible for Packer to automatically create and import the keys on both sides simplifying experience for the user without compromising on features.

Note there is a complication: if Packer is run multiple times with user data we need to run the ec2 config service and sysprep the box (further slowing it down).

As you note it will be slower but that will be the users choice.

What do you think?

[jen20]

Indeed - unfortunately it seems to me that Amazon are doing a rather half-assed job with Windows - it would be significantly better if they would add X509-based key pairs and enabled certificate-based authentication over WinRM by default similarly to Linux. I hadn't really considered the idea of generating out the certificates client side and uploading but I that might be a good way around the issue.

Agreed that securing the transport is currently more important though, though that part is fairly easy to do provided you accept the self-signed certificate for WinRM https, which doesn't seem demonstrably worse than accepting the SSH host key.

I'm still playing with this - it seems that despite all the warnings of 15 minutes, the password is available rather quicker in most circumstances. I've put in this pull request to goamz to support the API call for getting the password: https://github.com/mitchellh/goamz/pull/244 for now.

[mefellows]

I believe it's about 4 minutes + some bootstrapping of minute or so before you can start interacting - not far from the approach we have now.

The main issue with this approach is raised in #27, which would prevent you from pipelining images efficiently (i.e. building a base image into an AMI -> feeding AMI into a app image which produces another AMI etc.). The advantage of a static user/pass means there is no need to continually run the EC2Config service (required to auto-generate Administration password with a keypair) which adds 10-15 mins to the next boot.

I agree with the WinRM HTTPs though, although it is nice to know that both sides agree on the cert!

Great stuff on the goamz PR, i'll keep looking at WinRM in the meanwhile.

[jen20]

To clarify for people coming in future, it doesn't look like the upstream WinRM library has supported client certificate authentication (yet) - what it's added is support for specify a self-signed CA which goes a long way to solving the problem.