I have an Amazon EC2 instance and a corresponding RDS instance that I want to keep private. I'd like to keep it so that only myself and the sysadmin can access these instances. I don't want to provide access to other developers.
However, one of my developers is working on a project right now where he needs to create/configure his own EC2/RDS instance. I could have my sysadmin perform this work, but I'd rather have the developer do it for the sake of expediency.
Is there any way to configure a group/role/policy in a way that allows me to keep my current instances private from the new developer, but would allow him to create his own EC2 and RDS instances?
Your question appears to be mixing several security concepts, such as 'private', 'group/role/policy' and 'firewalls'.
An Amazon EC2 instance has several layers of security:
First, there is the ability to login to the EC2 instance. This is managed by you, typically by creating users on the instance (in either Linux or Windows) and associating a password or Public/Private. Only people who have login credentials will be able to access the instance.
Second, there is the ability to reach the instance. Security Groups control which ports are open from which IP address range. Therefore, you could configure a security group to only make the instance accessible from your own IP address or your own private network. Your instance might also be in a private subnet that has no Internet connectivity. This again restricts access to the instance.
A person can therefore only login to an instance if they have login credentials, if the security group(s) permit access on the protocol being used (RDP or SSH) and if the instance is reachable by the user from the Internet or private network.
Similarly, an Amazon Relational Database Service (RDS) instance is protected by:
Login credentials: A master user login is created when the database is launched, but additional users can be added via normal CREATE USER database commands
Security Groups: As with EC2 instances, security groups control what ports are open to a particular range of IP addresses
Network security: As with EC2 instances, an RDS instance can be placed in a private subnet, which is not accessible from the Internet.
Please note that none of the above controls involve Identity and Access Management (IAM) users/groups/roles/policies, which are used to grant access to AWS services, such as the ability to launch an Amazon EC2 instance or an Amazon RDS instance.
So, the fact that you have existing Amazon EC2 and Amazon RDS instances has no impact on the security of any other instances that you choose to launch. If a user cannot access your existing services, then launching more services will not change that situation.
If you wish to give another person the ability to launch new EC2/RDS instances, you can do this by applying an appropriate policy on their IAM User entity. However, you might want to be careful about how much permission you give them, because you might also be granting them the ability to delete your existing instances, change the master password, create and restore snapshots (thereby potentially accessing your data) and change network configurations (potentially exposing your instances to the Internet).
When granting IAM permissions to somebody, it is recommend that you grant least privilege, which means you should only give them the permissions they need and nothing more. If you are unsure about how much permission to give them or how to configure these permissions, you would be wise to have your System Administrator create the instances on their behalf. That way, you are fully aware of what has been done and you have not potentially exposed your systems.
Ok, the best explanation about how things works is in #John Rotestein response. But here a few practical suggestions (that must be considered as an complement to John's response):
You can create separate subnets and give permissions to your
developers to run instances in only one of the the subnets using IAM
Policies; But your developers still can reach your instance and you
must configure so/db/application restrictions.
If your company DO NOT use a shared gateway to the internet, you can
define the Network ACL to limit the access to your exclusive network
using your IP address. If you use a shared gateway, you will not be
able to use this solution;
In the second case, one way to limit the access is put your instance
in a private subnet and create a bastion host in your public subnet
to be used only by you (this solution must be configured to your RDS
instances too). The bastion host will be reachable by your
developers, but you can use a specific Key Pair that only you have
access. Just keep in mind that your instances and RDS will not be
available to the internet;
But I think that the simple solution would be create different
VPC's, one for your team and the other for the development team. In
this solution you can restrict access to all VPC resources to your
developers in the "main" VPC. Off course this also means no internet connection to your instances.
Related
I was talking to one of my friends on talk on API access. So let us say I have given one AWS account read-only access to my resources, say ec2. And that account tries to scan all the metadata for my ec2 instances. Per my friend, this API call belongs control plane and connects to the AWS API ec2 endpoint over the internet. As per him, this call can not be blocked by any number of VPC controls like NACLs/Security Group, etc. As per him, any data plane calls only goes to VPC. I was kind of agree but still not very convinced that scanning ec2 instances call like listing all instances can not be blocked ..say I have given read-only permission and still wants to block that account ...so is this true that VPC controls do not project that call further. Please help me to understand better ...in case I am in my corporate network and my consuming account, which wants to scan my ec2 instances if SAAS provider.
The Amazon EC2 service is responsible for creating and managing Amazon EC2 instance, VPCs, networking, etc. The API endpoint for the EC2 service reside on the Internet. Permission to make API calls is controlled by AWS Identity and Access Management (IAM).
This is totally separate to the ability to connect to an Amazon EC2 instance. Any such connections would go via a virtualized network VPC.
For example, imagine an Amazon EC2 instance that is turned off (that is, in a Stopped state). There are no actual resources assigned to a Stopped instance -- it is just some metadata sitting in a database. It would not be possible to 'connect' with this instance because it does not exist. However, it would be possible to connect to the AWS EC2 service and issue a command to Start the instance. This API call is made via the Internet and does not require any connectivity to the VPC.
Your wording that "any data plane calls only goes to VPC" is not correct -- the calls go to the EC2 service and do not involve the VPC. The VPC is purely a network configuration that determines how resources can communicate with each other.
I understand that it is a long upheld tradition to put your database servers in a private subnet and use a bastion host to access them as needed. But thinking specifically about cloud architecture, does that setup really make sense anymore?
What I am struggling to understand is why a publicly-accessible EC2 instance, that connects to my RDS servers, is more secure than a publicly accessible RDS instance that implements IAM Database Authentication? In both cases, I would use Security Groups to limit incoming connections.
I am using PostreSQL, and according to AWS documentation, enabling IAM authentication will enforce IAM credentials ( whereas for MySQL, I think password authentication will still work).
So is a bastion host really more secure than IAM Authentication and why?
The best security has multiple layers of security. For example, if an ex-staff member has credentials to the database, can they access it from outside of your corporate network? Or if somebody gains access to your bastion, can they also obtain access to the database?
So, yes, it could be considered safe enough to use authentication and to limit access to a specific IP address. It all depends upon your Risk Appetite. If the database contains confidential information that would be highly embarrassing for your company if exposed, then the additional layers of security can be worthwhile.
i have more than 30 production Windows severs in all AWS regions. I would like to connect all servers from one base bastion host. can any one please let me know which one is good choice? How can i setup one bastion host to communicate all servers which is different regions and different VPC's? Kindly anyone give advice for this?
First of all, I would question what are you trying to achieve with a single bastion design? For example, if all you want is to execute automation commands or patches it would be significantly more efficient (and cheaper) to use AWS System Manager Run Commands or AWS System Manager Patch Manager respectively. With AWS System Manager you are getting a managed service that offers advance management capabilities with highest security principles built-in. Additionally, with SSM almost all access permissions could be regulated via IAM permission policies.
Still, if you need to set-up bastion host for some other purpose not supported by SSM, the answer includes several steps that you need to do.
Firstly, since you are dealing with multiple VPCs (across regions), one way to connect them all and access them from you bastion's VPC would be to set-up a Inter-Region Transit Gateway. However, among other, you would need to make sure that your VPC (and Subnet) CIDR ranges are not overlapping. Otherwise, it will be impossible to properly arrange routing tables.
Secondly, you need to arrange that access from your bastion is allowed in the inbound connections of your target's security group. Since, you are dealing with peered VPCs you will need to properly allow your inbound access based on CIDR ranges.
Finally, you need to decide how you will secure access to your Windows Bastion host. Like with almost all use-cases relying on Amazon EC2 instances, I would stress to keep all the instances in private subnets. From private subnets you can always reach the internet via NAT Gateways (or NAT Instances) and stay protected from unauthorized external access attempts. Therefore, if your Bastion is in private subnet you could use the capability of SSM to establish a port-forwarding session to your local machine. In this way, you enable yourself the connection while even your bastion is secured in private subnet.
Overall, this answer to your question involves a lot of complexity and components that will definitely incur charges to your AWS account. So, it would be wise to consider what practical problem are you trying to solve (not shared in the question)? Afterwards, you could evaluate if there is an applicable managed service like SSM that is already provided by AWS. In the end, from a security perspective, granting access to all instances from a single bastion might not be best practice. If you consider scenarios in which you bastion is compromised for whatever reason, you basically compromised all of your instances across all of the regions.
Hope it gives you slightly better understanding of your potential solution.
currently working with two environments/account.
Dev and staging
We are paling to spin up a new instance to install Jenkins for CI/CD in dev environment.
We are also wondering if we can use the same instance which is in dev as a CI/CD for staging account as well.
How will access work?
How can the CI/CD instance access the instances in stating for CI/CD?
Do we need to set up a cross-account role for this which allowed dev CI/CD to access the stating instances?
or
the private key is enough to have access to EC2 irrespective of account?
You can definitely enable this. Take a look at VPC peering.
This features enables 2 VPCs whether different account or different region, to connect to each other as there networks become connected via a tunnel between.
When you implement this the following factors are important:
No cross over of CIDR ranges within VPCs
The VPC peering connection must be added to the route table(s) in both VPCs allowing them to know how to connect to the other VPC.
You will need to whitelist in security groups to allow access fro the instances that you want to be able to connect.
By doing this you also benefit from any network connections traversing the AWS backbone rather than across the public internet which will lead to improvements for security and performance.
I am creating infrastructure for one of my web application on AWS. That app needs Mysql RDS instance. Now I am wondering that whether I should simply create RDS instance in public subnet and just change its settings to Publicly Accessible=No, or I will have to create this RDS instance in private subnet for better security or something. I am confused that whether any of above option will provide better security than other.
I have also read that simply assigning security group to instance will act as firewall, so I can have publicly accessible=true RDS instance and its security group allowing access only from my application EC2 instance. So basically I have three options mentioned below.
Publicly Accessible = True RDS instance in public subnet with security group allowing access only to EC2 application instance.
Publicly Accessible = False RDS instance in public subnet.
RDS instance in private subnet.
Can anyone explain pros and cons in terms of security for above approaches?
You are correct that Security Groups can provide sufficient protection for your database, and also for Amazon EC2 instances.
So why does AWS provide public/private subnets? It's because many customers want them because that is how enterprises typically organise their network prior to using the cloud. Traditional firewalls only act between subnets, whereas Security Groups apply to each instance individually.
So, if you understand how to correctly configure Security Groups, there is no actual need to use Private Subnets at all! Some people, however, feel more comfortable putting resources in private subnets because it provides an additional layer of security.