This is because servers in a private network don't have a public IP address, making it impossible to connect to them directly from the internet. With out, a user won’t be able to connect because it won’t be able to handle the encrypted session data.When you have a group of servers in a private network, it can be challenging to access them from the internet. This is needed for the EC2 instance to handle the user session encryption. This is the KMS arn that we set up when the SSM Document was configured.This is the arn of the bucket that we set up a little bit ago.Ī few variables are required here though: Won’t go into too much detail here, this is pulled primarily from the AWS documentation here.
BASTION EC2 CODE
The below code sets up the IAM Role that will be attached to the EC2 instance. Security group ingress + egress to secure the instance at the networking layer.AWS Autoscaling Group that manages the EC2 instance to more easily handle restarts.Custom AWS Launch Template to configure EC2 Instance.IAM Instance Profile based off the above IAM Role that is attached to the EC2 Instance.There is a lot to configure here, so let’s dive in and talk about what all is necessary. resource "aws_ssm_document" "session_manager_prefs" /*", Let’s see what this looks like using Terraform. If that is the case, the document will have to be imported into state, or deleted prior to using Terraform to manage the preferences. Due to this, there are effectively two different places to configure the same preferences! If doing this through Terraform, the document can be created, unless the preferences have been previously accessed through the AWS UI. This is a little confusing because if this is done through the UI, the document is lazily created the first time the preferences are accessed. To configure SSM Preferences, another document is also used. Context around the SSM Preferences Document Setting up a basic EC2 instance to be used as a jump boxĪWS SSM works on the notion of using different “documents”, which are effectively access profiles that can be used to do different things when tunneling with SSM.Cloudwatch can also be used, but this won’t be covered in this post.Setting up an S3 bucket for session logging.Using a KMS Key to encrypt user sessions.We’ll first cover setting up AWS Session Manager Preferences. Set up SSM to allow tunneling to an Aurora Postgres DB.Bonus: Set up an S3 bucket that is configured in a separate AWS account for optimal security.Configure session logging to keep track of any and all commands being used on the jump box.Set up a basic private EC2 instance to act as the jump box.Goals for this PostĪll of the goals below will utilize Terraform to set up the infrastructure.
BASTION EC2 FULL
The full code seen in this blog can all be found here. A jump box is still required, but we’re relying on AWS to be the source of authentication instead of SSH. Using a product like AWS SSM (no, this is not an advertisement), allows for using IAM Roles for authentication instead of having to manage SSH keys. This isn’t great for things like SOC2 or other general security audits. Unless the bastion host is behind a VPN, this results in port 22 (the common port for SSH) be exposed to the internet. We usually use this at Nucleus to access our staging database, and in rare instances, our production database. A common use-case for this is to tunnel into a database that is not publicly accessible to the internet. Bastion Hosts are typically used to provide authenticated access to private VPCs.
0 kommentar(er)
