Bastion host per environment?

Question

Hi all

I have a client who wants to use bastion host per environment. They want their application to be FedRAMP compliant and their agency wanted to use bastion host per environment. We all know we can use session managers instead but anyway we need to implement bastion hosts.

My question is, they implemented centralized network account and VPC, they wanted to put their bastion hosts in the centralized VPC public subnet. They want to restrict access per environment, i.e., dev, test, prod, how can we control the access? E.g., create bastion host per env?

Thanks.

Lijan Kuniyil · Accepted Answer

Hi Sonic, Thank you for reaching out! We can use  secure way to use SSH Tunnel, then RDP through local hosts. We have several options to accomplish this : Bastion Host or SM Session Manager or AWS AppStream.  Please see in details below how to select each one depending on the requirement.

AppStream 2.0 is a fully managed non-persistent application streaming service, so there's no instances to manage, no VPN or internet-facing endpoint for the customer to manage, and no bridging of networks. AppStream 2.0 supports SAML federation simplifying the entitlements and discovery process of the bastion host. AppStream 2.0 is primarily HTML5, so the end user doesn't need to install any clients, and can use the device of their choice. The customer can build an image with whatever software they want, and quickly spin up as many bastion host instances as they need - and each user gets their own instance, so no noisy or nosy neighbor problems exist. A customer uses AppStream 2.0 as their bastion host provider for their development environments. AppStream 2.0 also enables customers to configure admin control policies that prevent users from downloading data, or copying data out of the environment. However, like the other managed services, this may be overkill for smaller scenarios.

A bastion host instance requires the customer to manage its lifecycle, and bridges two networks, adding an element the customer has to manage closely. They are simple, quick to spin up, but can be difficult to scale, depending on the number of users that need to use it.

SSM Session Manager seems to be mostly CLI-based access to instances (though I'm not an expert) - if a GUI is required, Session Manager Port Forward seems to be a good option, but you lose the ability to control the endpoint beyond what RDP supports. With a bastion host or an AppStream 2.0 instance, you're able to control the "gateway" middle boundary.

Overall, there's no one size fits all, and it really depends on what the user experience and security requirements are. Depending on the requirements, the recommendation can change wildly (even to a fully persistent environment such as WorkSpaces)

Leo K · Answer

It's strongly advised against to expose bastion hosts directly to the internet. Exposing an SSH or RDP port, for example, to the entire internet will make the machines immediate targets of password spraying and vulnerability exploit attacks. It's fine to use bastion hosts for remote access, but instead of placing them in public subnets and exposing them to the public internet, they should be accessed from the public internet through fully AWS-managed services with built-in strong security mechanisms, such as those in SSM Session Manager. Your setup would remain otherwise unchanged, but just the access path from the outside to the bastion hosts would go via SSM Session Manager.

Regardless of which method you might be required to use as the initial access path, the simplest way to control connectivity to your internal resources from each environment's bastion hosts is to use EC2/VPC security groups. In each target environment, you'd grant inbound access to resources like RDS databases, EC2 instances, EFS file systems, or other resources from the security group ID of the bastion host that you want to grant access. Referencing security group IDs in this way requires the central network to be connected to the resource networks via a Transit Gateway or VPC peering connections and to be located in the same region.

If cross-region connectivity is needed or if you have a separate firewall between the bastion hosts and the resources, another simple solution would be to allocate separate CIDRs (IP address blocks) in the bastion host VPC for the different environments. That would make it easy to grant access from those CIDRs to the target resources, which works also over cross-region peering connections, VPNs, and third-party firewalls.

You could allocate the supernet 10.227.0.0/16, as an arbitrary example, for all the bastion hosts. Then allocate a smaller CIDR from within that block for each each environment's bastion hosts, perhaps of the size /23 or /22, depending on the size of your environment. You could have one environment's bastion hosts in the CIDR 10.227.16.0/23, for example. In the NACLs of the target VPC(s), you could first have one rule that allows all IP traffic from 10.227.16.0/23 to allow the correct set of bastion hosts to connect, followed by a second NACL rule that blocks all traffic from 10.227.0.0/16. Traffic from the correct bastion hosts would be permitted by the first rule and traffic from all the other bastion hosts blocked by the second rule. You should also configure the same rules in the opposite direction. In the egress/outbound NACL rules of the specific environment's resource VPC, you'd allow traffic to 10.227.16.0/23, followed by a rule blocking traffic to 10.227.0.0/16.

Bastion host per environment?

Add your answer

Relevant content