EngineeringQuantum Helix

Communication & integration

A QHx proxy authenticates the peer on its connection and applies the configured identity restrictions. Resource admission, network isolation and access to an object’s key are separate controls.

Browse documentation
On this page

Put the proxy on the intended path.

QHx Proxy carries configured application traffic over mutually authenticated TLS (mTLS) connections. In the paired HTTP deployment, the application connects to a local client proxy. That proxy authenticates the receiving server proxy, which forwards the request to the destination application.

The protected connection runs between the proxies. The documented local application connections can be plaintext, so their listeners and routes need protection. Binding a listener to loopback limits network exposure; host and workload isolation still matter.

The proxy needs access to a SPIFFE Workload API socket, an eligible workload registration and accepted trust bundles. Credential issuance supplies its identity. Peer authentication checks the certificate and possession of its private key; configured identity restrictions determine whether the proxy accepts that peer. Network placement alone neither establishes that identity nor grants connection permission. Protected transport, routes, availability and required boundary controls remain deployment requirements.

From the existing feed to a permitted connection.

A fielded publisher exposes an existing HTTP observation feed. An integration adapter reads it, maps the output to the receiving application’s contract and sends through its local QHx proxy. The mission application belongs to another operator. A maintenance application has a separate workload identity but should not use the receiving service. The adapter is an authorized plaintext processor, implemented for this application; QHx supplies the surrounding communication controls.

Illustrative service connectionApplication traffic
An existing observation feed reaches a separately operated mission application Under the sensor operator, an integration adapter reads an existing HTTP observation feed and maps its output. The adapter sends through a local QHx client proxy with the adapter workload identity. An authenticated encrypted connection reaches the mission operator’s server proxy, which permits the adapter identity and forwards to the mission application. The adapter sees plaintext; its identity does not establish authenticated origin at the original sensor. Sensor operatorMission operator Fielded observation publisher Existing HTTP feed Integration adapterReads plaintext · maps the output Local HTTP QHx client proxyAdapter workload identity Receiving mission application Local HTTP QHx server proxyAdapter identity permitted Authenticated,encrypted connection

Sensor operator

Fielded observation publisher

↓ Existing HTTP feed

Integration adapterReads plaintext and maps the output

↓ Local HTTP

QHx client proxyAdapter workload identity

Authenticated, encrypted connection

Mission operator

QHx server proxyAdapter identity permitted

↓ Local HTTP

Receiving mission application
Another requesterMaintenance application× Connection refusedIts identity is outside the receiving proxy’s allowed set.
Boxes group administrative responsibility. Arrows show the forward application path; the middle leg is the authenticated, encrypted proxy connection. The adapter is application-specific integration. Object protection and request recording are separate arrangements.
  1. Issue identities. Each operator configures node attestation and workload registration. The adapter’s proxy receives an identity associated with the registered adapter workload; the maintenance workload receives a different identity. Protect the local listener so another workload cannot borrow the adapter’s proxy path.
  2. Configure the path. The adapter sends HTTP to its local listener. Its proxy targets the mission proxy’s reachable HTTPS address and restricts the outgoing peer identity to the mission service. The mission proxy accepts only the adapter’s registered identity pattern and targets its own local application.
  3. Authenticate and authorize the connection. The operators configure trust bundles for the accepted issuing authorities. During connection establishment, the proxies authenticate each other. The receiving proxy checks the incoming identity against its allowed patterns.
  4. Observe both results. The adapter’s exchange reaches the mission application. A connection from the maintenance workload’s own proxy authenticates under the recognized authority but fails the receiving proxy’s identity restriction. No request evidence is implied by this transport example.

The feed and local application legs expose plaintext to their participants. Authenticate and isolate those interfaces according to their environment. The adapter’s credential does not prove origin at an unauthenticated source device, and transformation alone does not establish an approved release decision.

After the receiving application changes

Check its API contract and update the adapter mapping where necessary. Review the receiving identity, workload registration, target address and network rules. If those interfaces and identities remain valid, the existing proxy and issuance mechanisms can be reused. Re-test both authorized and refused connections and inspect existing sessions separately; changing a rule does not promise immediate termination of every session.

The worked integration follows replacement of the recipient, partner access and operation after the remote link is lost.

The receiving restriction

This illustrative listener excerpt allows the adapter service account in the observations namespace. Replace the example identity with the intended registration; a broad pattern authorizes every matching workload.

# Receiving server proxy: listener excerpt, not a full deployment.
mode: server
protocol: http
source:
  spiffe_ids:
    - '^spiffe://sensor\.example/ns/observations/sa/adapter/.*$'
target:
  url: http://127.0.0.1:8080

source.spiffe_ids and target.spiffe_ids are lists of regular expressions. An empty list accepts any SPIFFE identity authenticated by the available trust bundles. Anchor the patterns and escape literal dots. Setting an incoming identity pattern on a plaintext client listener does not authenticate its local application caller.

A central proxy changes the identity visible at the next hop: the server authenticates the central proxy. Do not treat that identity as direct proof of the original caller. Application authorization and any additional requester context need their own enforcement.

Adapt the interface without hiding the processor.

The documented proxy handles HTTP, TCP and MQTT transport paths. Protocol forwarding does not itself transform an observation schema, create an audience-specific tasking product or supply a semantic connector to every broker. The adapter’s contract identifies its inputs, outputs, permissions and failure behavior.

A bounded, versioned transformation can make recurring application work easier to test and replace. M42 is exploring how more of that work can be expressed in reusable mechanisms. This is an engineering direction, not a packaged universal adapter runtime. Existing interfaces and integration code remain part of the deployment.

Translate the service path into configuration.

For the managed Kubernetes path, operators annotate Services with flowspecs describing the protocol, source selection and port. QHx Manager reconciles that configuration and configures the proxy path. Source selectors can refer to supported workload labels, service accounts or SPIFFE identity patterns.

A manually configured proxy instead loads listeners, targets and identity restrictions from its configuration. For an HTTP client proxy, an HTTPS target selects the protected outgoing hop; a client-mode setting alone does not turn a plaintext HTTP target into mTLS.

Configuration is control traffic. The application’s requests use the resulting data path. Node attestation and resource admission are not performed on every packet, and enabling a proxy does not automatically enable Notary recording.

Control resource admission and labels.

QHx admission control maps principal identity to classification, compartment and releasability labels. These labels constrain resource operations and supply inputs to subsequent controls. Policy administrators configure the mappings and protect the authority to change them.

Admission checks concern resource operations. They are distinct from a proxy authenticating a peer or an application deciding whether to perform a requested action. Labeling a resource does not itself establish approval to disclose information or transfer it between classification domains.

Close paths around the proxy.

QHx Manager can generate Kubernetes NetworkPolicies using MLS identity labels. The cluster’s network implementation must enforce those policies, and the effective rules must exclude unintended direct access to protected services.

Inspect the generated rules and test direct connections as well as proxy connections. A proxy policy governs traffic that reaches that proxy; it cannot deny traffic on a path that bypasses it. NetworkPolicy also does not isolate host memory or prevent a sufficiently privileged administrator from changing the controls.

The security model sets out the trusted authorities and remaining host, network and application assumptions.

Protect an object beyond its connection.

CABE specification

CABE is an open specification defining an encrypted Envelope and a key-access mechanism. QHx can use it through a separate client integration where object-level protection and an independent key authority are appropriate; CABE can also be used independently. QHx transport does not apply this object protection automatically. A transport connection ending at a broker exposes its application payload there unless the publisher applies separate object protection.

A protected object through shared storageCABE integration pattern
  1. PublisherAssigns Attributes, obtains authorized key material and encrypts the Payload.
  2. Broker or archiveCarries the encrypted Envelope. This intermediary receives no decryption key.
  3. Receiving applicationRequests key access; decrypts locally if the Key Service permits it.
Separate key-access pathClient ⇄ Key Service: authenticate the caller, apply Policy, return permitted key material.
Illustration using a Non-Captive Key. Envelope delivery and key access are separate operations. A second recipient can receive the same Envelope and be refused key access, provided it does not already hold usable key material. The Key Service and authorized recipients remain trusted for the keys they hold.

The publishing application assigns Attributes and encrypts before handing the Envelope to the intermediary. The Key Service authenticates clients and applies Policy to requests for key material. Its decision is separate from the permission to establish a QHx connection.

This arrangement separates custody of an encrypted Envelope from authority to obtain its key. An approved broker or archive can carry information for several audiences without becoming a reader of every Payload. Encryption does not itself authorize placing the object on that intermediary, and key authorization does not replace the applicable information-release policy. The integration still supplies compatible application formats, Attribute meanings, release rules and a permitted transport arrangement.

SPIFFE identity federation and CABE Key Service federation are different relationships. A CABE Domain is not inherently a classification domain or an approved security boundary. Neither mechanism erases keys or plaintext already released to a recipient.

The authoritative descriptions are CABE’s architecture, Envelope format and key access protocol. Its federation specification describes preparation for independently operated Key Services.

EngineeringDeployment & operations