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.
Related
I have a ec2 instance that is running a website and associates ALB.
normally as a practice inside the ec2 instance security group, alb security group is referenced, but here the client has a configuration in such a way that inside ec2 instance the source is name of the security group itself.
security group for ec2 instance whose name is
sg-0bc7e4b8b0fc62ec7 - default
As per my understanding of aws security group, under an inbound rule when it comes to source, we can mention IP address, or CIDR block or reference another security group.
But what does this mean for an inbound rule where ALL traffic, all ports are allowed but for source = sg-0bc7e4b8b0fc62ec7 / default.
I am confused with usage of the same name of the security group as source, what this rule will mean?
Each VPC has a default security group (SG). In this SG, inbound rule allows all incoming traffic from "itself". This means that
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.
In other words, if you have two instances that use the default VPC SG, they can only communicate with each other. No other inbound traffic is allow to either instance.
The use of SG as source is a good practice and if often used between load balancer (LB) and its instances, or between instances and RDS database. In the first case the instances allow incoming traffic only from the SG of the LB, while in the second case, db instance allows incoming connections only from SG of the instance.
I'm investigating security setting of an EC2 instance, and taking a look at
security group setting.
In one of the inbound rule's source, instead of source IP address, it has it's own security group's ID and Group name.
What does this mean?
In AWS, Security Groups are applied to each resource individually.
So, let's say you had:
A security group (App-SG) permitting inbound HTTP access on port 80
Two Amazon EC2 instances in a public subnet associated with App-SG
Even though both EC2 instances have the same security group, they are not able to SSH with each other. Some people sometimes say that the instances would be "in" the same security group (which gives the impression that they can communicate with each other), but it is more appropriate to say that the instances are associated with the same security group.
The thing to remember is that security group rules are applied to each instance individually.
So, if you wanted to permit both instances to SSH to each other, you could add an inbound rule to the security group:
Protocol: SSH (Port 22)
Source: App-SG
This says: "Allow any resource associated with this security group to receive traffic from any other resource associated with this security group on port 22".
You might say that security group can "communicate with itself", but the reality is that the same rules are applied separately on each resource.
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.
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
I know that security group are STATEFUL, meaning that if either inbound or outbound traffic is ruled, there will be an associate rule in the other bound to send the traffic.
Considering this, I have created a custom VPC and a public subnet. I have ssh-ed successfully to one of the public instances from my network. But, I cannot ping from one public machine to the other in the same subnet! even when I add this inbound rule that
All Traffic All ALL sg-xxx
the above rule should automatically consider an outbound to every instance in the same security group. But it doesn't
So, I have to add manually an outbound rule again with:
ALL TRAFFIC ALL ALL sg-xxx
why is this happening?
It appears that your situation is:
Two instances (call them A and B) in the same subnet
A security group has been applied to both instances
The security group has been configured with an Inbound rule allowing all traffic
You are unable to ping from one instance to another
For Instance A to ping Instance B, the following is necessary:
An Outbound rule on the security group associated with Instance A, which permits ICMP traffic
An Inbound rule on the security group associated with Instance B, which permits ICMP traffic
The return traffic from Instance B to Instance A will be allowed to leave Instance B due to the stateful nature of the security group
The return traffic from Instance B to Instance A will be allowed to enter Instance A due to the stateful nature of the security group
Since you are using the same security group for both instances, you will need to permit both Inbound and Outbound access. Alternatively, you could use two different security groups:
One security group on Instance A permitting the Outbound traffic
One security group on Instance B permitting the Inbound traffic
The important concept to understand is that a security group defines inbound/outbound rules. Multiple instances that are associated with the same security group have the rules applied to each instance individually. Unlike network subnets, instances with the same security group are not "inside" the security group -- they merely have the same rules.