In an enterprise environment, you may have broader groups and scopes that dictate access, so be cautious: It is somewhat easy to over-provision access with this method. You should also build a tightly scoped IAM role for this instance. Let's build that EC2 instance and leverage SSM on it. But we haven't actually created that server yet, so let's do that next. We're done with the SSM setup and automation creation now! Any servers tagged with with ShouldEcho = True will now have our Echo script run on them every 5 minutes. "Hello World from the maintenance window!" The task will link the targets to a window, and execute the document within the window schedule. EchoTargets:ĭescription: Add our server into the maintenance windowįinally, we will tie this all together with a task. We don't have to use tags, but I find it a simple way to group servers into sets based on automation documents targeting their risk level, OS, or something else. Here, it is based on tags specifically created for this task. Then, I create a grouping to execute the script on target instances. ![]() Schedule: cron(*/5 * * * ? *) # Every 5 mintues for this test. For testing purposes, I want this to be run every 5 minutes: EchoWindow:ĭescription: Run Echo documents - our sample automation Next we will create a maintenance window that defines how frequently and when this should be run. A real document might check security agents, setup logging, or hardening attributes." EchoDocument:ĭescription: "Just echo's into a file - to show how SSM works. In the past I have used this method to install or verify installation of security agents, setup logging, audit software, and more.įirst we will create a Document, which defines a single parameter and our shell script (a couple of echo commands). Since I am using a shell script in this example, you could modify this template to do anything on the server. To keep the example simple, we will write an Echo automation, which accepts a parameter and echos it into a local text file on the server. 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. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |