-
Notifications
You must be signed in to change notification settings - Fork 22
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
Adds SSM capability to Packer #526
Conversation
990382b
to
0c22950
Compare
83a4317
to
c4deefb
Compare
@@ -267,6 +274,9 @@ Resources: | |||
unzip -d /opt/packer /tmp/packer_*_linux_amd64.zip | |||
echo 'export PATH=${!PATH}:/opt/packer' > /etc/profile.d/packer.sh | |||
|
|||
wget -P /tmp https://s3.amazonaws.com/session-manager-downloads/plugin/latest/ubuntu_64bit/session-manager-plugin.deb | |||
dpkg -i /tmp/session-manager-plugin.deb |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
in a follow up PR, we should move both this step and the preceeding step to install packer into the AMI so that it doesn't run on every boot, but I think we can keep it here for now as it's a significant security improvement
c4deefb
to
0453ae9
Compare
This change is now on PROD and working 👍🏽 |
- Effect: Allow | ||
Action: | ||
- iam:GetInstanceProfile | ||
Resource: !Ref PackerInstanceProfile |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm looking at the policies we define as part of the CDK migration (see #598). I can't quite work out why this policy is needed (other than tracking it down to this PR). Are there any links available that explain it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we needed to add this so that the amigo instances are able to initial SSM sessions with the packer instances.
What is the problem?
Security HQ was showing an error when trying to collect the security groups of the Deploy Tools account. After debugging, we learnt that AWS Trusted Advisor was unable to return a response for an account with over 200 security groups. The Deploy Tools account had over 850! Most of these were temporary Packer security groups created by Amigo. Whilst we wrote a script to delete the unused security groups, we wanted to find a way to stop Amigo creating all of these security groups.
What is the solution?
We decided to add SSM support to Packer and create two dedicated security groups (one for CODE and another for PROD), so that the security groups do not need any inbound access rules and also so that we no longer create a new temporary security group for each new Packer instance created by Amigo.
How to test
We've tested this on CODE.
When deploying to PROD:
How can we measure success?
No more temporary Packer security groups are created by Amigo, we just have 2 dedicated security groups.