The ZooKeeper access control lists

ZooKeeper's data model provides a mechanism to control the access to znodes using ACL. While creating a znode, the ACLs determine the permissions with respect to the various operations that you can perform on the znodes. The ZooKeeper ACL model is similar to the Unix/Linux file permissions in terms of permitting or preventing operations being done on a znode by setting/unsetting permission bits. However, the ZooKeeper node doesn't have the concept of ownership, which is present in the Unix/Linux filesystem. ACLs are determined on the basis of the authentication mechanism of the client and the ZooKeeper service.

ZooKeeper provides the following built-in authentication mechanisms based on ACLs:

  • World: This represents anyone who is connecting to the ZooKeeper service
  • Auth: This represents any authenticated user, but doesn't use any ID
  • Digest: This represents the username and password way of authentication
  • IP address: This represents authentication with the IP address of the client

In addition to the authentication schemes mentioned in the preceding list, ZooKeeper also supports a pluggable authentication mechanism, which makes it possible to integrate third-party authentication schemes if needed. Any authentication schemes in ZooKeeper consist of the following two main authentication operations:

  • Firstly, the authentication framework in ZooKeeper authenticates the client. The client authentication occurs when the client connects to the ZooKeeper service by validating client information.
  • Secondly, the authentication framework finds the entries in the ACL, which correspond to the client. ACL entries are pairs that consist of <IDs, Permissions> pairs, where IDs are some strings that identify the client.

An important point about znode ACLs is that the ACL associated with a particular znode doesn't propagate to its children. A client's authentication with ZooKeeper is optional; if the ACLs associated with a znode require a client to authenticate, then it must authenticate using any of the previously mentioned authentication mechanisms. An ACL is the combination of an authentication mechanism, an identity for that mechanism, and a set of permissions.

ZooKeeper's ACLs support the following permissions:

Operation

ACL Permission

CREATE

Creates a child znode

READ

Gets a list of child znodes and the data associated with a znode

WRITE

Sets (writes) data to a znode

DELETE

Deletes a child znode

ADMIN

Sets ACLs (permissions)

Any client that is connecting to a ZooKeeper service has the permission to check the existence of a znode. This exist operation is permission-free, which allows to retrieve the stat structure of a znode. We will read about the stat structure of ZooKeeper in the next section.

There are a number of predefined ACLs in ZooKeeper. These IDs, as defined by ZooKeeper ACLs, are shown in the following table:

ACL

Description

ANYONE_ID_UNSAFE

This ID represents anyone

AUTH_IDS

This is used to set ACLs, which get substituted with the IDs of the authenticated client

OPEN_ACL_UNSAFE

This denotes a completely open ACL, and grants all permissions except the ADMIN permission

CREATOR_ALL_ACL

This ACL grants all the permissions to the creator of the znode

READ_ACL_UNSAFE

This ACL gives the world the ability to read

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.149.242.118