server: avoid considering non-authenticated reqs as root-authenticated #45125
Conversation
This file contains 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
|
This change is |
This patch fixes `/health` by ensuring it does not require authentication, does not perform KV operations and does not expose sensitive details. Reminder, for posterity: - `/_status/v1/details` exposes health, readiness and node details, which is potentially privileged information. This requires an authenticated admin user. It also performs a KV operation for authentication and thus subject to cluster availability. - `/_admin/v1/health` only exposes health and readiness. It is non-privileged and does not require authentication. It does not perform KV operations and is thus not subject to cluster availability. - `/health` is now an alias for `/_admin/v1/health`. (It used to be a non-authenticated alias for `/_status/v1/details` which was both a UX and security bug. See release notes below for details.) - both `/health` and `/_admin/v1/health` accept a boolean flag e.g. via `?ready=1`. When `ready` is specified, a HTTP error is returned if the node is up but not able to accept client connections, or not live, or shutting down. When `ready` is *not* specified, a HTTP success is always returned if the node is up, even when it cannot accept client connections or is not live. Release note (security update): The non-authenticated `/health` HTTP endpoint was previously exposing the private IP address of the node, which can be privileged information in some deployments. This has been corrected. Deployments using automation to retrieve a node build details, address details etc should use `/_status/v1/details` instead and use a valid admin authentication cookie. Release note (bug fix): Accesses to `/health` do not hang any more when a node is currently under load or if a system range is unavailable.
Prior to this patch, the impl code for the various RPCs were assuming that the lack of a username in their incoming context implied that the connection *necessarily* had already been authenticated for the `root` user. This assumption does not seem to be substantiated anywhere. Even if the current structure of the code may have made this true by accident, there is no guardrail that enforces it. This patch rectifies the situation by lifting the assumption. This changes the requirement for the conn acceptors to always populate the username metadata. Release note: None
knz
force-pushed
the
20200214-disauth
branch
from
c86376f
to
d7b3ca9
Compare
|
This PR was an attempt to fix some of the shortcomings now identified in #96427. It was very incomplete, and also based off incomplete understanding. We should re-do this work. |
DB Server & Security
automation
moved this from Tech debt & Grouping attempts
to Done 21.2
Feb 2, 2023
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.
Fixes #45018.
First commit from #45119.
Prior to this patch, the impl code for the various RPCs
were assuming that the lack of a username in their incoming context
implied that the connection necessarily had already been
authenticated for the
rootuser.This assumption does not seem to be substantiated anywhere.
Even if the current structure of the code may have made this true
by accident, there is no guardrail that enforces it.
This patch rectifies the situation by lifting the assumption.
This changes the requirement for the conn acceptors to always
populate the username metadata.
Release note: None