atlas-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hemanth Yamijala (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ATLAS-572) Handle secure instance of Zookeeper for leader election.
Date Thu, 31 Mar 2016 09:42:25 GMT

    [ https://issues.apache.org/jira/browse/ATLAS-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15219675#comment-15219675
] 

Hemanth Yamijala commented on ATLAS-572:
----------------------------------------

Did some more research on the ACLs bit. There are two forms of znodes created for the Atlas
HA:
* znodes created transparently by curator (mainly as part of the recipes - leader latch, shared
lock etc)
* znodes created to store the application state - currently the active server address.

Right now, these are automatically created with world readable ACLs (in Zookeeper terms: {{world:anyone:cdarw}}).
To support secure installations, it would be ideal to have ACLs on these znodes that lock
down access. The most secure form would be to only allow the Atlas service instances to have
full access. I assume that for debugging / operations, an admin who sets up the identity of
the Atlas service, could identify herself to Zookeeper and still access the znodes.

There are various schemes available with Zookeeper for setting ACLs: https://ihong5.wordpress.com/2014/07/24/apache-zookeeper-setting-acl-in-zookeeper-client/
is a good introduction I found, and of late a very enterprise-y scheme used is the SASL ACL
scheme: https://cwiki.apache.org/confluence/display/ZOOKEEPER/Zookeeper+and+SASL. I suppose
given the diversity of deployments possible, providing a config option to specify the scheme
to use would be a flexible approach.

To that effect, the proposal is to introduce two config options:
* an option for specifying the scheme to use for the ACL: This would be a string of the form
{{scheme:identity}}. This scheme would be used to create a full control ACL for this identity.
* an option for specifying the corresponding auth scheme to use: As seen in the first link
mentioned here, one can use different auth schemes for a given ACL scheme; hence providing
the option. This would be a string of the form {{scheme:auth}}

If the ACL option is not defined, it would default to an unsecure, open mode.
If specified, I'll make modifications to use the ACLs for all znodes created either by curator
recipes or by the Atlas code. For the curator recipes, I guess this would happen by using
a curator {{ACLProvider}} implementation. For self created znodes, we should the corresponding
curator APIs to set the ACL.

Will start implementing on these lines. Let me know if there are any issues.

> Handle secure instance of Zookeeper for leader election.
> --------------------------------------------------------
>
>                 Key: ATLAS-572
>                 URL: https://issues.apache.org/jira/browse/ATLAS-572
>             Project: Atlas
>          Issue Type: Sub-task
>            Reporter: Hemanth Yamijala
>            Assignee: Hemanth Yamijala
>
> ATLAS-511 introduces Zookeeper based leader election in unsecure mode. In this JIRA we
will make necessary changes for making Atlas work with secure Zookeeper installations.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message