Configuration of SSM Patch Manager to create custom patch baselines and distribute patches to Windows instances
System Manager (SSM) Patch Manager is a function that automates the application of patches to EC2 instances.
This time, we will focus on Windows instances. In addition to the default AWS-DefaultPatchBaseline, we will create our own patch baseline (custom patch baseline) and run both to check the behavior of Patch Manager.
For more information on running SSM Patch Manager on a Linux instance (Amazon Linux 2), please refer to the following page.
Environment
Basically, the resources to be used are the same as in the Linux version.
In the Windows version, instead of a VPC endpoint, a NAT gateway is deployed to provide a route to access resources outside the VPC (System Manager and S3).
CloudFormation templates
We will build the above configuration using CloudFormation.
I Place the CloudFormation template file at the following URL.
https://github.com/awstut-an-r/awstut-soa/tree/main/04/003
Explanation of key points of templates
As mentioned earlier, many of the settings are the same as in the Linux version. In this page, we will only cover the unique aspects of the Windows version.
Prepare routes for Internet at NAT gateways instead of VPC endpoints
As mentioned earlier, NAT gateways and Internet gateways are used to route traffic to the Internet. This is due to the requirements in running the SSM Patch Manager against a Windows instance.
Windows Server managed nodes must be able to connect to the Windows Update Catalog or Windows Server Update Services (WSUS). Confirm that your nodes have connectivity to the Microsoft Update Catalog through an internet gateway, NAT gateway, or NAT instance.
Patch Manager prerequisites
In the Linux version, the requirement to run Patch Manager was met by creating VPC endpoints for SSM and S3. However, as mentioned above, for Windows instances, in addition to this, the requirement is to be able to access the Internet and connect to the Microsoft Update Catalog. Therefore, this time, we will deploy a NAT gateway so that the Windows instance in the private subnet can access the Internet, and the configuration will meet this requirement.
Key Points on Creating Custom Patch Baselines for Windows
The point is a custom patch baseline resource for Windows instances.
Resources:
MyPatchBaseline:
Type: AWS::SSM::PatchBaseline
Properties:
ApprovalRules:
PatchRules:
- ApproveAfterDays: 7
ComplianceLevel: UNSPECIFIED
EnableNonSecurity: false
PatchFilterGroup:
PatchFilters:
- Key: CLASSIFICATION
Values:
- CriticalUpdates
#- SecurityUpdates
- Key: MSRC_SEVERITY
Values:
- Critical
#- Important
Description: Test Patch Baseline.
Name: !Sub "${Prefix}-MyPatchBaseline"
OperatingSystem: WINDOWS
PatchGroups:
- !Sub "${Prefix}-patch-group"
Code language: YAML (yaml)Overall, it is the same as the Linux version, but the details are different.
First, specify the target OS for the patch baseline in the OperatingSystem property, and since this is for Windows, specify “WINDOWS”.
Next, in the Key property under the PatchFilters property, Severity, which indicates the degree of severity, is “MSRC_SEVERITY” for Windows, and “SEVERITY” for Linux.
The custom patch baseline that we will create this time will be created by modifying a part of the default AWS-DefaultPatchBaseline.
If you uncomment out, the configuration is the same as AWS-DefaultPatchBaseline.
Let’s organize the behavior when AWS-RunPatchBaseline is run in this configuration.
- Instance1: No tag (patch group) setting -> The default AWS-DefaultPatchBaseline is executed.
- Instance2: With tag (patch group) setting -> Custom patch group (MyPatchBaseline) will be executed.
Architecting
Using CloudFormation, we will build this environment and check its actual behavior.
Create CloudFormation stacks and check resources in stacks
Create a CloudFormation stack.
For more information on creating stacks and how to check each stack, please refer to the following page.
After checking the resources of each stack, the information of the main resources created this time is as follows
- Name of the bucket for log storage: soa-04-003
- ID of Instance1: i-0be0847252c5cf00e
- ID of Instance2: i-008140484431d4e33
- Custom Patch Baseline Name: soa-04-003-MyPatchBaseline
- ID of custom patch baseline: pb-0cc1eee728bf421b0
- Patch group for the custom patch baseline: soa-04-003-patch-group
Verify the custom patch baseline that has been created.
A rule has been created for Windows Server to approve only those patches whose critical updates are critical, and the Patch groups entry also shows that this baseline applies to the soa-04-003-patch-group. In the Patch groups section, you can also see that this baseline is applied to “soa-04-003-patch-group”.
Next, let’s check the tags assigned to the instances.
Only Instance2 has a Patch Group tag. You can see that the value of this tag is the same name as the patch group in the custom patch baseline that we just checked. This means that Instance2 belongs to the patch group.
Check results of Patch Manager execution
Now that we are ready, let’s check the results of the Patch Manager run, which can be viewed on the SSM Run Command page.
We can see that the Patch Manager has been successfully executed for two instances.
Next, let’s check the execution results for each instance. First, let’s check Instance1.
You can see that the default AWS-DefaultPatchBaseline has been run and the 28 patches have been applied.
Next, let’s check Instance2.
A custom patch baseline (soa-04-003-MyPatchBaseline) was run, but none of the patches were applied. It seems that none of the patches met this condition (critical update is a critical patch).
Finally, check the execution log. The logs will be placed in the specified bucket for each instance ID.
The above image shows the log of Instance1, but the execution log is placed as stdout.txt.
Let’s check the contents of the Instance1 execution log.
Preparing to download PatchBaselineOperations PowerShell module from S3.
Downloading PatchBaselineOperations PowerShell module from https://s3-ap-northeast-1.amazonaws.com/aws-ssm-ap-northeast-1/patchbaselineoperations/Amazon.PatchBaselineOperations-1.33.zip to C:\ProgramData\Amazon\SSM\InstanceData\i-0be0847252c5cf00e\document\orchestration\a84181fe-a330-4d8d-abf1-fdd49a6f4a61\PatchWindows\Amazon.PatchBaselineOperations-1.33.zip.
Extracting PatchBaselineOperations zip file contents to temporary folder.
Verifying SHA 256 of the PatchBaselineOperations PowerShell module files.
Successfully downloaded and installed the PatchBaselineOperations PowerShell module.
Patch Summary for i-0be0847252c5cf00e
PatchGroup :
BaselineId : pb-04ba050f612fba3a6
Baseline : {"AccountId":"486716784251","BaselineId":"pb-04ba050f612fba3a6","Name":"AWS-DefaultPatchBaseline","GlobalFilters":{"Filters":[{"Key":"PRODUCT","Values":["*"]}]},"ApprovalRules":{"Rules":[{"ApproveAfterDays":7,"FilterGroup":{"Filters":[{"Key":"CLASSIFICATION","Values":["CriticalUpdates","SecurityUpdates"]},{"Key":"MSRC_SEVERITY","Values":["Critical","Important"]}]}}]},"ApprovedPatches":[],"RejectedPatches":[],"RejectedPatchesAction":"ALLOW_AS_DEPENDENCY","CreatedTime":1525327437.876,"ModifiedTime":1525327437.876,"Description":"Default Patch Baseline Provided by AWS."}
SnapshotId : 936681b3-6848-40e0-932a-87557809dd23
ExecutionId : a84181fe-a330-4d8d-abf1-fdd49a6f4a61
RebootOption : RebootIfNeeded
OwnerInformation :
OperationType : Install
OperationStartTime : 2022-01-22T11:19:01.0000000Z
OperationEndTime : 2022-01-22T11:43:08.5621334Z
InstalledCount : 28
InstalledRejectedCount : 0
InstalledPendingRebootCount : 0
InstalledOtherCount : 9
FailedCount : 0
MissingCount : 0
CriticalNonCompliantCount : 0
SecurityNonCompliantCount : 0
OtherNonCompliantCount : 0
NotApplicableCount : 1885
UnreportedNotApplicableCount : 0
EC2AMAZ-JNT8FVJ - PatchBaselineOperations Installation Results - 2022-01-22T11:43:09.077
KbArticleId Installed Message
----------- ----------- -----------
KB5009557 Yes Success
KB5009718 Yes Success
Code language: plaintext (plaintext)You can check the details of the patch application.
Summary
Using SSM Patch Manager, we confirmed that we can deliver patches to EC2 instances (Windows).
By creating and running a custom patch baseline in addition to the default AWS-DefaultPatchBaseline, we confirmed how to check the patch application results and the log output status.