Security

This page describes the platform's security model: what Conncentric provides and what your infrastructure is responsible for. Authentication is delegated to your identity provider, access is controlled there, and network encryption and audit coverage come from layers you already run. Each section states the boundary explicitly, so you can tell at a glance which controls are yours to configure.

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

The Portal does not provide role-based access control: all authenticated users have full access to the Portal. Control who can reach Conncentric at the identity provider level, as described below.

Mitigating the Absence of Native RBAC

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 separation (UAT vs. Production), deploy separate Conncentric instances per environment with a distinct OIDC group assignment for each. This gives you environment-level isolation using infrastructure you already manage: you control which people can log in to which environment. It does not create a read-only tier. Within any single instance, access is all-or-nothing: every user who can authenticate has full access, so separate instances cannot be used to grant operations staff read-only access while configuration engineers get full access. To keep someone from changing a given environment, do not grant them access to that instance at all.

This approach helps you meet the common requirement that 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

The platform does not provide application-level audit logging (tracking which Portal user changed which configuration and when). You can assemble audit coverage from the infrastructure layers below.

Infrastructure-Level Audit Coverage

These use tools your infrastructure already provides. Combined, the following layers help you reconstruct who changed what and when:

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 definitions from the Portal, commit them to Git, deploy via Helm), your Git history serves as an auditable change log for your 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: 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 give you a layered record across identity, configuration, and infrastructure.

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

The platform does not manage certificates, keys, or TLS for protocol sessions. Whether a session to an external venue or counterparty is encrypted depends on that session and on your infrastructure: where your network terminates TLS at the boundary (load balancer or network layer), the traffic is encrypted there; sessions carried in the clear over a private link or VPN are not. Configure encryption for each session according to what the counterparty supports and your organization's standard approach.

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 a Kubernetes Secret and reference it by name.

Create the Secret before deploying. The Secret's data keys must be named username and password; the platform reads those keys by name, so other key names will not be picked up:

kubectl create secret generic conncentric-db-credentials \
  --from-literal=username=<user> --from-literal=password=<pass> \
  -n conncentric

Then reference it by name in your Helm values:

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.

Credentials in Component Configurations

Connection credentials that a connector or processor needs (a message bus password, an external database login) should never be typed into a configuration form as a literal value. Instead, reference an environment variable:

${env:BUS_SASL_PASSWORD}

A reference can stand alone or sit inside a longer value (for example inside a SASL JAAS line). It resolves inside the adapter pod at the moment the component is wired, from the pod's environment. The platform's configuration store, environment exports, and support bundles carry only the reference text; the resolved value exists only in the running component. To emit the literal text ${env:...} without resolution, escape it as $${env:...}.

Supply the variables from a Secret you own:

kubectl create secret generic connector-credentials \
  --from-literal=BUS_SASL_PASSWORD=<value> -n conncentric

adapter:
  extraEnvFromSecrets:
    - connector-credentials

If a configuration references a variable that is not set, the component fails to start with an event naming every missing variable; it never starts with an empty credential. Rotated secret values take effect on pod restart.

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 externally through the same Ingress as the Portal. The Ingress routes /api and /actuator paths to the Orchestrator so the Portal (running in the user's browser) can make API calls. This means the Orchestrator API is protected by the same HTTPS and OIDC authentication as the Portal.

Within the cluster, Adapter pods and the Installer job communicate directly with the Orchestrator ClusterIP Service on port 8080. Use Kubernetes NetworkPolicies to restrict direct access to the Orchestrator Service to only pods within the Conncentric namespace. See Prerequisites for the complete network port matrix.

Platform Attack Surface

The platform exposes traffic outside the cluster through two mechanisms:

1. Ingress (HTTPS). The Portal UI and the Orchestrator API are both served through the same Ingress, protected by HTTPS and OIDC authentication. The Portal is a single-page application that runs in the user's browser and calls the Orchestrator API at /api. 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.

Metrics and health endpoints are served by the Orchestrator under /actuator, and the Ingress routes /actuator to the Orchestrator on the same public path as /api and the Portal. They are therefore reachable through the authenticated Ingress (behind the same HTTPS and OIDC), not network-isolated behind the cluster boundary. In-cluster Prometheus scrapes the same /actuator endpoints directly over the ClusterIP Service. If you need metrics and health to be unreachable from outside the cluster, exclude the /actuator path from the Ingress and rely on the in-cluster scrape path only. See Networking & Ingress for the full networking model.