The AWS docs are almost useless when trying to describe an entire system. Is there any resource or compiled list of all the resources that can belong to a security group and the different types of security groups?
Here is what I have so far:
EC2-Classic instance
EC2-VPC instance
RDS
ElasticCache
Anything else I'm missing? Any really good doc resource I'm missing?
The main concept to understand about an AWS Security Group is that it determines what traffic is permitted in/out of a resource on a virtual network.
Therefore, think about what can be launched "into" a virtual network:
Amazon EC2 instances
Services that launch EC2 instances:
AWS Elastic Beanstalk
Amazon Elastic MapReduce
Services that use EC2 instances (without appearing directly in the EC2 service):
Amazon RDS (Relational Database Service)
Amazon Redshift
Amazon ElastiCache
Amazon CloudSearch
Elastic Load Balancing
Lambda
Resources do not "belong" to a security group. Rather, one or more Security Groups are associated to a resource. This is often a difficult concept to understand since Security Groups have similar abilities to firewalls, and firewalls generally "encase" a number of devices. Rather than "belonging to", or "being encased by", a security group, the virtual network simply uses the definitions contained within a security group to determine what traffic to permit in/out of the resource.
For example, imagine two EC2 instances that are associated with a "Web" security group and the security group is configured to permit incoming traffic on port 80. While both instances are associated to the same security group, they cannot communicate with each other. This is because they do not "belong" to the security group, and are not "within" the security group. Rather, the security group definition is used to filter traffic in/out of the instances. The security group can, of course, be configured to permit incoming traffic from the security group itself (a self-reference), which really means that incoming traffic is permitted from any resource that is, itself, associated with the security group. (See, I told you that it's a difficult concept grasp!)
Also, a security group is not actually associated with an EC2 instance within a VPC. Rather, the security group is associated with the Elastic Network Interface (ENI) that is attached to an EC2 instance. Think of the ENI as a "network card" that links an instance to a VPC subnet. An instance can have multiple ENIs and can therefore connect to multiple subnets. Each ENI can have its own association with security groups. Thus, the actual security groups being used depends upon where the traffic is flow in/out of the instance, rather than actually being associated with the instance.
There are only two "types" of security groups:
EC2 Classic (the legacy network configuration)
EC2 VPC (the modern private network configuration)
Either type of security group can be associated with any other resource, as long as they are in the same network type (classic or VPC).
A Lambda Function can also be associated with a Security Group. That might not have been the case in 2015, when the original answer was written.
Fargate tasks can also be assigned to security groups.
AWS EFS (Elastic File System) needs a security group attached.
From the AWS document:
To connect your Amazon EFS file system to your Amazon EC2 instance,
you must create two security groups: one for your Amazon EC2 instance
and another for your Amazon EFS mount target.
Reference: https://docs.aws.amazon.com/efs/latest/ug/accessing-fs-create-security-groups.html
interface endpoints can also be associated with security groups, this is a good question and so far not easy to find on AWS documentation.
Related
I am unable to use AWS SSM sessions manager for secure login to my private instances with NACL rules applied. Whereas AWS SSM works if I update NACL rules open To public(0.0.0.0/0).I want my private instances to be secure and not have open connections in NACL.
Please help.
I want my private instances to be secure and not have open connections
To use AWS SSM in a completely private subnet that has no inbound or outbound access to the internet, you need to use VPC endpoints. Follow the steps described in the AWS docs to do this:
Amazon EC2 instances must be registered as managed instances to be
managed with AWS Systems Manager. Follow these steps:
Verify that SSM Agent is installed on the instance.
Create an AWS Identity and Access Management (IAM) instance profile for Systems Manager. You can create a new role, or add the needed
permissions to an existing role.
Attach the IAM role to your private EC2 instance.
Open the Amazon EC2 console, and then select your instance. On the Description tab, note the VPC ID and Subnet ID.
Create a VPC endpoint for Systems Manager. For Service Name, select com.amazonaws.[region].ssm (for example, com.amazonaws.us-east-1.ssm).
For a full list of Region codes, see Available Regions. For VPC,
choose the VPC ID for your instance. For Subnets, choose a Subnet ID
in your VPC. For high availability, choose at least two subnets from
different Availability Zones within the Region. Note: If you have more
than one subnet in the same Availability Zone, you don't need to
create VPC endpoints for the extra subnets. Any other subnets within
the same Availability Zone can access and use the interface. For
Enable DNS name, select Enable for this endpoint. For more
information, see Private DNS for interface endpoints. For Security
group, select an existing security group, or create a new one. The
security group must allow inbound HTTPS (port 443) traffic from the
resources in your VPC that communicate with the service. If you
created a new security group, open the VPC console, choose Security
Groups, and then select the new security group. On the Inbound rules
tab, choose Edit inbound rules. Add a rule with the following details,
and then choose Save rules: For Type, choose HTTPS. For Source, choose
your VPC CIDR. For advanced configuration, you can allow specific
subnets' CIDR used by your EC2 instances. Note the Security group ID.
You'll use this ID with the other endpoints. Optional: For advanced
setup, create policies for VPC interface endpoints for AWS Systems
Manager. Repeat step 5 with the following change:
For Service Name, select com.amazonaws.[region].ec2messages.
Repeat step 5 with the following change: For Service Name, select com.amazonaws.[region].ssmmessages. You must do this if you want to
use Session Manager.
After the three endpoints are created, your instance appears in
Managed Instances, and can be managed using Systems Manager.
I'm still experimenting with migrating my service fabric application to kubernetes. In service fabric I have two node types (effectively subnets), and for each service I configure which subnet it will be deployed to. I cannot see an equivalent option in the kubernetes yml file. Is this possible in kubernetes?
First of all, they are not effectively subnets. They could all be in the same subnet. But with AKS you have node pools. similarly to Service Fabric those could be in different subnets (inside the same vnet*, afaik). Then you would use nodeSelectors to assign pods to nodes on the specific node pool.
Same principle would apply if you are creating kubernetes cluster yourself, you would need to label nodes and use nodeSelectors to target specific nodes for your deployments.
In Azure the AKS cluster can be deployed to a specific subnet. If you are looking for deployment level isolation, deploy the two node types to different namespaces in k8s cluster. That way the node types get isolation and can be reached using service name and namespace combination
I want my backend services that access my SQL database in a different subnet to the front-end. This way I can limit access to the DB to backend subnet only.
This is an older way to solve network security. A more modern way is called Zero Trust Networking, see e.g. BeyondCorp at Google or the book Zero Trust Networks.
Limit who can access what
The Kubernetes way to limit what service can access what service is by using Network Policies.
A network policy is a specification of how groups of pods are allowed to communicate with each other and other network endpoints.
NetworkPolicy resources use labels to select pods and define rules which specify what traffic is allowed to the selected pods.
This is a more software defined way to limit access, than the older subnet-based. And the rules are more declarative using Kubernetes Labels instead of hard-to-understand IP-numbers.
This should be used in combination with authentication.
For inspiration, also read We built network isolation for 1,500 services to make Monzo more secure.
In the Security team at Monzo, one of our goals is to move towards a completely zero trust platform. This means that in theory, we'd be able to run malicious code inside our platform with no risk – the code wouldn't be able to interact with anything dangerous without the security team granting special access.
Istio Service Entry
In addition, if using Istio, you can limit access to external services by using Istio Service Entry. It is possible to use custom Network Policies for the same behavior as well, e.g. Cilium.
I am setting up a VPC on AWS. It has a public subnet and two private subnets. The public subnet is for web servers. The private subnets are for high availability databases. I am securing the resources using Security Groups, not Network ACL's.
The default security group which was created when I created the VPC allows all outbound traffic, and only allows inbound traffic from other subnets in the VPC. I'm not sure exactly what kind of servers I'll be deploying in the future - more web servers, more RDS instance, something else? In light of this, I think my default security group should allow no traffic inbound or outbound. Does that make sense?
In this way, if I forget to explicitly choose the security group when I launch an instance, the server is isolated from all other resources.
Given your design, a recommended security configuration is:
Put your load balancer in the public subnet: It is public-facing
Put your web servers in a private subnet: This keeps them secure by removing direct access from the Internet
This way, if you launch a future instance in the private subnet, it is more secure than launching in a public subnet. Security groups are then an extra layer of security.
Given that you are aiming for High Availability, also spread your web servers across multiple Availability Zones. An easy way to do this is to use Auto Scaling, which distributes instances evenly across Availability Zones and has the benefit of scaling in/out to meet demand while minimizing costs.
For an example architecture, see the Web Application Hosting reference architecture in the AWS Architecture Center.
I'm puzzled by the role played by several groups that seem to have been added automatically to my list of AWS security groups, connected in what I gather is the default configuration, and wonder how they work (and what about them it is safe to change). Specifically there are three that are mysterious:
launch-wizard-1 which has an inbound rule SSH, TCP, 22, 0.0.0.0/0.
default described as "default VPC security group" which has an inbound rule for all traffic and all ports that uses itself as a source.
default_elb_... described as "ELB created security group used when no security group is specified during ELB creation - modifications could impact traffic to future ELBs" which has an inbound rule allowing HTTP from all IP addresses
The first two do not appear to be connected to any other security groups, while the latter is the source for a for an inbound HTTP rule in each of the security groups for my Elastic Beanstalk environments.
What do these do three groups do? Can I change them? Or change connections to them?
For example, the latter rule seems to have the effect of allowing HTTP traffic from anywhere to all of my EB environments. Can I change this rule to limit IPs (to to all environments)? Can I "un hook" the rule as a source from a given EB environment (e.g. replacing it as a source with a range of IPs)?
Looks like you've got a handle on what a security group is: a stateful firewall that is applied to EC2 instances.
When you manually launch an EC2 VM from the web console, AWS will provide you with the option of reusing an existing security group or creating a new one. When you create a new one, the default rule is SSH (port 22) and a default security group name of "launch-wizard-#".
Unfortunately, since a security group can be used by multiple EC2 instances, they are not cleaned up when you delete a VM. So if you deleted the VM that launch-wizard-1 was created with, it does not delete the security group.
Onto the "default security group for VPC". When you create your VPC, a default security group is created alongside with it. When EC2 instances are launched into a VPC subnet, they will have the default security group assigned to them if another is not specified. (http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_SecurityGroups.html#DefaultSecurityGroup).
So what does that rule mean that allows it to talk to itself? By default, all inbound traffic is denied by a security group. This 'talk to itself' inbound rule indicates that if two VMs both have this rule assigned to them, they will be allowed to communicate with one another on all ports. Should you use this default group? No. Create unique security groups that exercise the rule of least privilege (only open the ports you need to the instances that need them).
Unfortunately, I do not have much elastic beanstalk experience, so this is where my answer turns to assumptions. In the little that I have played with beanstalk, I recall that it created auxiliary resources in your account. This appears to the be the case with your Elastic Load Balancer (ELB). As the description indicates, when Elastic Beanstalk needs to launch a new load balancer, the load balancer will use this default group unless you specify another. I believe that this link documents how you would do this (http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.managing.elb.html).
In all cases, I would recommend against using the default security groups in favor of individual firewall rules unique to that instance's security needs.
Can you change or delete these?
launch-wizard-1: Yes, you can delete or modify this group. Since you mentioned he is unused, go ahead and nuke him.
default: VPC is finicky about some of the default resources that it creates. I tested it on my account and I cannot delete it. You can of course modify it, but I'd recommend instead just not using it.
default_elb: If I remember properly, elastic beanstalk uses cloudformation to create additional resources, such as an ELB security group. You can modify this security group, but it will create inconsistencies between the cloudformation definition and reality. For your specific question, you can change the range of allowable IPs, but if you're writing rules on a private IP you won't be able to cross environments if the environments are deployed to separate VPCs.
I'm using Amazon web service (AWS).
I have a web server installed on one server instance (ec2).
It's served on port 8080. The machine is on a security group called "web-secgrp".
I want to allow access to that web server ONLY from another set of ec2 instances. These instances all share the same security group called "client-secgrp"
I can do this via the security groups by adding each and every individual public IP's of the set of ec2 instances to "web-secgrp". But this is not easy to maintain as I may have more or less of these machines running at once and it's just painful to add all the IP's by hand.
I noticed that in the Source of the security group, I can enter the ID of another security group. I tried entering the ID of client-secgrp in the inbound rules of web-secgroup but that seems to have no effect.
For what it's worth, I also remember that in the (very distant) past, I had to add the security group of an ec2 to the security group rules of an RDS (mysql service).
Any insight on a better way to manage the firewall ports of AWS is greatly appreciated.