granted-aws

granted.dev's assume gives short-lived AWS creds and console access without plaintext keys on disk. The tool is marketed for SSO, but works for plain IAM users too. First-run fails in three specific ways that no error message explains well - this skill is those three, plus picking the right flow.

Pick the flow from the sign-in URL

The URL you log into decides everything. Check it first:

URL shape	World	Flow
`https://<account-id>.signin.aws.amazon.com/console`	IAM user or root, one account	IAM-user flow
`https://<subdomain>.awsapps.com/start`	IAM Identity Center (SSO)	SSO flow

A gist or doc that opens with granted sso populate assumes the second URL. Running it against the first gets you nowhere - there's no SSO to populate.

Requires granted/assume and aws on PATH (brew install common-fate/granted/granted awscli).

IAM-user flow (long-lived key → keychain)

granted stores the secret in the OS keychain and writes only a credential_process line to ~/.aws/config - no plaintext key on disk.

Mint the key in the console. IAM → Users → your user → Security credentials → Create access key (CLI). Never create keys for root; put MFA on the IAM user - a long-lived key with no MFA is the weak point.
Point granted at your browser (one-off): granted browser set.
Create ~/.aws/config first - granted credentials add errors with open ~/.aws/config: no such file or directory if it's absent:
```
mkdir -p ~/.aws && touch ~/.aws/config
```
Add the key to the keychain:
```
granted credentials add          # prompts: profile name, Access Key ID, Secret
```
Then delete the console tab showing the secret. Check with granted credentials list; re-run is granted credentials update <profile>.
Set a region - assume <profile> errors region not set on profile until one exists:
```
aws configure set region <region> --profile <profile>   # e.g. eu-west-2
```
Verify:
```
assume <profile>
aws sts get-caller-identity        # prints the account + user ARN
```
Don't exit afterwards - assume exports credentials into the current shell (no subshell is spawned), so exit closes your real shell. The credentials expire on their own; assume --unset clears them sooner.

Scripts and agents can skip assume entirely: once the profile exists, aws --profile <profile> sts get-caller-identity works directly via credential_process. assume and granted credentials add are interactive-only (prompts, browser hand-offs) - use aws --profile in anything unattended.
Console from the CLI, in a chosen browser profile:
```
assume <profile> -c --browser-profile "<profile-dir>"
```
Find <profile-dir> at chrome://version → Profile Path → last path segment (e.g. Default, Profile 3). To skip the flag each time, set a default in ~/.granted/config.

SSO flow (no long-lived keys)

granted sso populate --sso-region <region> https://<subdomain>.awsapps.com/start
assume            # pick a profile; short-lived creds, nothing stored long-term

granted sso populate writes a profile per account+permission-set into ~/.aws/config. Console open is the same assume <profile> -c as above.

Upgrade IAM-user → SSO later

No rework of console/browser setup needed:

granted sso populate --sso-region <region> https://<subdomain>.awsapps.com/start
granted credentials remove <profile>     # drop the keychain-stored long-lived key

Then delete that access key in the IAM console. Now zero long-lived secrets.