Skip to main content

Security

Authentication​

Portal Login​

The Portal authenticates users via OIDC (OpenID Connect). Users log in through your organization's identity provider (Auth0, Okta, Azure Entra ID, or any OIDC-compliant provider).

No passwords or user accounts are stored in Conncentric. Authentication is fully delegated to your identity provider.

See Authentication Configuration for setup details.

Access Control​

Native role-based access control (RBAC) within the Conncentric Portal is on the product roadmap but is not yet shipped. Currently, all authenticated users have full access to the Portal. When roles ship, they will be derived from claims in the identity provider's token. No configuration in Conncentric will be required.

Mitigating the Absence of Native RBAC​

Until native RBAC is available, control who can access Conncentric at the identity provider level. This is the recommended approach:

  1. Create a dedicated application group in your identity provider (e.g., a "conncentric-users" group in Okta, an App Assignment group in Azure Entra ID, or a role in Auth0).
  2. Restrict the OIDC application so that only members of that group can authenticate. Most providers support conditional access policies or application assignment requirements that prevent non-members from obtaining tokens.
  3. For environments requiring stricter separation (e.g., read-only access for operations staff versus full access for configuration engineers), deploy separate Conncentric instances per environment (UAT vs. Production) with different OIDC group assignments for each. This provides environment-level isolation using infrastructure you already manage.

This approach satisfies the compliance requirement of "only authorized personnel can access the application" using your existing identity infrastructure. Access grants and revocations are managed centrally through your identity provider's standard workflows.

Change Tracking and Audit Coverage​

Application-level audit logging (tracking which Portal user changed which configuration and when) is on the product roadmap but is not yet implemented within the platform.

Infrastructure-Level Audit Coverage​

You can achieve defensible audit coverage using tools your infrastructure already provides. Combined, the following layers answer the "who changed what and when" question that compliance teams require:

Identity provider logs. Your OIDC provider (Okta, Azure Entra ID, Auth0) records all authentication events: who logged in, when, from which IP address, and whether access was granted or denied. These logs establish who had access to the platform at any given time.

GitOps configuration trail. If you adopt the recommended GitOps workflow (export adapter configurations from the Portal, commit JSON manifests to Git, deploy via Helm), your Git history serves as a complete, immutable, and auditable change log for all production configuration changes. Every change is attributed to a Git author, timestamped, and reviewable through pull request history.

Kubernetes audit logs. Enable the Kubernetes API server audit policy to capture all API calls within the Conncentric namespace. This records pod lifecycle events, secret access, ConfigMap changes, and Helm release activity at the cluster level.

Database audit logging. Enable pgaudit (or your managed database provider's equivalent) on the PostgreSQL instance. This captures all SQL statements executed against the Conncentric database, providing a record of every data modification.

Summary for compliance teams: Authentication events are logged by the identity provider. Configuration changes are tracked in Git. Infrastructure-level mutations are captured by Kubernetes audit logs and database audit logging. Together, these provide a layered audit trail while native application-level audit logging is under development.

Encrypted Connections​

To the Portal​

All traffic to the Portal goes through HTTPS. TLS is terminated at the Ingress controller or load balancer. This is standard Kubernetes Ingress configuration and is managed by your infrastructure team, not by the platform.

Protocol Sessions​

Connections to external venues and counterparties are encrypted at the infrastructure boundary. Your infrastructure team configures TLS termination at the load balancer or network layer using your organization's standard approach. The platform does not manage certificates or private keys directly.

Between Platform Components​

Internal communication between platform components runs within the private Kubernetes cluster network, isolated from external traffic. Use Kubernetes NetworkPolicies to further restrict cross-component traffic to Conncentric pods only.

Keeping Secrets Safe​

Passwords and credentials should never be written directly into Helm values files. Instead, store them in Kubernetes Secrets and reference them by name:

database:
  auth:
    existingSecret: "conncentric-db-credentials"

For teams using centralized secrets management, Conncentric is compatible with HashiCorp Vault, AWS Secrets Manager, and Azure Key Vault via their standard Kubernetes integrations.

Network Access​

Outbound (Initiator Pattern)​

Adapter pods configured as initiators (outbound connections to external systems) require outbound network access to:

  • The Orchestrator (to maintain their session lease and fetch configuration)
  • The external systems they connect to (venues, brokers, message clusters, etc.)

No inbound ports need to be opened for initiator-mode adapters.

Inbound (Acceptor Pattern)​

Adapter pods configured as acceptors (listening for inbound connections from external systems) require inbound ports to be opened. The specific port is defined in the adapter configuration and must be reachable by the external counterparty.

For acceptor-mode adapters:

  • Expose the configured port via a Kubernetes Service (LoadBalancer or NodePort).
  • Restrict inbound traffic to known counterparty IP ranges using Kubernetes NetworkPolicies or cloud security groups.

Internal Traffic​

The Orchestrator API is accessible only from within the cluster. It is not exposed through the Ingress. Only Adapter pods, Portal pods, and the Installer job communicate with the Orchestrator.

Use Kubernetes NetworkPolicies to restrict cross-component traffic so that only Conncentric pods can reach the Orchestrator service. See the Day 0 Onboarding Runbook for a complete network port matrix.

Platform Attack Surface​

The platform exposes two entry points to traffic outside the cluster:

  1. The Portal (HTTPS via Ingress). A web application protected by your OIDC provider. No unauthenticated access is possible.
  2. Adapter acceptor ports (if configured). TCP ports for inbound protocol sessions. These are defined per adapter and should be restricted to known counterparty IP ranges.

The Orchestrator API, management ports, and metrics endpoints are internal only and are not exposed outside the cluster.