Initial Foray into AWS: Tinkering with IAM Permissions

2026-10-16T00:00:00Z

The point of this series is to document my exploration of AWS, fumbles and all. I find that by the time someone expert in a thing gets around to writing about it, the initial confusion has long been forgotten.

Querying with root credentials seemed like a bad idea. So my first step was to explore IAM (Identity and Access Management) and create a broad-ish set of permissions through which I could do my initial querying.

I began using the local directory to redirect terminal outputs to files to see the general structure of a user and analyze various other data shapes.

aws iam get-user --profile pokesandbox > iam-profile.json

The output for my sandbox user profile looked like this:

   {
    "User": {
        "Path": "/",
        "UserName": "PokeSandbox-Dev",
        "UserId": "AIDXXXXXXXXXXXXX",
        "Arn": "arn:aws:iam::123456789012:user/PokeSandbox-Dev",
        "CreateDate": "2026-10-16T10:06:32+00:00"
    }
}

Next, I wanted to map out exactly what read-only commands were available to me under this profile, starting with a simple search for the get- verb:

λ aws iam help | grep get-
    get-access-key-last-used
    get-account-authorization-details
    get-account-password-policy
    get-account-summary
    get-context-keys-for-custom-policy
    get-context-keys-for-principal-policy
    get-credential-report
    get-delegation-request
    get-group
    get-group-policy
    get-human-readable-summary
    get-instance-profile
    get-login-profile
    get-mfa-device
    get-open-id-connect-provider
    get-organizations-access-report
    get-outbound-web-identity-federation-info
    get-policy
    get-policy-version
    get-role
    get-role-policy
    get-saml-provider
    get-server-certificate
    get-service-last-accessed-details
    get-service-last-accessed-details-with-entities
    get-service-linked-role-deletion-status
    get-ssh-public-key
    get-user
    get-user-policy

While looking over this list, I realized filtering for just get- was artificially limiting my visibility. In the AWS API design, get- is typically reserved for fetching deep, specific details on a single object. If I wanted a complete view of my read-only constraints, I needed to expand my filter to include list- (for arrays/collections of objects) and generate- (for back-end auditing engine tasks).

Using an extended regex filter, I ran a much wider net:

Full output of the extended grep (70+ lines)

λ aws iam help | grep -E "get-|list-|generate-"
     generate-credential-report
     generate-organizations-access-report
     generate-service-last-accessed-details
     get-access-key-last-used
     get-account-authorization-details
     get-account-password-policy
     get-account-summary
     get-context-keys-for-custom-policy
     get-context-keys-for-principal-policy
     get-credential-report
     get-delegation-request
     get-group
     get-group-policy
     get-human-readable-summary
     get-instance-profile
     get-login-profile
     get-mfa-device
     get-open-id-connect-provider
     get-organizations-access-report
     get-outbound-web-identity-federation-info
     get-policy
     get-policy-version
     get-role
     get-role-policy
     get-saml-provider
     get-server-certificate
     get-service-last-accessed-details
     get-service-last-accessed-details-with-entities
     get-service-linked-role-deletion-status
     get-ssh-public-key
     get-user
     get-user-policy
     list-access-keys
     list-account-aliases
     list-attached-group-policies
     list-attached-role-policies
     list-attached-user-policies
     list-delegation-requests
     list-entities-for-policy
     list-group-policies
     list-groups
     list-groups-for-user
     list-instance-profile-tags
     list-instance-profiles
     list-instance-profiles-for-role
     list-mfa-device-tags
     list-mfa-devices
     list-open-id-connect-provider-tags
     list-open-id-connect-providers
     list-organizations-features
     list-policies
     list-policies-granting-service-access
     list-policy-tags
     list-policy-versions
     list-role-policies
     list-role-tags
     list-roles
     list-saml-provider-tags
     list-saml-providers
     list-server-certificate-tags
     list-server-certificates
     list-service-specific-credentials
     list-signing-certificates
     list-ssh-public-keys
     list-user-policies
     list-user-tags
     list-users
     list-virtual-mfa-devices

Retrieving Policies for a user

I may want to see what policies are attached to a given user. I don't know how to use the command so I just bash it out and get some help text

λ aws iam list-user-policies

aws: [ERROR]: An error occurred (ParamValidation): the following arguments are required: --user-name

After adding the username...

λ aws iam list-user-policies --user-name=PokeSandbox-Dev
{
    "PolicyNames": []
}

After some searching I finally came upon aws iam list-attached-user-policies --user-name PokeSandbox-Dev

λ aws iam list-attached-user-policies --user-name PokeSandbox-Dev
{
    "AttachedPolicies": [
        {
            "PolicyName": "AWSXrayReadOnlyAccess",
            "PolicyArn": "arn:aws:iam::aws:policy/AWSXrayReadOnlyAccess"
        },
        {
            "PolicyName": "AmazonKinesisReadOnlyAccess",
            "PolicyArn": "arn:aws:iam::aws:policy/AmazonKinesisReadOnlyAccess"
        },
        {
            "PolicyName": "CloudWatchReadOnlyAccess",
            "PolicyArn": "arn:aws:iam::aws:policy/CloudWatchReadOnlyAccess"
        },
        {
            "PolicyName": "IAMReadOnlyAccess",
            "PolicyArn": "arn:aws:iam::aws:policy/IAMReadOnlyAccess"
        },
        {
            "PolicyName": "ViewOnlyAccess",
            "PolicyArn": "arn:aws:iam::aws:policy/job-function/ViewOnlyAccess"
        },
        {
            "PolicyName": "AmazonS3FullAccess",
            "PolicyArn": "arn:aws:iam::aws:policy/AmazonS3FullAccess"
        },
        {
            "PolicyName": "AWSLambda_FullAccess",
            "PolicyArn": "arn:aws:iam::aws:policy/AWSLambda_FullAccess"
        },
        {
            "PolicyName": "AmazonEventBridgeReadOnlyAccess",
            "PolicyArn": "arn:aws:iam::aws:policy/AmazonEventBridgeReadOnlyAccess"
        }
    ]
}

Attached user policies are a way to assign standalone permission sets by reference to one or more users, whereas inline policies are policies that are defined in the identity itself.

A discovery process

I eventually figured out that the AWS CLI is self documenting. So if I'm curious about IAM, for example, I could just run aws iam help and read the list of commands and then aws iam list-attached-user-policies help and so on.

I ran into an issue where my auth had expired and needed a way to have two auth "contexts" which is detailed in Part 2.

Separate AWS credentials per project on Windows (cmder + Git Bash)

2026-10-18T00:00:00Z

I do consulting work for a client and I'm also exploring AWS on my own, and the two need different credentials. Part 1 used --profile pokesandbox, but I wanted something where I couldn't accidentally run a command against the wrong account. My solution is one config file per project, selected by the terminal tab I open.

One config file per project

Each project directory gets its own .aws/config:

[default]
region = us-east-1
output = json
aws_access_key_id = AKIXXXXXXXXXXXXXXXXX
aws_secret_access_key = <secret_key>

The CLI also accepts keys in the config file, so I use a single file per project instead of splitting config and credentials. Add .aws/ to .gitignore, because this file now contains secrets.

Pointing the CLI at it

The CLI reads AWS_CONFIG_FILE before falling back to ~/.aws/config. I set it in a cmder task (Settings > Startup > Tasks):

-new_console:t:"PokeData":d:"C:\PokeData\" set "PATH=%ConEmuDir%\..\git-for-windows\usr\bin;%PATH%" & %ConEmuDir%\..\git-for-windows\git-cmd.exe --no-cd --command=%ConEmuBaseDirShort%\conemu-msys2-64.exe "%ConEmuDir%\..\git-for-windows\usr\bin\bash.exe" --login -i -c 'export AWS_CONFIG_FILE="/c/PokeData/.aws/config"; exec bash --login -i'

The part that matters is export AWS_CONFIG_FILE="/c/PokeData/.aws/config". The rest opens a Git Bash tab, titled "PokeData", starting in C:\PokeData\. The context comes from the tab, not the directory: the CLI doesn't detect where you are, the tab just has the variable set.

Checking which identity you're using

In the PokeData tab:

λ aws sts get-caller-identity
{
    "UserId": "AIDAXXXXXXXXXXXXXXXXX",
    "Account": "111111111111",
    "Arn": "arn:aws:iam::111111111111:user/PokeSandbox-Dev"
}

In a client tab:

λ aws sts get-caller-identity
{
    "UserId": "AIDAXXXXXXXXXXXXXXXXX",
    "Account": "222222222222",
    "Arn": "arn:aws:iam::222222222222:user/client-user"
}

Now I can operate in two different contexts without having to think about it.