bharos commented on code in PR #12757: URL: https://github.com/apache/gravitino/pull/12757#discussion_r4149797511
########## design-docs/tag-based-access-control.md: ########## @@ -0,0 +1,767 @@ +<!-- + Licensed to the Apache Software Foundation (ASF) under one + or more contributor license agreements. See the NOTICE file + distributed with this work for additional information + regarding copyright ownership. The ASF licenses this file + to you under the Apache License, Version 2.0 (the + "License"); you may not use this file except in compliance + with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, + software distributed under the License is distributed on an + "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + KIND, either express or implied. See the License for the + specific language governing permissions and limitations + under the License. +--> + +# Design of Tag-Based Access Control in Gravitino + +**Status:** draft for discussion. The [open questions](#open-questions) are deliberately left +undecided in this revision, each presented with its options; decisions will be folded in after +review. + +Discussion: [#12619](https://github.com/apache/gravitino/discussions/12619) + +--- + +## Summary + +An access rule is a `Policy` of type `system_access_control` whose `content` carries a set of +privileges and a role condition. The policy is bound to a tag. Any object carrying that tag +becomes subject to the rule. + +```json +POST /api/metalakes/prod/policies +{ + "name": "certified_access", + "policyType": "system_access_control", + "enabled": true, + "content": { + "privileges": ["SELECT_TABLE", "MODIFY_TABLE"], + "applicableRoles": ["analyst", "data_engineer"] + } +} +``` + +``` +PUT /api/metalakes/prod/tags/certified/policies/certified_access + { "selector": { "type": "ALL_VALUES" } } + +POST /api/metalakes/prod/objects/TABLE/lakehouse.finance.orders/tags + { "tagsToAdd": [{ "name": "certified" }] } +``` + +Read together: *a caller holding either `analyst` or `data_engineer` may select from and modify +any table that carries the tag `certified`.* Any listed role satisfies the condition, and every +listed privilege is conferred to it. + +Only one thing is attached: the policy to the tag. The roles are values inside `content`, not a +second link. No new user-facing entity, REST resource or client API is introduced. + +--- + +## Background + +Gravitino authorizes metadata operations through RBAC. A grant names a securable object and a +privilege and binds them to a role; the authorization expression on each REST endpoint evaluates +those grants over the object's ancestor chain. + +Tags are a separate subsystem. They apply to catalogs, schemas, tables, views, topics, filesets, +models, columns and functions, carry assignment values (see +[tag-assignment-values.md](tag-assignment-values.md)), and inherit down the object hierarchy. +Policy-on-tag ([policy-on-tag.md](policy-on-tag.md)) lets governance policies be selected by those +tags. Authorization does not read tags at all. + +So a label cannot drive access. An organization that already tags tables `certified`, `pii` or +`data_domain=finance` must still issue grants object by object to act on those tags. New objects +need new grants, dropped objects leave stale ones, and the rule itself is written down nowhere — it +exists only as the pile of grants someone remembered to issue. + +--- + +## Scope + +### In this version + +- A rule of the form *(action, role condition)* bound to a tag. +- `ALLOW` only. +- Roles as the matched condition. +- Evaluation inside the existing authorization-expression path, composing with RBAC. Review Comment: Added a "Credential vending" section. Short version: this does reach storage, and that's intended. `getCredentials` is gated by `CAN_ACCESS_METADATA`, which a tag-conferred SELECT_TABLE or READ_FILESET satisfies. Read vs write is a second check for ANY_MODIFY_TABLE on the Iceberg REST path, ANY_WRITE_FILESET on the generic endpoint , and both privileges are allowlisted, so a tag can confer write too. The guarantee is symmetry: the same privilege granted through a role vends the same credential. A tag changes the route, not the reach. That's why the allowlist admits only data privileges. Where it ends: secrets are a separate endpoint requiring USE_SECRETS, which isn't allowlisted. How far a credential reaches once issued is the credential provider's business ; a token provider scopes it to the object's location, a static secret-key provider hands out the catalog's key pair, and a tag changes neither. Nothing recalls a credential once issued. And an engine holding its own storage credentials never asks Gravitino, so only the metadata operation is decided there. -- 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]
