AWS Autoscaling access with bastion

[asanz-mrmilu]

I was planning on using bastion to control access to our environments on a big project. However I came across the task of giving access on instances that auto-scale, I found out that (I thought this could happen, but wanted to confirm it) when instances get recreated, the access is lost.

I though of adding a script that will:

• Decrypts an ssh key with enough access to add itself to the group
• Adds itself to designated groups
• Deletes the key after doing it

Although there are some things that I will need to do:

• Adding the ssh key as the user
• Create a user that has only enough permissions to add users to groups, and add itself into the group
• Controlling and making sure decryption happens and the key gets deleted

I was wondering if there's any plan on supporting auto-scaling?

[asanz-mrmilu]

Turns out there's quite an easy solution, we added our autoscaling instances in a special subnet, and we added the whole subnet as access for the users. This way after instances provision themselves, access is already granted and not lost!

[speed47]

Hey @asanz-mrmilu , indeed the solution you're giving is completely valid. If you have different possible ranges/subnets, you can also add them proactively. It's not a security issue if one of the IPs behind these subnets ends up pertaining to a VM of someone else, as it just instructs the bastion to try the group key when somebody attempts to connect there. As long as you use public/private keys, and never passwords (which are disabled by default on the bastion and should most of the time be kept this way), you are safe: even if the owner of this IP is malicious, and you try to connect there, they can't extract any information or cause any harm whatsoever.

It's also why, for some cases, even adding 0.0.0.0/0 to a group is okay and makes sense, as long as you know what you're doing. It in essence means "always try this key when connecting to a remote server", along with the other ones that may match from other groups.

To complete the answer, there's also another way that we use in some of our groups and bastions: a specific account declared as an aclkeeper of the group, which can be used by your automation to keep the IP list up to date on the group. i.e. get triggered by your automation when a VM is created or destroyed, and uses the groupAddServer and groupDeleteServer commands accordingly. Such account can have the --osh-only flag set, to ensure that it can never be allowed to actually use the bastion to connect somewhere, and just allow osh commands instead.