Only allow SSH to reach Packer instance from Elastic Stack #1308
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
GuardDuty is complaining to us about Packer instances being probed on their SSH port, which by default is open to the world. Packer can be configured to allow connections only from a particular CIDR, however elastic-stack runs in the `main` VPC on `10.16.0.0/16`, whereas Packer runs in the default VPC on `172.31.0.0/16`, and there is no routing configured between them. Apparently they communicate over the public internet, so this seems the simplest method to block public SSH. There's a few other options to consider, I'm happy to go down one of these paths instead: * Launch the Packer instances in the same VPC as the Elastic Stack by hard coding `vpc_id` (brittle if you update the stack) * Launch the Packer instances in the same VPC as the Elastic Stack by setting `vpc_filter` (we currently have 2 identically tagged VPCs, leftover from a previous stack version perhaps?) * Peer the Packer VPC and Elastic Stack VPCs so they can communicate privately
moskyb
approved these changes
Apr 3, 2024
|
Checked it works locally: $ aws-vault exec buildkite-sandbox-admin -- make packer-linux-arm64.output
==> amazon-ebs.elastic-ci-stack-ami: Creating temporary security group for this instance: packer_660db2d5-affb-5cb0-4afc-78f531d07987
==> amazon-ebs.elastic-ci-stack-ami: Checking current host's public IP...
==> amazon-ebs.elastic-ci-stack-ami: Current host's public IP: 101.98.[redacted]
==> amazon-ebs.elastic-ci-stack-ami: Authorizing access to port 22 from [101.98.[redacted]/32] in the temporary security groups...
Build 'amazon-ebs.elastic-ci-stack-ami' finished after 6 minutes 41 seconds.
|
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
GuardDuty is complaining to us about Packer instances being probed on their SSH port, which by default is open to the world.
Packer can be configured to allow connections only from a particular CIDR, however elastic-stack runs in the
mainVPC on10.16.0.0/16, whereas Packer runs in the default VPC on172.31.0.0/16, and there is no routing configured between them.Apparently they communicate over the public internet, so this seems the simplest method to block public SSH.
There's a few other options to consider, I'm happy to go down one of these paths instead:
vpc_id(brittle if you update the stack)vpc_filter(we currently have 2 identically tagged VPCs, leftover from a previous stack version perhaps?)