feat(aws): use ambient AWS credentials when static keys are empty#349
Merged
Conversation
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>
Semgrep Scan ResultsRepository:
Scanned at 2026-06-29 17:21 UTC |
Security Scan ResultsRepository:
Scanned at 2026-06-29 17:21 UTC |
📊 Statement coverageMeasured on the documented included set (see
Baseline: |
- 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>
smecsia
approved these changes
Jun 30, 2026
universe-ops
approved these changes
Jun 30, 2026
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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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:
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.