[codex] Clarify OIDC AWS Parameter Store configuration

[llewellyn-sl]

Summary

This draft clarifies how to configure OIDC values from AWS Parameter Store for current versioned Platform docs.

Source context

• Slack source: https://seqera.slack.com/archives/C0APYR2A3A8/p1775513396564269
• Jira: https://seqera.atlassian.net/browse/EDU-1120
• Report: https://github.com/seqeralabs/agent-education-feedback-automation/blob/cursor/prompt-file-execution-4398/2026-03-30/2026-04-06.md

Repo and doc targets

• Repo: seqeralabs/docs
• Docset: platform-enterprise_versioned_docs
• Pages:
  • version-25.3/enterprise/configuration/authentication/overview.md
  • version-25.3/enterprise/configuration/aws_parameter_store.md

Rationale

The ticket described repeated startup failures caused by incorrect OIDC Parameter Store paths and by splitting the issuer, client ID, and client secret across multiple configuration sources. The current docs already covered OIDC and AWS Parameter Store separately, so this patch updates those existing pages instead of creating new docs.

What changed

• Added a warning that OIDC issuer, client ID, and client secret must stay in the same configuration source.
• Added the AWS Parameter Store keys for OIDC client ID, client secret, and issuer.
• Clarified that the OIDC client secret should be stored as SecureString.
• Added a Terraform interpolation note for generated user-data or manifest templates.

Validation

• Ran npx markdownlint-cli2 on the two touched files.
• The command reported pre-existing style issues already present in these files; no new automated build was run.

Follow-up

Please confirm the exact OIDC Parameter Store paths match product expectations in production deployments.

[netlify]

❌ Deploy Preview for seqera-docs failed. Why did it fail? →

Name	Link
🔨 Latest commit	b82ccc9
🔍 Latest deploy log	https://app.netlify.com/projects/seqera-docs/deploys/69d4593528a7350008b89723

[gwright99]

Big Brother's responsiveness is impressive.

With that said, please note that I suspected the root cause of the problem was the OIDC values split across two different configuration sources, but we haven't definitively proved it. I just know that I got the client fixed when we moved the Issuer credential out of their tower.env and into Parameter Store (where the OIDC user and password creds were).