This repository has been archived by the owner on Dec 18, 2024. It is now read-only.
Sync/upstream + upgrade/security #35
Merged
Conversation
This file contains 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
When launching ec2 source instances, we have code which waits for the instance to become ready, but previously this codepath was not being applied to spot instances. This change factors that code out into a common function, and then calls that common function in both the 'regular' and 'spot' instance launches. This fixes issues where packer tries to connect to a spot instance before it is running and ready, which means it won't have a public ip address ready yet, and so packer times out on SSH access. fixes hashicorp#40
Fixes SSM Session Manager Error when user has not access to create keypair in AWS #31
To run some acceptance tests with an SSH key, we add an extra function that generates a new one on demand. This requires `ssh-keygen' to be available.
The acceptance tests relying on ssh-keygen to create the temporary SSH key for the related tests do not work on windows necessarily, and aside from that, unless we're in an acceptance testing scenario, should not run at all. To avoid problems in these environments, we add an extra check that mimics what is already done in the SDK to avoid running those at all.
Previously the ssh access IP would fallback to the private ip address on the first "try" if a public IP is not available yet. This changes the logic to only fallback to private IP address if we are on the final attempt at finding an IP address. Precedence of always preferring public IP is left unchanged. related to hashicorp#40 and hashicorp#308
Some acceptance tests require generating a temporary SSH key pair for ensuring they are sent to AWS and that we can connect through SSH to an instance with a user-provided key. This was implemented through `ssh-keygen', part of the openssh suite of tools, but because the behaviour may change between environments, we opted to rewrite the keygen steps in pure go, by relying on the functions exposed by the `crypto' standard library.
Due to a side-effect that was merged in a previous PR, all the SSM-enabled builds now upload their public key. This is a problem, since some users have their environments block such requests, which makes their builds fail. To circumvent this issue, we check that we didn't specify a SSH key in the configuration before uploading it, and this acceptance test ensures that it doesn't happen when no SSH private key is specified.
The acceptance test that would generate an SSH key prior to running it was failing on Windows machines in CI as it made the process timeout. While this is not clear why that happens, we fixed the issue earlier by adding this extra check prior to running the test, so it is not run when running normal tests in CI. Because we now generate this SSH key directly from Go code, and not by relying on ssh-keygen, we can remove this as we don't risk encountering this problem anymore.
The EBS test in which we push the public key corresponding to the private key we add in the configuration on an SSM-backed connection would not check that the SSH public key upload message was in the output, potentially leading to some inconsistencies in the future. To avoid this from happening at some point, we add an extra check that the message was indeed in the output.
Fix hashicorp#289 SSM session will reconnect in case the connection drops until the builder stops the instance(The actual build finishes). In order for the SSM session without a keypair, the ssh public key has to be sent periodicly.
Snychronize communication between SSM session and send key goroutines to only send key when session is created.
As mentioned in an issue on the plugin, SSM builds that have to reboot the EC2 instance never complete since the SSM session gets interrupted, and is never re-initiated afterwards. The previous commit fixes this problem, and this commit adds some acceptance tests so we can be sure it never happens again.
Co-authored-by: Lucas Bajolet <[email protected]>
The session recreate loop with get-status-api is not neccessary and while it can be used I'm removing it to keep the change list smaller.
If session channel messages are not consumed then the start session operation gets blocked. To avoid this the channel messages are always consumed then the conditions are checked to upload the key or not.
Lint tools complained that the errors for `session.Start` weren't checked, which would prevent us from merging this series of commits. To fix that, we run the channel consumption in a separate coroutine, and catch the error if it happens, and show a message to the user about it.
RunTags value is used to set tags for resources created by packer except for Iam role and profile. This PR adds the tags when creating these resources. Resolves hashicorp#322
Since the depreciation_time attribute implies being able to deprecate an AMI after a specific date, it should apply to any builder able to produce AMIs, that is everything but ebsvolume. So this commit moves that to common, so all the builders (ebs, ebssurrogate, chroot and instance) are able to support it.
The capacity reservation options (ID, ARN, or Preference) are all mutually exclusive, only one of the three should be set in a given configuration. The code wasn't enforcing this, leading to cases in which conflicts could be specified in the configuration, and the call to start the instance would then fail during build instead of before it starts. This commit adds some logic to ensure that only valid options are accepted, and some tests are added to make sure these options cannot conflict.
… sync/upstream_+_upgrade/security
…e to out-dated-packaged
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
What does this PR do?
It sync with upstream and upgrades the dependencies using dependabot as reference. The latter means it was just update what was strict necessarily apart what already was update by the upstream.
Why?
To fix security issues.
Output
https://github.com/inloco/packer-plugin-amazon/releases/tag/v1.3.3