Abstract & Container Services
The course is part of these learning pathsSee 1 more
When implementing different AWS services and architecting them within your environments, whether it be production, test or dev, do you know your security responsibilities for these services?
It is very likely that you are using services from three different classifications, which each have very different boundaries for enforcing security between the customer and AWS.
These classifications are:
- Infrastructure services
- Container services
- Abstract services
The level of responsibility around these services are defined within three different AWS Shared Responsibility Models, and it’s essential when using AWS you understand your level of responsibility when it comes to applying security.
This course focuses on Container and Abstract services. The primary Container services we look at are: RDS, EMR and Elastic Beanstalk and the primary Abstract services include: S3, DynamoDB, SQS and Glacier.
The lectures within this course will define and guide you through the following areas to help you apply the correct level of security to your Container and Abstract services.
What are AWS Abstract & Container Services?: This lecture provides you with a clear understanding of what abstract and container services are within AWS. There is a clear divide between the two which must be understood as responsibilities around security is a key difference between them
Security Controls: Data at Rest and In Transit: Here we will take a look some of the available options and best practises to help you maintain integrity and protection around your data when at rest, in transit and held within a number of container and abstract services
Security Controls: Network Segmentation: In this lecture we look at how we can use the network infrastructure and architecture to connect and restrict access to our container and abstract services to increase security through a number of different controls
Identity & Access Management: IAM is heavily used for both container and abstract services and plays a key part in authorisation and authentication for access and management, this lecture looks at how IAM can be used to help protect access across your services
Built-in Service Security Controls: This lecture will briefly look at some of the service specific security controls that may not have been covered in the previous lectures that you can leverage to help secure you data and environment
If you have thoughts or suggestions for this course, please contact Cloud Academy at firstname.lastname@example.org.
Hello and welcome to this lecture, where we're going to discuss how the configuration of your network infrastructure can help you increase security specifically for your container services.
If we remember back to the lecture entitled AWS Abstract and Container Services, where we looked at the different responsibility models, we can see that the responsibility for network traffic control lays firmly in the hands of us, the customers. As a result, we must look at the best ways to architect and secure our services and data, utilizing different network features and controls.
Within this lecture, we are going to cover the following topics, and how each one can help you secure container services.
So we'll be looking at subnets, both public and private. Routing tables, network access control lists, known as NACLs, security groups, network address translation and bastion hosts.
Let's start out by looking at a high level at what each of these controls are, starting with public and private subnets within your VPC.
Firstly, what is a subnet, and what makes a subnet public or private? Subnets allow you to segment your VPC into different networks, with different IP ranges, which is important both from a deployment and design perspective, and also for security.Segmentation allows you to refine your security profile as appropriate for each of the services operating within each subnet. A subnet is distinct network segment with its own IP address range within the larger VPC CIDR block.
So let's have a quick look at how these subnets look and their network diagram. So we have our VPC with a network range of 10.0.0.0/16, so that's our VPC CIDR block. And then we have a private subnet within this, with a 10.0.1.0/24, and another private subnet with an IP address range of 10.0.2.0/24. And each subnet is in a different availability zone. It's important to point out here that subnets cannot cross availability zones.
So what is the difference between a public and a private subnet? Well you can only have a public subnet when the following two conditions are true. Firstly, you need to have an Internet Gateway attached to your VPC, and secondly, you need to have a route from your subnet pointing to the outside world via the Internet Gateway. If both of these conditions are met, then that subnet is considered to be a public subnet.
If your subnet does not meet this criteria, then you have a private subnet. So if we take a look at our network diagram again to see how these controls fit in, without an Internet Gateway attached to your VPC, then your VPC is at that point an isolated network, only accessible via the management console or the AWS CLA. By attaching an Internet Gateway to your VPC, it provides your VPC a gateway to the outside world. And this internet gateway is provided and managed by AWS, all we need to do is to create it and attach it to our VPC.
When the Internet Gateway's attached, the subnet still doesn't know it exists as there are not routes to that Internet Gateway to the outside world. At this point, your subnet and other subnets are still classed as private. That is why it is only when point two from the conditions I mentioned previously is true, that the subnet is then classed as a public subnet. There has to be a route. So here we can see that there's now a route from subnet 10.0.1.0/24 to the Internet Gateway via Public Route Table, and between the two subnets, we just have a private route. So when this public subnet is configured, traffic can then traverse in and out of your VPC public subnet and potentially beyond, depending on security controls you have set up between your other private subnets.
As we briefly mentioned, when you have more than one subnet you an implement routing between the two network segments using route tables, which are attached to the subnet itself. These route tables define which subnets can talk to which other subnets. This helps you isolate traffic between specific subnets to help increase security, and by only allowing communication between subnets that need to talk to each other. You may have subnets where instances never need to send traffic to instances or services in another subnet. If so, then it's best practiced to insure no route between these two subnets exist.
Also attached to each subnet is something called a Network Access Control List, a NACL. NACLs provide a rule-based tool for controlling ingress and egress network traffic at the protocol and subnet level. In other words, NACLs monitor and filter traffic moving in and out of a network. You can attach a NACL to one or more subnets within your VPC. If you haven't created a custom NACL, then your subnets will automatically be associated with your VPC's default NACL, which allows all traffic to flow in and out of every subnet. One point to mention is that NACLs are stateless in their design. Meaning that any response traffic generated from a request would have to be specified in either the inbound or outbound raw set, depending on the direction of response expected. So again, if we go back to our network diagram, we can see that we have two NACLs, both a public and a private NACL, that control ingress and egress network traffic at the subnet level.
Security groups are very similar to NACLs, but they work at the instance level rather than the network subnet level. AWS security groups are associated with instances and provide security at the protocol and port access level. Each security group, working much the same as a file contains a set of rules that filter traffic coming into and out of an EC2 instance. There are no deny rules like there are with NACLs, rather if there is no rule that explicitly permits a particular data packet, it will be dropped. Whereas NACLs are stateless by design, AWS security groups are stateful, meaning that response traffic does not need to be specified in the inbound/outbound rule set.
So if we have a quick look at our network diagram, just to see the placement of our security groups, and there you can see, within our security groups, we have instances that are protected by the conditions within those security groups.
Now let's look at what a NAT is. From a security stance, a NAT, network address translation, essentially allows your private instances to have outgoing connectivity to the internet, while at the same time, blocking inbound traffic from the internet. Therefore protecting your private instances. Your NAT resides within the public subnet. This is useful for allowing your private instances to access the internet for important operating system updates that may be required.
Lastly, at a high level, a Bastion host sits within your pubic subnet, which should only be accessible by authorized personnel via a secure connection using SSH or RDP. Once remote connectivity is established with a Bastion host, the host then acts as a jump server, allowing you to SSH or RDP to lock into other instances within private subnets, deeper within your network. When properly configured through the use of security groups and network ACLs, the Bastion essentially acts as a bridge to your private instances via the internet. If you require remote connectivity with your private instances over the public internet, then a Bastion host will be a great solution. There are many ways to secure your Bastion hosts, and it should be locked down as much as possible. Such as hardening your chosen operating system. If this is not locked down sufficiently and gets breached by a malicious user, then they could potentially gain access to your internal instances too.
Again, looking at our network diagram, we can see that on that instance, sits within our public subnet, along with our Bastion host.
Okay, thus far we have looked at some of the network security controls that are available within the VPC.I now want to talk about some of the container services and how they can leverage these features to implement additional security.
As before, let's run though some of the container services mentioned previously, to see the best placement within a VPC starting with RDS.
As we know, RDS is a database service, and as such will often store sensitive customer data for some application. This application could be a web app, which would be accessible from the internet by the general public. In this scenario, we would only want internet users to interact with the web server and not look back at infrastructure, such as the application servers, or more importantly, the database where the customer data may be stored.
As a result for security concerns, and possibly governor's controls, the RDS instances should be located within a private subnet within your VPC, removing the exposure to the internet like we have with the public subnet. This essentially creates multiple layers within your infrastructure through the use of multiple subnets. From a network architecture perspective, a best practice approach would be to use different subnets carrying out similar functions to create different layers within your infrastructure.
For exampleyou would have a public subnet which would act as a public internet layer. Here you may have an elastic load balancer receiving incoming traffic from your web application. Next you'll have a threat protection layer, where network level security appliances can intercept and analyze traffic before being sent to the next layer. Next we'll have a webserver layer. This is where your web service will be located to manage the web communications from your users. Following this, an application layer. This is where your application will process the request from the web servers. And finally, your database layer. And this is where your RDS instances will be located to store any data from your application processing.
As you can see, by placing your RDS instances in the fifth level behind the other four layers, the likelihood of malicious users and traffic getting access to your RDS instance is significantly reduced, especially when you begin to couple this with other security features we have discussed such as NACLs, security groups, and route tables.
The route tables for these subnets can be configured to only allow communications with the subnets both above and below its current layer. For example, the subnet for layer three only needs to be able to communicate with layer two and four subnets. Routes to subnet one and five can be removed from the route table.
For Elastic Beanstalk, we can use the same approach. Again we are responsible for implementing the correct level of security for our environments that are deployed via the Elastic Beanstalk service, which often by design, have a multilayer approach of web, app, and database infrastructure components. Grouping similar elements and spitting others into different subnets enhances the overall security of the deployment.
This grouping allows you to implement other security features, such as NACLs and security groups more effectively, as the number of protocols and ports being used will be kept to a minimum, thus narrowing any room for error or malicious access. For example, an incoming NACL applied at level five subnet, the database layer, using the layer example previously discussed, may look like following.
This keeps the network level firewall restricted to only those ports expected by the instances within that subnet. Which in this case would by MySQL running on RDS.
In addition to this network level security, it would be advisable to also implement security groups to add another level of security protection at the instance level. In this example, we would use VPC security groups to control this access.
One security group would contain all the application servers and another security group would contain the database instances. This would insure that the only communication between the application servers and the database servers would be between the instances included within their respected security groups over specific ports that are defined inside this security group. It's recommended that you define the specific ports here instead of opening up access to communicate over all TCP ports, for example. With RDS being a container service, platform and application management is taken are of. As a result, the need to patch the instance and perform updates on the database itself falls under the responsibility of AWS, therefore, the need for NAT implement is not required to perform these actions.
I briefly mentioned the Elastic Beanstalk earlier, where I referenced the resources called up to deploy your environment to run your application. Depending on your configuration, you will likely be using a number of resources between your public and private subnets. And so it's imperative to make use of the range of network security features throughout the VPC that we have already mentioned.
Again, AWS offers the ability for Elastic Beanstalk to manage updates to your underlying platform run in your application, such as PHP, Java, et cetera, the OS as well as the web and application server updates.
By design, Elastic MapReduce automatically uses some of these VPC security features, in particular, security groups. During an EMR job flow, EMR will launch and create two different EC2 security groups. One that sets the security for the master node, and a secondary security group for the slaves. This secondary security group only allows communication between the slaves and the master. The master security group allows communication between itself and the EMR service and resources such as S3 for pulling data. As these are security groups, we have the ability to modify and change these groups as necessary, so we still have control over security from this perspective.
Again, the EC2 instances used by EMR within its cluster should be located within a private subnet, especially if the data is sensitive. This subnet would also have its own NACL.
Always protect your data and services where possible within private subnets. If the data or service does not need to be accessed over the internet, then they should be within private subnets, behind NACLs, behind route tables, and not made accessible via the public subnet.
If we take a quick look at our abstract services, the network security is largely taken care of by AWS, as the shared responsibility model dictates. Firstly, DynamoDB.
DynamoDB is an abstract database service whereas RDS is a container database service. There are some fundamental differences between the two as expected. More of DynamoDB's security, operation controls, and underlying maintenance falls under the responsibility of AWS. For example, DynamoDB hardware failover and data replication is taken care of by AWS automatically and does not have to be configured like it does in RDS by setting multi-az failover. Also with DynamoDB, you do not place a database yourself within a particular az or network segment, being an abstracted service, and as such, network inspections around security for DynamoDB, are also managed by AWS.
This approach remains the same for both S3 and SQS network security controls and management for these services are managed by AWS, and are governed by the security mechanisms imposed on AWS's own network. However, controlling who has access to these services does require you to set up the necessary authorized permissions. This is largely related to identity and access management, AIM, and this is what we'll be discussing in the next lecture.
So to summarize this lecture quickly, we can clearly see that there's a clear distinction between the amount of network security control we have over container services to those of abstract services. Detail, care, and attention should be taken to insure the correct level of network security is used to protect your data when using these container services. Generally speaking, container services offer more control, along with that is an increased effort to secure them, however. Conversely, abstract services are easy to set up, as AWS is responsible for the lion's share, but also offer less control.
Stuart has been working within the IT industry for two decades covering a huge range of topic areas and technologies, from data center and network infrastructure design, to cloud architecture and implementation.
To date, Stuart has created 90+ courses relating to Cloud reaching over 100,000 students, mostly within the AWS category and with a heavy focus on security and compliance.
Stuart is a member of the AWS Community Builders Program for his contributions towards AWS.
He is AWS certified and accredited in addition to being a published author covering topics across the AWS landscape.
In January 2016 Stuart was awarded ‘Expert of the Year Award 2015’ from Experts Exchange for his knowledge share within cloud services to the community.
Stuart enjoys writing about cloud technologies and you will find many of his articles within our blog pages.