Cloudera Docs

Creating the Ranger role for Ozone STS

Create the Ranger role that Ozone STS uses to generate session credentials (access key and secret) for Cloudera Iceberg REST Catalog.

hive is the identity that Cloudera Iceberg REST Catalog uses to obtain short-lived credentials from IDBroker on behalf of external clients, so the Ranger role that Ozone STS uses to generate session credentials must grant that identity Assume Role access.

  1. In Ranger, go to Settings > Roles, then click Add New Role to create the sts-assume-role role.
    Select the hive user when creating the role.
    Figure 1. Creating the sts-assume-role Ranger role
  2. Go to Resource Policies > cm_ozone service and create the Assume Role Policy.
    1. Add the sts-assume-role as role under Resources.
  3. Grant the hive user Assume Role access on the sts-assume-role role.
    Figure 2. Creating the Assume Role policy
  4. Grant the sts-assume-role role read access on the Cloudera Object Store (powered by Apache Ozone) volume, bucket, and key resources that back the shared tables.
    • This grant requires the Ranger action-matcher condition for the Ozone service definition to be enabled.
    • When you author resource paths for a policy that covers a table stored on Ozone, use the translated s3a:// link bucket path (for example, s3a://[***VOLUME***]-[***BUCKET***]/...), not the original ofs:// location. Cloudera Iceberg REST Catalog derives IDBroker policy paths and inline loadTable credential prefixes from this translated link bucket, so a policy written against the raw ofs:// path does not match.
    1. Edit your Ozone volume policy (for example, the default all - volume policy) and add the sts-assume-role role to the Allow Rules with read permissions.
      Figure 3. Ozone volume policy
    2. Edit your Ozone bucket policy (for example, the default all - volume, bucket policy) and add the sts-assume-role role to the Allow Rules with read permissions.
      Figure 4. Ozone bucket policy
    3. Edit your Ozone key policy (for example, the default all - volume, bucket, key policy) and add the sts-assume-role role to the Allow Rules with read permissions.
      Figure 5. Ozone key policy
  5. Generate the Ozone S3 access key and secret for the hive user.

    These credentials belong to the identity that was granted Assume Role access. Save them into the Knox IDBroker aliases in Configuring the Knox IDBroker for Ozone S3 environments.

    Authenticate as the hive Kerberos principal by using the Hive Metastore keytab present on the host you are configuring, and then retrieve the secret:

    kinit -kt [***HIVE_KEYTAB_PATH***] hive/[***HMS_HOST***]@[***REALM***]
ozone s3 getsecret

    The ozone s3 getsecret command returns the Ozone S3 access key (the Kerberos principal) and secret:

    awsAccessKey=hive/[***HMS_HOST***]@[***REALM***]
awsSecret=[***OZONE_S3_SECRET_KEY***]

Continue with Configuring the Knox IDBroker for Ozone S3 environments.