Document Opaque secret support in NGINX Ingress Controller - #2305
promptless[bot] wants to merge 1 commit into
Conversation
Document that NGINX Ingress Controller now validates referenced Kubernetes Secrets by their data keys and role instead of by the Secret type field, so a standard Opaque secret with the required keys is accepted for API-key, basic-auth, JWT/JWK, OIDC, CA/mTLS, WAF-bundle, and NGINX Plus license use cases. Existing nginx.org/*, nginx.com/*, and kubernetes.io/tls typed secrets keep working and are not deprecated. Reframe each policy secret field in the Policy reference to accept an Opaque or typed secret keyed on its required data key(s), add a shared explanatory note, and apply the same key-based framing to the WAF bundle sources, license secret, management ConfigMap, and Helm and install guides. Keep standard kubernetes.io/tls secrets on their standard type. Minor accuracy touch to the architecture design page. Documents source PRs nginx/kubernetes-ingress#10935 and #10816. Unreleased: version left as a <VERSION> placeholder pending confirmation.
github-actions
Bot
added
documentation
![promptless[bot]](https://avatars.githubusercontent.com/in/979718?s=60&v=4){kind=small}
✅ Deploy Preview will be available once build job completes!
|
|
target nic-release-5.7, not main |
|
In reply to this discussion Thanks for flagging the base branch — you're right that this documents unreleased ~v5.7 behavior, so it should target |
|
In reply to this discussion Blocked — one thing needed from you
Need: Tell me which you'd prefer: allow a force-push on the |
|
close this PR and create a new one from nic-release-5.7 as base |
|
In reply to this discussion Got it — I'll close this PR and open a new one for the same Opaque secret changes with |
|
Closing per review feedback ("close this PR and create a new one from Replaced by #2307, which is based on |
|
In reply to this discussion Done — I closed this PR and opened #2307 in its place, based on One heads-up: the description still notes the behavior as unreleased (asking reviewers to hold or retarget until it ships) and carries a Docs PR: #2307 |
1 participant
Proposed changes
Documents F5 NGINX Ingress Controller's new type-agnostic secret validation, from source PR nginx/kubernetes-ingress#10935 ("Update examples to use opaque secrets") and its feature PR nginx/kubernetes-ingress#10816 ("Add opaque secret support"). This behavior is unreleased: both source PRs are open against a feature branch (~v5.7.0). Please hold or retarget this PR until the feature ships, and replace the
<VERSION>placeholder with the confirmed release.From that release, NGINX Ingress Controller validates a referenced Kubernetes Secret by its data keys and role rather than by the Secret
typefield. A standardOpaquesecret carrying the required keys is accepted anywhere a secret is referenced, and existingnginx.org/*,nginx.com/*, andkubernetes.io/tlstyped secrets keep working unchanged and are not deprecated. This lets users reuse secrets that cert-manager, External Secrets Operator, a GitOps pipeline, or Vault already produce, without converting them to NGINX-specific types (originating request: nginx/kubernetes-ingress#10639).What changed:
Opaquesecret (shown as primary) or the existing typed secret, keyed on the required data key(s). Replaced the "must be of type ... otherwise rejected" wording with data-key-based validation, and added one shared note explaining the reject-and-fix behavior. The APIKey, IngressMTLS, and CRL YAML examples now lead withtype: Opaque.kubectl create secretcommands drop the--typeflag.kubernetes.io/tlssecrets were intentionally kept on their standard type.Notes for review:
<VERSION>placeholder for the introducing release. Please confirm and replace it.Checklist
Before sharing this pull request, I completed the following checklist:
Footnotes
Potentially sensitive information includes personally identify information (PII), authentication credentials, and live URLs. Refer to the style guide for guidance about placeholder content. ↩