Skip to content
Vijay Work Resume Blog Contact

Project case study

Access governance platform

Sole architect and lead developer of an enterprise access governance platform — centralized attribute management, policy authoring for OPA/Ranger/OpenFGA, cryptographically signed bundle distribution, and enforcement that keeps working with the control plane offline.

Unified access control across a large telecom enterprise's data infrastructure: attributes from multiple systems of record under one roof, policies authored once and compiled for each enforcement engine, signed bundles shipped to local PDPs for sub-millisecond decisions. Full audit trail and approval workflows for every change.

OPA (Open Policy Agent) Apache Ranger Postgres Kubernetes (OCP) DataHub Java Python Airflow Production AI

Context

The problem

Large enterprises usually accumulate access rules across catalogs, query engines, workflow tools, and custom services. The goal here was to give the organization one governed path for attributes, approvals, policy authoring, distribution, and audit — without making the control plane a runtime dependency for every authorization decision.

Designed the entire system from first principles: a control plane with attribute, policy, approval, distribution, and audit services backed by PostgreSQL, plus an enforcement plane of OPA PDPs, Ranger PEP plugins, and OPAL-based bundle delivery. The architecture enforces a strict separation — the control plane is never in the authorization hot path, and enforcement points continue operating when the control plane is unavailable. Ports-and-adapters design means every external dependency (identity providers, data catalogs, approval tools, cloud services) sits behind an adapter interface. Multi-repository workspace with a manifest-driven orchestration CLI.

System trace

How the work moved through the system

A high-level operating path: where the request starts, how the system shapes it, and how other teams consume the result.

  1. 1

    Control plane with five services: attribute, policy, approval, distribution, and audit — each with its own PostgreSQL schema, communicating via NATS/JetStream.

  2. 2

    Attribute service ingests from multiple systems of record via scheduled connectors, with trust states and system-of-record-aware write-back policies.

  3. 3

    Policy service lowers authored policies to a canonical IR, then compiles to target-specific artifacts: Rego for OPA, authorization models for OpenFGA, delegating policies for Ranger.

Architecture

System shape

5
  1. 1 Control plane with five services: attribute, policy, approval, distribution, and audit — each with its own PostgreSQL schema, communicating via NATS/JetStream.
  2. 2 Attribute service ingests from multiple systems of record via scheduled connectors, with trust states and system-of-record-aware write-back policies.
  3. 3 Policy service lowers authored policies to a canonical IR, then compiles to target-specific artifacts: Rego for OPA, authorization models for OpenFGA, delegating policies for Ranger.
  4. 4 Distribution service assembles signed bundles containing only the attributes each policy set references, publishes to a registry, and notifies subscribers.
  5. 5 Enforcement stays local: OPA PDPs, Ranger plugins, and OPAL clients continue making decisions even if the control plane is unavailable.

Ownership

What I handled

4
  1. 1 Defined the control-plane and enforcement-plane split so policy authoring, approvals, and bundle generation never sat in the authorization hot path.
  2. 2 Designed the canonical policy IR and the compilation pipeline for OPA, OpenFGA, and Ranger targets.
  3. 3 Built the PostgreSQL-backed services for attributes, approvals, distribution, and audit, plus the adapter boundaries for external systems.
  4. 4 Created the multi-repository workspace workflow and orchestration CLI used to clone, sync, pin, and operate the platform consistently.

Lessons

What carried forward

3
  1. 1 Access governance works better when metadata, approvals, and policy compilation are treated as one platform instead of separate admin tools.
  2. 2 A control plane should improve authoring and auditability, not become a latency or availability dependency for authorization itself.
  3. 3 Bundle signing, projection, and offline enforcement are what turn central policy management into something production teams will trust.

Engineering decisions

Keep enforcement offline-capable

Authorization checks had to keep working during control-plane outages, so bundles were signed and delivered to local enforcement points instead of calling home on every decision.

Compile once, enforce many ways

A canonical policy representation made it possible to author once and emit target-specific artifacts for OPA, Ranger, and OpenFGA without duplicating governance logic.

Hide enterprise dependencies behind adapters

Identity sources, data catalogs, approval tooling, and cloud services all sat behind adapter interfaces so the core platform stayed testable and replaceable.

What can be shown

Public evidence without internal names

The internal systems stay private. This section keeps the public parts: my role, system boundaries, technology context, scale, decisions, constraints, and what I learned.

Internal enterprise system High-level architecture

Architecture shape

  • Control plane with five services: attribute, policy, approval, distribution, and audit — each with its own PostgreSQL schema, communicating via NATS/JetStream.
  • Attribute service ingests from multiple systems of record via scheduled connectors, with trust states and system-of-record-aware write-back policies.
  • Policy service lowers authored policies to a canonical IR, then compiles to target-specific artifacts: Rego for OPA, authorization models for OpenFGA, delegating policies for Ranger.
  • Distribution service assembles signed bundles containing only the attributes each policy set references (referenced-attribute projection), publishes to a registry, and notifies subscribers.
  • Enforcement plane is customer-owned: OPA PDPs as node-local DaemonSets, OPAL clients for bundle delivery, PEP plugins for Trino/Kafka/API gateways/Ranger.
  • Human-originated changes go through draft → approval → commit. Machine-ingested attributes skip approval. Concurrent edits use optimistic concurrency control.
  • Multi-repository workspace orchestrated via manifest files, lockfile-based snapshot pinning, and a custom repoctl CLI for clone/sync/status/checkout across all component repos.

Responsibilities

  • Platform architecture across control plane, policy compilation, bundle distribution, and local enforcement boundaries.
  • Service implementation for attributes, approvals, distribution, and audit workflows.
  • Adapter design for external identity, metadata, and approval systems.

Constraints

  • Control plane could not sit in the live authorization path.
  • Architecture details had to remain sanitized for public sharing.
  • Policy artifacts needed to serve multiple enforcement engines without duplicating governance logic.

Supporting context

High-level architecture

Sanitized system shape

High-level control-plane and enforcement-plane architecture shared without internal identifiers or policy data.

Related case studies

Continue through related work or return to the full project index.

Related projects

Continue in the same area

Project index

Java + Apache Ranger + Backend engineering

Ranger RBAC and policy-governance extensions

Extended enterprise data access governance around Apache Ranger-based RBAC, an external attribute store, DataHub tag-driven policies, row-level security, masking, Trino integration, audit clarity, and local/containerized development paths.

Python + DataHub + AI

Governed conversational data platform

I architected and built a governed conversational data and visualization agent: it retrieves business knowledge, answers business questions, runs governed queries from that context, reasons over results, and builds charts without making the LLM the data boundary.

Java + Airflow + Backend engineering

Hive metastore synchronization and metadata governance

Designed and built services that keep Hive metadata consistent across independent environments using real-time listener sync, daily reconciliation, expiry cleanup, one-time interval jobs, observability, and deployment hardening.