- Automated process for applying security-level patches. Also allows you to apply non-security updates for Linux Instances.
- Option to “dry-run”, listing missing patches without applying them.
- Ability to set up patch baselines to describe rules for patching, such as how many days a patch needs to be out before auto approving, a list of patches you have approved and rejected, and sorting by EC2 tags or individually.
Previous Blogs You Can Refer to:
- Resetting SSH Key Access To Your EC2 Instance Through Systems Manager Automation
- Remove Port 22 From Your Security Groups For Good: Systems Manager’s Session Manager And Run Command Features
- Handling Hybrid Environments In AWS With The Systems Manager’s Agent
We will start off by going to the Systems Manager console. Under actions we will select Patch Manager, then select default patch baselines. NOT configure patching.
Amazon has several default patch baselines available for various operating systems, however we want to really see what’s involved in these so we’re going to create our own from scratch. Click Create Patch Baseline. Here we will provide a name, description and which OS we want to apply this to. We then have approval rules, as you see below with product, type of update, severity, how many days the patch needs to be out before auto approval, compliance, and we’ll also check to allow non-security updates.
The next section we can explicitly state which packages to approve or reject regardless of the Approval rules stated above. These are example packages so you can see the format and wildcard option. We can also select whether a rejected package can still be installed if it’s a dependency or not. As for the patch sources, we won’t be covering this, but more detail is available here in step 11. This would be used for Linux, where you have an alternative patch repository for different versions of the same OS. We can remove the patch sources, and click Create Patch Baseline.
After we have a batch baseline set up, we can configure this onto a few instances. We’ll manually select our Baseline and click Configure patching. For this go, we will manually apply this to the 4 Amazon Linux 2 instances we have running. However this can also be done with Tags, or by creating patch groups. This is very useful to make sure the correct instances are following the appropriate patch baselines, but not needed for this exercise.
Next we will set the patching schedule. We can either choose an existing maintenance window, create a new one based off Cron or Rate, or can opt to skip scheduling so that the task runs immediately. For the purpose of the blog we will choose the latter. The two options under Patching operation let us either both scan for instances that need patching and install any approved packages, while the second option will only scan and give us a list to review. We’ll be opting for Scan & Install. We can click Configure patching.
It will bring us to the next page with this green bar on the top of the screen. Click on View details.
We can see that all 4 instances completed their patching as expected here. We can click on any instance as we’ve done before and see the Step 1 – Output log.
You’ll notice this is truncated output, and there was nowhere to select an output when we made the patch baseline. We will solve this by using State Manager. We want to first make sure that the new patch baseline we created is the default for Amazon Linux 2, so we will navigate back to Patch Manager. Select our Test baseline, and in the top right, click actions > Set default patch baseline.
We simply need to go to Actions > State Manager and click Create an Association. Name it what you’d like, and we will select the AWS-RunPatchBaseline document. We can change Scan to Install under parameters. We can manually select targets, and specify a schedule. We’d recommend no schedule, so that you can test this quickly.
The very last option is Output options, here we will now have an options to select an S3 bucket and prefix to send our logs to. Finally we can select Create Association.
We’ll be met with this screen next.
We can click the Association ID in order to get some more details. Take a look around here, but eventually you’ll want to come back to the description tab, and click the S3 Output link to be taken to the log outputs, where you can view the stderr and stdout for each instance it ran on.
There’s a lot more that you can go back and customize with Patch Manager, but we feel you should have a decent understanding of the process and can tweak things to your business needs. For instance, once in production you’d likely want to set the maintenance manager to have AWS-RunPatchBaseline run daily or weekly at given times.
If you have questions or would like assistance with setting up AWS Systems Manager’s Patch Manger, feel free to reach out to BlueChipTek’s Cloud Services Team.