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
Related
I have an ec2 instance, with a security group, let's call it A
In Security Group A, I defined a number of inbound rules
Is there a way to define a second security group, let's call it B, and set some inbound rules in it, and then have security group B, as one of the inbound rules for security group A?
AWS allows me to do that, but it's not working. As in, I added my home IP address, to the inbound rules for security group B, but I can't reach the ec2 instance, unless I add my home IP address to the security group A.
When you add another security group like that, you are saying that the AWS resources that belong to security group B can access the resources in security group A. You aren't combining the rules into a single security group somehow.
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 <>.
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'm a bit confused on how security group nesting is meant to work in AWS
say I have the following two security groups:
sg-teamA - IPs of team A members - all tcp
sg-teamB - IPs of team B members - all tcp
I then create a sg-RDP group and assign it to an EC2 instance
I add sg-teamA and teamB to the sg-RDP group for RDP (port 3389)
This doesn't work. Why?
I need to add the specific team A and team B member IPs to sg-RDP for them to be allowed to RDP to the VM.
What's the purpose of allowing nested groups/what scenarios is it meant for since it doesn't work for the above?
There is no such thing as "Nested security groups".
In your question, you say "sg-teamA - IPs of team A members - all tcp". It appears you are using Security Groups as a way of listing IP addresses that you want to use as a source for Security Group B. However, this is not how security groups work.
The Inbound rules on a security group act like a firewall, determining what traffic to come into an EC2 instance. Rules define an IP address and a Port that are permitted access.
For example:
Permit access from 54.22.33.44 on port 3389
Also, instead of specifying an IP address, Security Groups can refer to other security groups.
For example:
Security Group A is associated with EC2 instance A
Security Group B has an Inbound rule referring to Security Group A on port 3389
Result: Security Group B will permit inbound access from any EC2 instance that is associated with Security Group A (To clarify: Any instance that has Security Group A as one of its listed security groups will be allowed to access resources protected by Security Group B, on port 3389)
If you have a list of external IP addresses (not related to EC2 instances) and you wish to permit them to access resources protected by Security Group B, then you will need to list them in Security Group B itself.
In your case, this means you should add the external IP addresses to your Security Group sg-RDP.