Conversation
Up to standards ✅🟢 Issues
|
delcroip
approved these changes
Sep 29, 2026
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.
Why
conf/locations/opensearch.locauthorizes every Dashboards request against openIMIS rights throughan
auth_requestsubrequest toopensearch_reports/auth_check, and then discards everything thatsubrequest returned except its status. Enabling the OpenSearch security plugin needs the proxy to
tell the cluster who the caller is, not only that it let them through.
What changes
Four directives inside the existing
/opensearch/location. Twoauth_request_setreadX-Auth-UserandX-Auth-Rightsoff the subrequest's response; twoproxy_set_headerput them onthe upstream request as
x-proxy-userandx-proxy-rights, the names the cluster's proxyauthenticator is configured to read.
proxy_set_headerredefines the field rather than appending, so a browser-suppliedx-proxy-*header is replaced and cannot be used to forge an identity — including when the value is empty.
What does not change
No new environment variable, so nothing to add to
.env.example, the Dockerfile or any composefile. The
Authorizationheader the gate already sends is untouched; retiring it belongs with thesecurity plugin roll-out, and removing it now would break deployments whose cluster uses basic auth.
The
/check_opensearch/block, the 401 login redirect and the 403 pass-through are unchanged.The added nginx variables are lowercase, so
script/entrypoint.sh's uppercase-onlyenvsubstlistleaves them intact — the same reason
$backendand$opensearchsurvive rendering.A backend that does not set the two response headers leaves these variables empty, and nginx then
omits the header entirely rather than sending a blank one. This gate is therefore safe to merge
before the backend that fills it.
Tests
nginx -tsuccessful through the real entrypoint rendering path. Verified on a local stack withthis file mounted as the live gate: anonymous
302to/front/login, authenticated200atDashboards, and the rendered configuration showing all four directives with their nginx variables
intact. A client-supplied
x-proxy-userwas replaced rather than passed through, both with a valuepresent and with the variable empty.
Note this hop ends at Dashboards, not the cluster: Dashboards relays a header onwards only if it is
listed in
opensearch.requestHeadersAllowlist, whose 3.8.0 default is[authorization, securitytenant]. Adding these two is part of the security plugin ticket, and until then they stopthere.
Follow-ups
openimis-dist_dkrcarries a byte-identical copy of this file and mounts it over this image's, sothe same change goes there in a companion PR; the two must not diverge. The backend that sets the
headers is a third PR, in
openimis-be-opensearch_reports_py.Ticket: OP-3140