Enterprise Identity Integration: Entra ID, SPIFFE, OPA, and Beyond

The previous post outlined our five-phase enterprise roadmap — closing the gap between connectivity tool and enterprise infrastructure. The response was immediate: which identity providers? Which policy engines? Which compliance tools?

This post answers those questions. The design principle is simple: enterprises already have answers to "who is this?", "are they allowed?", "what did they do?", and "are they still trusted?" Pilot should consume those answers, not reinvent them.

The Principle: Consume, Don't Reinvent

Every enterprise already runs identity infrastructure. They have spent years deploying it, writing policies for it, training staff on it, and passing audits against it. When a new connectivity layer arrives and says "here's our identity system, use it instead" — that is a non-starter.

The right approach: Pilot accepts proof from enterprise systems as authorization for network operations. An OIDC token from Entra ID is proof. A SPIFFE SVID is proof. A certificate from your internal CA is proof. A Kerberos ticket is proof. Pilot does not care which system issued the proof. It cares that the proof is cryptographically valid and matches the network's requirements.

This is how TLS works. A web server does not care whether your certificate came from Let's Encrypt, DigiCert, or your company's internal CA. It verifies the chain. Pilot should work the same way for agent identity.

Identity Providers

Microsoft Entra ID (Azure AD)

Every Microsoft shop runs Entra ID. It is the identity backbone for Microsoft 365, Azure, and increasingly for non-Microsoft workloads. For Pilot, Entra ID integration means:

• OIDC join rule. A Pilot network configured with Entra ID as the OIDC issuer. Agents present a JWT from Entra ID to join. The registry validates the signature via Entra's JWKS endpoint, checks the tenant ID, and optionally matches group claims.
• Group-to-network mapping. Entra ID security groups map to Pilot networks. An agent in the backend-services group auto-joins the backend network. Group membership changes in Entra propagate to Pilot network membership.
• Conditional Access. Entra's Conditional Access policies can gate token issuance. Only agents on compliant devices, from approved locations, with MFA-verified operators get tokens. Pilot inherits these controls without implementing them.
• Managed Identity. Agents running on Azure VMs or AKS pods use Azure Managed Identity — no credentials to manage. The Azure platform provides the OIDC token automatically.

Google Workspace & GCP

Google Cloud's Workload Identity Federation allows workloads to exchange credentials from external identity providers for short-lived Google credentials. For Pilot:

• Domain-restricted join rules. Only agents with tokens from @acme.com Google Workspace accounts can join a network.
• GKE Workload Identity. Agents in GKE pods get OIDC tokens from the cluster's issuer. The pod's Kubernetes service account becomes the agent's identity. No secrets in environment variables.
• Service account keys → OIDC tokens. GCP service accounts can generate OIDC tokens programmatically. Existing GCP automation translates directly to Pilot network authorization.

Okta / Auth0 / OneLogin

The same OIDC pattern applies to any compliant identity provider. What makes these interesting beyond basic OIDC:

• Okta FastPass. Device-bound, phishing-resistant authentication. Agents on FastPass-enrolled devices get stronger identity assertions.
• Auth0 Actions. Custom logic during token issuance. An Auth0 Action could inject Pilot-specific claims (allowed networks, port restrictions, tag assignments) into the token before the agent presents it.
• SCIM provisioning. When HR offboards an employee in Okta, SCIM can trigger deprovisioning of that employee's agents from all Pilot networks. No manual revocation — the identity lifecycle drives the network lifecycle.

Active Directory / LDAP

On-premises enterprises that have not fully migrated to cloud identity still run Active Directory. Integration here is less elegant than OIDC but equally necessary:

• AD group membership. Map AD security groups to Pilot networks. Agent service accounts inherit network access from their group memberships.
• Kerberos-to-token bridge. An on-prem gateway service that validates Kerberos tickets and issues short-lived Pilot join tokens. The agent authenticates to AD normally; the bridge translates to Pilot authorization.
• LDAP bind verification. For simpler deployments, the registry could verify agent credentials directly against an LDAP directory. Less elegant, but pragmatic for enterprises that are years away from OIDC migration.

Cloud IAM (AWS / GCP / Azure)

Agents running on cloud infrastructure already have workload identity:

• AWS IAM Roles. EC2 instance roles, ECS task roles, Lambda execution roles. AWS STS can issue OIDC-compatible tokens. An agent on an EC2 instance with role agent-backend gets a token that proves it — Pilot verifies via AWS's OIDC federation endpoint.
• GCP Workload Identity. GKE pods and Compute Engine VMs get OIDC tokens from Google's metadata service. Zero credential management.
• Azure Managed Identity. System-assigned or user-assigned identities on VMs, App Services, and AKS pods. The Azure platform handles token rotation.

The pattern: the cloud provider is just another OIDC issuer. Pilot's OIDC join rule already handles this — it is a matter of configuring the right issuer URL and audience.

Policy Engines

Open Policy Agent (OPA)

OPA is becoming the lingua franca for authorization policy in cloud-native infrastructure. Kubernetes admission controllers, Envoy proxies, Terraform plans, CI/CD pipelines — they all evaluate Rego policies. Pilot should speak the same language.

Instead of hardcoded tag-matching rules, imagine Pilot evaluating Rego policies at SYN time:

package pilot.access

default allow = false

# Backend services can reach databases on port 5432
allow {
    input.src.tags[_] == "backend"
    input.dst.tags[_] == "database"
    input.dst_port == 5432
}

# Frontend can reach API on HTTP ports
allow {
    input.src.tags[_] == "frontend"
    input.dst.tags[_] == "api"
    input.dst_port in {80, 443}
}

# Monitoring can reach anything on the metrics port
allow {
    input.src.tags[_] == "monitoring"
    input.dst_port == 9090
}

Enterprises that already write OPA policies for their Kubernetes clusters would use the exact same policy language for Pilot access control. One policy framework, two enforcement points.

HashiCorp Vault

Vault solves two problems that Pilot's enterprise roadmap needs:

• PKI engine for CA-based enrollment. Instead of manually managing CA keys, Vault's PKI secrets engine issues certificates on demand. An agent requests a certificate from Vault, Vault validates the agent's identity (via AppRole, Kubernetes auth, or cloud IAM), and issues a short-lived cert. The agent presents the cert to join a CA-gated Pilot network. Certificate rotation is automatic.
• Dynamic secrets for join tokens. Vault can generate single-use, time-limited Pilot join tokens. Instead of a static token shared across a fleet, each agent gets a unique token from Vault that expires after first use. Leaked tokens are worthless.

Audit & Compliance

SIEM Integration

Phase 2 of the roadmap adds structured audit events at the registry level. But "structured JSON logs" is only the first step. Enterprises need those events flowing into their existing security monitoring:

• Splunk. HTTP Event Collector (HEC) endpoint. The registry ships audit events directly to Splunk with source type, index, and correlation fields. Security analysts see Pilot events alongside firewall logs, endpoint alerts, and authentication events in the same dashboard.
• Microsoft Sentinel. Azure Monitor ingestion. Pilot audit events appear in Log Analytics workspaces and trigger Sentinel analytics rules. A compromised agent triggers the same incident workflow as a compromised user account.
• Elastic / Datadog. Standard log shipping via Filebeat, Fluentd, or Datadog Agent. Pilot's JSON log format maps directly to ECS (Elastic Common Schema) or Datadog's log facets.

OpenTelemetry

Audit logs answer "what happened." Traces answer "how did it flow." OpenTelemetry integration means:

• Distributed traces across tunnels. A request enters Agent A, crosses a Pilot tunnel, hits Agent B, which calls Agent C. One trace ID, three spans, visible in Jaeger or Tempo. The Pilot tunnel hop appears as a span with attributes: source address, destination address, port, encryption status, RTT.
• Metrics export. Connection counts, bytes transferred, retransmission rates, SYN reject counts — exported as OTel metrics to Prometheus, Datadog, or CloudWatch. Standard dashboards, standard alerting.

Compliance Evidence

SOC 2, ISO 27001, HIPAA, and FedRAMP audits require evidence that access controls exist and are enforced. Pilot should generate:

• Immutable audit logs. Append-only log with cryptographic checksums (hash chain). Tampering is detectable. Auditors verify the chain rather than trusting the log source.
• Access control evidence reports. Exportable reports: which nodes accessed which networks, when, with what identity, under what policy. Maps directly to SOC 2 CC6.1 (logical access) and CC6.3 (access revocation).
• Encryption evidence. Proof that all data-in-transit was encrypted: cipher suite, key exchange method, certificate chain. Maps to HIPAA technical safeguards and ISO 27001 A.10.

Certificate Infrastructure

Enterprise PKI

Large organizations run internal Certificate Authorities — Microsoft AD Certificate Services (AD CS), EJBCA, Venafi, or Smallstep. Pilot's CA-based join rule (Phase 4) should accept certificates from these existing CAs:

• Trust chain validation. The network's trust bundle contains the enterprise CA root. Any certificate chained to that root is accepted. The enterprise CA team issues certs through their existing processes — no Pilot-specific tooling needed.
• Certificate templates. AD CS uses templates to define certificate properties. A "Pilot Agent" template with the right Extended Key Usage and Subject Alternative Name fields integrates with existing certificate lifecycle management.

ACME (Automated Certificate Management)

The Let's Encrypt model for Pilot: automated certificate issuance with proof of authorization.

• Challenge-response enrollment. An agent proves it controls a Pilot address by responding to a challenge from the CA. The CA issues a certificate bound to that address. Renewal is automatic.
• Short-lived certificates. Certificates valid for hours, not months. If a certificate is compromised, it expires before an attacker can use it. Aligns with zero-trust principles — no long-lived secrets.

Device & Workload Context

Device Trust Signals

Identity answers "who is this?" Device trust answers "should we trust the machine it's running on?" Enterprise endpoint management tools provide these signals:

• CrowdStrike / SentinelOne. Is the machine's endpoint protection active and reporting clean? A compromised host should not run trusted agents.
• Jamf / Intune / Workspace ONE. Is the device MDM-enrolled, disk-encrypted, OS-patched, and policy-compliant? Non-compliant devices get restricted network access.
• Conditional join rules. Combine identity and device signals: "agents with a valid Entra ID token AND running on an Intune-compliant device can join the production network. All others get the staging network."

Kubernetes-Native Identity

For containerized agents, the Kubernetes cluster provides identity without any external system:

• Projected service account tokens. Kubernetes 1.20+ projects OIDC-compatible tokens for service accounts. The cluster's issuer URL is the OIDC issuer. The service account name is the identity. No secrets, no sidecars, no init containers.
• Namespace isolation. Kubernetes namespaces map to Pilot networks. Agents in the production namespace auto-join the production network. Agents in staging get a different network. The mapping is declarative — change the namespace, change the network.

SPIFFE Federation Across Organizations

The most interesting cross-org scenario: two companies federate their SPIFFE trust domains. Company A's SPIRE infrastructure and Company B's SPIRE infrastructure exchange trust bundles. Now:

• An agent at Company A with SPIFFE ID spiffe://a.com/agents/data-pipeline can join a shared Pilot network.
• An agent at Company B with SPIFFE ID spiffe://b.com/agents/data-consumer can join the same network.
• Neither company shares secrets with the other. Each uses their own SPIRE infrastructure. The federation is cryptographic, not administrative.

This is how B2B agent collaboration should work — not by sharing API keys or VPN credentials, but by federating existing identity infrastructure.

What We're Building First

The full list above is the vision. Here is the priority order based on enterprise demand:

1. OIDC (Phase 5) — covers Entra ID, Google, Okta, Auth0, AWS/GCP/Azure IAM, and any compliant provider. One implementation, broad reach.
2. SPIFFE (Phase 5) — covers Kubernetes-native identity, SPIRE deployments, and cross-org federation. The most sophisticated integration.
3. OPA policy evaluation — the policy lingua franca. Enterprises already write Rego. Pilot should evaluate it.
4. Vault PKI — dynamic certificate issuance for CA-based join rules. Eliminates static secrets.
5. SIEM forwarding — structured event shipping to Splunk/Sentinel/Elastic. Not just logs — native integration.
6. SCIM lifecycle — automated deprovisioning when identity is revoked upstream. Closes the revocation loop.
7. Device trust signals — conditional join rules based on endpoint compliance. Later priority, high value for regulated industries.

Items 1-2 are in the Phase 5 roadmap. Items 3-7 represent a Phase 6+ expansion that builds on the same foundation.

The Pattern

Every integration follows the same pattern:

1. Enterprise system issues proof (token, certificate, ticket, device attestation).
2. Agent presents proof to join a Pilot network.
3. Registry validates proof against the network's configured trust anchor (JWKS, CA root, trust bundle).
4. Agent joins with its enterprise identity mapped to its Pilot address.
5. Audit trail links the Pilot address to the enterprise identity.

The proof format changes. The validation logic changes. The pattern does not. This is why OIDC comes first — it is the most universal proof format, and it covers the widest range of enterprise identity providers with a single implementation.