[
https://issues.apache.org/jira/browse/OMID-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17937325#comment-17937325
]
Istvan Toth edited comment on OMID-304 at 3/24/25 7:13 AM:
-----------------------------------------------------------
Omid Zookeeper Authentication Design Document
h1. Motivation
Traditionally Big Data clusters did not focus on security, and relied on
firewalls and limited access for security.
The requirements are changing, and many users require encryption and/or
authorization for all network traffic.
While this is foremost a regulatory requirement, implementing access controls
does increase security and protects against attacks.
h1. Scope
This applies to Omid's direct uses of ZK:
* HA
* ZK timestamp store
The ZK used by HBase is outside the scope, unless it interferes with the above
use cases.
Zookeeper has a very flexible authentication and authorization framework, but
as Omid is tied to HBase, only the authorization method supported by HBase
(SASL) is considered.
h1. Subjects and permissions
Omid is a distributed system, its code is running in three environments:
* TSO server
* HBase coprocessors
* HBase client
The ZK timestamp store is only ever accessed from the TSOprocess (if
configured, as it is not the default)
The ZK HA nodes are only modified by the TSO process, and are read by the HBase
client and coprocessor components.
h1. Authenticating Omid
The Omid HBase client already supports logging into a Hadoop/HBase cluster.
The same Subject is used for authenticating to ZK.
Unless problems are found, the current authentication logic will be used
without changes.
{color:#FF0000}Q: Does the TSO log on to HBase (Kerberos) ?
{color}It has to when it uses HBaseCommitTable, but what happens when
InMemoryCommitTable is configured ? Do we even care ?
h1. The HBase solution for ACLs
HBase uses two roles, a superuser , and the client role, and marks some znodes
as "client readable"
Full access is provided to the creator of all Znodes. (usually the hbase
superuser)
Full access is provided for all Znodes to all principals in defined in the
*hbase.superuser* property
For Znodes which are _isClientReadable_ (as returned by the ZNodePaths class),
a world readable permission is also added.
h1. Setting the ACLs
We can pretty much copy the HBase logic for this.
Timestamp store Znodes are only used by the TSO processes, so only the TSO
principal needs to access them, we can treat them as the HBase treats the non
client readable Znodes.
The HA Znodes are only modified by the TSO processes, and only read by everyone
else, so they can be treated as client readable Znodes.
HBase uses some helper classes for handling the ACLs,Curator has built-in
support for that, so we only need to implement the Curator hooks.
was (Author: stoty):
Omid Zookeeper Authentication Design Document
h1. Motivation
Traditionally Big Data clusters did not focus on security, and relied on
firewalls and limited access for security.
The requirements are changing, and many users require encryption and/or
authorization for all network traffic.
While this is foremost a regulatory requirement, implementing access controls
does increase security and protects against attacks.
h1. Scope
This applies to Omid's direct uses of ZK:
* HA
* ZK timestamp store
The ZK used by HBase is outside the scope, unless it interferes with the above
use cases.
Zookeeper has a very flexible authentication and authorization framework, but
as Omid is tied to HBase, only the authorization method supported by HBase
(SASL) is considered.
h1. Subjects and permissions
Omid is a distributed system, its code is running in three environments:
* TSO server
* HBase coprocessors
* HBase client
{color:#FF0000}The first task is identifying which of these environments are
accessing ZK, and what operations they perform, for both (ZK, timestamp) use
cases.{color}
Based on this, we need to group the ZNodes created by Omid into classes which
can have the same ACLs applied to them.
h1. Authenticating Omid
The Omid HBase client already supports logging into a Hadoop/HBase cluster.
The same Subject is used for authenticating to ZK.
Unless problems are found, the current authentication logic will be used
without changes.
{color:#FF0000}Q: Does TSO log on to HBase when the ZK timestamp store is
configured ?{color}
If not, then we may need to change that.
h1. Setting the ACLs
See general considerations above for the different subjects and required
permissions.
We can define roles, and use fixed permissions for each role and class of
ZNodes, and specify a list of subjects per role.
This can be achieved by adding configurable lists for each class.
As all ZK access is done via Curator, we can implement this with an ACLProvider.
For example, if for the HA ZNodes, we want an ACL list like this:
SASL:omid_tso_subject@realm : CRDWA
SASL:hbase_server_subject@realm: R
SASL:phoenix_client_subject@realm: R
Then we can define a HA_TSO role (CRDWA) and a HA_CLIENT (R) role ( fixed in
code),
and the configuration could look something like:
subjects:
HA_TSO:
* SASL:omid_tso_subject@realm
HA_CLIENT:
* SASL:hbase_server_subject@realm
* SASL:phoenix_client_subject@realm
> Support Zookeper Authorization
> ------------------------------
>
> Key: OMID-304
> URL: https://issues.apache.org/jira/browse/OMID-304
> Project: Phoenix Omid
> Issue Type: New Feature
> Reporter: Istvan Toth
> Assignee: Istvan Toth
> Priority: Major
>
> Omid uses ZK directly both for HA and for its timestamp storage, but does not
> support authorization.
> This is not acceptable in some use cases.
> Add support for ZK authorization.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
