sec(iac/aws): reject the all-zeros OIDC thumbprint in the aws-target bundles

[cristim]

Closes #1615.

Read this first: the reachability is narrower than the issue states. The issue describes an authentication bypass reachable by MITM/DNS-hijacking the issuer's JWKS endpoint. That is not what the all-zeros thumbprint does under current AWS behaviour. The parameter is still wrong and still needs fixing, but for a different reason, and the fix is different from the one the issue proposes. Details in What I verified and Corrected reachability.

What I verified about AWS thumbprint handling

Two current AWS docs, quoted verbatim.

Obtain the thumbprint for an OpenID Connect identity provider:

AWS secures communication with OIDC identity providers (IdPs) using our library of trusted root certificate authorities (CAs) to verify the JSON Web Key Set (JWKS) endpoint's TLS certificate. If your OIDC IdP relies on a certificate that is not signed by one of these trusted CAs, only then we secure communication using the thumbprints set in the IdP's configuration. AWS will fall back to thumbprint verification if we are unable to retrieve the TLS certificate or if TLS v1.3 is required.

CreateOpenIDConnectProvider, on ThumbprintList:

This parameter is optional. If it is not included, IAM will retrieve and use the top intermediate certificate authority (CA) thumbprint of the OpenID Connect identity provider server certificate.

Required: No

AWS::IAM::OIDCProvider says the same for the CloudFormation property, and lists it as Update requires: No interruption. aws_iam_openid_connect_provider documents thumbprint_list as (Optional).

Note the trusted-CA rule is no longer scoped to a named list of IdPs (the older "Auth0, GitHub, GitLab, Google, S3-hosted JWKS" phrasing that both this repo's Terraform module and much of the community folklore are built on). It now applies to any issuer whose JWKS endpoint presents a publicly trusted certificate.

Corrected reachability

There is no fail-open value for this parameter. The thumbprint is a comparison target for a certificate fingerprint. Unlike OIDCSubjectClaim in #1602, it is not part of an IAM policy document, so there is no ${...} policy-variable expansion, no wildcard, and no value that makes AWS accept an arbitrary certificate. Every non-matching value fails closed.

Split by path:

Path	When	What all-zeros does
Primary	JWKS endpoint's TLS certificate chains to a CA in AWS's trusted-root library. Covers both documented issuers and every realistic hosted IdP.	Not read. A correct thumbprint is equally not read. The value is inert.
Fallback	Certificate does not chain to a trusted CA, AWS cannot retrieve it, or the endpoint requires TLS 1.3.	Compared against the retrieved certificate's SHA-1. All-zeros is not the fingerprint of any certificate, so it matches nothing and every AssumeRoleWithWebIdentity call fails.

So the issue's scenario does not hold. An attacker who MITMs or DNS-hijacks the JWKS endpoint still has to present a certificate signed by a CA in AWS's trusted-root library, and that bar does not move with this parameter — it is identical whether the thumbprint is all-zeros, correct, or absent. The Terraform module's stated rationale, "the all-zeros value bypasses the CA-chain check entirely", describes a mechanism that does not exist.

What is actually wrong is narrower, and is a defect in all three of the ways the parameter was specified:

1. The all-zeros value is the one value guaranteed never to match a real certificate. On the fallback path it does not weaken verification, it nulls it out — converting "verify" into "always fail" — while reading like a deliberate configuration.
2. The documentation asserted a security property the value does not carry: "Leave as zeros only for well-known providers where AWS auto-validates the chain" tells the operator that setting it correctly matters for other issuers, when in fact it is unread for every publicly-trusted issuer and actively breaks private-CA ones.
3. There was no way to express "let IAM retrieve the correct thumbprint", which is AWS's own default and the only correct configuration for the case where the thumbprint is actually consulted.

The severity is therefore availability and misleading documentation on a customer-deployed template, not takeover of the commitment-purchasing role. I have not relabelled the issue; that is the maintainer's call.

The fix

Empty is now the default and means omit ThumbprintList entirely, so IAM retrieves and uses the issuer's real top intermediate CA thumbprint — what the IAM console does by default. An operator with a private-CA issuer can still pin a real thumbprint. The placeholder is rejected.

CloudFormation (iac/federation/aws-target/cloudformation/template.yaml):

• OIDCThumbprint defaults to ""; a HasThumbprint condition resolves ThumbprintList to AWS::NoValue when it is empty.
• Two independent layers reject the placeholder:
  • AllowedPattern: "^$|^[0-9a-fA-F]{0,39}[1-9a-fA-F][0-9a-fA-F]{0,39}$" plus MaxLength: 40 — empty, or up to 40 hex characters of which at least one is non-zero.
  • An unconditional Rules assertion comparing against the literal. Rules are evaluated before any resource is created and abort the operation on failure.
• The parameter documentation is replaced with the behaviour above.

Terraform (iac/federation/aws-target/terraform/): brought to the same rule, because the issue names this module as the reference implementation and its guard rests on the rationale corrected above. Leaving the two paths contradicting each other on the same defect is the drift #1547 tracks. thumbprint_list defaults to [] and is passed as null when empty; the all-zeros entry is rejected unconditionally rather than for non-allowlisted issuers; the "must contain at least one thumbprint" validation is dropped, since empty is now correct.

Why the pattern is not a tautology

The #1602 precedent was an AllowedPattern that rejected a harmless value (*, compared literally by StringEquals) while admitting the fail-open one (${...}, expanded by IAM). Enumerating the same way here:

• Fail-open values: none. See above — no value of this parameter causes AWS to accept a certificate it would otherwise reject.
• Operationally broken values: the all-zeros placeholder, and any wrong-but-well-formed thumbprint. Both fail closed. Only the first is a shipped default reachable by doing nothing, and only that one is rejected.
• Malformed values: non-hex, wrong length, whitespace, wildcards, policy variables. Rejected by the pattern, except 1–39 hex characters, which the IAM API rejects on its fixed length of 40 — fail-closed, with the stack rolling back.

The guard is an exact-match rejection over a fully enumerated domain, not a heuristic: within "empty or 40 hex characters", 0 * 40 is the only all-zero string, and 0 has no case variants.

The one asymmetry worth flagging: the pattern rejects 0 * 40 but accepts 0 * 39 + 1, which is equally bogus. That is deliberate — the goal is to make the shipped placeholder unreachable, not to guess which supplied thumbprints are real, which is not decidable from the string.

Upgrade path (deliberate break, same call as #1602)

ThumbprintList is Update requires: No interruption, so switching between the two forms never replaces the OIDC provider or changes its ARN, and no re-onboarding is needed.

• CloudFormation stacks currently holding the placeholder will fail their next update until OIDCThumbprint is cleared or set to a real value. aws cloudformation deploy reuses previous parameter values for anything not in --parameter-overrides, so it will resubmit 0000… and the change set will be rejected with the ConstraintDescription. The remedy is one flag: --parameter-overrides "OIDCThumbprint=".
  This is deliberate. Such a stack is either on the primary path (where the value was never read, so clearing it changes nothing) or on the fallback path (where it cannot be authenticating today at all). Nothing that currently works regresses.
• Terraform: thumbprint_list is Optional+Computed in the AWS provider, so clearing it does not clear a value already stored on an existing provider — Terraform keeps reading back what is there. Existing providers must be corrected out of band with aws iam update-open-id-connect-provider-thumbprint, or replaced. Documented in main.tf and known_issues/13_iac_aws_target.md.
• Generated onboarding bundles are unaffected: aws-wif-cf-params.json.tmpl, aws-cfn-deploy.sh.tmpl and aws-wif.tfvars.tmpl never pass a thumbprint, so they pick up the new empty default. Unlike sec(iac/aws): require OIDC subject claim in aws-target CloudFormation #1602, this introduces no newly-required parameter.

Verification

• Regression tests (internal/api/handler_federation_test.go, following the existing convention in that file of reading ../../iac/federation/... from disk). The AllowedPattern, MaxLength and Default are parsed back out of the committed template rather than retyped, then evaluated the way CloudFormation evaluates them (anchored full match and the length cap), over 8 must-accept and 12 must-reject inputs — including the non-zero digit in first, middle and last position, and as both an upper- and lower-case hex letter. A second test asserts the resource wiring and that the placeholder appears exactly once in the template, in the Rules assertion that rejects it and nowhere else.
  Both tests fail against the pre-fix template (confirmed by checking out origin/main's copy and re-running) and pass after. Full package green: 2018 tests.
• Terraform, exercised against the real binary: terraform validate succeeds; terraform fmt -check clean; terraform plan rejects ["0000…"] even for the accounts.google.com issuer that the old guard allowed, rejects a short value, and accepts both [] and a real thumbprint.
• scripts/check-aws-iam-parity.sh: green. It compares IAM action lists across the CFN/TF/CLI onboarding flavors and has no thumbprint or trust-policy dimension, so there was nothing to extend for this change; the missing parity mechanism is sec(iac): onboarding paths drift - shell/CFN/ARM templates lack the guards their Terraform siblings enforce #1547.
• cfn-lint: cannot lint this template, on main and on this branch alike. It bails at parse time with E0000 Unhashable type "{'Fn::Sub': '${OIDCIssuerHost}:aud'}" — the trust policy legitimately uses !Sub as a mapping key. Pre-existing and out of scope here; the template is instead parsed and asserted on by the Go tests above.
• Full pre-commit on every commit, no --no-verify.

Out of scope

internal/iacfiles/templates/aws-wif-cli.sh.tmpl:33 hardcodes the same placeholder into aws iam create-open-id-connect-provider. That is the CLI bundle generator tracked by #1640, so it is left alone here and noted on that issue instead of widening this diff.

[coderabbitai]

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in: 41 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 53a74fa5-c01c-44d7-a1a7-66f5b526e909

📥 Commits

Reviewing files that changed from the base of the PR and between 6ded401 and 6d93bef.

📒 Files selected for processing (5)

• iac/federation/aws-target/cloudformation/template.yaml
• iac/federation/aws-target/terraform/main.tf
• iac/federation/aws-target/terraform/variables.tf
• internal/api/handler_federation_test.go
• known_issues/13_iac_aws_target.md

---

_{Comment @coderabbitai help to get the list of available commands.}