Skip to main content

Service Account Privileges for Assertion Management

Angelo Bresci
Updated

Area: API Issues

Sub-Area: Authorization and Permissions

Issue

Service accounts receive 403 unauthorized errors when attempting to upsert assertions via the DataHub SDK, even when they have MANAGE_TESTS and EDIT_ENTITY_ASSERTIONS privileges configured. This occurs because the SDK uses a REST API path that requires different authorization than the GraphQL interface used by the UI.

Error Messages

  • User urn:li:corpuser:service_ is unauthorized to modify entity: HttpStatus: 403
  • Urn: urn:li:assertion:

You Might Be Asking

  • Why does EDIT_ENTITY_ASSERTIONS privilege not allow assertion upserts via SDK?
  • What's the difference between UI and SDK authorization for assertions?
  • How can I grant minimal permissions for assertion management?

Solution

Add the EDIT_ENTITY privilege to your service account's metadata policy, scoped to assertion and monitor entity types:

  1. Navigate to Settings → Permissions → Policies in the DataHub UI
  2. Find your service account's metadata policy (or create a new one)
  3. Add EDIT_ENTITY to the privileges list
  4. Ensure the resource filter includes both assertion and monitor entity types

Alternatively, create a new policy using GraphQL:

mutation createAssertionEditPolicy {
  createPolicy(input: {
    type: METADATA
    name: "Service Account - Edit Monitors and Assertions"
    description: "Allows service account to create and edit monitor and assertion entities via SDK"
    state: ACTIVE
    actors: {
      users: ["urn:li:corpuser:service_"]
      groups: []
      resourceOwners: false
      allUsers: false
      allGroups: false
    }
    resources: {
      filter: {
        criteria: [
          {
            field: "RESOURCE_TYPE"
            values: ["monitor", "assertion"]
            condition: EQUALS
          }
        ]
      }
    }
    privileges: ["EDIT_ENTITY"]
  })
}

Example complete metadata policy configuration:

{
  "type": "METADATA",
  "state": "ACTIVE",
  "privileges": [
    "VIEW_ENTITY",
    "EXISTS_ENTITY", 
    "CREATE_ENTITY",
    "EXECUTE_ENTITY",
    "EDIT_ENTITY",
    "EDIT_ENTITY_TAGS",
    "EDIT_ENTITY_GLOSSARY_TERMS",
    "EDIT_ENTITY_DOCS",
    "EDIT_ENTITY_DOC_LINKS",
    "EDIT_ENTITY_OWNERS",
    "EDIT_ENTITY_PROPERTIES",
    "EDIT_DOMAINS_PRIVILEGE",
    "EDIT_LINEAGE",
    "EDIT_DATASET_COL_DESCRIPTION",
    "EDIT_DATASET_COL_TAGS",
    "EDIT_DATASET_COL_GLOSSARY_TERMS",
    "EDIT_ENTITY_ASSERTIONS",
    "EDIT_ENTITY_DATA_CONTRACT",
    "EDIT_ENTITY_MONITORS",
    "EDIT_ENTITY_SQL_ASSERTION_MONITORS"
  ],
  "resourceFilter": {
    "field": "TYPE",
    "condition": "EQUALS",
    "values": ["container", "dataset", "dataFlow", "dataJob", "assertion", "monitor"]
  }
}

Additional Notes

This is an architectural design gap, not a configuration error. The SDK uses REST API endpoints that require EDIT_ENTITY privilege for assertion entities, while the UI uses GraphQL endpoints that respect EDIT_ENTITY_ASSERTIONS. The EDIT_ENTITY privilege scoped only to assertion and monitor types is safe and doesn't grant broad editing rights. The same requirement applies to other secondary entity types including subscriptions, data contracts, and DataHub actions. MANAGE_INGESTION privilege does not bypass entity-level authorization checks for assertion upserts.

Related Documentation

Tags: service-account, assertions, authorization, permissions, 403-error, sdk, api, edit-entity, privileges, metadata-policy

Related articles