Enterprise Features

Technical reference. This page is for integrations, advanced configuration, or platform operations. For portal tasks, start with the user guide.

This guide focuses on the enterprise capabilities that are present in the current codebase and API surface, and it calls out where the implementation is still foundational rather than fully productized.

Current baseline

The implemented enterprise baseline today includes:

• Organization, namespace, and workspace hierarchy with scoped cost reporting
• OIDC bearer-token validation with JWKS-based signature verification
• Workload principal bindings for access control
• Audit records on key control-plane mutations
• Redis-backed building blocks for rate limiting and event fan-out
• When organization enablement is absent, the Estate overview is unavailable. Authorized core workspace pages remain usable according to their own permissions. Healthy enabled overview counts are not yet qualified; observed lineage and unregistered-system coverage are not established.
• The Estate systems register (/estate/systems, orqestractl estate systems list) pages, sorts and filters server-side; facets, totals and the unassigned-workloads banner come from the same authorized scope as the rows, and per-user saved views (orqestractl estate systems views) show live counts. Sources that cannot answer (releases, regions, documentation snapshots) are shown as unavailable, never as zero; regions are declared sovereignty-profile values, not verified locations.

The guide below distinguishes between what is live now and what is still deployment-specific or evolving.

Multi-tenancy

An organization is the tenancy root inside an Orqestra deployment. Namespaces divide an organization into delegated ownership and cost boundaries; workspaces contain the assets, workloads, releases, secrets, connections, and members used by a team.

Organization
  -> Namespace
       -> Workspace

Runtime resource limits are configured and enforced through Governance Pools, not tenant, namespace, or workspace metadata. Workspace concurrency is workspace-scoped, provider TPM is scoped by organization, provider, and model, and daily cost is organization-scoped. These limits do not use namespace-to-workspace inheritance.

See Namespace & Workspace Management for the current API and operator workflow.

OIDC / SSO

The control plane supports OIDC bearer-token validation using the configured issuer’s JWKS endpoint.

How token mapping works

The current implementation extracts actor context from standard claims plus a small number of optional custom claims.

OIDC always resolves a user actor. If the configured actor-ref claim has no prefix, the control plane adds user:. A pre-prefixed user: value is retained; internal service:, system:, and workload: subjects are rejected. Any actor_type claim in a user JWT is ignored.

Configuration

Set these environment variables on the control plane:

Example:

export ORQESTRA_OIDC_ISSUER_URL="https://auth.example.com/realms/orqestra"
export ORQESTRA_OIDC_JWKS_URL="https://auth.example.com/realms/orqestra/.well-known/jwks.json"
export ORQESTRA_OIDC_AUDIENCE="orqestra-control-plane"
export ORQESTRA_OIDC_CLIENT_ID="orqestra-cp"
export ORQESTRA_OIDC_ACTOR_REF_CLAIM="email"
export ORQESTRA_OIDC_CLOCK_SKEW_LEEWAY_SECONDS="30"

JWKS verification is derived from the issuer by default. Set ORQESTRA_OIDC_JWKS_URL only when the token issuer must remain browser-facing but the service must fetch keys through an internal network address. The actor-ref claim must match the stable subject populated by SCIM. Local Keycloak uses email because dev-memory user IDs can change after a restart.

Workload access control

Workload access is currently modeled with principal bindings on the workload routes.

Principal binding fields

Access modes

Example binding

curl -X POST http://localhost:8000/v1/workloads/{workload_id}/principal-bindings \
  -H "Content-Type: application/json" \
  -d '{
    "actor_type": "user",
    "actor_ref": "user:alice",
    "access_mode": "interactive",
    "scope_ref": "tenant:acme-corp"
  }'

Secrets

The runtime supports multiple secret-resolution backends. Local deployments can use HashiCorp Vault. Cloud deployments can use Vault or the provider-native secret manager for the deployment environment.

What is true today:

• Secret references are resolved at runtime, not stored inline in governed assets
• Secret references can be redacted from logs and traces
• The runtime includes environment, Vault, Azure Key Vault, AWS Secrets Manager, GCP Secret Manager, and static config resolvers
• Control-plane workspace secret APIs support create, list, update, delete, and audited reveal workflows
• Connection instances bind non-secret config to named secret slots

Choose Vault, Azure Key Vault, AWS Secrets Manager, or Google Secret Manager based on your operating model, identity controls, rotation process, audit requirements, and network boundaries. See Connections & Secrets for backend configuration and lifecycle APIs.

Rate limiting

The repository includes a Redis-backed sliding-window rate limiter service.

That means:

• The core algorithm exists and is tested
• Redis is already part of the broader operational story for triggers and caches

But the docs should not overstate current enforcement. Rate limiting is better described as available platform infrastructure rather than a universally enforced ingress policy across every public surface today.

Cost reporting

Workspace and namespace cost reporting are implemented.

curl http://localhost:8000/v1/workspaces/{workspace_id}/cost-report?window_days=30
curl http://localhost:8000/v1/namespaces/{namespace_id}/cost-report?window_days=30

Auditability

Control-plane mutations record audit events. Release transitions are a concrete implemented example.

Auditability is strongest today around:

• release transitions
• release approvals
• workload mutations
• execution and evidence records

The platform’s governance spine adds a hash-chained, tamper-evident audit log (governance_audit) with role-separated immutability triggers and an optional Layer 2 WORM export to S3 Object Lock. See the Audit & Compliance guide for retention defaults, WORM configuration, and the daily verification workflow.

External SIEM forwarding remains a deployment responsibility rather than a built-in push connector surface.

Deployment guidance

For enterprise deployments today, the safest framing is:

• OIDC and organization/namespace/workspace tenancy primitives are implemented
• access control is workload-centric
• audit and cost visibility are available
• secrets are supported through Vault and cloud-native secret managers, with deployment-aware identity and network hardening decisions
• rate limiting needs deployment-aware hardening decisions

That framing is more accurate than presenting every enterprise control as fully turnkey today.