There are even many Bastion Host CloudFormation templates out there. There are many sample CloudFormation templates out there. Without mappings, it would be impossible to write a CloudFormation template that works across all regions because AMIs are region specific, at least without asking them to select an AMI, and that wouldn’t work so well because my bootstrap code probably depends on having a specific operating system (and architecture). Then well use the current region and that architecture to select an appropriate AMI id. In this case, the user selects an instance type, and we’ll use that to lookup the architecture. The whole purpose of these mappings is to define a resource property that will grab a value based on some parameter. It allows us to perform some validation on our parameters, in addition to the validation we did in the Parameters section in my last post ( Provisioning a VPC with CloudFormation in AWS). So I’ll start by explaining the new sections of the template below and finish up with the resources section and how that looks when deploying an auto-scaling EC2 instance. If you don’t understand those, go back and read the previous post, they’re not any different in this template than they were in the VPC template. I’m not going to describe in detail the sections of the template that I described in the previous post, like Parameters and Metadata. Just provisioning the Bastion is looking like it’ll be a pretty big blog post, so I’ll probably do a short follow up that talks about hardening it, and of course we’ll talk about the other security groups in subsequent posts as we get to their resources. Then I need to do a wee bit of hardening of the Bastion Host. I need to stand up a bastion host and configure my security groups such that administrators can only connect into the bastion host from the Internet, and all other instances in the VPC only allow administrative connections from the bastion. So I’ll need to concentrate some effort on securing that one blue line. ![]() There will of course also be HTTP traffic into my network, but that will go through an application load balancer and AWS Shield standard will protect me from common denial of service attacks, so I’ll call that a less direct route with numerous safe-guards. The only direct route into my network, at least for administrative purposes, will be to the Bastion Host. As I build out my workload, I’ll use green lines to indicate less direct routes into and out of the network, and there’s really only going to be one more blue line when we’re done, for web traffic coming into my load balancer. The blue line represents a direct connection from the Internet. Here is what our VPC will look like after deployment: If the box goes south and stops responding, the auto-scaling group will kill it and bring up a new fresh instance. We’re going to deploy our bastion host to an auto-scaling group, not so much for the purpose of high availability but rather for some measure of auto-healing. So in this post, we’re going to look at a CloudFormation template for adding a Bastion Host to a VPC. So you two-hop into your network (jump box) and you assume the direct exposure to the Internet means you may get compromised at some point (sacrificial lamb). If you need to administer a more private instance, you SSH into the bastion and from there you can SSH into the private instance (which doesn’t accept SSH connections from outside of your network) to do your administration task. ![]() So you take one box and expose it through SSH to the outside world (or RDP if it’s a Windows box). In general, you don’t want all of your machines directly exposed to the Internet. Technically, it’s just a machine that is directly exposed to the Internet. What is a bastion host? It’s sometimes called a jump box, or in days gone by a sacrificial lamb.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |