[
https://issues.apache.org/jira/browse/HBASE-1697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell resolved HBASE-1697.
-----------------------------------
Resolution: Fixed
> 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
>
> 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 was sent by Atlassian JIRA
(v6.2#6252)
