Deployment and Provisioning
In this group of lectures we run a hands on deployment of the next iteration of the Pizza Time solution. The Pizza Time business has been a success. It needs to support more customers and wants to expand to meet a global market.
We define our new solution, then walk through a hands on deployment that extends our scalability, availability and fault tolerance.
Hi, and welcome to this lecture.
In this lecture, we start by taking a look at some issues in our Pizza Time app. Then, I will quickly talk about what a Bastion host is. Then, we will go to the AWS Console and have a demo on applying secured best practices.
So, this is our Pizza Time app. We already deployed almost everything. We haven't finished dealing with the domain yet. We haven't deployed a cross region 3D replica. And in here, we have a few gaps. For example, the requests are coming through the Elastic Load Balancer, okay? And, the Elastic Load Balancer is forwarding the requests to the instance. But we haven't closed this group of instances to only accept connections coming from the lesser load balancer. That might not be a big of an issue, but we want to have our users passing through our Elastic Load Balancer every time. Otherwise, if we don't close the access directly through the instances, people will be able to access an instance directly. And if we terminate that instance, that might become an issue because a user will try to access an instance that was terminated and so on.
Also, our database secured group is too open, is accepting connections from everybody. Even after we moved things through the router, we are still allowing connections from all the VPC and that's not a best practice. We should only allow connections coming from our EC2 two instances. And we only want to allow connections coming from our Elastic Load Balancer through our EC2 instances. So we need to change a few things.
When we have a security group, we have two options. We can allow connections to IP addresses or IP ranges, or we can allow access to other security groups. So for example, we could say here in the Pizza Time EC2 security group that we are going to allow connections only from members of the EOB security group. And in the RDS security group, we can say that we are going to allow connections only coming from members of the EC2 security group. So we don't need to deal with IP addresses. We don't need to specify a particular IP address of an instance, for example. We don't need to specify an IP range for the whole supernet because we can also start launching new instances running other applications in that subnet and if we allow the connection for that whole sub net the instances of other applications could solve with our RDS data base and we probably don't want that so we should re-factor our configurations in regards to security groups to allow only connections coming from other security groups.
Talking about what a Bastion Host is. We don't have a need of a Bastion Host because we only have instances running in the public subnet. And for example, if you wanted to connect directly to an instance in the pubic subnet we would only have to change the security group of that instance, allowing connections from our IP address. And we would be able to access that instance.
But how about when you have instances in a private subnet for example. When you have this situation you can't connect directly through the instance inside that private subnet. So those instances can not be accessed directly from the internet. Therefore we need to create a Bastion Host. The Bastion Host will live in a public subnet and we will create a security group for a Bastion Host. And this security group should only allow connections coming from a particular IP address. Lets say, the IP address from our data center. And these Bastion Hosts would have access to the instances in the Private subnet. So we could say that the security group of the Bastion Host has permissions in the security group of the instances in the Private subnet.
One thing more about Bastion Hosts, they should be stopped when you're not using them. Otherwise, that can be a potential issue because if someone, somehow get's access to that Bastion Host they would have internal access to things that is running in the Private subnet.
So let's go now to the AWS console and have a demo on how to apply security best practices on EC2 instances.
So I'm at the EC2 console and I will click in here in Security Groups. In here we have all the security groups in the Oregon region. I will only show you how to do that in the Oregon region if you want to do that in the other other region by yourself that's okay, the process will be exactly the same that I'm going to show you here.
First, let's start with the ELB security group. We have only permissions coming from everybody in the port 80 and that's okay. We don't want to restrict the access to anyone we want to allow access coming from the whole wall so that's okay for the elastic load balancer. And we don't have any other rule in here.
Talking now about the EC2 security group. We have an issuing here. We are allowing connections coming from everybody so we don't need to access the elastic load balancer to have access to a particular instance. Instead, we could access the instance directly and we want to avoid that. So let's click here to edit this route and instead of putting in IP address in here we can start typing S, G and it address will show us the available security groups that we can put in these rules. So I will select the ELB security group. Click on save.
And from now on we are only allowing access from the members of this security group, the ELB security group. Here in the RDS security group, we are allowing connections to all VPC so if we somehow launch another application inside the Pizza Time VPC we could have access to our RDS database. And we definitely don't want that. That could create a huge mess for us. So let's restrict the access. If you want to give access to our RDS database to other applications we can do that later but right now since we only have one application, let's restrict the access to only that application.
And also this rule is too general. We are allowing all traffic through our RDS instance. So, let's restrict that a bit more. I will delete the rule and I will add a new rule. I will say that connections coming to my single port will be allowed only for the members for the EC2 security group. And from now on only resources inside the EC2 security group will have access to our RDS security group.
So let's check our application to see if everything is working as expected. We can access the application nothing will be here because our application is being served from a cloud form distribution. And we deployed our angler in an S3 bucket.
So let's try to make a database call or try to log in here. I was able to log in and we can also check all the orders. We can see the orders so everything is working we were able to limit the access and our application is still working.
We could check that by taking any of the instance that we have, getting the IP address and trying to connect directly through that IP address. And we won't be able to do that because now we have denied the access the direct access through the instances.
About the Author
Eric Magalhães has a strong background as a Systems Engineer for both Windows and Linux systems and, currently, work as a DevOps Consultant for Embratel. Lazy by nature, he is passionate about automation and anything that can make his job painless, thus his interest in topics like coding, configuration management, containers, CI/CD and cloud computing went from a hobby to an obsession. Currently, he holds multiple AWS certifications and, as a DevOps Consultant, helps clients to understand and implement the DevOps culture in their environments, besides that, he play a key role in the company developing pieces of automation using tools such as Ansible, Chef, Packer, Jenkins and Docker.