Security
Catalyst's security model layers multiple controls: data-plane components carry cryptographic SPIFFE identities and communicate over mTLS, applications authenticate to the platform with scoped App ID API tokens over TLS, projects and regions provide isolation boundaries, and sensitive configuration lives in secret stores you own or Catalyst manages on your behalf. Human and machine access is governed by role-based access control and audited.
Trust boundaries
The Catalyst control plane is never on the request path for application data. Configuration flows down from the control plane to the data plane; application payloads stay within the data plane and your applications.
A Catalyst deployment has three trust zones:
- Catalyst control plane — the management surface (CLI, console, API). It stores resource definitions, manages the workload identity system, and reconciles desired state into the data plane.
- Catalyst data plane — the Dapr Servers, platform services, and backing infrastructure that handle your Dapr API calls. Runs in a Kubernetes cluster — Diagrid-managed on Catalyst Cloud and Enterprise Dedicated, customer-managed on Self-Hosted and Air-Gapped.
- Customer applications — your application and agent code, running wherever you choose to run it. Catalyst never executes this code; it only routes traffic to and from it.
Three boundaries are crossed at runtime:
| Boundary | What crosses it | How it is secured |
|---|---|---|
| Application → data plane | Dapr API calls (state, pub/sub, workflow, service invocation, …) | App ID API token on every call; transport is TLS to the regional Gateway. |
| Data plane → application | Pub/sub deliveries, input bindings, service-invocation callbacks | Optional application token in the dapr-api-token header; combine with network allowlisting on the project's egress address. |
| Data plane internals | Dapr Server ↔ Dapr Server, Dapr Server ↔ backing infrastructure | SPIFFE-based mTLS — each in-platform workload mutually authenticates with a short-lived X.509 SVID. |
Identity and mTLS
Catalyst issues a SPIFFE-based, cryptographically verifiable identity — a short-lived X.509 SVID, signed by a Dapr Sentry and automatically rotated — to every workload that participates in the data plane: each Dapr Server, each Catalyst component, and each platform service. These identities drive mTLS between data-plane components, and the certificates that back this mTLS are issued, distributed, and rotated by Catalyst with no operator intervention.
Your application itself does not carry a SPIFFE identity. It authenticates to Catalyst on every Dapr API call using its App ID API token, and the underlying transport is TLS to the regional Gateway. The Dapr Server that handles those calls is the entity with the SPIFFE identity — it represents your App ID inside the data plane and uses its SVID to mutually authenticate downstream connections.
On Catalyst Enterprise Self-Hosted, the identity system spans two trust domains — one for in-region traffic and one for traffic between the region and Diagrid Cloud. The regional CA that signs in-region SVIDs is either auto-generated by Sentry on first boot (suitable for non-production; one-year lifetime, no auto-renewal) or supplied by you and rotated under your own PKI lifecycle, typically with cert-manager. See System Architecture › Workload Identity and Regional PKI.
Isolation and data protection
Project and region isolation. Regions and projects are Catalyst's isolation primitives — see Organisations and Projects for the model. From a security standpoint, the project boundary is enforced at the network layer: Catalyst applies a deny-by-default network policy in each project so workloads in one project cannot reach another project's namespace or other internal services on the cluster network without an explicit allow rule. On Self-Hosted you can tune the defaults; see System Architecture › Network Policies.
Secret management. Sensitive metadata on components, HTTP endpoints, and configurations (connection passwords, API keys, tokens, certificates) is held in secret stores you own or Catalyst manages on your behalf — never as plaintext in the control plane. The two models are covered in Managing Secrets:
- Transparent extraction (default) — plaintext values in sensitive fields are extracted into a Catalyst-managed secret store at submission time and replaced with a
secretKeyRef. - Bring your own secret store — reference a Dapr secret store component (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) from your resources and Catalyst applies them as declared.
Applications can also resolve secrets at runtime via the Dapr Secrets API, keeping credentials out of application code and environment variables.
Access control
Access to the Catalyst control plane is governed by role-based access control:
- Human users belong to an organisation and are assigned one of four roles — Admin, API Operator, API Consumer, or Viewer — either globally or scoped to specific projects. Enterprise plans support SAML 2.0 SSO, so user lifecycle is managed by your IdP.
- Automation uses API keys: named tokens with a role assignment, configurable expiry, and optional project scope; the secret value is shown only at creation time.
See Manage Access for the full role matrix, SSO setup, and API key management.
Workloads authenticate to the data plane using their App ID API token. Runtime behaviour for each App ID — what it can invoke, which components it can use, and how requests are filtered — is governed declaratively by policies.
Audit logging and compliance
User and application audit logs capture who did what and when across the control plane — which user created an App ID, who rotated an API key, which service account deployed a component. Audit logs are available on Catalyst Enterprise plans and support compliance review; see Observability › Audit logs.
Diagrid is SOC 2 Type II certified. You can request the SOC 2 Type II report by contacting sales@diagrid.io.
Shared responsibility model
Catalyst is a managed runtime, and the line of responsibility shifts with the hosting model. The table below summarises the split for Catalyst Cloud and Enterprise Dedicated; on Self-Hosted and Air-Gapped, customer responsibility expands to cover the Kubernetes cluster, the regional PKI lifecycle, and any backing infrastructure you choose to bring (PostgreSQL, Kafka, etc.).
| Area | Diagrid is responsible for | Customer is responsible for |
|---|---|---|
| Control plane | Availability, patching, hardening, secret storage | Managing users, API keys, and roles |
| Data plane (Dapr runtime) | Runtime versioning, mTLS, certificate issuance and rotation, isolation between projects | Configuring App IDs, components, and policies for your workloads |
| Workload identity | Issuing and rotating SPIFFE SVIDs for in-platform components | Binding applications to App IDs and protecting App ID API tokens |
| Encryption in transit | mTLS everywhere on the data plane | TLS termination on your own application endpoint if Catalyst calls back to it |
| Secrets | Encrypted storage in the managed or BYO secret store, never in the control plane DB | Choosing the secret store, rotating long-lived credentials it holds |
| Network isolation | Deny-by-default NetworkPolicies between project namespaces | Allowlisting Catalyst's project egress on your application network |
| Application code | — | Application logic, dependencies, callback authentication, input validation |
| Compliance | SOC 2 Type II, audit log capture, status reporting | Your own compliance posture and access reviews for users and keys |
See System Architecture for the full Self-Hosted responsibility breakdown, including outbound connectivity to Diagrid Cloud.
See also
- Application Identities — App ID as the unit of identity and access.
- Organisations and Projects — top-level isolation scopes.
- Policies — declarative runtime behaviour bound to App IDs.
- Manage Access — users, roles, and API keys.
- Managing Secrets — transparent extraction and BYO secret stores.
- System Architecture (Self-Hosted) — dual-sentry trust model, regional PKI, network policies.
- Dapr Open Source security guide — the OSS security baseline Catalyst builds on.