This is not the Access Policy you’re looking for

by Mike Saunders

The AWS ReadOnlyAccess policy might be providing more access than you’re intending to grant. On a recent assessment, we observed widespread use of IAM roles with the ReadOnlyAccess policy (arn:aws:iam::aws:policy/ReadOnlyAccess) attached. The client’s intent was to allow what you’d expect – read-only access to their AWS organization. What we found was access that went beyond their understanding of read-only. In this blog, we’ll take a look at what this policy actually lets you do.

 

The ReadOnlyAccess Policy

Read-only access might not seem like a bad deal. You want to provide read-only access to a set of users and AWS provides a convenient policy for you to use. As shown in the screenshot below, AWS’ own documentation states explicitly that the ReadOnlyAccess policy provides read-only access to all existing and future services. You can’t edit AWS managed policies. That means that you’re explicitly granting access to any service you’re already using and any you might use in the future. You have change control? AWS has a bypass for that.

 

 

What’s the big deal?

In my opinion, AWS read-only access is commonly misunderstood. In many cases, ViewOnlyAccess may be the only access one needs. This is what AWS has to say about ViewOnlyAccess

This user can view a list of AWS resources and basic metadata in the account across services. The user cannot read resource content or metadata that goes beyond the quota and list information for resources.

ReadOnlyAccess, on the other hand allows “read-only access to every resource in an AWS account.” In other words, ViewOnlyAcess allows access to metadata only. ReadOnlyAccess grants access to the data itself. In some cases, even the control plane.

At this point you might be thinking “yes, Mike, I want to give read-only access to my users.” Let’s take a look at what a user with read-only access can actually do.

 

Not so secret secrets

You have secrets stored in Secrets Manager, so you’re safe… right? Here are some other places you may be storing secrets that you didn’t consider.

EC2

Consider Elastic Compute Cloud, or EC2. With ReadOnlyAccess, you’re probably not intending to allow people to access your EC2 instances. But can they? Security groups and firewall rules aside, let’s imagine you have Windows EC2 instances that are accessible. When Windows EC2 instances are launched, the local Administrator password is encrypted with the public key of a key pair specified at launch. The password can be retrieved by calling ec2:GetPasswordData. ReadOnlyAccess conveniently grants ec2:Get*, which means the password can be retrieved by any user with ReadOnlyAccess! The only way to prevent this is attaching a policy that explicitly denies ec2:GetPasswordData.

Systems Manager

The boundary drawn by AWS in the policy is instructive. ReadOnlyAccess excludes secretsmanager:GetSecretValue, instead granting only secretsmanager:Describe*, secretsmanager:List*, and secretsmanager:GetResourcePolicy, on the basis that secret values are not appropriate for a read-only role. However, the policy includes ssm:Get*. This action returns Systems Manager (SSM) parameter values including cleartext String and encrypted SecureString values. Sensitive material placed in Parameter Store rather than Secrets Manager receives weaker protection from this policy.

During our assessment, we encountered instances of passwords for Relational Database Services (RDS) instances stored as SecureString parameters in the SSM Parameter Store. But wait, didn’t I just say that SecureStrings are encrypted? Isn’t encryption a KMS (Key Management Service) function?

The ReadOnlyAccess policy doesn’t grant access to kms:Decrypt. Per AWS, “Parameter Store encrypts the values using AWS Key Management Service.” Read that again. “Parameter Store encrypts the values using AWS Key Management Service.” Data stored in SecureStrings is encrypted using AWS’ KMS, not the customer-managed KMS. That means that any user with ReadOnlyAccess can read any “secret” data stored in Parameter Store SecureStrings with ssm get-parameter.

Elastic Container Registry

Another place secrets are commonly stored is the Elastic Container Registry, or ecr. Secrets like API keys, encryption keys, and more, are commonly stored in configuration blobs for container images. The ReadOnlyAccess policy provides the following ECR actions: ecr:BatchGet*, ecr:Describe*, ecr:Get*, and ecr:List*. Users with ReadOnlyAccess can list repositories with ecr describe-repositories. They can then review individual images with ecr describe-images. At this point, they have an image name and associated image tags.

With this information, the user can use ecr batch-get-image to retrieve the image manifest and make note of the image digest. The user can then use ecr get-download-url-for-layer --repository-name <repo name> --layer-digest <sha256:…> --query downloadUrl to get the download URL for the configuration blob of the image. They can now download the configuration blob and retrieve any secrets that are stored there. They can also pull down the file system layers and review them for additional secrets that may be hard-coded in the image.

Users with ReadOnlyAccess can also call ecr get-login-password to retrieve a login password that can be used to run your containers with Docker.

Lambda

The ReadOnlyAccess policy grants access to lambda:Get* and lambda:list*. With this, users can list available Lambda functions with lambda list-functions and retrieve function code with lambda get-function. While they shouldn’t be stored there, if there are secrets in function code, any user with ReadOnlyAccess can retrieve them.

 

But wait, there’s more!

We’ve covered just a couple of services that may disclose more information than you’re comfortable with to ReadOnlyAccess users. There are likely many more examples I could show of how this policy provides greater access than what you might intend. As of September 2026, AWS has more than 200 services. Because any new service is automatically added to the ReadOnlyAccess policy, the potential exposure is only going to grow. The only way it gets smaller is if AWS starts cutting services or they change their approach to how ReadOnlyAccess is built.

 

What can you do?

AWS recommends using AWS managed policies as a starting point, not operational policies. You can grant the majority of access provided by ReadOnlyAccess by copying the ReadOnlyAccess policy and creating a new policy based on it. Start by copying the policy to a new policy document
aws iam get-policy-version --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess --version-id <default-version-id> --query PolicyVersion.Document > readonly-baseline.json

Modify the new policy document and remove the following actions:

• ssm:Get*
• ec2:GetPasswordData
• ecr:BatchGet*
• ecr:Get*
• s3:Get*
• lambda:Get*

Then, install the new policy:
aws iam create-policy --policy-name ReviewerReadOnly --policy-document file://readonly-baseline.jso

You can now attach the policy to any roles or principals that need more than ViewOnlyAccess. Be advised that this only fixes access for issues we discussed in this blog. There may be other actions that you want to consider removing from the policy. If you make a copy of the ReadOnlyAccess policy in the future after this blog was written, there may be new services that you want to consider removing from your copied policy.

---

About Principal Security Consultant Mike Saunders

Mike Saunders is Red Siege Information Security’s Principal Consultant. Mike has over 25 years of IT and security expertise, having worked in the ISP, banking, insurance, and agriculture businesses. Mike gained knowledge in a range of roles throughout his career, including system and network administration, development, and security architecture. Mike is a highly regarded and experienced international speaker with notable cybersecurity talks at conferences such as DerbyCon, Circle City Con, SANS Enterprise Summit, and NorthSec, in addition to having more than a decade of experience as a penetration tester. You can find Mike’s in-depth technical blogs and tool releases online and learn from his several offensive and defensive-focused SiegeCasts. He has been a member of the NCCCDC Red Team on several occasions and is the Lead Red Team Operator for Red Siege Information Security.

Certifications:
GCIH, GPEN, GWAPT, GMOB, CISSP, and OSCP