sec(iac/aws): aws-wif-cli.sh.tmpl hardcodes an unoverridable OIDC thumbprint placeholder (not a bypass)

[cristim]

internal/iacfiles/templates/aws-wif-cli.sh.tmpl (grep for thumbprint-list; line number shifts as the file changes) hardcodes the all-zeros
placeholder thumbprint when creating the AWS OIDC provider:

aws iam create-open-id-connect-provider $PROFILE_ARG \
  --url "${OIDC_ISSUER_URL}" \
  --client-id-list "${OIDC_AUDIENCE}" \
  --thumbprint-list "0000000000000000000000000000000000000000" >/dev/null

There is no way for the operator to override it, so every CLI-bundle
onboarding creates the provider with that value. This is the CLI-bundle
sibling of LeanerCloud/cloud-commitments-cli#1615, which PR LeanerCloud/cloud-commitments-cli#1678 fixed for the CloudFormation and Terraform
bundles (empty default, ThumbprintList omitted via AWS::NoValue /
thumbprint_list = null so IAM retrieves the issuer's real thumbprint) but
deliberately left this file alone — noted in a comment on LeanerCloud/cloud-commitments-cli#1640 by the LeanerCloud/cloud-commitments-cli#1678
author, since internal/iacfiles/ was that issue's scope, not LeanerCloud/cloud-commitments-cli#1615's.

Not an authentication bypass

Worth stating plainly, since the wording on LeanerCloud/cloud-commitments-cli#1615 could be read otherwise (PR
LeanerCloud/cloud-commitments-cli#1678 corrects that). Per AWS's docs,
AWS verifies the JWKS endpoint's TLS certificate against its own library of
trusted root CAs and consults the configured thumbprint only when that
certificate does not chain to one of them, AWS cannot retrieve it, or the
endpoint requires TLS 1.3. All-zeros is inert on the primary path, and on the
fallback path it is simply not the SHA-1 of any certificate: it matches
nothing, so role assumption fails outright. For CUDly's actual issuers
(accounts.google.com, login.microsoftonline.com — both well-known
providers AWS auto-validates without consulting the configured thumbprint at
all) this has no live impact today. The failure mode for a hypothetical
custom/non-well-known issuer would be availability plus misleading
configuration, not takeover.

Second gap in the same file: re-running doesn't correct an existing provider

if [[ "${EXISTING_PROVIDER}" == "None" || -z "${EXISTING_PROVIDER}" ]]; then
  aws iam create-open-id-connect-provider ...
fi

The script only creates the provider when one doesn't already exist; there is
no else that re-checks or corrects the thumbprint on an existing provider.
An operator who re-runs the script after a fix ships still has the
placeholder on whatever provider they already created.
aws iam update-open-id-connect-provider-thumbprint is the out-of-band
remedy today.

Fix, when this is worked

--thumbprint-list is optional on create-open-id-connect-provider;
omitting it makes IAM retrieve and use the issuer's real top intermediate CA
thumbprint, matching what PR LeanerCloud/cloud-commitments-cli#1678 did for the CloudFormation and Terraform
bundles. Also decide explicitly whether to detect-and-correct an existing
provider's thumbprint on re-run, or to leave the skip-existing behavior and
document update-open-id-connect-provider-thumbprint as the remedy in the
script's own output.

Tracked in known_issues/13_iac_aws_target.md.

Refs LeanerCloud/cloud-commitments-cli#1615, LeanerCloud/cloud-commitments-cli#1640, LeanerCloud/cloud-commitments-cli#1678.