fix(iac): make ibm-iks pass tofu validate — and stop it claiming OIDC federation IBM cannot do

[mdheller]

Stacked on #1103 (fix/tofu-fmt-validate-blackout) — that PR's provider-source declaration is what makes tofu init work here at all. Retarget to main once #1103 merges.

infra/tofu/environments/ibm-iks has never passed tofu validate. It failed at tofu init because modules/ibm-trusted-profile used ibm_* resources without a declared provider source, so OpenTofu inferred the nonexistent hashicorp/ibm. #1103 fixed that, which unblocked init and exposed two errors that had been unreachable the entire time.

Before / after

Both with OpenTofu 1.8.3 (the TOFU_VERSION in tofu-plan.yml), tofu init -backend=false && tofu validate:

Before — 2 errors:

Error: "tags.2" ("repo:SocioProphet/prophet-platform") should match regexp ^[A-Za-z0-9:_ .-]+$
  with ibm_is_vpc.this, on main.tf line 21

Error: "type" must contain a value from []string{"Profile-SAML", "Profile-CR"}, got "Profile-OIDC"
  with module.github_ci.ibm_iam_trusted_profile_claim_rule.github,
  on ../../modules/ibm-trusted-profile/main.tf line 28

After — from a clean .terraform:

Success! The configuration is valid.

tofu fmt -check -recursive infra/tofu/ also clean.

⚠️ Local evidence only. Actions is at a spend cap (456 queued, 0 running), so CI could not verify this. Everything above was run on a local 1.8.3 binary.

---

Error 1 — the tag convention, and where it applies

IBM user tags must match ^[A-Za-z0-9:_ .-]+$. No /. So repo:SocioProphet/prophet-platform is rejected.

Convention chosen: split the owner out into its own tag.

-    "repo:SocioProphet/prophet-platform",
+    "org:socioprophet",
+    "repo:prophet-platform",

This is not a new invention — it is what the rest of the estate already does. environments/aws-eks, environments/azure-aks and shared/labels.tf all carry a separate "org" = "socioprophet" key and never embed the owner in the repo name. ibm-iks was the only place in the tree that tried to put owner/name in a single tag. Values are lowercase because IBM lowercases user tags on write.

Where else it applies: nowhere. I checked before changing it, as asked. local.prophet_tags is not shared — every root declares its own, and the shapes are not even compatible:

Root	prophet_tags type
environments/ibm-iks	list of "key:value" strings (IBM tag format)
environments/aws-eks	map
environments/azure-aks	map

So this change is scoped to ibm-iks. Within ibm-iks it is applied consistently by construction: all four tagged resources (ibm_is_vpc, ibm_is_subnet, ibm_container_vpc_cluster, ibm_cr_namespace) reference local.prophet_tags. Only the VPC errored because only ibm_is_vpc attaches a ValidateFunc to tags, but all four were carrying the malformed value.

---

Error 2 — this is a redesign, not a fix

Profile-CR is not the answer. There is no answer. IBM Cloud cannot federate GitHub Actions OIDC at all, so the module's premise — "IBM's equivalent of AWS IRSA / Azure WIF / GCP WIF" — was never achievable.

The claim rule enum is closed at two values, hard-coded in the provider (resource_ibm_iam_trusted_profile_claim_rule.go):

ValidateFunc: validate.ValidateAllowedStringValues([]string{"Profile-SAML", "Profile-CR"}),

Profile-CR is compute-resource-only. From the provider docs:

cr_type — The compute resource type the rule applies to, required only if type is specified as 'Profile-CR'. Supported values are VSI, PVS, BMS, IKS_SA, ROKS_SA, CE.

Every one of those six is a workload running inside IBM Cloud — VPC virtual server, Power VS, bare metal, IKS service account, OpenShift service account, Code Engine. The CR token is not an arbitrary JWT; it is platform-injected, read from the instance metadata service or a projected service account file (/var/run/secrets/tokens/sa-token, /var/run/secrets/codeengine.cloud.ibm.com/compute-resource-token/token). A GitHub-hosted runner cannot mint one.

Profile-SAML is for human SSO. Same docs: realm_name is "The realm name of the Idp this claim rule applies to. This field is required only if the type is specified as 'Profile-SAML'", and the type carries an expiration ("session expiration in seconds"). It maps a federated user arriving via browser SSO from a registered SAML realm onto a profile. GitHub Actions issues OIDC JWTs, not SAML assertions.

And there is no IdP route either. resource_ibm_iam_idp.go allows exactly saml, appid, ldap — no OIDC type, and no issuer / jwks / client_id fields anywhere in the IAM Identity surface to point at https://token.actions.githubusercontent.com.

Corroborating: IBM's own IBM/actions-ibmcloud-cli action accepts exactly one auth input — api_key. No OIDC, no trusted profile, no id-token permission. And the upstream terraform-ibm-modules/terraform-ibm-trusted-profile makes no IRSA/WIF claim; its example uses Profile-CR with cr_type = "VSI". The IRSA-equivalence claim was added locally.

IBM's own docs enumerate how a trusted profile can be assumed — federated (SAML) users, compute resources, service IDs, cloud service instances (create-trusted-profile, trusted-profile-iam-token). External OIDC providers are not on the list.

Honest caveat on the negative: I found no IBM statement that says "we do not support OIDC federation." The conclusion rests on closed enums in two independent IBM-authored codebases, the total absence of OIDC primitives in the IAM Identity API, and IBM's own action shipping API-key-only auth. Strong, but it is negative evidence.

What this PR does instead

Removes the invalid claim rule rather than swapping it for one that passes the validator and federates nothing — that is precisely the "control that passes and does nothing" defect class. Consequence, stated plainly rather than hidden: the trusted profile is created but is NOT assumable by CI, and its policies grant nothing to anyone. That is now documented in four places — module header, the calling comment in ibm-iks/main.tf, the output description, and the env README — plus the IBM console description string itself reads NOT FEDERATED — no claim rule.

Recommended shape (needs a decision, not mine to make unilaterally)

1. Run the job on IBM compute. Move the drift plan to Code Engine (cr_type = "CE") or an IKS workload (IKS_SA), reduce GitHub Actions to a trigger. Only genuinely keyless option. Worth noting AWS IRSA is pod identity, which IBM does support via Profile-CR; it is Azure/GCP-style CI federation that IBM lacks — the module conflated the two.
2. Service ID + API key in GitHub secrets. Supported, works today, reintroduces the long-lived credential. Rotation needs an owner.
3. Service ID + API key in IBM Secrets Manager, fetched at job start. Narrows blast radius; still needs a bootstrap secret.

1 is the recommendation; 2 and 3 are interim.

🔴 Also broken, flagged not fixed (out of lane)

.github/workflows/infra-drift-detect.yml (~line 149) posts a GitHub OIDC token to grant_type=urn:ibm:params:oauth:grant-type:cr-token. That grant expects a compute resource token and will reject it, for exactly the reason above. The two halves of this design never agreed with each other — the module declared Profile-OIDC while the workflow assumed CR. Neither has ever run. That workflow is outside environments/ibm-iks/ + modules/ibm-trusted-profile/, so it is untouched here and needs reworking alongside whichever option is chosen.

---

CI coverage — this rotted because nothing watched it

tofu-plan.yml runs fmt -check -recursive across all of infra/tofu/, but validate on only four roots, all under envs/: local, gcp-landing, shared, prod. The entire environments/ tree and all of bootstrap/ are unvalidated. That is why a root that had never validated survived indefinitely.

⚠️ I have not edited tofu-plan.yml — PR #1097 owns it. Recommendation for whoever lands #1097:

Add these nine roots to the fmt-and-validate job (tofu init -backend=false && tofu validate each):

infra/tofu/environments/ibm-iks
infra/tofu/environments/aws-eks
infra/tofu/environments/azure-aks
infra/tofu/environments/gcp-ephemeral
infra/tofu/environments/gcp-gke
infra/tofu/environments/gcp-persistent
infra/tofu/bootstrap/aws
infra/tofu/bootstrap/azure
infra/tofu/bootstrap/gcp

All nine are safe to add now. I validated each locally on 1.8.3: eight already pass clean, and the ninth (ibm-iks) passes as of this PR. So this widening goes green immediately — there is no cleanup backlog gating it.

Two notes for whoever implements it:

• bootstrap/aws emits a non-fatal provider deprecation warning (aws_s3_bucket_lifecycle_configuration missing rule[0].filter) — pre-existing, warns only, does not fail validate. Worth a separate ticket before it becomes an error in a future provider.
• A matrix over the root list would be tidier than nine copy-pasted steps, and would make the next added root a one-line change rather than an omission.

Given the tree is 13 roots and CI watches 4, a cheap follow-up guard would be a check that every directory containing a versions.tf/backend block appears in the validate matrix — otherwise root #14 lands unwatched the same way this one did.

Test plan

• tofu init -backend=false && tofu validate in environments/ibm-iks on 1.8.3 — clean .terraform, passes
• tofu fmt -check -recursive infra/tofu/ — clean
• All 8 other uncovered roots validated locally on 1.8.3 — all pass
• CI — blocked, spend cap. Not verified in Actions.
• tofu apply — not attempted; no IBM credentials, and per the above CI cannot obtain any.

[Copilot]

Pull request overview

Note

Copilot couldn't run its full agentic review because it didn't start before the timeout. Make sure your repository has a runner available, or add a copilot-code-review.yml file specifying one with the runs-on attribute. See the docs for more details.

Fixes infra/tofu/environments/ibm-iks so it passes tofu init -backend=false && tofu validate by correcting an IBM tag value and removing an invalid IAM trusted profile claim-rule configuration that implied unsupported GitHub Actions OIDC federation.

Changes:

• Adjust IBM user tags to satisfy IBM’s tag regex (no /), splitting repo owner/name into separate tags.
• Remove the invalid Profile-OIDC claim rule from the IBM trusted profile module and document the non-federated state clearly.
• Update environment/module documentation to reflect the current authentication limitations and implications.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
infra/tofu/modules/ibm-trusted-profile/main.tf	Removes unsupported claim rule; updates module docs and profile description to reflect non-federated state.
infra/tofu/environments/ibm-iks/main.tf	Fixes invalid IBM tag (/) and clarifies trusted-profile usage and limitations.
infra/tofu/environments/ibm-iks/README.md	Documents validation history and clarifies that CI auth via trusted profile is not currently possible.

Comments suppressed due to low confidence (1)

infra/tofu/environments/ibm-iks/README.md:1

• This README text is time/PR-relative ("as of the PR that added this line"), which will become stale quickly. Consider rephrasing to a timeless statement (e.g., "This root now passes tofu validate; previously it failed due to …") so the docs remain accurate when read out of PR context.

# ibm-iks — IBM Cloud IKS substrate (VPC)

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[mdheller]

Disposition (merge-gate review)

IaC validates cleanly: on the cumulative merged tree (#1103 -> #1107/#1108/#1115) all 14/14 roots pass tofu validate and tofu fmt -check exits 0 on tofu 1.8.3.

The non-federated labelling is correct and should stay as-is — main.tf's output description and the README state plainly that IBM cannot federate GitHub Actions OIDC and that apply needs IC_API_KEY. Please don't let this get "fixed" into an OIDC-federation claim IBM can't honor.

One small alignment nit: infra/tofu/environments/ibm-iks/versions.tf:23 carries # CI: IBM_TRUSTED_PROFILE_ID + short-lived OIDC token via github-oidc; no static API keys, which reads against the authoritative non-federated labelling elsewhere. Worth rewording to match (no federation; apply uses IC_API_KEY). Minor, non-blocking.

Copilot's inline on the trusted-profile description length/charset is a reasonable apply-time robustness note (validate passes regardless).