Few questions:
Are us-east-1a, us-east-1b, and us-east-1d considered one or three availability zone?
Say I have two instances within us-east-1a, one has a mongodb server, the other has a nodejs app. Do I need to add permissions for port 27017 (mongodb) to the security group for the app server to connect to the mongo server?
Same question as above, but say one server is in us-east-1a and the other is in us-east-1b. Do I need to modify the security group?
Would the VPC or Subnet ID have any effects on communication between instances?
edit
moved to Server Faults
1) 3
2) Yes.
3) Yes
4) If you are using a VPC and trying to communicate outside of the VPC, you'll need to add a NAT box in that VPC. Then you'll obviously have to make security group changes. If you are trying to communicate inside of the VPC, it's easier since you won't need to create a NAT box, but you will still need to make security group changes. No matter what, you have to create security group changes if you want to communicate outside of ssh.
Side Note: You can use the instanceID in the security groups instead of IP addresses. This can be handy for a variety of reasons.
Related
I've followed https://docs.gitlab.com/runner/configuration/runner_autoscale_aws_fargate/ to create a custom runner which has a public IP attached and sits in a VPC alongside "private" resources. The runner is used to apply migrations using gitlab ci/cd.
ALLOW 22 0.0.0.0/0 has been applied within the security group; but it's wide open to attacks. What IP range do I need to add to only allow gitlab ci/cd runners access via SSH? I've removed that rule for the moment so we're getting connection errors, but the IPs connecting on port 22 all come from AWS (assuming gitlab runners are also on AWS).
Is there something I'm missing or not understanding?
I had a look at the tutorial. you should only allow EC2 instances to be able to ssh into the Fargate tasks.
One way to do that is, You could define EC2 instance's security group as the source in the Fargate task's security group instead of using an ip address(or CIDR block). You don't have to explicitly mention any ip ranges. This is my preferred approach.
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).specify a security group as the source
Second approach is, As #samtoddler mentioned, you can allow the entire VPC network, or you can restrict it to a subnet.
I was misunderstood; gitlab-runner talks to gitlab, not the other way round, my understanding was gitlab talks to runners over SSH.
My immediate solution was 2 things:
Move the EC2 instance into a private subnet
As per #Aruk Ks answer, only allow EC2 to communicate over SSH to ECS Fargate tasks
This answered my question as well https://forum.gitlab.com/t/gitlab-runner-on-private-ip/19673
Is there an alternative to AWS's security groups in the Google Cloud Platform?
Following is the situation which I have:
A Basic Node.js server running in Cloud Run as a docker image.
A Postgres SQL database at GCP.
A Redis instance at GCP.
What I want to do is make a 'security group' sort of so that my Postgres SQL DB and Redis instance can only be accessed from my Node.js server and nowhere else. I don't want them to be publically accessible via an IP.
What we do in AWS is, that only services part of a security group can access each other.
I'm not very sure but I guess in GCP I need to make use of Firewall rules (not sure at all).
If I'm correct could someone please guide me as to how to go about this? And if I'm wrong could someone suggest the correct method?
GCP has firewall rules for its VPC that work similar to AWS Security Groups. More details can be found here. You can place your PostgreSQL database, Redis instance and Node.js server inside GCP VPC.
Make Node.js server available to the public via DNS.
Set default-allow-internal rule, so that only the services present in VPC can access each other (halting public access of DB and Redis)
As an alternative approach, you may also keep all three servers public and only allow Node.js IP address to access DB and Redis servers, but the above solution is recommended.
Security groups inside AWS are instance-attached firewall-like components. So for example, you can have a SG on an instance level, similar to configuring IP-tables on regular Linux.
On the other hand, Google Firewall rules are more on a Network level. I guess, for the level of "granularity", I'd say that Security Groups can be replaced to instance-level granularity, so then your alternatives are to use one of the following:
firewalld
nftables
iptables
The thing is that in AWS you can also attach security groups to subnets. So SG's when attached to subnets, are also kind of similar to google firewalls, still, security groups provide a bit more granularity since you can have different security groups per subnet, while in GCP you need to have a firewall per Network. At this level, protection should come from firewalls in subnets.
Thanks #amsh for the solution to the problem. But there were a few more things that were required to be done so I guess it'll be better if I list them out here if anyone needs in the future:
Create a VPC network and add a subnet for a particular region (Eg: us-central1).
Create a VPC connector from the Serverless VPC Access section for the created VPC network in the same region.
In Cloud Run add the created VPC connector in the Connection section.
Create the PostgreSQL and Redis instance in the same region as that of the created VPC network.
In the Private IP section of these instances, select the created VPC network. This will create a Private IP for the respective instances in the region of the created VPC network.
Use this Private IP in the Node.js server to connect to the instance and it'll be good to go.
Common Problems you might face:
Error while creating the VPC Connector: Ensure the IP range of the VPC connector and the VPC network do not overlap.
Different regions: Ensure all instances are in the same region of the VPC network, else they won't connect via the Private IP.
Avoid changing the firewall rules: The firewall rules must not be changed unless you need them to perform differently than they normally do.
Instances in different regions: If the instances are spread across different regions, use VPC network peering to establish a connection between them.
I am setting up EMR clusters on demand, and have a windows EC2 server as a workstation, and a linux EC2 server as a secondary server. All in the same VPC. I would like to avoid having to set security group rules each time an instances comes up with a new IP.
How would I simply allow any traffic to flow freely between all servers in the same VPC?
Thanks!
EDIT- Thanks for the replies, I know this is not good practice in production, but we are dealing with some issues tracking down functionality which we believe is caused by ports, this is just a exploration phase, and this will help us. Thanks!
In the security groups, assign incoming access to other security groups by specifying a security group ID instead of IP addresses. In the web console, if you start typing "sg" in the source field it will pop up a list of your security groups to choose from. Using a security group ID as the source allows all resources that belong to that security group to have access.
Alternatively, if you just want one rule that allows access to every resource in your VPC you would specify your VPC's IP range.
to Allow any traffic between ALL servers in the VPC is not a good practice.
you should rethink in your VPC purpose.
Any way, if you want a group of servers to communicate with each other you can create a Security Group
And Assign it for all servers that you want.
and in inbound rules you add one rule from type "All TCP" and the source of this rule will be the same Security Group.
if your Security Group ID is 'sg-xxxxxxxx'
then the rule will be like this:
All TPC | TCP | 0-65535 | custom | sg-xxxxxxxx
To add to the other answers here, if you really want this, you can set it up via the Subnet or VPC IP CIDR Block
For example, if your VPC is 10.0.0.0/16, then add that to your security groups and all VPC traffic should be able to flow to each other.
I have a t2.micro instance running, that is producing some data that needs to be written to a database. So, I created a RDS database with MySQL on it.
The issue I'm facing is, nonsurprisingly, getting the EC2 instance to communicate with the RDS database in any way/shape/form.
I'm been battling with it all day. I'm left with these bits of confusion:
I figured I've just add the public IP of the EC2 instance to the security group of the RDS. Turns out the RDS doesn't really have a security group, only a VPN. So how do I allow communication from the EC2 instance, then?
Speaking of security groups, do I need to se the EC2 up to require outbound connections?
The RDS has an 'endpoint' and not a public IP as far as I can tell. So I can't add it to any security group at all. Is this correct?
Am I going to have to figure out how to use Elastic Beanstalk or some other way to get these components to play together?
These are all the things I'm trying to troubleshoot but I'm not getting anywhere. There doesn't seem to be any good blogs / etc; mostly what I'm finding is stuff on how to get the RDS to be accessed by your local hardware, not an EC2 instance.
How should I set this up?
There are two ways to allow inbound connection to RDS database: CIDR/IP or EC2 security group.
You can go to VPC, at the left panel there is "Security Groups" (yes, RDS do have security group). Click that, and choose your DB security group (if you already have the RDS instance created) or create a new one.
Under connection type, choose either CIDR/IP or EC2 security group.
If you choose to go with CIDR/IP, you should know what IP address your EC2 instance is and put the address or range in e.g. "10.11.12.0/24".
If you choose to go with EC2 security group, you should know the security group nameof your EC2 instance and select it from the dropdown provided e.g. "my security group".
Please note that the EC2 instance and the RDS instance need to be able to "see" each other i.e. in the same region, VPC, subnets with proper NACL (network access control list) etc.
Speaking of outbound connection and security group, no, security groups only manage inbound connection.
Hope that helps, let me know if I can make my answer clearer.
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.