Cloudera Docs

Using Ranger with Ozone

You can use Apache Ranger to secure access to your Ozone data. For Ozone to work with Ranger, you can use Cloudera Manager and enable the Ranger service instance with which you want to use Ozone.

  1. Go to the Ozone service.
  2. Click the Configuration tab.
  3. Search for ranger_service.
  4. Select the RANGER service checkbox.
  5. Enter a Reason for Change, and then click Save Changes to save the property changes.
  6. Restart the cluster.
Set up policies in Ranger for the users to have the right access permissions to the various Ozone objects such as buckets and volumes.

When using Ranger to provide a particular user with read/write permissions to a specific bucket, you must configure a separate policy for the user to have read access to the volume in addition to policies configured for the bucket.

For example,
  • user/group -> Allow Read on Volume=testvol, Bucket=testbucket1.
  • user/group -> Allow All (including delete on) on Volume=testvol, Bucket=testbucket1, Keys=*
To disallow users to delete volumes or buckets:
  • user/group -> Allow Read on Volume=testvol, Bucket=testbucket1. Deny Delete on Volume=testvol, Bucket=testbucket1
  • user/group -> Allow All (including delete on) on Volume=testvol, Bucket=testbucket1, Keys=*

Further, if Infra-Solr is managed by Ranger, the Ozone Manager principal (om) must have access to Infra-Solr. You can provide access to the Ozone Manager principal by adding om to the RANGER_AUDITS_COLLECTION Solr collection for cm_solr on Ranger.

Ranger policies with Ozone resources

For Ozone resources, including volume, bucket, and key, you must define separate Ozone policies to grant access at each level of the resource hierarchy. Additionally, you can specify a wildcard ("*") character at a child resource level to grant access at the parent level.

Let's say you create an Ozone policy (for example, Policy1) as follows:
Volume: "testvolume"
Bucket: "testbucket"
Key: "*"
Users: "hrt_1", Permission: "Read"
This policy applies only to all keys under the testbucket bucket and does not grant permission to access the testvolume volume. To allow access to the volume resource, you need a separate policy (for example, Policy2) for testvolume which grants read access as follows:
Volume: "testvolume"
Users: "hrt_1", Permission: "Read"
Now, if you have multiple keys under the testbucket bucket and want to define a policy that grants read access only to a specific key (for example, ext), update Policy1 as follows:
Volume: "testvolume"
Bucket: "testbucket"
Key: "ext"
Users: "hrt_1", Permission: "Read"
When you attempt to list the ext key using the following command:
hdfs dfs -ls ofs://ozone1753202391/testvolume/testbucket/ext/
access is expected to be denied with the following error:
User hrt_1 doesn't have READ permission to access bucket Volume:testvolume Bucket:testbucket.

This occurs because Policy1 is now defined only for the ext key, and you need a separate policy to grant access to the bucket (assuming Policy2 is already defined for the volume). Any time you have a specific resource at the child level, it means you are writing policies for that level of the resource hierarchy. Having wildcard at a resource level is another way of specifying the policy for the parent. That is why when you have "*" for the key, READ access for the bucket is authorized, but for volume, the access is still denied until a separate policy is configured for the volume resource.