One instance of Cloudera Manager (CM) can manage N clusters. In the current Role Based Access Control (RBAC) model, CM users hold privileges and permissions across everything in CM’s purview (including every cluster that CM manages). For example, Read-Only user John is a user who can perform all the actions of Read-Only users on all clusters managed by CM. The “Cluster Admin” user Chris is a cluster administrator of all the clusters managed by CM. This RBAC model has been sufficient to satisfy a number of use-cases. However, as the number of clusters managed by CM grows, there is an increasing demand for more fine-grained access control, which allows for different degrees of resource isolation. Some sample use-cases are listed below:
- An admin who oversees operations of an instance of Cloudera Manager that manages N clusters may want to create Cluster Admin users who can each administer their own cluster but not see any of the other clusters.
- There might be a super-secret cluster that CM manages, which should only be seen by the admin and not any other users.
- An admin may need to create users who can do certain limited operations (like Limited Operator)/ administrative operations on one cluster but not do anything but view other clusters (Read-Only).
With the new RBAC model, it will be possible to create users who have permissions only on a single specific cluster or a set of clusters. Users can also be configured to have multiple roles, each on different clusters. For example, it’s possible to have a user John with Cluster Admin privileges on ClusterABC and only Read-Only privileges on ClusterXYZ.
Consider a CM that manages 2 clusters – Cluster 1 and Cluster 2.Let’s walk through the experience for the user Jane, who has Cluster Admin privileges on Cluster 2. She logs in:
She sees only the cluster(s) she is authorized to see, namely Cluster 2. In the previous RBAC implementation, Jane could see and perform actions on all the clusters. Now, she can only see and perform actions on Cluster 2.
All the pages that display information about any activity on the clusters managed by CM will only show information about Cluster 2 to Jane.
For example, the cluster status page only shows Cluster 2.
The Commands page only shows commands on Cluster 2.
The user Jane can perform all her duties on Cluster 2 but not on any other clusters. Her access is isolated.
When external authentication/authorization is in use, it’s now possible to manage all external entities like LDAP groups or SAML attribute from the Roles page and configure them with these new cluster-specific permissions.
To use the new model, log in to the Cloudera Manager Admin Console with an account that has the admin or user admin roles. An admin logged in to CM, can navigate to the “Users and Roles” page, and configure these cluster-specific permissions.
The “Users and Roles” page allows the admin to view and configure users and their permissions.
The “Roles” tab on this page allows the admin to view and configure roles that can be assigned to any user or external entities like LDAP groups.
A cluster-specific role can be added through this page, and later assigned to a user.
A new user can be created and assigned this new cluster-specific cluster admin role.
All these operations are also supported via REST APIs. New APIs have been introduced to manage permissions of users and external entities.
In the API call, Auth Roles refer to the new granular role that has an associated privilege and scope. They are identified using UUIDs and referenced by them. They contain a base role, such as Cluster Administrator, that determines the privilege and a list of clusters that represents the scope of the privileges. Users and external entities that need these privileges can be associated with these auth roles. All CRUD operations are supported.
-------- python code snippet ----------
import cm_client
auth_roles_api = cm_client.AuthRolesResourceApi(api_client)
authRoles = {
“Items” : [{
"clusters" : [ { “clusterName” : “ClusterA” }],
"users" : [ {
"name" : "user2"
}, {
"name" : "user1"
} ],
"externalUserMappings" : [ {
"uuid" : "uuid2",
"name" : "ldap_group_special_admins",
"type" : "LDAP"
}, {
"uuid" : "uuid1",
"name" : "ldap_group_admins",
"type" : "LDAP"
} ],
"displayName" : "Cluster Administrator on ClusterA",
"baseRole" : {
"displayName" : "Cluster Administrator",
"uuid" : "b5c8c8ee-3621-4e0f-a1ee-77ae9319fba4"
},
}]
}
auth_roles_api.create_auth_roles(body=dict(items=authRoles))
--------------------------------
The above code snippet creates a new auth role that actually represents Cluster Admin scoped to ClusterA. The same API call also associates users user1 and LDAP groups ldap_group_special_admins, ldap_group_admins to this new auth role, which essentially means, that user1 and any user part of ldap_group_special_admins or ldap_group_admins are Cluster Admins of ClusterA. They cannot see any other cluster managed by this instance of CM. For example, if this user issues an API call to GET all /clusters, she would see only her own cluster.
Cloudera Manager, thus, supports fine grained cluster granular access control. This feature can be used through either the Cloudera Manager Admin Console or the REST API. It is available starting with Cloudera Manager 6.0.
Editor's Choice
1) How does one setup fine -grained data access rules like Role1 or user1 can access only these HDFS folders or these Hive schemas, Hive tables?
2) Are there APIs that allow this setup of fine-grained data access rules?