kumaab opened a new pull request, #1257:
URL: https://github.com/apache/ranger/pull/1257
## What changes were proposed in this pull request?
- Config super users and groups (`ranger.admin.super.users` /
`ranger.admin.super.groups`, added in RANGER-5627) are meant to give system
admin privileges. Since KMS is out of scope for this feature, this change
removes KMS privileges from super users and fixes related bugs from RANGER-5627.
- **KMS resources, audits and UI.**
- *Before*: the check that stops system admins from changing the KMS
service-def was skipped for super users. They had the Key Manager module in
their session and profile. Because of the key-admin flag,
`/xaudit/access_audit` and the admin audit log (`/assets/report`) showed them
only KMS entries, while `/assets/accessAudit` showed everything.
- *After*: they follow system admin rules. Changes to the KMS service-def
are rejected, KMS audits are excluded everywhere, and there is no Key Manager
module. As for system admins, KMS services (such as `dev_kms`) are still listed
and can be created.
- **Visibility of KMS users.**
- Before: `checkUserAccessible`, `hasAccessToGetUserInfo` and
`searchXUsers` were bypassed for super users, so they could look up and list
key-admin and key-auditor users.
- After: they get system admin visibility (sys admin, auditor and user
roles only). Two exceptions are kept: `rangerusersync`, when configured as a
super user, still sees all users, and a super user can always read its own
record.
- **Grant/revoke through plugins.** Plugin grant and revoke requests are
rejected when the grantor has an auditor role in the Ranger DB. Config super
users are now exempt from this check, since they act as system admins whatever
their DB role. No other grantor is affected.
**Fixes**:
- **Super users were blocked as auditors.**
- Before: `isAuditUserAdmin()` and `isAuditKeyAdmin()` returned true for
every super user. So `blockAuditorRoleUser()` rejected them wherever auditors
are rejected.
- After: super users are not treated as auditors, whatever their DB role.
- **Other users were shown with the super user's roles**
- When a super user loaded another user's details
(`UserMgr.mapXXPortalUserToVXPortalUser`), that user's roles were replaced with
`ROLE_SYS_ADMIN`.
- After: the super user's roles apply only to its own record. Other users
are shown with their roles from the Ranger DB.
- **Checks on a super user's account used its super-user roles instead of
its DB roles**.
- Before: when a regular system admin (not a super user) created or
updated an account that is a super user through the `/xusers` APIs,
`checkUserAccessible` used that account's super-user roles
(`UserMgr.getRolesByLoginId`). On master these always included
`ROLE_KEY_ADMIN`, so the check rejected the request, even if the account's only
DB role was `ROLE_USER`.
- After: new `UserMgr.getDBRolesByLoginId` returns only the roles stored
in the Ranger DB, and `checkUserAccessible` uses it. A system admin can create
or update a super-user account under the same rules as any other account, and
the request is rejected only if that account has a KMS role in the DB.
## How was this patch tested?
- Unit tests
- Live setup: Ranger Admin and Postgres in Docker, built from this branch.
Super users were configured by name, by group, and as SPIFFE IDs, including
super users with a key admin or auditor role in the DB.
- 88 REST checks pass: 46 with basic auth, and 42 with header auth
(X-Spiffe-Id, X-Forwarded-User).
REST checks run as super users:
- `GET /users/profile`: shows only `ROLE_SYS_ADMIN` and no Key Manager
module, whatever the DB role.
- `GET /xusers/users`, `/xusers/users/{id}`,
`/xusers/users/userName/{name}`: KMS users are hidden or return 403, and other
users show their DB roles. A super user can look up its own record, and
`rangerusersync` can look up KMS users.
- `PUT /xusers/secure/users/{id}`: updating a KMS user is rejected. A system
admin can't update a super user who has a key admin role in the DB.
- `PUT /xusers/secure/users/roles/userName/{name}`: assigning
`ROLE_KEY_ADMIN` is rejected, and so is changing one's own roles. A super user
with an auditor role in the DB can change other users' roles.
- `PUT /plugins/definitions/{id}` for KMS is rejected. `GET
/plugins/definitions` doesn't list KMS. `GET
/plugins/policies/service/name/dev_kms` returns no policies.
- `POST /plugins/services/grant|revoke/dev_hdfs`: a grantor with only the
system admin role in the DB gets 200. A grantor that also has an auditor role
in the DB gets 403, unless it is a config super user, in which case it gets 200.
- A proxy roles header of `RANGER_ROLE_KEY_ADMIN` gives a super user no KMS
access.
Where KMS rules don't apply, super users get the same results as a regular
system admin.
--
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]
