Document Opaque secret support in NGINX Ingress Controller - #2307
Open
promptless[bot] wants to merge 1 commit into
Open
promptless[bot] wants to merge 1 commit into
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
5 tasks
✅ Deploy Preview will be available once build job completes!
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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. ↩