Beware The AWS Managed Policy

What is that AWS managed policy you are told to use really doing?

Elliott Gorrell

3 minute read

Let use AWS SSM!

In the team I am currently working in we have AWS SSM installed on our fleet of roughly 100 machines spanning 3 environments. For those who don’t know AWS Systems Manager (SSM) is a tool which allows you to automate tasks, check configuration and perform patching across a fleet of servers (Basically a real simple version of a Chef, Puppet, Ansible Tower type of tool). We are using SSM as we currently have a lot of pets in our fleet :(… I know I know, “PETS! run for the hills” but sometimes you can’t avoid this without huge engineering effort, especially when working with IBM software. There is some work about to be undertaken to deploy a chef server and so this will eventually phase out our use of SSM, however in the meantime this tool is incredibly easy to set up and does what we need to stay on track.

Today the team noticed some instances were not registering themselves to the SSM service correctly. As part of the troubleshooting a team member and I thought the IAM role might not contain the AWS managed policy AmazonEC2RoleforSSM which gives the instance permissions to talk to the SSM API in your account. That turned out not to be the problem in the end but we did end up having a look at what permissions this policy contained and we were quite shocked to see what was awarded to all our boxes with this attached.


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ssm:DescribeAssociation",
                "ssm:GetDeployablePatchSnapshotForInstance",
                "ssm:GetDocument",
                "ssm:GetManifest",
                "ssm:GetParameters",
                "ssm:ListAssociations",
                "ssm:ListInstanceAssociations",
                "ssm:PutInventory",
                "ssm:PutComplianceItems",
                "ssm:PutConfigurePackageResult",
                "ssm:UpdateAssociationStatus",
                "ssm:UpdateInstanceAssociationStatus",
                "ssm:UpdateInstanceInformation"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "ec2messages:AcknowledgeMessage",
                "ec2messages:DeleteMessage",
                "ec2messages:FailMessage",
                "ec2messages:GetEndpoint",
                "ec2messages:GetMessages",
                "ec2messages:SendReply"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "cloudwatch:PutMetricData"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "ec2:DescribeInstanceStatus"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "ds:CreateComputer",
                "ds:DescribeDirectories"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "logs:CreateLogGroup",
                "logs:CreateLogStream",
                "logs:DescribeLogGroups",
                "logs:DescribeLogStreams",
                "logs:PutLogEvents"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:AbortMultipartUpload",
                "s3:ListMultipartUploadParts",
                "s3:ListBucket",
                "s3:ListBucketMultipartUploads"
            ],
            "Resource": "*"
        }
    ]
}

There is alot of worryingly liberal permissions given here such as the ability to create computers in an Active Directory Service, and look at and put to any logstream in Cloudwatch. The one that really made us gasp however was the s3 permissions - any of the boxes could get or put to anything in S3. This means sensitive files could be downloaded and files can be tampered with and overwritten.

Your S3 buckets probably should also be getting locked down at the bucket policy level however more often then not this is not the case in most AWS accounts I have seen. Motto of the story kids is check what a managed policy gives before blindly applying it, might be best to make your own, or maybe it will spark a constructive conversation about the practices around access in your AWS account.

comments powered by Disqus