I have an instance that hosts a mongodb service and I am trying to allow incoming traffic for port 27017 from an autoscaling group of instances. I am adding the security group (that has the AG instances) I want to access the specific instance, but I see it times out.
Inbound rule:
I have tried allowing a specific address or 0.0.0.0 and it works. Only when I am specifying the security group id it doesn't work.
Any help on this highly appreciated.
Assuming that you also have a Load Balancer, you would want three security groups:
ELB-SG: Allow incoming web traffic as appropriate (eg 80, 443). Associate it with the Load Balancer.
App-SG: Allow incoming traffic from ELB-SG. Associate it with the Auto Scaling Group, which will automatically assign it to the instances launched via Auto Scaling.
Mongo-SG: Allow incoming traffic from App-SG on port 27017. Associate it with the instance running Mongo.
Basically, have the security groups reference another Security Group and they will automatically accept traffic from instances associate with that other security group.
Related
I am trying to understand this statement:
"You can reference AWS Security Groups from other Security Groups."
What exactly does this mean?
This is how I understood this. I created a security group and call it "SG-10" and attached it to an instance "EC2-10". The SG "SG-10" has allow port 443 defined inside it.
Now, I create a security group and call it "SG-20" and attached this to an instance "EC2-20". This also has port 443 allowed. Now, if I call "SG-10" inside "SG-20" does this mean that "EC2-10" will be able to connect to "EC2-20" on port 443.?
Regards,
Nik.
if I call "SG-10" inside "SG-20"
No, you can not call a security group, this does not make any sense.
If a security group A references security group B, it does mean that the instance to which the security group A is attached allows inbound or outbound traffic to another instance to which security group B is attached. But if you want to send traffic form instance with security group A to the instance with security group B, you have to use the IP or the DNS of the instance B.
Usually the reason why we would want to reference a security group instead of an IP, is that the IP might change over time or it is not exposed at all. A fairly common example is having an application load balancer (ALB) and a group of EC2 instances which allow traffic only from the ALB. The IP address of the ALB changes over time, so in order to be able to receive traffic from the ALB, we can reference the security group attached to it.
In we want to reference a security group from another security group, we have to edit the rules of the initial security group:
As an example of referencing security groups, imagine a 3-tier architecture:
A Load Balancer receiving traffic from the Internet and sending requests to an Amazon EC2 instance
An Amazon EC2 instance receiving requests from the Load Balancer and sending queries to an Amazon RDS database
An Amazon RDS database receiving requests from the EC2 instance
This would involve 3 security groups:
A security group on the Load Balancer (LB-SG) that allows incoming traffic on port 80/443.
A security group on the EC2 instance (App-SG) that allows incoming traffic on port 80 only from the load balancer. It does this by setting the source to LB-SG.
A security group on the RDS database (DB-SG) that allows incoming traffic on the relevant port (eg 3306) only from the EC2 instance. It does this by setting the source to App-SG.
All security groups allow All Outbound Traffic.
By referencing other security groups, resources can be added/removed without having to change the security groups. For example, another EC2 instance could be launched and assigned the App-SG security group. This new instance would then be able to communicate with the database since DB-SG allows incoming traffic from App-SG, without being tied to any specific IP addresses.
If a resource is associated with multiple security groups, then all rules apply to the resource. Security Groups only say what is 'Allowed'. They do not include 'Deny' rules.
In your SG-10/SG-20 example, you do not mention the source of the traffic, so it is not possible to answer your question. If you want EC2-20 to accept connections from EC2-10, then the SG-20 security group should allow connections with the Source set to SG-10.
As an aside, I should mention that Network ACLs should normally be left at their default "Allow All" settings unless there is a specific networking requirement (eg creating a DMZ).
I've been burned on this before by trying to connect to an EC2 instance's public address... sounds very similar to your setup. Please check this question: Source Security group isnt working as expected in aws. Actually. When you wire up the inbound rule so that the source is a security group, you must communicate through the source instance's private address.
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 have a server (you can think it as a DB) in ec2. Let's call it SERVER-1
I have autoscaling group for web servers. and I want these servers to be able to connect to the SERVER-1
I need to specify ip in the security group of SERVER-1
How can I specify them when I don't know the ip because they will be assigned when created,, they are auto scaling group - controlled ec2.
You should create two Security Groups:
Create a security group for the app servers (App-SG). Allow inbound access for app usage (eg ports 80, 443). Associate the security group with the Auto Scaling group, which will then associate it with each instance launched by the Auto Scaling group.
Create a security group for the database sever (DB-SG). Allow inbound access from App-SG. Associate it to SERVER-1.
That is, DB-SG should permit inbound connections from App-SG. DB-SG refers to App-SG, which means it will accept inbound connections from any EC2 instance that is associated with App-SG. This will continue working as instances are added to, and removed from, the Auto Scaling group.
i have a jupyter notebook on one ec2 instance that want to get the data from data service that is deployed on other ec2 instance. should i put ingress and egress rules for each other on both instances? I'm quite new on the field, so any explanations are appreciated! :)
Yes, you can create 2 different security groups and attach to each one.
You can allow inbound traffic from a particular security group, all instances that have the security group attached can send traffic to the instance on the port you specify.
Another important thing no notice is that security groups are stateful, when you set outbound rules the response traffic is allowed regardless of the inbound rules.
Security Group Outbound rules allow all traffic by default. Typically, you should not modify these settings.
The best way to configure you setup is:
Create a Jupyter-SG security group and associate it with your Jupyter EC2 instance. Add whatever rules you use to connect with the instance (eg SSH).
Create a Data-SG security group and associate it with your "Data Service" EC2 instance. Add a rule permitting inbound access on the desired port, with Source set to the Security Group ID of Jupyter-SG.
This tells the Data-SG security group to permit inbound access from the Jupyter instance (or, more accurately, from any instance that is associated with the Jupyter-SG security group).
I want to launch a single ec2 instance. The challenge that I am facing is I need to configure security group for this instance and I want only the instances coming from an Auto scale group to be allowed to access this. How do I set the inbound in such a case, since the instances coming from an Auto Scale will vary?
Security groups can refer to each other.
For example, if you had a load Balancer and an Auto Scaling group of Amazon EC2 instances, you would need to create two security groups:
A Load Balancer security group (let's call it LB-SG)
A Web Server security group (Web-SG) that is referenced by the Auto Scaling launch configuration
Configure your Web-SG to permit incoming traffic from the LB-SG. This can be referenced by name or by sg-xxxx identifier.
Permitting traffic from another security group is a way of saying "permit traffic from any instance that is associated with that security group". This includes the security group assigned to instances from Auto Scaling.
If you have another instance that should accept incoming traffic from instances in the auto scaling group, create another security group (eg Backend-SG) and permit incoming traffic from Web-SG.
Here is a sample diagram from a Rackspace article on Network Segregation in AWS. Notice how each security group refers to the one 'above' it:
You can add the source ID of load balancer security group in the inbound rule for needed protocols (HTTP, HTTPs). Then delete all the other inbound rules.
Ref: AWS Documentation