![]() Now that we have SSM available for instances, let's create a sample script that we would like to run on a regular basis across all our EC2 instances. I am using a managed policy for simplicity, but I recommend creating your own policy with limited permissions instead, as most managed policies are too permissive. arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore Here is a CloudFormation snippet to create an instance profile and a role that allows the EC2 instance to leverage SSM: SSMProfile:ĭescription: Basic SSM permissions for EC2 An SSM agent installed and running on the EC2 instance.A Role that can assume permissions for SSM tasks.An Instance profile we can attach to EC2 instances.In order to leverage SSM, we need a few things: The full CloudFormation template for deploying a SystemsManager enabled instance with a sample automation document can be found on my GitHub. The templates shown in this article don't depend on other templates in my Advanced AWS security architecture series, but you might be interested in reading the first article before taking on this one. In this article, we'll be walking through an initial SSM setup, testing SSH to an EC2 instance along with a tunnel to RDS, and then configuring automated patching and security checks for that instance. Full SSH session logging is simple to enable (I actually recommend disabling this unless you really need it to avoid storing sensitive information in these logs).Enforced security standards on OS level hardening or agent installs.We can also pick up a couple of extra security goodies when moving to systems manager: In 2019, AWS announced tunneling support for SSH and SCP with Systems Manager, meaning that Bastion hosts can be replaced for most use cases. While this method is good because it reduces the attack surface area and gives a single point of control, it also increases overall cost of maintenance and results in a pretty risky server. Sometimes, the bastion host is used to tunnel to databases or other more sensitive ports as well, though I generally prefer to chain SSH -> bastion -> application server -> DB/etc. A dedicated "bastion" server is provisioned with SSH ports exposed to an internal network, or in some cases the internet, so that other servers do not have to expose their own SSH ports. When I first started using AWS environments, the Bastion architecture was prevalent as the way to setup SSH connections.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |