microsoft/PurviewIntegrations

microsoft/PurviewIntegrations

Description: A collection of tools and integrations for Microsoft Purview

Language: TypeScript

License: MIT

Stars: 8

Forks: 5

Open issues: 3

Created: 2026-02-25T20:57:36Z

Pushed: 2026-09-13T13:21:28Z

Default branch: main

Fork: no

Archived: no

README:

Purview GitHub Action

A GitHub Action that scans repository files and sends them to Azure Purview for data governance and compliance tracking.

Features

• 🔐 Secure Authentication: Uses GitHub OIDC for passwordless Azure authentication
• 📁 Smart File Processing: Automatically detects and processes changed files; binary files are skipped
• 🔄 Resilient API Integration: Built-in retry logic with exponential backoff
• 📊 Comprehensive Logging: Detailed execution logs with sensitive data redaction
• 🚀 Enterprise Ready: Handles large repositories with chunking and streaming

Prerequisites

1. Azure AD Application with federated credentials configured for GitHub OIDC 2. Purview account with API access enabled 3. GitHub repository with OIDC permissions

Auth Setup

1. Create an app registration in entra with the following permissions:

• ContentActivity.Write (Application)
• Content.Process.User (Application)
• ProtectionScopes.Compute.All (Application)
• (Optional, used for user id lookup) User.Read.All (Application)

2. Grant admin consent to those permissions 3. In that app registration, click the "Certificates & secrets" tab, then click the "Federated credentials" tab, and click "Add credential" 4. Choose "Other issuer" from the "Federated credential scenario" dropdown. 5. Set Issuer to https://token.actions.githubusercontent.com 6. Set Type to "Claims matching expression" 7. Set "Value" to claims['sub'] matches 'repo:{your-user-or-org-name}/{your-repo-name}:*' replacing the sections in curly braces with the values for your repo. 8. Set Name and Description. 9. Set "Audience" to api://AzureADTokenExchange if not already set. 10. Click "Add".

Usage

name: Scan with Purview
on:
push:
branches: [main]
pull_request:
workflow_dispatch: # Allow manual triggering for full scans

permissions:
id-token: write
contents: read
pull-requests: write
actions: read

jobs:
scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4

- uses: microsoft/purview-github-action@v1
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
with:
client-id: ${{ secrets.AZURE_CLIENT_ID }}
client-certificate: ${{ secrets.AZURE_CLIENT_CERTIFICATE }}
tenant-id: ${{ secrets.AZURE_TENANT_ID }}
users-json-path: 'users.json'
file-patterns: '**'
debug: true

User ID resolution via users.json

Instead of passing a single Azure AD user ID, the action resolves user IDs from a users.json file placed in your workflow-definition repo. When the workflow-definition repo differs from the target repo being scanned (cross-repo workflow), the action automatically fetches users.json from the workflow-definition repo via the GitHub API using the state-repo-token. When the workflow repo is the same as the target repo, the file is read from the local filesystem ($GITHUB_WORKSPACE).

The file maps commit author emails to Azure AD user IDs:

{
"users": [
{ "email": "alice@contoso.com", "userId": "aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa" },
{ "email": "bob@contoso.com", "userId": "bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb" }
],
"defaultUserId": "00000000-0000-0000-0000-000000000000"
}

For each commit author, the action checks the email against the users array. If a match is found that user ID is used; otherwise the defaultUserId is used. The chosen value is logged for every commit.

Commit author emails come from git metadata and can be set to anything locally, so an address that is not a plausible email is never sent to the directory lookup — it simply falls back to defaultUserId like any other unresolved author. Identities are also checked at the API boundary: a userId given as a user principal name is resolved to its object ID, and one that cannot be resolved skips the protection-scope and processContent calls and is routed through contentActivities instead.

Inputs

| Input | Description | Required | Default | |-------|-------------|----------|---------| | client-id | Azure AD application client ID | Yes | - | | client-certificate | PEM containing private key + certificate for certificate-based auth. If omitted, uses GitHub OIDC federated credentials. | No | - | | client-secret | Azure AD application client secret for secret-based auth. If omitted, uses GitHub OIDC federated credentials. | No | - | | tenant-id | Azure AD tenant ID | Yes | - | | users-json-path | Path to users.json in the workflow-definition repo (relative to repo root). In cross-repo workflows the file is fetched via the GitHub API using state-repo-token. | No | users.json | | purview-account-name | Name of the Purview account | No | - | | purview-endpoint | Purview API endpoint URL | No | https://graph.microsoft.com/v1.0 | | file-patterns | Comma-separated file patterns to scan | No | ** | | exclude-patterns | Comma-separated file patterns to exclude from scanning | No | **/.git/** | | max-file-size | Maximum file size in bytes | No | 10485760 (10MB) | | debug | Enable debug logging | No | false | | state-repo-branch | Branch in the workflow-definition repo where the state marker is written | No | repo default branch | | state-repo-token | Token with contents:write access to the workflow-definition repo. Used for first-run state tracking and for fetching users.json in cross-repo workflows. | No | empty |

File pattern examples

Patterns are standard glob patterns and should use / as the path separator.

Scan only specific extensions:

with:
file-patterns: "**/*.md,**/*.yml,**/*.yaml,**/*.json"

Scan a single folder (and everything under it):

with:
file-patterns: "src/**"

Exclude common folders (even if included by file-patterns):

with:
file-patterns: "**/*"
exclude-patterns: "**/node_modules/**,**/dist/**,**/build/**,**/.git/**"

Exclude a specific folder and file type:

with:
file-patterns: "**/*"
exclude-patterns: ".github/**,**/*.lock"

First-run state tracking

When state-repo-token is provided, the action stores a marker file (.purview/state/-.json) in the workflow-definition repo. On the first run it performs a full repository scan; subsequent runs only process changed files. The...