Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

allow AWS-managed ssh key pairs to be disabled #392

Merged
merged 3 commits into from
Mar 15, 2018
Merged

allow AWS-managed ssh key pairs to be disabled #392

merged 3 commits into from
Mar 15, 2018

Conversation

cheeseplus
Copy link
Contributor

@cheeseplus cheeseplus commented Mar 14, 2018

Fixes #391. When adding the new auto-generation feature of keys/security groups, the option to not pass any SSH key id at all was lost. This means that aws_ssh_key_id now has three states:

  • if nil we auto-create a key-pair
  • if "/path/to/key.pem" or ENV["AWS_SSH_KEY_ID"] is set, we use specified key
  • if "_disable", don't provide any key-pair at all - this requires the remote image/instance to have this configured out of band (baking, user_data)

TODO

  • Update the docs once the triple-option is settled upon.

context "with key pair configured to false" do
before do
config[:aws_ssh_key_id] = false
expect(driver).to receive(:submit_server).and_return(server)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe include a negative expectation for setting aws_ssh_key_id to false?

expect(driver).to_not receive(:create_key)

Looking at the spec, I found myself wondering what was different.

Copy link
Contributor Author

@cheeseplus cheeseplus Mar 14, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The key won't get created if you provide a path either so not sure checking this is any more meaningful but I do see what you are saying. Initially I'd added this to the instance_generator but that felt like more code that wasn't really doing much.

@ghost
Copy link

ghost commented Mar 15, 2018

Just throwing this out there .... should ENV["AWS_SSH_KEY_ID"] also be allowed to be set to false.

@cheeseplus
Copy link
Contributor Author

No, env vars have no concept of boolean - they are always strings and we're going to respect whatever a person sets there and fail if it's bad data.

@cheeseplus
Copy link
Contributor Author

cheeseplus commented Mar 15, 2018

@pantocrator27 so we've figured out the fix (mostly) but bike shedding on the option, would you prefer:

aws_ssh_key_id: false

OR

aws_ssh_key_id: disable #perhaps a symbol even, :disable

We definitely want to keep auto-generation as the default when Nil and given this is a relatively niche use case you kinda get to pick what sounds best!

@robbkidd
Copy link
Contributor

@pantocrator27 Updated this PR with what :disable might look like.

@robbkidd robbkidd changed the title Allow aws_ssh_key_id to be False allow AWS-managed ssh key pairs to be disabled Mar 15, 2018
@ghost
Copy link

ghost commented Mar 15, 2018

@cheeseplus @robbkidd Thanks for all of your work on this guys! It honestly feels to me that "disable" may sound better than "false". It semantically feels better to me if this makes sense because we are essentially disabling this feature ....

Thoughts?

@cheeseplus
Copy link
Contributor Author

That was pretty much our thinking too but just wanted to shop it out since, as of now, you are the primary use case.

expect(fake_file).to receive(:write).with("RSA PRIVATE KEY")
context "with no AWS-managed ssh key pair configured, creates a key pair to use" do
before do
config.delete(:aws_ssh_key_id)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤔 This should probably be config[:aws_ssh_key_id] = nil to accurately reflect the default config where the key is present and its value is nil. config.delete(:aws_ssh_key_id) as setup is technically testing when the key is not present.

@coderanger
Copy link
Contributor

Hmm, I am :-/ on using disable since we shouldn't do stuff that requires symbols (as opposed to strings) and magic string values are usually a thing that will bite people later.

@robbkidd
Copy link
Contributor

robbkidd commented Mar 15, 2018

@coderanger Do you have a suggestion for a better way to disable the current SET KEY NAME || GENERATE KEY behavior? @cheeseplus and I talked about Yet Another Config Option and didn't like the taste of that either.

we shouldn't do stuff that requires symbols (as opposed to strings)

The current code handles either with a config[:aws_ssh_key_id].to_sym == :disable tucked in there after the nil check.

relevant specs
Run options: include {:focus=>true, :locations=>{"./spec/kitchen/driver/ec2_spec.rb"=>[686]}}

Randomized with seed 62956

Kitchen::Driver::Ec2
  #create
    and AWS SSH keys
      with AWS-managed ssh key pair disabled, does not create a key pair or pass a key id
        (disable as a string)
          successfully creates and tags the instance
        (disable as a symbol)
          successfully creates and tags the instance
      with no AWS-managed ssh key pair configured, creates a key pair to use
        successfully creates and tags the instance
      with AWS ssh key pair set, uses set key and does not create a key pair
        successfully creates and tags the instance

Finished in 0.0321 seconds (files took 2.81 seconds to load)
4 examples, 0 failures

@cheeseplus
Copy link
Contributor Author

I'm not super opposed to false as it fits in with everything else in the ecosystem even if semantically it's not great.

@ghost
Copy link

ghost commented Mar 15, 2018

At this point ... I am not going to look a gift horse in the mouth :) or ask you guys to do something contrary to the set of current coding standards

@ghost
Copy link

ghost commented Mar 15, 2018

As the customer, I will be equally pleased with either approach so long as it is documented. Please and thanks!

@robbkidd
Copy link
Contributor

Alternate proposal: config[:aws_ssh_key_id] = ⛔️ :trollface:

@ghost
Copy link

ghost commented Mar 15, 2018

@robbkidd can that be done :)

@ghost
Copy link

ghost commented Mar 15, 2018

also I hate to ask this, could this make its way into the next release of ChefDK ... I don't know how that process would work?

@cheeseplus
Copy link
Contributor Author

The deps in ChefDK just need to get bumped - the catch being that the ChefDK release is on it's own monthly schedule so if you wanted it sooner you'd have to consume a build from the current channel once the Gemfile.lock has been bumped.

@ghost
Copy link

ghost commented Mar 15, 2018

thanks for the info @cheeseplus!

@coderanger
Copy link
Contributor

I think I've convinced myself that a magic string is fine but what if we do _disabled instead just to make it clear it's a special value? And re: to_sym, better to do .to_s == 'whatever' since to_sym involves permanent allocs ;-)

@robbkidd
Copy link
Contributor

Updated for "_disabled".

@coderanger
Copy link
Contributor

Just needs some text in the readme to document it :) I can do that post merge if you're low on cycles since you already put in a 💯 effort <3

@robbkidd
Copy link
Contributor

Regarding ...

should ENV["AWS_SSH_KEY_ID"] also be allowed to be set to [_disabled]?

As things currently stand in this PR, if the environment variable is set to "_disabled", that value will carry in and apply in the same way as if you had set aws_ssh_key_id: _disabled in kitchen.yml.

@robbkidd
Copy link
Contributor

@coderanger I'm working on the README update right now! Thanks for the offer, though.

robbkidd and others added 2 commits March 15, 2018 14:03
Both ec2_spec and ec2/image_selection_spec use this class, so let's
promote it to a proper shared test class under spec/support.

Signed-off-by: Robb Kidd <robb@thekidds.org>
If :aws_ssh_key_id is nil, continue to perform the key auto-generation.

If :aws_ssh_key_id is explicitly set to "_disabled", do not generate a
key. This means that the kitchen configuration must be more explicit
about how connections will be authenticated. For example, when an
environment has disallowed AWS-managed keys, a key could be named in the
driver's `user_data` and the private key specified in the transport.

* moved the gnarly setup/expectations for #create_key to a separate
  describe block so that the expectations around key auto-generation
  or enable/disable are more clear

Co-authored-by: Robb Kidd <robb@thekidds.org>
Co-authored-by: Seth Thomas <sthomas@chef.io>
Signed-off-by: Robb Kidd <robb@thekidds.org>
Signed-off-by: Seth Thomas <sthomas@chef.io>
Copy link
Contributor

@coderanger coderanger left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:shipit:

Intended to call out the three states `aws_ssh_key_id` can be in and put
the words appropriate for each state next to it.

Signed-off-by: Robb Kidd <robb@thekidds.org>
@robbkidd
Copy link
Contributor

Did a quick rearrangement within the doc section. Does that make things better or worse?

@ghost
Copy link

ghost commented Mar 15, 2018

I personally feel it makes sense

@cheeseplus
Copy link
Contributor Author

We've got two thumbs and since I started the PR I can't approve - :shipit:

@coderanger coderanger merged commit 4adaa2a into master Mar 15, 2018
@robbkidd robbkidd deleted the fix-391 branch March 15, 2018 19:40
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.

4 participants