Skip to content

OP-3140: Forward the auth_check identity headers upstream - #239

Open
yakusevv wants to merge 1 commit into
developfrom
feat/opensearch-identity-headers
Open

yakusevv wants to merge 1 commit into
developfrom
feat/opensearch-identity-headers

Conversation

@yakusevv

Copy link
Copy Markdown
Contributor

Why

conf/locations/opensearch.loc authorizes every Dashboards request against openIMIS rights through
an auth_request subrequest to opensearch_reports/auth_check, and then discards everything that
subrequest 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. Two auth_request_set read
X-Auth-User and X-Auth-Rights off the subrequest's response; two proxy_set_header put them on
the upstream request as x-proxy-user and x-proxy-rights, the names the cluster's proxy
authenticator is configured to read.

proxy_set_header redefines the field rather than appending, so a browser-supplied x-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 compose
file. The Authorization header the gate already sends is untouched; retiring it belongs with the
security 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-only envsubst list
leaves them intact — the same reason $backend and $opensearch survive 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 -t successful through the real entrypoint rendering path. Verified on a local stack with
this file mounted as the live gate: anonymous 302 to /front/login, authenticated 200 at
Dashboards, and the rendered configuration showing all four directives with their nginx variables
intact. A client-supplied x-proxy-user was replaced rather than passed through, both with a value
present 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 stop
there.

Follow-ups

openimis-dist_dkr carries a byte-identical copy of this file and mounts it over this image's, so
the 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

@codacy-production

Copy link
Copy Markdown

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants