Lazy but Cautious: An all-inclusive AWS EC2 instance Cloudformation Template — Part 1
Develop fast, stay cautious!
New to EC2 and looking to learn how to provision a secure EC2 on AWS? A “lazy” cloud platform developer looking to save your time and effort? Simply hunting for answers on Google?
How is this Medium blog different from any other?
The idea is to highlight the best practices to keep in mind when developing AWS infrastructure as code. In this case, it’s the creating an EC2 instance. The practice of keeping cloud security in mind when developing makes you not only a good developer, but is central to the concept of zero trust architectures in AWS, at the very least.
The problem we’re solving is:
1. Create an EC2 instance which uses the latest Amazon Linux 2 AMI ID
2. Copies and runs a Python3 file stored in a S3 bucket at launch.
Constraint: Utilize Cloudformation to achieve this.
So go ahead, read on!
A (slightly elaborate) introduction:
- Security Groups
Security groups control the access that traffic has in and out of an EC2 instance. By default, network access is disabled for an EC2 instance. You can specify rules in a security group that allow access from an IP address range, port, or security group. Once ingress rules are configured, the same rules apply to all EC2 instances that are associated with that security group. You can specify up to 20 rules in a security group. ~~ AWS Documentation
Points to remember: Be EXTREMELY careful of the ingress rules. Allow access to specific CIDR blocks to specific ports only.
- IAM Roles (and EC2 Instance Profile)
IAM roles, instead of being uniquely associated with one person(IAM user) are assumable by any IAM identity which needs it.
IAM roles do not have standard long-term credentials such as a password or access keys associated with them. Instead, when you assume an IAM role, it provides you with temporary security credentials for your role session.
An EC2 instance profile is specific to when you want your IAM Role to be assumable by the EC2 service. To know more about IAM roles with EC2, read here.
Points to remember: Choose IAM Roles wherever possible.
- IAM Policy
Identity-based policies are permissions policies that you attach to an IAM identity, such as an IAM user, group, or role. They control what actions the identity can perform, on which resources, and under what conditions.
Identity-based policies can be further categorized:
a. Managed policies — Standalone identity-based policies that you can attach to multiple users, groups, and roles in your AWS account. You can use two types of managed policies:
-> AWS managed policies — Managed policies that are created and managed by AWS.
-> Customer managed policies — Managed policies that you create and manage in your AWS account.
Points to remember: These provide more control over your policies than AWS managed policies. For more information, see Creating IAM policies and Editing IAM policies.
b. Inline policies — Policies that you create and manage and that are embedded directly into a single user, group, or role.
Points to remember: Maintaining version control over inline policies is an overhead best avoided. Stick to Managed Policy when creating your custom policies.
- EC2 Keypair
A key pair, consisting of a private key and a public key, is a set of security credentials that you use to prove your identity when connecting to an instance.
Amazon EC2 stores the public key, and you store the private key. You use the private key, instead of a password, to securely access your instances.
Points to remember: If you plan to connect to the instance using SSH/RDP, you must specify a key pair.
- Amazon Machine Image (AMI)
An AMI provides the information required to launch an instance. You must specify an AMI when you launch an instance.
You can launch multiple instances from a single AMI when you need multiple instances with the same configuration. You can use different AMIs to launch instances when you need instances with different configurations.
Points to remember: Treat AMIs as the base OS + configs (packages you need pre-baked) for your EC2 instance. Be mindful of what you need.
Basic Security Concepts for EC2:
EC2 server misconfigurations can cost you and/or your organization a LOT if you are not careful. Treat building security into your code as a way to protect yourself AND others.
- Safeguard your EC2 keypair.
Anyone who possesses your private keys can connect to your instances, so it’s important that you store your private keys in a secure place. Do NOT share them on the public domain, upload them to Github repositories (especially public), or share them with untrusted personnel. One mistake is all it takes.
- Use only trusted AMIs.
AMIs can be Private or Public. Private AMIs are either created in your account or in another account and shared with your account. Make sure you don’t share untested, unverified AMIs with others. As for Public AMIs, make sure it’s from a trusted account, such Amazon/Ubuntu. Using a Public AMI, without knowing the account details, could result in ghastly results.
- Be careful of what subnet you put your EC2 instance in.
Depending on your use case, be mindful of where to put your EC2 instance. Once created, the subnet of an EC2 instance cannot be modified. Secondly, EC2 servers interacting with a database should ideally be kept in private subnets. Only public facing applications should be kept in the public subnet.
- Choose IAM roles with minimal permissions, if needed.
If your EC2 instance needs to interact with other services, or perform actions on specific AWS resources, ensure that you grant minimal IAM permissions. Unnecessary IAM permissions can result in unauthorized access, especially in case your EC2 instance gets compromised.
- Open port(s) only to specific IP address(es) in your security group.
Your security group ingress and egress rules should be explicitly clear on which IP addresses and be allowed in. Unless it’s a public facing application, do not open ports to the internet (0.0.0.0/0), especially when an EC2 instance is in the public subnet (Use a load balancer in such scenarios anyway). Make sure you grant access to only specific ports, not all, to reduce risks.
- Encrypt your EBS volumes.
EBS volumes attached to your EC2 instances should be encrypted at rest.
To know more about the details about how to create the Cloudformation template and its details, continue to Part 2 here.
Although the basic security concepts covered above will get you by, but for additional reading, about enhanced logging and monitoring, go ahead and read the AWS documentation!
Keep checking out the next parts in this series! Thanks for reading!