morningman opened a new pull request, #68220:
URL: https://github.com/apache/doris/pull/68220
### What problem does this PR solve?
Issue Number: None
Related PR: #68203 (documents the behaviour; this PR changes it)
Problem Summary:
A Ranger policy item can name users, groups and roles. The requests the
`ranger-doris` and `ranger-hive`
sources build carry no groups - Doris has none of its own to hand over - so
every policy item written
against a group never matches: an allow on a group grants nothing to a Doris
user, a row filter or a mask
on a group does not apply, and a **deny on a group is silently ignored**
while a user-level allow on the same
table still admits the user. Operators who manage access by Ranger group (so
that nobody edits a policy
every time somebody joins a team) see the user denied on everything, down to
`SHOW DATABASES` and
`SWITCH`, and it starts working the moment the same user is put on the item
directly.
Ranger's answer for a plugin that cannot compute groups itself is the **user
store** - the users and groups
Ranger Admin holds, kept current by usersync - which a plugin downloads next
to its policies. Ranger 2.5+
reads the requesting user's groups out of it when
`ranger.plugin.<type>.use.rangerGroups=true`; the
plugin library on branch-3.0/2.1 is 2.4.0, which has no such setting, so on
those branches no
configuration can make group items work.
What this PR does:
- `RangerUserStoreGroups` (ranger-common): the two Ranger plugins Doris
embeds put the user store
enricher on the service definition they download (`setPolicies`), exactly
as `RangerBasePlugin` does for
`use.rangerGroups`, and the request builders read the user's groups out of
the downloaded store and set
them on every request (`RangerAccessRequestImpl.setUserGroups`). This does
not depend on the Ranger
version the plugin was built against.
- On by default. `ranger.plugin.doris.use.rangerGroups=false`
(`ranger.plugin.hive.` for the catalog-level
source) switches it off and restores the previous requests; the property
is the one Ranger itself reads
for the same thing, so one setting decides both. The refresh interval and
retriever class are read under
Ranger's own option names (`userStoreRefresherPollingInterval`, default
60000 ms).
- Each plugin logs one line at start-up saying whether groups are attached
and how to switch it off.
- Regression: `ranger_p2/test_ranger_group_policy` writes an access policy,
a row filter, a mask and a
deny against a Ranger group only, and checks them as a member of that
group, then after leaving it.
`httpTest` gains `op "put"` for the Ranger user update that bumps the user
store version.
Verified end to end against the `docker/thirdparties` Ranger (Admin 2.4.0):
group allow / row filter /
mask apply, a group deny outranks a user allow, a Ranger role granted to a
group resolves, leaving the group
revokes within one user store refresh, and `use.rangerGroups=false` gives
the previous behaviour.
### Release note
Ranger policy items written against a Ranger **group** now apply to Doris
users who are members of that
group in Ranger, for both the `ranger-doris` and `ranger-hive` sources:
allow items, deny items, row filters
and column masks. The plugin downloads Ranger's user store for this
(refreshed every 60 seconds by default;
`userStoreRefresherPollingInterval` in `ranger-<type>-security.xml` changes
it). Deployments whose Ranger
services already hold group items will see them take effect after upgrading;
set
`ranger.plugin.doris.use.rangerGroups=false` (or
`ranger.plugin.hive.use.rangerGroups=false`) to keep the
previous, user-and-role-only evaluation.
### Check List (For Author)
- Test
- [x] Regression test
- [x] Unit Test
- [x] Manual test (add detailed scripts or steps below)
- [ ] No need to test or manual test. Explain why:
- Behavior changed:
- [ ] No.
- [x] Yes. Group items in Ranger policies are evaluated (see release
note); opt-out property above.
- Does this need documentation?
- [ ] No.
- [x] Yes. (ranger.md: group-based policies + the two properties)
### Check List (For Reviewer who merge this PR)
- [ ] Confirm the release note
- [ ] Confirm test cases
- [ ] Confirm document
- [ ] Add branch pick label
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
