I want to delete a security group, sg-d578d9ab, in my AWS account.
I got the following message when trying to delete it.
These security groups are associated with one or more network
interfaces. Delete the network interfaces, or associate them with
different security groups. View your network interfaces.
In order to solve the problem, I opened the Network Interfaces page to see which network interface is using sg-d578d9ab.
It turns out there's 1 network interface that's using the security group.
Then I use Change Security Groups option to dissociate the security group from the network interface.
Then I got a message saying
You do not have permission to access the specified resource.
Why can't I change the security group of the network interface?
My AWS account has AdministratorAccess permission.
The Attachment owner and Owner ID properties of the network interface are amazon-rds. This seems to be the reason I can't change its security group.
Does this mean that the network interface is created when someone else sets up an AWS RDS?
The security group, sg-d578d9ab, is used by one of my RDS instances.
After dissociating the RDS instance and the security group. I'm able to delete the security group.
Saw the same error, but from a VPC endpoint. After dissociating the VPC endpoint from the security group, I was able to delete the security group.
Related
I was trying to connect to an RDS Instance from an EC2 instance. This resulted in creation of security groups for both of these resources. Now I do not want this connection and have deleted the RDS instance but the security groups still exist. How can I delete them?
When I try to delete them from console it says:
The following security groups can't be deleted. They are either default security groups, referenced by other security groups, or they are associated with instances or network interfaces.
Reason: 1 security group associated
These security groups were also attached to network interfaces earlier which was also a reason for why I couldn't delete them but I was able to disassociate them from these security groups.
Delete the particular rule referencing the other security group (or edit to something else) first. This removes the dependency and you'll be able to delete the security group itself.
I have a license server that has a static IP set up inside the same security group and VPC as the EC2s I’m spinning up using terraform. Basically I want the license server and these EC2s to be able to communicate. At the moment they can’t because the security doesn’t add the EC2s as an inbound rule so that the license server also gets it as an inbound rule (same security group). I’m wondering how to add the IP of the EC2 I’m spinning up in terraform to the inbound of its security group so that it can talk to the license server?
There is no such concept as being "inside the same security group". Security Groups rules apply to each instance individually.
The correct configuration is:
Create a Security Group for the EC2 instances (EC2-SG) that permits appropriate Inbound access to use the instance, and
Create a Security Group for the licensing server (License-SG) that permits Inbound access on the licensing port from EC2-SG
That is, you need TWO security groups. License-SG will permit inbound access from any EC2 instance that has is associated with EC2-SG. You can have more security group as necessary for your instances -- simply add them as sources in License-SG.
Security Groups can also refer to themselves. In your current situation, where the instances and the licensing server are all associated with the same security group, you could add a rule that permits inbound connections from itself. However, this is also saying that the instances are permitting inbound connections from the licensing server, which would not be a correct configuration.
Please note that all communication within the VPC should take place via private IP addresses, otherwise the traffic exits the VPC and then comes in again, which does not allow Security Groups to operate correctly (and also costs you more money!).
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.
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 having an issue with Security Groups in AWS. I have 4 security groups, 2 in EC2 and 2 in RDS.
ec2-prod
ec2-test
rds-prod
rds-test
On the other hand, I have a database DEV, having the rds-test security group associated.
In the rds-test inbound rules I've added ec2-prod and ec2-test, and my IP is added into the ec2-test, but for some reason it's not working.
If I add my IP directly on rds-test I can connect to the database, but this behavior make no sense to me.
Just in case, in the ec2-test security group, my IP has permission ALL TCP.
Any ideas?
It's the normal behavior. You have to add your IP to the DB security group.
The DB security group defines the access the RDS DB.
The EC2 security group defines the access the EC2 instance.
The fact that your IP is authorized to access the instance doesn't mean your IP is authorized to access the DB (but you can connect to the DB from the instance).