kumaab opened a new pull request, #1096:
URL: https://github.com/apache/ranger/pull/1096
## What changes were proposed in this pull request?
- Adds SPIFFE-based service-to-service authentication as a second
trusted-header path, alongside the existing username-header (user identity)
authentication, in Ranger Admin and the PDP server.
- When the username header is absent, the server reads a configured SPIFFE
header and extracts the trailing service-account segment from the SPIFFE ID
(spiffe://<trust-domain>/ns/<ns>/sa/<service-account> → <service-account>),
authenticating the caller as that service account.
- Adds a shared SpiffeIdUtil helper in common-utils so Admin and PDP share
identical parsing semantics.
- New config:
- ranger.admin.authn.header.spiffe (Admin)
- ranger.pdp.authn.header.spiffe (PDP).
- By design the config accepts a comma-separated list of SPIFFE header names
while also fully supporting a single header name (a single value is just a list
of one).
- Precedence: the username header always wins; among SPIFFE headers, the
first one carrying a well-formed SPIFFE ID is used, and malformed values are
skipped.
- Backward compatible: the existing *.authn.header.enabled flag continues to
gate the entire trusted-header path.
## How was this patch tested?
- Added unit tests for SpiffeIdUtil, the Admin RangerHeaderPreAuthFilter,
and the PDP HttpHeaderAuthNHandler.
- Verified end-to-end in the dev-support/ranger-docker stack (Admin + PDP).
- Single-ID scenarios: no header → 401; valid SPIFFE header → authenticated
as the service account; malformed SPIFFE ID → 401.
- Multiple-ID scenarios: falls through to a later header when an earlier one
is absent; the first well-formed header wins even when a later header would
resolve to a different valid identity; a malformed leading header is skipped so
resolution continues to the next configured header.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
