[
https://issues.apache.org/jira/browse/HBASE-1697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12990709#comment-12990709
]
Gary Helmling commented on HBASE-1697:
--------------------------------------
Hi Suchi,
Thanks, that is great!
We've discussed per-KeyValue ACLs as a future feature, but have deferred the
implementation due to other HBase internal changes that would be required to
support them efficiently.
Our rough plan was to implement a new 'metacolumn' feature for HBase
(HBASE-2893). A 'metacolumn' would be a special, internal only (or coprocessor
only?) column family associated with each table. Table level and column family
level ACLs would still apply in the normal case, but the metacolumn would allow
storing per-row or per-KeyValue override ACLs directly inline with the row data.
For read operations, scans would then probably use a special filter to allow
specific KVs to be included in results back to the client. For write
operations, the org.apache.hadoop.hbase.security.rbac.AccessController.prePut()
method would check for entries in the row metacolumn in addition to the normal
ACLs.
See also HBASE-3435 for a discussion of adding per-column-qualifier ACLs to our
scheme. I have some work in progress that would enable column-qualifier ACLs
to be used. It incorporates the use of an AccessControlFilter to allow
returning only those KVs matching the granted column qualifiers for a scan.
I'll be posting a patch for that soon.
So summing it all up, we'd ultimately like to have a hierarchy for applying
ACLs as follows:
global -> table -> column family -> column qualifier -> row -> key value
The assumption so far has been that the ACLs granted at each level are additive
-- if I have "read" access at the table level, then you can't revoke that
access for specific KVs (and we don't have to continue checking for
authorization down the full hierarchy). This is mainly a performance
consideration. We can discuss if that meets your needs or not.
If you'd like to work out a way to collaborate on getting all of this done,
we'd love the help! Please email me directly at [email protected].
Best,
Gary
> Discretionary access control
> ----------------------------
>
> Key: HBASE-1697
> URL: https://issues.apache.org/jira/browse/HBASE-1697
> Project: HBase
> Issue Type: Improvement
> Components: security
> Reporter: Andrew Purtell
> Assignee: Andrew Purtell
> Fix For: 0.92.0
>
>
> Consider implementing discretionary access control for HBase.
> Access control has three aspects: authentication, authorization and audit.
> - Authentication: Access is controlled by insisting on an authentication
> procedure to establish the identity of the user. The authentication procedure
> should minimally require a non-plaintext authentication factor (e.g.
> encrypted password with salt) and should ideally or at least optionally
> provide cryptographically strong confidence via public key certification.
> - Authorization: Access is controlled by specifying rights to resources via
> an access control list (ACL). An ACL is a list of permissions attached to an
> object. The list specifies who or what is allowed to access the object and
> what operations are allowed to be performed on the object, f.e. create,
> update, read, or delete.
> - Audit: Important actions taken by subjects should be logged for
> accountability, a chronological record which enables the full reconstruction
> and examination of a sequence of events, e.g. schema changes or data
> mutations. Logging activity should be protected from all subjects except for
> a restricted set with administrative privilege, perhaps to only a single
> super-user.
> Discretionary access control means the access policy for an object is
> determined by the owner of the object. Every object in the system must have a
> valid owner. Owners can assign access rights and permissions to other users.
> The initial owner of an object is the subject who created it. If subjects are
> deleted from a system, ownership of objects owned by them should revert to
> some super-user or otherwise valid default.
> HBase can enforce access policy at table, column family, or cell granularity.
> Cell granularity does not make much sense. An implementation which controls
> access at both the table and column family levels is recommended, though a
> first cut could consider control at the table level only. The initial set of
> permissions can be: Create (table schema or column family), update (table
> schema or column family), read (column family), delete (table or column
> family), execute (filters), and transfer ownership. The subject identities
> and access tokens could be stored in a new administrative table. ACLs on
> tables and column families can be stored in META.
> Access other than read access to catalog and administrative tables should be
> restricted to a set of administrative users or perhaps a single super-user. A
> data mutation on a user table by a subject without administrative or
> superuser privilege which results in a table split is an implicit temporary
> privilege elevation where the regionserver or master updates the catalog
> tables as necessary to support the split.
> Audit logging should be configurable on a per-table basis to avoid this
> overhead where it is not wanted.
> Consider supporting external authentication and subject identification
> mechanisms with Java library support: RADIUS/TACACS, Kerberos, LDAP.
> Consider logging audit trails to an HBase table (bigtable type schemas are
> natural for this) and optionally external logging options with Java library
> support -- syslog, etc., or maybe commons-logging is sufficient and punt to
> administrator to set up appropriate commons-logging/log4j configurations for
> their needs.
> If HBASE-1002 is considered, and the option to support filtering via upload
> of (perhaps complex) bytecode produced by some little language compiler is
> implemented, the execute privilege could be extended in a manner similar to
> how stored procedures in SQL land execute either with the privilege of the
> current user or the (table/procedure) creator.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
