User Role Management - Accidental Role Changes and Recovery

DataHub administrators or users with elevated privileges can accidentally change their own role while testing the user management CLI or API, potentially locking themselves out of administrative functions. This commonly occurs when experimenting with the `user upsert` CLI command or GraphQL mutations for user management. Once an admin reduces their own privileges (for example, from "Admin" to "Reader"), they cannot restore their original permissions through the UI, as they no longer have the necessary administrative access. This situation requires intervention from someone with GMS access or another administrator to restore the correct role.

Common Error Messages:

• "Insufficient privileges to perform this action" after role change
• "Access denied" when trying to access Settings or Admin features
• No error - UI simply doesn't show admin features anymore

You Might Be Asking:

• How do I restore admin access after accidentally downgrading my role?
• Can I change my own role back through the UI?
• Who can help if I lock myself out?
• How do I prevent accidental role changes?
• What's the proper way to test user role changes?
• Can support restore my admin access?

Immediate Recovery - Contact Support or Another Admin

If you've lost admin access:

1. Contact your DataHub support team or vendor - They can restore your role
2. Ask another admin - If another user has admin access, they can restore your role via UI
3. Use API with admin token - If you have a personal access token from before the change

Self-Service Recovery via CLI

If you still have CLI access to your DataHub instance:

This is applicable to CLI-based operations with existing admin token.

# Using datahub CLI with admin token
export DATAHUB_GMS_TOKEN="your_admin_token"

# Restore admin role
datahub user upsert \
  --urn "urn:li:corpuser:your_username" \
  --role "Admin"

# Verify the change
datahub get --urn "urn:li:corpuser:your_username" --aspect corpUserInfo

Recovery via Direct Database Access

For self-hosted DataHub with database access:

This is for DataHub Open Source deployments with direct database access.

# Connect to your DataHub MySQL/PostgreSQL database
mysql -h localhost -u datahub -p datahub_db

# Find the user's role aspect
SELECT * FROM metadata_aspect_v2 
WHERE urn = 'urn:li:corpuser:your_username' 
AND aspect = 'roleMembership';

# Update role to Admin
# (Specific SQL varies based on schema version)

GraphQL Mutation for Role Update

Another admin can execute this mutation:

mutation updateUserRole {
  updateCorpUserProperties(
    urn: "urn:li:corpuser:your_username"
    input: {
      roles: ["urn:li:dataHubRole:Admin"]
    }
  ) {
    urn
  }
}

Python Script for Role Restoration

from datahub.emitter.rest_emitter import DatahubRestEmitter
from datahub.emitter.mce_builder import make_user_urn
from datahub.metadata.schema_classes import (
    RoleMembershipClass,
    DataHubRoleInfoClass
)

# Use an admin token
emitter = DatahubRestEmitter(
    "http://localhost:8080",
    token="ADMIN_TOKEN_HERE"
)

# User URN to restore
user_urn = make_user_urn("affected_username")

# Create admin role membership
admin_role = RoleMembershipClass(
    roles=["urn:li:dataHubRole:Admin"]
)

# Emit the role update
emitter.emit_mcp(
    MetadataChangeProposalWrapper(
        entityUrn=user_urn,
        aspect=admin_role
    )
)

print(f"Restored admin role for {user_urn}")

Preventive Measures

1. Create a Service Account for Testing:

This is applicable to CLI-based operations.

# Create a test user for role experiments
datahub user upsert \
  --urn "urn:li:corpuser:test_user" \
  --name "Test User" \
  --email "test@company.com" \
  --role "Reader"

# Test role changes on this account, not your own

2. Use Staging Environment:

This is applicable to CLI-based operations.

# Always test user management in staging first
export DATAHUB_GMS_HOST="https://datahub-staging.company.com"

datahub user upsert \
  --urn "urn:li:corpuser:your_username" \
  --role "Reader"  # Test here first

# Only apply to production after validation

3. Create Emergency Admin Account:

This is applicable to CLI-based operations.

# Maintain a separate admin account for recovery
datahub user upsert \
  --urn "urn:li:corpuser:emergency_admin" \
  --name "Emergency Admin" \
  --email "datahub-admin@company.com" \
  --role "Admin"

# Store credentials securely (password manager, vault)

4. Implement Role Change Confirmation:

This is applicable to CLI-based operations.

#!/bin/bash
# Wrapper script with confirmation

read -p "Are you changing your OWN role? (yes/no): " response

if [ "$response" = "yes" ]; then
    echo "WARNING: This will change your own permissions!"
    read -p "Are you ABSOLUTELY sure? (yes/no): " confirm

    if [ "$confirm" != "yes" ]; then
        echo "Aborted."
        exit 1
    fi
fi

# Proceed with role change
datahub user upsert "$@"

Understanding DataHub Roles

# Default roles in DataHub
Admin: Full system access
Editor: Can modify metadata
Reader: View-only access

# Check available roles
query {
  listRoles {
    roles {
      urn
      name
      description
      privileges
    }
  }
}

Proper User Management Workflow

This is applicable to CLI-based operations.

# 1. Check current role before making changes
datahub get --urn "urn:li:corpuser:target_user" --aspect roleMembership

# 2. Make the change
datahub user upsert \
  --urn "urn:li:corpuser:target_user" \
  --role "Editor"

# 3. Verify the change
datahub get --urn "urn:li:corpuser:target_user" --aspect roleMembership

# 4. Test with that user's credentials
# Log in as that user and verify permissions

Bulk User Management Script

For managing multiple users safely:

#!/usr/bin/env python3
"""
Safe bulk user role management
"""
import csv
from datahub.emitter.rest_emitter import DatahubRestEmitter

def update_user_roles(csv_file: str, emitter: DatahubRestEmitter):
    """Update user roles from CSV file"""

    with open(csv_file, 'r') as f:
        reader = csv.DictReader(f)

        for row in reader:
            username = row['username']
            new_role = row['role']
            current_user = emitter.get_current_user()

            # Safety check - don't modify your own role
            if username == current_user:
                print(f"SKIPPED: Refusing to modify your own role ({username})")
                continue

            # Apply role change
            try:
                user_urn = f"urn:li:corpuser:{username}"
                # ... emit role change ...
                print(f"SUCCESS: Updated {username} to {new_role}")
            except Exception as e:
                print(f"ERROR: Failed to update {username}: {e}")

# Usage
emitter = DatahubRestEmitter("http://localhost:8080", token="TOKEN")
update_user_roles("users_to_update.csv", emitter)

Recovery Contact Information

Document emergency contacts: - DataHub administrators in your organization - Support team email/Slack channel - Vendor support (for Acryl DataHub)

• Always maintain at least two admin accounts
• Document user management procedures
• Test role changes in staging first
• Keep audit logs of all role modifications
• Consider implementing approval workflows for role changes
• Use service accounts for automation, not personal accounts
• Regular backups can help recover from catastrophic user management errors
• This is a common issue during initial DataHub setup and configuration

• User Management
• Access Control
• DataHub CLI

5390, 5365, 5398