Lock down MC EC2 Bastion hosts outgoing ports to only 80, 8080, and 443, and put in private subnet

[galenatjpl]

We’ll need to figure out why the bastion host was making an outgoing connection request to Tor, but as a first step let's:

• [ ] confirm that only 80, 8080 and 443 are allowed as outgoing ports in the EC2 security group.
• [ ] only allow incoming to be from SSM connect
• [ ] Put bastion host in a private subnet

I think the only outgoing ports would be those to github (for clone, git pull, git push, etc..), and for commands like sudo apt update pip3 install boto3, etc..

• [ ] As part of this ticket, the documentation here: https://unity-sds.gitbook.io/docs/developer-docs/common-services/docs/users-guide/deployment/deployment-concepts-and-infrastructure/detailed-breakdown-of-project-onboarding-steps should be updated to make it clear (more clear) about the security group guidance, and putting the bastion host in a private subnet (instead of public) See step 9 .

[jpl-btlunsfo]

Just to confirm, this happened in Unity-CM? is the (new?) EC2 instance Unity-CM-NAT-Instance using the same security group? (looks to be named sg-0df416467120a4399)

Because all I'm seeing right now is some source-IP limited inbound rules, and nothing on the outbound.

Is there a good venue for me to poke at the bastion security groups in? (or just use unity-venue-dev as usual)

[galenatjpl]

@jpl-btlunsfo This is NOT the Unity-CM-NAT-Instance. That is something else that I believe MCP manages themselves. So we shouldn't be touching that one.
The relevant instance here is the unity-cm-cs-management_console-bastion one, which is now stopped.
We need to rework the procedure and security group, and relaunch a new instance. There also may be some trickiness involved with the crontab, that's relevant only in this bastion, because this bastion also serves as the nightly CM host (dual purpose machine that uses cron to schedule nightly runs). Check with @hargitayjpl about the actual cron job that needs to be populated there. We have that documented somewhere.. But the main purpose of this ticket isn't the cron, it's the security group settings. So don't really worry about the cron stuff until the instance is up, and has the new security group. Once proven to work (e.g. the nightlies succeed), then the security group changes need to be rolled out to all bastion hosts, on all venue accounts.

[galenatjpl]

@jpl-btlunsfo I created a new bastion host in unity-venue-test following the above approach. So that's one less venue that will need to be done in this ticket.

[jpl-btlunsfo]

Looking into the private-subnet side of this, it appears we'll have to redeploy these instances to actually change the (base) network interface (which is associated to a subnet). I'll probably be able to get away with creating an image from the running instance, and then deploying an instance of that to prevent losing much.

I think that'll be necessary for (basically all of them):

• [x] unity-venue-dev
• [x] unity-sbg-dev
• [x] unity-venue-test
• [x] unity-venue-ops

However I've made sure the above security groups are in line with our 80/443/8080 security group rules.

[galenatjpl]

we are good here for now. CLosing.