Skip to content

feat(aws): track AWS CLI profiles and let nonprod reauthenticate - #121

Open
wadefletch wants to merge 1 commit into
mainfrom
feat/aws-stow-package
Open

feat(aws): track AWS CLI profiles and let nonprod reauthenticate#121
wadefletch wants to merge 1 commit into
mainfrom
feat/aws-stow-package

Conversation

@wadefletch

Copy link
Copy Markdown
Owner

Why

~/.aws/config was the last untracked piece of shell setup — a new machine needed it rebuilt by hand.

It also carried a latent bug. Opening a terminal in constellation failed with:

Authentication failed for provider 'kms': AWS KMS: authentication failed: ...
Session token not found or invalid
Run `aws sso login` to authenticate?

Answering yes then failed a second time:

Missing the following required SSO configuration values: sso_start_url, sso_region

constellation's mise config sources fnox on every directory entry to decrypt the KMS values in fnox.toml, and .env.local pins AWS_PROFILE=nonprod. The nonprod profile reaches its account by assuming OrganizationAccountAccessRole from root, so it has no SSO configuration of its own — and aws sso login resolves SSO settings from the named profile only, never through source_profile.

What changed

Declaring sso_session on the profile gives the login command a session to resolve, without disturbing credential resolution:

[profile nonprod]
sso_session = tractorbeam          # so `aws sso login` resolves
source_profile = root              # credentials still chain through here
role_arn = arn:aws:iam::716174523075:role/OrganizationAccountAccessRole

Keeping the chain matters. assume-role precedes sso in botocore's provider chain, so the resolved identity stays OrganizationAccountAccessRole — and that exact ARN is what two cross-account trust policies match on (ArnLike aws:PrincipalArn):

  • codeartifact-npm-read in shared-services, which constellation's mise run secrets:fetch assumes
  • codeartifact-read in distribution, which a scaffolded project's mise run codeartifact:login assumes

Converting nonprod to an ordinary SSO profile would have fixed the login and broken both.

The carlyle profile is dropped; caddi was never present locally. brizzco stays — it is a fictional customer used for bring-your-own-cloud testing.

Scope

Only ~/.aws/config is tracked. Credentials and the SSO token cache stay host-local, so the package stows without folding — the same treatment codex already gets. bootstrap.sh now drives that off a NO_FOLDING list instead of a hardcoded codex comparison.

Verification

  • bash -n bootstrap.sh passes; NO_FOLDING routes aws and codex to --no-folding, others to folding
  • stow -n --restow --no-folding aws reports no conflicts; ~/.aws/config is a symlink and sso/, cli/, workbench/ are untouched
  • aws configure list-profiles lists all 12 profiles
  • aws sso login under AWS_PROFILE=nonprod reaches the browser step instead of erroring on configuration
  • --debug confirms the provider chain still selects assume-role for nonprod, before and after

~/.aws/config was the last untracked piece of shell setup, so a new machine
needed it rebuilt by hand.

The nonprod profile reaches its account by assuming OrganizationAccountAccessRole
from root, and a profile configured that way carries no sso_start_url of its own.
Any tool that offers to reauthenticate when the session lapses — fnox does, on
every directory entry, because constellation's mise config sources it — ran
`aws sso login` against that profile and failed on missing SSO configuration.

Declaring sso_session on the profile gives the login command a session to resolve
while leaving credential resolution alone: assume-role precedes sso in the
provider chain, so the identity stays OrganizationAccountAccessRole. That exact
role ARN is what the cross-account CodeArtifact trust policies match on, so
turning nonprod into an ordinary SSO profile would have broken `secrets:fetch`
and `codeartifact:login` instead.

Only the config file is tracked. Credentials and the token cache stay host-local,
so the package stows without folding, as codex already does.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant