Ranger Policy Access

Overview

At checkout, the broker calls the Apache Ranger Admin REST API to create a policy granting the requesting user access to a specific resource — an HDFS path, Hive database/table, or HBase table. At checkin, the policy is deleted. No standing policies exist between sessions.

This pattern supports all Ranger-managed services in Cloudera: HDFS, Hive, HBase, Kafka, Ozone, and others.

Before You Begin

The broker is running and connected (see Getting Started)
curl and jq are installed on the broker host
The Ranger service account has the Admin role in Ranger Admin
The Ranger service name for the target component is known (e.g. mycluster_hive)

Checkout Routine

Environment variables:

Variable	Notes
`BRITIVE_USER_EMAIL`	Injected — requesting user’s email; used as the Ranger user
`ranger_url`	Ranger Admin base URL — set as a resource parameter
`ranger_service`	Ranger service name — set as a resource parameter
`ranger_user`	Ranger service account username
`ranger_password`	Ranger service account password — reference from Britive Secrets Store
`resource_path`	The resource to grant access to (e.g. `/data/finance` for HDFS, `mydb.transactions` for Hive)
`permissions`	Comma-separated Ranger permissions (e.g. `read,write` for HDFS, `select` for Hive)
`TRX`	Injected — used to uniquely name the policy per session

Create a Ranger policy:

# Derive the Ranger username from the email (strip domain)
RANGER_USER_NAME=$(echo "$BRITIVE_USER_EMAIL" | cut -d'@' -f1)

# Build the policy name using TRX for uniqueness
POLICY_NAME="britive-jit-${RANGER_USER_NAME}-${TRX}"

# Convert comma-separated permissions to JSON array
PERMS_JSON=$(echo "$permissions" | tr ',' '\n' | jq -R . | jq -s .)

# Create the policy via the Ranger Admin API
RESPONSE=$(curl --silent --user "${ranger_user}:${ranger_password}" \
  --request POST \
  "${ranger_url}/service/public/v2/api/policy" \
  --header "Content-Type: application/json" \
  --header "Accept: application/json" \
  --data "{
    \"name\": \"${POLICY_NAME}\",
    \"service\": \"${ranger_service}\",
    \"isEnabled\": true,
    \"isAuditEnabled\": true,
    \"resources\": {
      \"path\": { \"values\": [\"${resource_path}\"], \"isRecursive\": true, \"isExcludes\": false }
    },
    \"policyItems\": [{
      \"users\": [\"${RANGER_USER_NAME}\"],
      \"accesses\": $(echo $PERMS_JSON | jq '[.[] | {\"type\": ., \"isAllowed\": true}]'),
      \"delegateAdmin\": false
    }]
  }")

POLICY_ID=$(echo "$RESPONSE" | jq -r '.id')
echo "POLICY_ID=${POLICY_ID}"
echo "POLICY_NAME=${POLICY_NAME}"

The resource structure differs per Ranger service type. For Hive, use database and table keys instead of path. See Ranger REST API reference for the schema for each service type.

Checkin Routine

Delete the Ranger policy using the stored policy ID:

POLICY_ID=$(echo "$BRITIVE_RESPONSE" | jq -r '.POLICY_ID // empty')

if [ -n "$POLICY_ID" ]; then
  curl --silent --user "${ranger_user}:${ranger_password}" \
    --request DELETE \
    "${ranger_url}/service/public/v2/api/policy/${POLICY_ID}"
  echo "Policy ${POLICY_ID} deleted."
else
  # Fallback: look up by name using TRX
  RANGER_USER_NAME=$(echo "$BRITIVE_USER_EMAIL" | cut -d'@' -f1)
  POLICY_NAME="britive-jit-${RANGER_USER_NAME}-${TRX}"

  POLICY_ID=$(curl --silent --user "${ranger_user}:${ranger_password}" \
    "${ranger_url}/service/public/v2/api/policy?policyName=${POLICY_NAME}" \
    -H "Accept: application/json" | jq -r '.[0].id // empty')

  if [ -n "$POLICY_ID" ]; then
    curl --silent --user "${ranger_user}:${ranger_password}" \
      --request DELETE \
      "${ranger_url}/service/public/v2/api/policy/${POLICY_ID}"
    echo "Policy ${POLICY_NAME} (ID: ${POLICY_ID}) deleted."
  else
    echo "Policy not found — may have already been deleted."
  fi
fi

Hive-Specific Policy

For Hive, the resource keys are database and table instead of path. Replace the resources block in the checkout routine:

# Hive policy resource block
"resources": {
  "database": { "values": ["mydb"], "isExcludes": false },
  "table":    { "values": ["transactions"], "isExcludes": false },
  "column":   { "values": ["*"], "isExcludes": false }
}

Configure in Britive

Create a permission

Go to Resource Manager → Resource Type Permissions → New Permission. Set Language to Shell.

Paste the checkout and checkin routines. Declare variables:

Variable	System defined	Notes
`BRITIVE_USER_EMAIL`	Yes	Injected automatically
`TRX`	Yes	Injected automatically
`ranger_url`	No	Set per resource
`ranger_service`	No	Set per resource
`ranger_user`	No	Ranger Admin service account
`ranger_password`	No	Reference from Britive Secrets Store
`resource_path`	No	Set on the permission or profile
`permissions`	No	e.g. `read,write` or `select`

Set show_orig_creds = true — no credential is returned to the user; checkin confirmation is the only output.

Create a profile

Go to Resource Manager → Profiles → New Profile. Set an expiration (e.g. 4h). Under Associations, select the resource label(s) for your Cloudera clusters. Under Permissions, add the permission above.

Add a policy

Under Policies, assign members and configure approval conditions.

cloudera-ranger-access.tf

# Resource type — defines the ClouderaCDP class
resource "britive_resource_manager_resource_type" "cloudera" {
name        = "ClouderaCDP"
description = "Cloudera Data Platform cluster"

parameters {
  param_name   = "ranger_url"
  param_type   = "string"
  is_mandatory = true
}
parameters {
  param_name   = "ranger_service"
  param_type   = "string"
  is_mandatory = true
}
parameters {
  param_name   = "ranger_user"
  param_type   = "string"
  is_mandatory = true
}
}

# Permission — Ranger policy checkout/checkin
resource "britive_resource_manager_resource_type_permission" "ranger_policy" {
name             = "Cloudera-RangerPolicy-Access"
resource_type_id = britive_resource_manager_resource_type.cloudera.id
description      = "JIT access via ephemeral Apache Ranger policy"
code_language    = "Shell"
show_orig_creds  = true

checkout_code_file = "${path.module}/scripts/checkout.sh"
checkin_code_file  = "${path.module}/scripts/checkin.sh"

variables = ["BRITIVE_USER_EMAIL", "TRX", "ranger_url", "ranger_service", "ranger_user", "ranger_password", "resource_path", "permissions"]
}

# Resource label — categorize by environment
resource "britive_resource_manager_resource_label" "env" {
name        = "environment"
description = "Deployment environment"
label_color = "#2563eb"

values { name = "Production";  description = "Production clusters" }
values { name = "Staging";     description = "Staging clusters" }
}

# Resource — a specific Cloudera cluster
resource "britive_resource_manager_resource" "cdp_prod" {
name          = "cdp-prod-hive"
description   = "Production CDP cluster — Hive service"
resource_type = britive_resource_manager_resource_type.cloudera.name

parameter_values = {
  ranger_url     = "http://ranger.internal:6080"
  ranger_service = "mycluster_hive"
  ranger_user    = "britive_svc"
}

resource_labels = {
  environment = "Production"
}
}

# Profile — JIT Ranger policy access
resource "britive_resource_manager_profile" "ranger" {
name                = "CDP-RangerPolicy-Access"
description         = "JIT access to Cloudera resources via Ranger policy"
expiration_duration = 14400000   # 4 hours in milliseconds

associations {
  label_key = "environment"
  values    = ["Production"]
}
}

# Profile permission
resource "britive_resource_manager_profile_permission" "ranger" {
profile_id = britive_resource_manager_profile.ranger.id
name       = britive_resource_manager_resource_type_permission.ranger_policy.name
version    = "latest"

variables {
  name              = "resource_path"
  value             = "finance_db.transactions"
  is_system_defined = false
}
variables {
  name              = "permissions"
  value             = "select"
  is_system_defined = false
}
variables {
  name              = "ranger_password"
  value             = ""   # inject from Britive Secrets Store
  is_system_defined = false
}
}

# Profile policy
resource "britive_resource_manager_profile_policy" "ranger" {
profile_id  = britive_resource_manager_profile.ranger.id
policy_name = "CDP-RangerPolicy-AccessPolicy"

members = jsonencode({
  tags             = [{ name = "data-engineers" }]
  users            = []
  serviceIdentities = []
  aiIdentities     = []
})

condition   = jsonencode({ ipAddress = null, timeOfAccess = null })
access_type = "Allow"
consumer    = "resourceprofile"
is_active   = true
is_draft    = false
}

Verify

Check out the profile

Navigate to My Access → find the profile → Check Out.

Confirm the policy in Ranger Admin

Log in to Ranger Admin and go to the relevant service (e.g. Hive → Policies). A policy named britive-jit-<username>-<trx> should appear.

Access the resource

Connect to Hive, HDFS, or HBase using your existing credentials — the Ranger policy now allows the configured access.

# Hive example
beeline -u "jdbc:hive2://hiveserver:10000" -n jdoe -e "SELECT * FROM finance_db.transactions LIMIT 10;"

Check in

Return to My Access → Check In.

Confirm the policy is deleted

In Ranger Admin, the britive-jit-<username>-<trx> policy should no longer appear. Repeat the data access command — it should fail with Permission denied.

Troubleshoot

Symptom	Cause	Fix
`HTTP 400` on policy create	Wrong resource key for service type	Hive uses `database`/`table`, HDFS uses `path` — check the Ranger API schema for your service
Policy created but access still denied	Ranger policy cache not refreshed	Ranger plugins sync on a schedule (default 30s) — wait and retry
`HTTP 404` on checkin	Policy ID not found — may have expired or been manually deleted	Confirm `POLICY_ID` is passed correctly via the response; the fallback name lookup handles this case
Policy not deleted at checkin	Checkin routine ran with wrong `TRX`	Verify `TRX` is declared as a system-defined variable — Britive injects the same value for checkout and checkin
Ranger Admin unreachable from broker	Network or firewall block	Check that TCP port 6080 (or 6182 for TLS) is open between broker and Ranger Admin host

Last updated on July 8, 2026

Getting Started