Try GreenOps Scan Safely: Create a Read-Only AWS Profile First

A five-minute setup that guarantees the scanner can't touch anything

Running a third-party tool against your AWS account raises a fair question before you type a single command: what can it actually do with my credentials?

With GreenOps Scan the honest answer should be "nothing but read." But you do not have to take that on faith. AWS lets you create a dedicated IAM user or role that is technically incapable of making changes — no write, no delete, no configuration changes, anywhere. If you attach only ReadOnlyAccess to the credentials you scan with, there is no policy misconfiguration or bug in the scanner that could put your infrastructure at risk.

This post walks through creating that profile with the AWS CLI, so you can try npx greenops-scan with full confidence.

Why a dedicated profile instead of your existing one

Your day-to-day AWS CLI profile is probably tied to broad permissions you use for real work — deploying, provisioning, tagging, cleaning up. Even if you trust the tool, reusing that profile means the blast radius of any mistake (yours, the tool's, or a future dependency's) is as large as your normal permissions.

A dedicated read-only profile:

• can be created and deleted in minutes
• is scoped with an AWS-managed policy, not something you have to write and audit yourself
• makes the guarantee "this can't change anything" enforced by IAM, not by trusting the tool's code
• can be reused later for any other inspection tool, dashboard, or audit script

Step 1: Create an IAM user for scanning

aws iam create-user --user-name greenops-scan-readonly

This creates a new IAM user with no permissions attached yet.

Step 2: Attach the AWS-managed ReadOnlyAccess policy

aws iam attach-user-policy \
  --user-name greenops-scan-readonly \
  --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess

ReadOnlyAccess is an AWS-managed policy (you don't own or maintain it — AWS does) that grants Describe*, Get*, List*, and similar read-only actions across services, while explicitly excluding any action that creates, modifies, or deletes a resource. It's the same policy GreenOps' own cross-account scanner role uses for continuous monitoring.

Do not attach any additional policies to this user. The whole point is that this identity has exactly one capability: reading.

Step 3: Create an access key for the user

aws iam create-access-key --user-name greenops-scan-readonly

The output looks like this — copy the AccessKeyId and SecretAccessKey, since the secret is only shown once:

{
  "AccessKey": {
    "UserName": "greenops-scan-readonly",
    "AccessKeyId": "AKIAEXAMPLE1234567",
    "Status": "Active",
    "SecretAccessKey": "abcdEXAMPLEsecretkeyvaluexxxxxxxxxxxxxxxx",
    "CreateDate": "2026-08-13T09:00:00Z"
  }
}

Step 4: Add the credentials as a new local AWS CLI profile

Rather than overwriting your default profile, add a named profile — call it something obvious like greenops-readonly:

aws configure --profile greenops-readonly

You'll be prompted for:

AWS Access Key ID [None]: AKIAEXAMPLE1234567
AWS Secret Access Key [None]: abcdEXAMPLEsecretkeyvaluexxxxxxxxxxxxxxxx
Default region name [None]: eu-west-1
Default output format [None]: json

This writes the profile into ~/.aws/credentials and ~/.aws/config, alongside — not over — any existing profiles.

Step 5: Verify the profile actually has read-only access (and nothing more)

Confirm the identity resolves correctly:

aws sts get-caller-identity --profile greenops-readonly

Then confirm it can read, as expected:

aws ec2 describe-instances --profile greenops-readonly --region eu-west-1

And confirm it genuinely cannot write. Try something harmless but mutating, like creating a tag or a security group, and expect an UnauthorizedOperation / AccessDenied error:

aws ec2 create-tags --profile greenops-readonly \
  --resources i-0123456789abcdef0 \
  --tags Key=test,Value=should-fail

Expected output:

An error occurred (UnauthorizedOperation) when calling the CreateTags operation:
You are not authorized to perform this operation.

If that call fails with an authorization error, the profile is doing exactly what it should.

Step 6: Run GreenOps Scan against the read-only profile

Now you can run the scanner with full confidence that it is structurally unable to change anything in your account:

npx greenops-scan --profile greenops-readonly --region eu-west-1

Or omit the flags and let the interactive prompt list your available profiles, including greenops-readonly, so you can pick it explicitly each time.

GreenOps Scan itself only ever calls read-only AWS APIs (Describe*, Get*, List*) — see how GreenOps Scan handles credentials for more on that design. Pairing that behavior with a profile that is incapable of anything else gives you two independent layers of protection instead of one: the tool's own design, and IAM's enforcement.

Cleaning up afterwards

If you only wanted to try the CLI once, you can safely remove the user when you're done:

aws iam detach-user-policy \
  --user-name greenops-scan-readonly \
  --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess

aws iam list-access-keys --user-name greenops-scan-readonly
aws iam delete-access-key --user-name greenops-scan-readonly --access-key-id AKIAEXAMPLE1234567

aws iam delete-user --user-name greenops-scan-readonly

And drop the corresponding profile block from ~/.aws/credentials and ~/.aws/config if you no longer need it.

From a one-off scan to continuous, still-read-only monitoring

If the scan surfaces useful findings and your team wants recurring visibility instead of a one-time snapshot, GreenOps Cloud extends the same read-only model with a cross-account IAM role (scoped with sts:ExternalId and the same ReadOnlyAccess policy) so continuous monitoring never requires write access either.

Either way — a local profile for a single npx greenops-scan run, or a cross-account role for ongoing monitoring — the underlying guarantee stays the same: the scanner can look, but it cannot touch.

Tags: #AWS #IAM #ReadOnlyAccess #CloudSecurity #FinOps #GreenOps