aws-creds

Files (2)

• SKILL.md
• portals.md

SKILL.md (first lines)

# AWS SSO credentials (any portal)

Fetches short-lived credentials from an IAM Identity Center portal and makes them
usable from the shell. Portal-agnostic: every portal-specific fact lives outside
this file, nothing is hardcoded here.

## Resolve the portal first

Portal facts — start URL, IdP, account IDs, cache prefix — come from one of two
places:

- **A per-org wrapper skill** invoked this one (e.g. a private `<org>-aws` skill
  that pins one portal and its accounts). If so, use the facts it handed you.
- **`portals.md`** in this directory, for portals registered directly here.

`portals.md` ships as a **template**. Keep real org data either in it (private
checkout) or in a dedicated wrapper skill — never commit real orgs to a public
copy of this skill.

Map what the user said — an org name, an account name, a bare "dev" — onto a
portal and an account. If the request is ambiguous, or names an account that
isn't listed, **ask**. Don't guess which AWS account to touch.

If the user names a portal you have no facts for, ask for its start URL, do the
run, then record it (in `portals.md` or the wrapper skill) so the next run is one
step shorter.

## Output contract

On success:

1. Credentials written to `~/.agents/state/aws-creds/<portal>-<account>.env`, mode `600`.
2. Print the **path**, the **account ID from `sts get-caller-identity`**, and the
   expiry (~1 hour). Never the secrets.
3. Callers consume it by sourcing:

```bash
set -a && source ~/.agents/state/aws-creds/<portal>-<account>.env && set +a && aws sts get-caller-identity
```

The Bash tool does not persist env between invocations, so either prefix every
`aws` call with that `source`, or put everything needing AWS in one bash block.

Print raw `export` lines only if the user explicitly asks for them.

**Profile path output** (below) differs: no file is written. Return the **profile
name** and the verified account ID; callers use `aws --profile <name> ...` or
`AWS_PROFILE=<name>`.

## Profile path — try this first

If `~/.aws/config` has an SSO profile for the account (and role) wanted, use it. The
CLI resolves credentials itself, so nothing is materialized into a file or the
transcript.

1. **Find the profile.** A wrapper skill hands you the profile name. Otherwise match
   `~/.aws/config` on the portal's `sso_session`/`sso_start_url` plus
   `sso_account_id` and `sso_role_name`. No match → go to the Workflow below.
2. **Test it:** `aws sts get-caller-identity --profile <p> --query Account --output text`
   and compare to the expected account ID. Match → done.
3. **Token expired** (error mentions the SSO token / `aws sso login`): run
   `aws sso login --sso-session <session> --use-device-code --no-browser`
   in the background with output to a file (never pipe to `head`; it dies on SIGPIPE).
   It prints a URL and a code. Open the URL in Chrome and check the page's code matches
   the printed one. An IdP redirect is fine to complete; a password prompt means stop
   and ask the user to sign in. Click **Confirm and continue**, then **Allow access**
   (the `botocore-client-<session>` grant). Re-run step 2.
4. **No profile, login fails, or something blocks the CLI path** → the Workflow below.

Do not run `aws configure export-credentials`; it writes out the very credentials
this path exists to avoid.

## Workflow (browser fallback)

### Step 0 — Load Chrome tools

One call, batched:

```
ToolSearch query: "select:mcp__claude-in-chrome__tabs_context_mcp,mcp__claude-in-chrome__tabs_create_mcp,mcp__claude-in-chrome__navigate,mcp__claude-in-chrome__javascript_tool,mcp__claude-in-chrome__find,mcp__claude-in-chrome__computer"
```

### Step 1 — Reach the portal, logged in

`tabs_context_mcp`, then navigate to the portal's start URL. Screenshot to see
where you landed.

- **On the IdP** (`login.microsoftonline.com`, Okta, etc.) → this is an SSO
  redirect, not fresh credential entry, so completing it is in scope. `find` the
  row for the user's account and click it. If it asks for a **password**, stop:
  the browser session expired and the user must sign in manually. Never type a
  password.
- **On the portal showing account tiles** → continue.

### Step 2 — Expand the account, open the credentials modal

Account rows are collapsed by default and the expand chevron is a small target;
clicking the account **name** is more reliable than the arrow. Then `find` the
`Access keys` link within that row.

**Verify you opened the right account before copying anything.** The modal states
the account name and ID:

```javascript
(() => {
  const dlgs = Array.from(document.querySelectorAll('[role="dialog"]'));
  for (const d of dlgs) {
    // Account names contain spaces ("Example Corp Dev"), so match anything up to
    // the "(<id>)" rather than a single non-space token — \S+? silently fails to
    // match every multi-word account and reports NO_CRED_DIALOG on a valid modal.
    const m = d.textContent.match(/Create access for the account\s+(.+?)\s*\((\d+)\)/);
    if (m) return `account=${m[1]} id=${m[2]}`;
  }
  return 'NO_CRED_DIALOG';
})();
```

**`NO_CRED_DIALOG` means "no modal found", not "wrong account" — never treat it as
a pass.** If you get it while a credentials modal is clearly open, the selector or

From RascalTwo/ai-setup, MIT.

More from RascalTwo/ai-setup