SSM Policy for Instances Assumed to Be Compromised

Question

If I wanted to apply a very limited custom SSM policy to instances that were assumed to be compromised, what could I remove from the `AmazonSSMManagedInstanceCore` managed policy? The basic need is to be able to patch the instance, run commands, change a configuration (e.g. local config file), and initiate a remote session.

Accepted Answer

In order to patch instances, run commands, change a configuration and initiate a remote session, you would need to retain the following permissions from the AmazonSSMManagedInstanceCore policy:

* ssm:DescribeAssociation
* ssm:GetDeployablePatchSnapshotForInstance
* ssm:GetDocument
* ssm:DescribeDocument
* ssm:GetManifest
* ssm:GetParameter
* ssm:GetParameters
* ssm:ListAssociations
* ssm:PutInventory
* ssm:PutComplianceItems
* ssm:PutConfigurePackageResult
* ssm:UpdateAssociationStatus
* ssm:UpdateInstanceAssociationStatus
* ssm:UpdateInstanceInformation
* ssmmessages:CreateControlChannel
* ssmmessages:CreateDataChannel
* ssmmessages:OpenControlChannel
* ssmmessages:OpenDataChannel
* ec2messages:AcknowledgeMessage
* ec2messages:DeleteMessage
* ec2messages:FailMessage
* ec2messages:GetEndpoint
* ec2messages:GetMessages
* ec2messages:SendReply

You could remove permissions that grant broader access to other SSM resources or functionalities that are not needed in a compromised instance situation. For example, you could probably remove permissions like ssm:ListInstanceAssociations or ssm:ListComplianceItems.

SSM Policy for Instances Assumed to Be Compromised

Relevant content