[
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/21/25 9:09 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
{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
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
The first task is identifying which of these environments are accessing ZK, and
what operations they perform, for both (ZK, timestamp) use cases.
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.
Q: Does TSO log on to HBase when the ZK timestamp store is configured ?
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)
