In my studies of AWS, multiple times I have seen references to "linking" security groups. I do not understand what this means in practice. My current understanding is that when rules are defined in security groups, they are defined in terms of ports and CIDR ranges, there is no linkage to another group. So, my question is, what is this language referring to? I have a snippet from the Elasticache FAQ below with this language:
"To allow network access to your cluster, create a Security Group and link the desired EC2 security groups (which in turn specify the EC2 instances allowed) to it."
When you edit inboud/outbound rules for a Security Group, you are allowed to reference another Security Group as source/destination. Example:
The benefit of this is that you don't have rely on IP addresses or IP ranges, because these might change (instance is restarted, you want to migrate from one instance to another, etc.).
Moreover, linking a Security Group may simplify the rule table, since more than one entity can have the same Security Group attached, you don't need to specify the IP of each entity.
The security group you made can be created without an EC2 instance in place. It won't have any effect if you do, but you can prepare the groups ahead of time.
Then when you have 1 or more EC2 instances (or any other resource really) you can apply 1 or more of these groups to the instances. Applying them is apparently called "linking" in your training, according to your last sentence.
To allow network access to your cluster, create a Security Group and
link the desired EC2 security groups (which in turn specify the EC2 instances allowed) to it.
(emphasis mine)
Alternatively, like #luk2302 mentioned, you can also provide fine grained security by linking security groups to each other. For example:
Allow traffic on port 80 of my security group only by EC2 instances who belong to <>.
Related
I'm having trouble understanding the source attribute on AWS security groups. My understanding is that e. g. this security group:
Would allow traffic on Port 5432 from all EC2 instances that have the attached security group sg-0a5.... I'm not sure how this is determined though. Is there an IP table with all security groups and their instances that this is checked against?
I'm also very confused because I'm currently following a guide that suggests creating a security group and attaching the source attribute to its own environment. To my understanding, this would mean that the environment allows traffic to itself, which is quite paradoxical to me. I'd love some clarification.
When traffic traverses internally inside the VPC the evaluation is actually performed on whether the private IP address is part of an ENI which has that security group attached.
To be clear as it is evaluated based on the ENI, this rule will only work traffic travels internally inside the VPC/region (private IP to private IP). If it leaves the AWS network or region then the evaluation cannot be performed and thus the rule will fail.
When you specify a security group as the source for a rule, traffic is allowed from the network interfaces that are associated with the source security group for the specified protocol and port. Incoming traffic is allowed based on the private IP addresses of the network interfaces that are associated with the source security group (and not the public IP or Elastic IP addresses).
In your example you mention referencing a security group as a source within itself, however based on the description above it is more seen as metadata when evaluated to confirm the host instance has met this requirement.
In fact the default security group starts by allowing an inbound rule where the source is itself.
I have an ALB with a SG (ALB_SG) that I want to give access only to a list of IP's already defined in another SG (Whitelist_SG) in the same VPC.
I have created 2 (relevant) ingress rules for the ALB_SG.
443 ingress from Whitelist_SG
80 ingress from Whitelist_SG
In the Whitelist_SG I have a list of ingresses from relevant CIDR blocks that allow all ports.
When I access the ALB I am timing out (sign of bad SG). If I add the Whitelist_SG directly to the ALB it works.
What am I missing to make the nested rules work?
As an aside I know that when I add the Whitelist_SG to a EC2 instance via a nested rule I also have to add it to the instances Network adapter. I am assuming its something like that here.
AWS security groups don't work in the way you are trying to use them. There is no concept of "nesting" or "chaining" security groups like you are attempting.
The ability to reference one security group from another security group only works to allow members of one security group to access the members of the other security group. Security group membership only applies to resources like EC2 instances, Lambda functions, etc., that are running within your VPC (or a peered VPC).
For example, adding your laptop's IP address to security group A just gives your laptop access to anything security group A is directly attached to. It does not make your laptop a "member" of security group A.
Im using an internal ELB right now. Its only accessible from inside my VPCs which is good.
But now I want to add a security group to allow an external network access to the ELB. I could use a proxy server but I suspect there is a better way.
Can I create a public ELB and use security group to only allow it access to my VPC networks without hardcoding IPs? Is there a variable/placeholder i can use in a security group that says "all my connected vpcs"? Because then i could do that and just add an sg for that external network.
You can create an ELB and assign it a security group, then assign all resources you wish the ELB to be able to access a second security group, with a rule permitting access from the ELB's source security group.
See the ELB section of this guide
You can't assign access by specifying vpc- (how you might expect to, similar to being able to allow access based on other security groups by specifying the sg number, sg-..., under Source:).
However, it's easy enough to just put the subnets of your VPCs you want to allow access to and from. If your VPC is assigned the subnet of 10.10.0.0/16, specify that as a Source.
If you really want to have a single security group defined on your ELB for all of your VPCs, just create a stand-alone security group allowing access from all of your VPCs called vpc-access or something, and then assign that sg-... to your ELB Source: list.
I have several IP's and I want add access from exactly those IP's to some security groups.
Is there way to declare the IP's once and reuse them in security groups instead of declare those IP's on each security group?
There is no way to do an "include" in a security group, including a list of rules by reference.
However, by default, each instance can be a member of up to five security groups, so one common solution is to make each instance a member of two security groups -- one for common rules, and another for rules that are more specific and not shared across all the instances.
Note that it is possible to use a security group ID instead of an IP address in a security group rule, but this has nothing to do with the rules in the referenced group -- it is not an "include." An inbound rule listing a security group ID allows inbound traffic from instances that are members of the listed group. It does not cause a security group to follow any of the rules in the other group.
The accepted answer is no longer true, you can use Prefix Lists to achieve that.
https://docs.aws.amazon.com/vpc/latest/userguide/managed-prefix-lists.html
So for reasons Id rather not go into, my DB is on an EC2 instance in eu-west-1 and I have created a beanstalk app on us-east-1. Id like my app to talk to that EC2 instance on a MySQL port (3306).
Can anyone assist with how Id set this up, what ingress rules I need to setup on the EC2 security group? Given that I will have multiple versions of the app in beanstalk, the IP address may change regularly (after environment rebuilds etc).
The important concept regarding Security Group Rules you might be missing is, that you do not necessarily specify IP addresses as traffic sources alone, rather regularly will refer to other security groups as well:
The source can be an individual IP address (203.0.113.1), a range of
addresses (e.g., 203.0.113.0/24), or an EC2 security group. The
security group can be another group in your AWS account, a group in
another AWS account, or the security group itself.
By specifying a security group as the source, you allow incoming
traffic from all instances that belong to the source security group.
[...] You might specify another security group in your account if you're creating a
three-tier web service (see Creating a Three-Tier Web Service).
[emphasis mine]
Consequently you'll simply need to add the Beanstalk app instances security group as a traffic source for TCP port 3306 within the MySQL instance security group.
Taking this further
An additional concept to make oneself familiar with is, that you can have multiple security groups assigned to an instance, thus enabling (possibly dynamic) composition of the resulting firewall.
For example, a recommended practice for larger architectures suggests to specify a dedicated security group per 'role' your instances have (rather than accumulating several rules within one security group as usual), e.g. we have security groups like 'role-ssh' (TCP port 22) and 'role-mysql' (TCP port 3306), which are assigned to EC2 instances as needed in turn. You can read more about this concept in e.g. Security Groups - Most Underappreciated Feature of Amazon EC2.