Skip to content

feat(aws): use ambient AWS credentials when static keys are empty#349

Merged
Cre-eD merged 2 commits into
mainfrom
feat/aws-ambient-oidc-creds
Jun 30, 2026
Merged

feat(aws): use ambient AWS credentials when static keys are empty#349
Cre-eD merged 2 commits into
mainfrom
feat/aws-ambient-oidc-creds

Conversation

@Cre-eD

@Cre-eD Cre-eD commented Jun 28, 2026

Copy link
Copy Markdown
Contributor

When an aws auth config has no `accessKey`/`secretAccessKey`, fall back to the AWS default credential chain (GitHub OIDC web-identity / instance profile / env) instead of pinning empty static creds.

Three spots that previously hard-wired static creds now guard on non-empty:

  • `provider.go` Provider — only set `AccessKey`/`SecretKey` on the Pulumi AWS provider when present.
  • `provider.go` InitStateStore — only `os.Setenv` the AWS_* vars when present (empty would otherwise blank the ambient/OIDC creds the runner exported).
  • `static_website.go` — omit AWS_* from the `aws s3 sync` command env when empty.

Mirrors the guarded handling already in `cloudtrail_validation.go` + `cloudtrail_security_alerts.go`.

Backward compatible: configs with static keys behave exactly as before. Prereq for de-keying the service-deploy path (integrail-deployer-bot) via OIDC.

Enable GitHub OIDC / instance-profile / default-chain credentials for
sc deploy & provision: when an aws auth config has no accessKey/secretAccessKey,
do NOT pin empty static creds on the Pulumi AWS provider, do NOT blank the
AWS_* env vars in the state-store setup, and omit them from the static-website
s3-sync command env — falling back to the AWS default credential chain instead.

Mirrors the guarded handling already in cloudtrail_validation.go +
cloudtrail_security_alerts.go. Fully backward compatible: configs with static
keys behave exactly as before. Prereq for de-keying the integrail-deployer-bot
service-deploy path via OIDC.

Signed-off-by: Dmitrii Creed <creeed22@gmail.com>
@github-actions

github-actions Bot commented Jun 28, 2026

Copy link
Copy Markdown

Semgrep Scan Results

Repository: api | Commit: 51b83d9

Check Status Details
⚠️ Semgrep Warning 1 warning(s), 1 total

Scanned at 2026-06-29 17:21 UTC

@github-actions

github-actions Bot commented Jun 28, 2026

Copy link
Copy Markdown

Security Scan Results

Repository: api | Commit: 51b83d9

Check Status Details
✅ Secret Scan Pass No secrets detected
✅ Dependencies (Trivy) Pass 0 total (no critical/high)
✅ Dependencies (Grype) Pass 0 total (no critical/high)
📦 SBOM Generated 523 components (CycloneDX)

Scanned at 2026-06-29 17:21 UTC

@github-actions

github-actions Bot commented Jun 28, 2026

Copy link
Copy Markdown

📊 Statement coverage

Measured on the documented included set (see docs/TESTING.md → Coverage scope). Observe-only — no regression gate is enforced yet.

Scope This PR main baseline Δ
Included set (Gold-tier denominator) 90.3% 90.3% +0.0 pp
Full set (whole repo, transparency) 27.9% 27.9% +0.0 pp

Baseline: main @ 9d972a9

- provider_test.go: regression tests that InitStateStore preserves ambient
  AWS_* env when no static keys are configured (the OIDC path), and still
  exports static keys when present (back-compat).
- parent-ecs-fargate guide: note accessKey/secretAccessKey are optional;
  omitting them falls back to the AWS default credential chain (OIDC /
  instance profile / env).

Signed-off-by: Dmitrii Creed <creeed22@gmail.com>
@Cre-eD Cre-eD merged commit dea14c1 into main Jun 30, 2026
22 checks passed
Cre-eD added a commit that referenced this pull request Jun 30, 2026
… bake creds (#354)

## Problem
A real GitHub-OIDC `sc deploy` to a throwaway env failed at the explicit
AWS provider:
```
pulumi-aws: error validating credentials: Invalid credentials configured.
pulumi:providers:aws '...--ecs-fargate--...--provider--testtmp' has a problem: Invalid credentials configured.
```
Everything else under ambient creds worked — OIDC federation, the S3
Pulumi state backend, KMS, StackReference reads.

## Root cause (verified, not guessed)
- In pulumi-aws v6.83.4, **"Invalid credentials configured" =
*incomplete* creds**, not "none" (that is `No valid credential sources
found`). The provider *does* fall back to env (`token` else
`AWS_SESSION_TOKEN`), and the runner env had **complete** creds incl.
the session token (confirmed in the run log).
- Inspecting the stack's Pulumi state: the `aws` provider resource has
**`accessKey` + `secretKey` baked in** (from prior **static-key**
deploys), `skipCredentialsValidation: false`, **no `token`**.
- So this is a **static→ambient transition**: the provider's eager STS
pre-validation chokes on the incomplete (token-less) credential picture,
even though the real API calls would resolve the complete ambient env
creds.

## Fix
In ambient mode (empty static keys): leave the provider
**credential-less** (default chain resolves env creds at call time) and
set **`SkipCredentialsValidation: true`** to skip the brittle
pre-validation. Static keys keep validation on. Shared
`applyAWSProviderCreds` helper for `Provider()` + the CloudTrail region
provider. Tests cover both paths.

The first ambient deploy self-heals the state (provider becomes
creds-less + `skipCredentialsValidation: true`); no manual state
surgery.

## What this deliberately does NOT do
The original version of this PR baked the ambient env creds (incl. the
rotating `AWS_SESSION_TOKEN`) onto the provider inputs. A **Codex
(gpt-5.5) + Gemini** review rejected that: it persists ephemeral creds
in the encrypted checkpoint and produces a provider diff **every run**.
Dropped.

## Verification
- `go build` / `go vet` / `go test ./pkg/clouds/pulumi/aws/` green.
- End-to-end confirmation pending: a `testtmp` re-deploy on this build
(preview or post-release) — the ambient code path is dormant for every
current caller (only reached when `aws-oidc-role` is set), so there is
no production exposure from merging.

Follow-up to #349.

Signed-off-by: Dmitrii Creed <creeed22@gmail.com>
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.

3 participants