Monitor for public AWS Systems Manager custom documents with AWS Config rules

A new managed AWS Config rule is now available that checks if your AWS Systems Manager (SSM) documents have been shared publicly. This makes it easy to monitor your SSM document public sharing settings by leveraging a managed Config rule. This post demonstrates how to utilize detective controls and remediation actions for publicly shared SSM documents.

AWS Config has released a new managed rule that provides the ability to add an additional guardrail monitoring for any SSM documents that may have been shared publicly. Here is how it works: The rule is executed on a frequency of 1, 3, 6, 12, or 24 hours. When executed, it checks for any SSM documents owned by the account that are shared publicly. If it finds any publicly shared custom SSM documents, then those SSM documents will trigger noncompliance of the Config rule.

Detective monitoring for public SSM documents

To get started, you must add the new managed AWS Config rule (named SSM_DOCUMENT_NOT_PUBLIC) to your set of active rules in your AWS accounts. For more information on adding the rule to your accounts, see Working with AWS Config Managed Rules for console and AWS CLI. Once you have the new rule in place, note its name, as we will use it later.

Next, we will set up automated or manual remediation options when noncompliant SSM documents are discovered.

Remediation options for public SSM documents

If your detective monitoring finds that you have SSM documents that should not be shared publicly, then you can configure an automatic remediation of these documents via AWS Config. AWS Config rules can configure an automatic or manual remediation action for noncompliant rules. The execution of the Config remediation action is achieved via an SSM Automation runbook.

Several things can be done with these SSM Automation runbooks. You may want to create a Jira issue for further investigation, or you may choose to automatically disable the public sharing of the noncompliant SSM document. In this example, we will choose the latter and walk you through how to disable the public sharing of the noncompliant SSM document. To begin setting up the remediation, let’s create an SSM automation document. When executed, this document will disable the public sharing of the SSM document via an AWS API call to ModifyDocumentPermissions.

To create an SSM automation document (console)

1. Open the Systems Manager Documents console.
2. Under Create document, choose Automation.

Figure 1: Documents page in Systems Manager console

3. Enter a Name for the document (such as PublicDocumentConfigRemediation).

Figure 2: New automation document page

4. Select the Editor, and choose Edit to create a document with the following content:

description: Remove public permissions from an SSM Document
schemaVersion: '0.3'
assumeRole: '{{ AutomationAssumeRole }}'
parameters:
  DocumentName:
    type: String
    description: Name of the document to remove the public permissions settings
  AutomationAssumeRole:
    type: String
    description: (Optional) The ARN of the role that allows Automation to perform the actions on your behalf.
    allowedPattern: '^arn:aws(-cn|-us-gov)?:iam::\d{12}:role\/[\w+=,.@_\/-]+|^$'
mainSteps:
  - name: ModifyDocumentPermissions
    action: 'aws:executeAwsApi'
    description: Remove public permissions from the document
    inputs:
      Service: ssm
      Api: ModifyDocumentPermission
      PermissionType: Share
      Name: '{{ DocumentName }}'
      AccountIdsToRemove:
        - All

5. Choose Create automation

With the new AWS Config rule and the new SSM automation document are created, we must set the automation document as the Config rule remediation action.  In this blog post, we demonstrate how to attach the remediation document manually via the console to the Config rule.

Note: If you choose an automatic remediation option, then you’ll also need to have an IAM role with permissions for invoking the API calls within the runbooks. For the sample document above, the IAM role needs the ModifyDocumentPermissions permission.

To configure remediation for the new Config rule (console)

1. Open the AWS Config Rules console, and select your new Config rule for SSM_DOCUMENT_NOT_PUBLIC.
2. Under Actions, choose Manage remediation.

Figure 3: Manage Config rule remediation

3. Choose either Automatic remediation or Manual remediation.
4. Under Remediation action details, choose your remediation document created above (PublicDocumentConfigRemediation).
5. Under Resource ID parameter, choose DocumentName.
6. Under Parameters, for the AutomationAssumeRole value, enter the IAM Role ARN required to execute the document.

Figure 4: Remediation configuration settings

7. Choose Save changes.

You’ve now enabled a new detective control utilizing the new AWS Config rule to monitor for any publicly shared custom SSM documents in the region. And you’ve set up a remediation action for any noncompliant SSM documents which will remove the document from being shared publicly.

Conclusion

This post introduced you to the new SSM_DOCUMENT_NOT_PUBLIC AWS managed Config rule, and described how to set up detective monitoring in your AWS accounts for publicly shared SSM documents. When the Config rule detects noncompliance, we walked through how to setup a remediation action in order to remove the document from being shared publicly.

Consider adding this new Config rule in your AWS accounts in each operating region in order to provide an additional set of controls for your SSM documents. In order to enforce Config rules at scale across accounts and regions in your Organization, see automate configuration compliance at scale in AWS. For more information regarding other public SSM document best practices, see best practice considerations with using SSM document sharing and best practices for shared SSM documents.

About the authors