How QHx ties identity, policy, and protected data together

For the shorter conceptual overview, see Architecture.

QHx is a workload security fabric centered on application workloads. It provides cryptographic workload identity, authenticated application communications, and data-centric protection while extending trust across Kubernetes clusters and administrative domains.

QHx calls each managed identity domain a QHx Authority. A QHxAuthority is a QHx-managed workload identity authority backed by a dedicated SPIRE PKI and trust domain. A QHxPolicy object or the cluster default selects the QHx Authority for a namespace. The QHx Manager publishes that mapping, the CSI driver mounts the authority-specific Workload API socket, and the selected SPIRE runtime attests the workload and issues its SVID.

QHx Proxy provides the fabric’s service-mesh capability for explicitly configured application connections. CABE provides data-centric protection independently of QHx Proxy or any particular connection: an application that uses CABE presents its SVID to Khaled for authorized key access, while the CABE SDK constructs or opens the CBES envelope and protects the payload locally. The protected object can then be stored, forwarded, or transported without making its protection depend on the connection that carries it.

One QHx Manager operates one Kubernetes cluster and may operate multiple QHx Authorities in that cluster. A different cluster has its own Manager. Peer Managers exchange signed federation state, and each Manager makes accepted trust bundles available to the SPIRE servers in its own cluster. Federation makes foreign workload identities verifiable; it does not grant application access, proxy permission, or CABE key access. Khaled’s Cedar policy governs CABE key access, QHx Proxy rules govern transport peers, and the application applies its own authorization policy.

QHx from the application’s point of view

Workload identity begins when a participating Pod explicitly mounts a SPIFFE Workload API socket. Through that socket, the workload obtains an X.509-SVID from the selected QHx Authority. The QHx Authority determines the workload’s trust domain and identity profile, while its SPIRE runtime performs attestation and issues the credential.

Authenticated application communications and data-centric protection use that SVID at separate boundaries. A workload deployed with QHx Proxy can authenticate an explicitly configured application connection; the proxy supports HTTP, TCP, and MQTT listeners with source and target identity rules, and its in-process notary can record evidence when configured. An application that uses CABE calls Khaled through the CABE SDK for authorized key access, then the SDK protects the application object locally.

The QHx Manager resolves a namespace’s QHxPolicy object or the QHxCluster default and publishes the namespace-to-authority mapping. The shared CSI driver reads that mapping and bind-mounts one authority-specific SPIRE agent socket into the Pod. Each QHx Authority has its own SPIRE installation. Separately, the QHx Agent observes the lifetime and renewal of its own SVID and emits metrics; it is not an application-traffic proxy or a network interceptor.

One QHx Manager operates one Kubernetes cluster and may operate several QHxAuthority resources in that cluster. A peer Kubernetes cluster has its own Manager. Peer Managers exchange signed federation state, and each Manager makes the accepted trust bundles available to the SPIRE servers in its own cluster.

Figure 1. The selected QHx Authority’s SPIRE runtime issues the workload’s SVID. An application that uses CABE presents that identity to Khaled for authorized key access, while the CABE SDK constructs the protected CBES object locally. A workload deployed with QHx Proxy may use the same identity for an explicitly configured application connection. Federation makes remote identities verifiable without granting access to the protected data.

Figure event transcript

The namespace selects a local authority. A QHxPolicy object or the QHxCluster default supplies the namespace’s authority selection.
The Manager publishes routing state. Manager A turns the local selection into routing state for the shared CSI driver.
The CSI driver mounts the selected Workload API socket. The CSI driver is a socket router; it does not issue the workload credential.
SPIRE issues the workload identity. The selected QHx Authority’s SPIRE installation returns an X.509-SVID through the mounted socket.
The optional CABE integration requests authorized key access. The client library uses CKAP with Khaled and constructs the protected CBES object inside the application process.
The proxy remains explicitly deployed. QHx Proxy participates only in the configured application connection.
The in-process notary creates separate evidence. The optional notary remains inside the configured proxy process and does not produce CABE objects.
Peer Managers exchange federation state. Signed peer federation state flows between Manager A and Manager B at cluster scope.
Trust-bundle retrieval remains local to each cluster. Each local SPIRE server retrieves accepted bundles from its own cluster’s Manager.

Kubernetes configuration or reconciliation: Blue dashed connector
Identity issuance or trust: Cyan solid connector
CKAP request or key-access result: Amber solid connector
Application traffic or evidence: Violet solid connector
Federation-state exchange or trust-bundle delivery: Green connector

The QHx Authority selection determines the workload’s issuer, trust domain, and identity profile. The QHx Manager publishes the route, the CSI driver mounts the selected socket, and the authority’s SPIRE runtime issues the credential. Khaled, the CABE SDK, and QHx Proxy use that credential for separate and optional purposes.

Implementation evidence

Observed

messier-42/qhx-corepkg/manager/cmd/main.go

main

The Manager starts the local resource reconcilers, per-authority Workload API sources, peer-federation listener, and local trust-bundle listener.

Observed

messier-42/qhx-corepkg/agent/pkg/daemon/daemon.go

Daemon.Run

The QHx Agent observes SVID renewal and expiry and records identity-health metrics; it does not participate in CKAP requests.

Observed

messier-42/qhx-corepkg/proxy/cmd/config.go

proxyConfig.Validate

QHx Proxy owns explicitly configured application listeners and its own SPIFFE Workload API socket.

Bootstrapping a QHx Authority

The Helm release installs the QHx Manager, its admission service, the custom-resource definitions, and the configuration that creates the default QHxCluster and QHxAuthority. The cluster object identifies the default QHx Authority for the local cluster. Each authority object represents one dedicated SPIRE installation, PKI, and trust domain.

When the QHx Manager observes a QHxAuthority, its reconcilers create the SPIRE server, the SPIRE controller-manager, the SPIRE agents, the registration resources, and the authority-specific host socket directory. They also register the Manager in that trust domain. The Manager then opens the authority-specific agent.sock Workload API source and obtains its own SVID for serving accepted trust bundles to local SPIRE servers and for signed peer-federation artifacts. The Manager does not read an identity directly from a trust root or issue application credentials.

The authority’s SPIRE server owns the certificate authority, while the SPIRE controller-manager reconciles the registration resources. Agents on each node expose a Workload API socket under the authority’s directory beneath /run/spire/sockets. The shared CSI driver can select one of those directories for a Pod after the Manager writes namespace-map.yaml and default-authority.

Readiness arrives in layers. Kubernetes can accept the installation before the Manager becomes healthy, and the default QHxCluster can report Ready while its authority still waits for a trust root or the Manager’s SVID. The CSI DaemonSet can exist before kubelet registers the driver. Only a representative workload exercises the volume, the selected socket, attestation, registration, and SVID return together.

Step 10 of 10 · A workload check exercises the complete identity-issuance sequence.

Figure 2. Helm creates the default QHx resources. The Manager reconciles the QHx Authority’s SPIRE resources, registers itself in the trust domain, and obtains its SVID through the authority-specific agent Workload API.

Figure event transcript

Helm submits the installation resources. The Helm release creates the Kubernetes resources that establish the QHx control plane.
The API stores the Helm-created custom resources. The QHxCluster and QHxAuthority objects become the desired state for the local identity domain.
The Manager observes the custom resources. The QHx Manager watches QHxCluster and QHxAuthority rather than creating their default instances itself.
The Manager creates the authority’s SPIRE resources. The authority receives a server, controller-manager, agents, registrations, and socket storage.
The SPIRE server establishes the authority’s trust root. TrustRootAvailable becomes true only when the Manager observes an X.509 root in the bundle.
The Manager opens the authority-specific Workload API. The Manager connects to that authority’s agent.sock as an ordinary registered workload.
The authority’s agent returns the Manager SVID. SVIDResolvable records that the per-authority Workload API source can resolve the Manager credential.
The Manager publishes namespace-routing state. The routing ConfigMap contains namespace-map.yaml and default-authority.
The CSI driver registers with kubelet. The shared DaemonSet reads the routing files and authority socket base directory.
A workload check exercises the complete identity-issuance sequence. A representative Pod proves volume publication, socket selection, attestation, registration, and SVID return together.

Authority readiness

No single condition verifies the complete workload-identity flow. The QHx Manager reports several conditions on a QHxAuthority:

IdentityValid records whether the authority’s identity configuration is valid.
ConfigApplied records whether the Manager applied the authority’s desired resources.
TrustRootAvailable requires a bundle containing an X.509 root.
SVIDResolvable requires the Manager to open the authority’s Workload API source and resolve its SVID.
Ready rolls up the trust-root and SVID requirements after the preceding configuration checks pass.

Other signals cover different parts of the deployment. The Manager’s health endpoint on 8081 reports process health. The QHxCluster condition confirms that the named default authority exists. The CSI node-driver registrar confirms that kubelet registered the driver.

A representative workload is still required to exercise the mounted socket, workload attestation, SPIRE registration, and return of an X.509-SVID.

The QHx Manager creates and observes the authority’s resources; the SPIRE server owns the certificate authority and issues SVIDs. An end-to-end identity check must reach the workload through the selected socket rather than stop at an earlier readiness condition.

Implementation evidence

Observed

messier-42/qhx-coreconfig/default.nix

qhx-default-cluster and qhx-default-authority

The Helm release creates the default QHxCluster and QHxAuthority custom resources.

Observed

messier-42/qhx-corepkg/manager/pkg/controller/authority_lifecycle_controller.go

AuthorityLifecycleReconciler.ensureSpireResources

The Manager observes QHxAuthority desired state and creates or updates the authority-owned SPIRE resources.

Observed

messier-42/qhx-corepkg/manager/pkg/spire/resources.go

BuildServerStatefulSet, BuildAgentDaemonSet, BuildWebhookService, and controllerManagerConfig

The builders define the per-authority SPIRE server and controller-manager, agents, registrations, socket storage, interfaces, and shared CSI integration.

Observed

messier-42/qhx-corepkg/manager/pkg/spire/agentsource.go

AgentSourceManager.Sync and newWorkloadAPISource

The Manager is an ordinary workload of each authority and obtains its SVID from that authority’s agent.sock Workload API source.

Observed

messier-42/qhx-corepkg/kutest/authority_lifecycle_test.go

TestAuthorityLifecycle

The integration suite corroborates authority readiness and exercises default and explicit namespace bindings end to end.

From namespace policy to a workload SVID

A QHxCluster object supplies the default QHx Authority for the local cluster. Each QHxAuthority object names a QHx-managed workload identity authority and its dedicated SPIRE PKI and trust domain. A namespaced QHxPolicy object refers to one of those authorities and expresses the namespace’s identity-routing choice; it contains neither a certificate nor a SPIRE registration or CABE authorization rule.

The QHx Manager lists the cluster, its authorities, the namespaces, and their policies. It resolves an explicit QHxPolicy when one exists and otherwise uses the cluster’s default authority. The Manager writes each successful resolution to namespace-map.yaml and stores the default in the default-authority key of the same ConfigMap. A checksum annotation rolls the CSI DaemonSet when those files change.

A workload participates only when its Pod specification explicitly requests a volume using the driver name csi.spiffe.io and mounts that volume into the container. The current admission webhook does not add this volume to arbitrary workloads. When kubelet publishes the volume, it calls the CSI driver’s NodePublishVolume operation with the Pod metadata. The driver reads the namespace mapping, chooses one authority, and bind-mounts that authority’s socket directory into the Pod.

After the mount is available, the workload opens agent.sock through the SPIFFE Workload API directory. Its request reaches the selected SPIRE agent and then that authority’s SPIRE server. The server issues an X.509-SVID and returns the credential through the agent and the same socket to the requesting process. Both directions therefore follow the authority selected by the CSI driver.

spiffe://<authority-trust-domain>/ns/<namespace>/sa/<service-account>/pod/<pod-name>/<pod-uid>

The selected authority supplies the trust domain, while the path identifies the namespace, service account, and individual Pod instance.

Step 11 of 11 · The X.509-SVID docks at the workload.

Figure 3. The CSI driver bind-mounts one authority-specific socket directory into the Pod. The workload requests an identity through that SPIRE agent, and the issued X.509-SVID returns through the same socket.

Figure event transcript

The namespace supplies an authority selection. An explicit QHxPolicy reference or the QHxCluster default names one local QHx Authority.
The Manager publishes the resolved route. The Manager writes namespace-map.yaml and default-authority for the shared CSI driver.
Kubelet begins volume publication. Kubelet reads the Pod metadata and calls NodePublishVolume for the explicit csi.spiffe.io volume.
The request enters the CSI driver. The CSI driver reads the namespace route and selects the QHx Authority-specific socket directory.
The CSI driver mounts the selected socket. The driver bind-mounts the selected QHx Authority’s directory into the Pod.
The workload opens the Workload API. The process connects to agent.sock through its mounted volume.
The SPIRE agent attests the workload. The selected QHx Authority’s SPIRE agent verifies the calling workload context.
The SPIRE server resolves the registration. The agent asks its QHx Authority’s server to match the attested workload and issue a credential.
The server returns the issued credential. The X.509-SVID begins its response through the selected QHx Authority’s SPIRE agent.
The agent returns an explicit credential object. The SPIRE agent passes the issued X.509-SVID through the mounted Workload API socket.
The X.509-SVID docks at the workload. The credential response terminates at the process that made the Workload API request.

The QHx Manager writes the resolved namespace mapping, the CSI driver exposes the selected socket, and SPIRE issues the workload’s credential. The QHxPolicy object does not become a certificate or a Cedar rule, and it never travels to Khaled.

Implementation evidence

Observed

messier-42/qhx-corepkg/manager/pkg/policy/evaluator.go

Evaluator.Evaluate

The evaluator resolves a namespaced QHxPolicy authority reference, or the QHxCluster default when no policy exists.

Observed

messier-42/qhx-corepkg/manager/pkg/controller/spireinstance_controller.go

SpireInstanceReconciler.Reconcile

The Manager writes namespace-map.yaml and default-authority and rolls the CSI DaemonSet when routing data changes.

Observed

messier-42/spiffe-csi@v52.6.5pkg/driver/driver.go

Driver.lookupAuthority and Driver.NodePublishVolume

The CSI driver resolves the Pod namespace, selects the mapped authority or default-authority, and bind-mounts that authority’s socket directory.

Observed

messier-42/spiffe-csi@v52.6.5pkg/driver/driver_test.go

TestLookupAuthority/fallback to default authority

The pinned driver test verifies that a missing namespace entry falls back to the configured default authority.

Observed

messier-42/qhx-corepkg/kutest/authority_lifecycle_test.go

invalid explicit policy scenarios

This observed Manager behavior composes with the pinned CSI driver’s separately observed default fallback; together they produce the cross-component invalid-policy fallback.

Policy boundaries

Each QHx rule acts at a specific enforcement point and accepts inputs from that layer. A namespace-routing decision determines which QHx Authority a workload can reach; it does not grant access to cryptographic key material.

Policy and rule boundaries
Policy or rule	Input	Enforcement point	Effect
`QHxPolicy`	A namespace and a QHx Authority name	The QHx Manager and the CSI driver	Selects the workload’s QHx Authority
SPIRE registration and federation	Workload selectors and trust domains	SPIRE	Determines identity issuance and accepted trust
The Khaled Cedar policy	The principal, claims, action, CABE attributes, and time	Khaled	Permits or denies access to CABE key material
The proxy identity rules	Source and target SPIFFE-ID patterns	QHx Proxy	Permits or denies a transport peer
The CABE cryptographic binding	Attributes, lease context, references, and key material	Khaled and the CABE SDK	Protects references, key access, and the payload

A QHxPolicy object participates before the workload has an identity. It lets the Manager and CSI driver select the QHx Authority whose SPIRE Workload API socket the Pod can reach. SPIRE registrations then determine whether the attested workload matches an identity record, and federation bundles determine which remote trust domains SPIRE can verify.

The Khaled Cedar policy operates later. It receives an authenticated principal, Kubernetes-derived claims, a CKAP action, CABE attributes, and time-related context. Khaled evaluates those inputs when deciding whether the caller may receive key-access information. The proxy’s source and target rules operate on configured application connections, while CABE cryptographic bindings protect the integrity and relationships among attributes, lease context, references, keys, and payloads.

The current implementation does not translate a QHxPolicy object into a Cedar policy, and it does not send the QHxPolicy object to Khaled. An operator must configure both layers according to their separate purposes.

Implementation evidence

Observed

messier-42/qhx-corepkg/manager/pkg/api/v1/qhxpolicy_types.go

QHxPolicySpec

QHxPolicy is a namespaced reference that selects one QHxAuthority for workload identity routing.

Observed

messier-42/qhx-corepkg/proxy/cmd/config.go

listenerConfig.Validate

QHx Proxy validates listener-specific source and target SPIFFE-ID rules independently of QHxPolicy.

Observed

messier-42/khaledpkg/plugin/policyengine/cedar/cedar.go

Engine.DecideEncapsulate and Engine.DecideDecapsulate

Khaled evaluates CABE actions, the authenticated principal and claims, the CABE attribute set, and temporal context in Cedar.

Key access for encapsulation

CABE provides data-centric protection for application objects independently of QHx Proxy and its connection lifecycle. Once a workload has an X.509-SVID, its application can begin a CABE key-access sequence through the CABE SDK. The application supplies plaintext, a content type, and a CABE attribute set to the client-side cabecap implementation. The SDK obtains the caller’s SVID from the mounted Workload API and uses CKAP over HTTPS to request an authorized key-access result from Khaled.

Khaled is exposed by a Kubernetes Service on port 443, which targets its HTTPS listener on 8443. The representative base path is /ckap/, and CKAP uses deterministic CBOR encoding. The encapsulation request uses POST /ckap/Prograde. The request carries the inputs needed for key access; it does not carry the application plaintext.

The Prograde body supplies the CABE key-access inputs, not the caller’s Pod identity. Khaled verifies the connection’s X.509-SVID, parses its SPIFFE ID, reads the current Pod from the Kubernetes API, and checks the Pod UID and service account encoded in the identity. It creates claims from that current Kubernetes object rather than accepting an unverified identity string from the client.

For an encapsulation request, Khaled constructs the Cedar principal, action, resource, and context and evaluates the Encapsulate action. When a non-captive request is permitted, Khaled creates one lease result containing the derived lease key, an independently authenticated LeaseRef, and the lease context. The lease key is not transformed into the reference. The SDK uses the key and carries the opaque reference into the CBES envelope while encrypting the payload locally.

Kubernetes Service443 → 8443

TransportCKAP over HTTPS

Encodingdeterministic CBOR

OperationPOST /ckap/Prograde

Step 13 of 13 · The CABE SDK constructs the CBES envelope.

Figure 4. For non-captive access, Khaled returns one lease result containing the lease key, lease context, and an independently authenticated LeaseRef. The CABE SDK uses that result to encrypt the payload and construct CBES locally.

Figure event transcript

The application supplies plaintext and CABE attributes. The application passes both inputs to its local CABE SDK.
The client obtains the workload’s SVID. The CABE client uses the mounted Workload API identity established earlier.
The SDK sends the Prograde inputs. The CKAP request body carries CABE attributes and key-access inputs, not proof of the caller’s Pod identity.
Khaled authenticates the workload SVID. Khaled verifies the X.509-SVID and parses its SPIFFE ID before it reads Kubernetes state.
Khaled reads the current Pod. The authenticated SPIFFE identity names the Kubernetes Pod that Khaled retrieves.
Khaled verifies and derives the Pod claims. The current Pod UID and service account are checked and converted into authorization claims.
Cedar evaluates the Encapsulate action. Khaled supplies the principal, claims, action, CABE attributes, and context to Cedar.
Khaled derives the lease key. A permitted request reaches the CABE key engine inside Khaled.
Khaled creates an authenticated LeaseRef. The reference independently authenticates the lease context and binds it to the authorized CABE attributes.
The lease key enters the non-captive lease result. The authorized response carries the derived key as key-access material.
The LeaseRef and lease context enter the same result. The response carries the authenticated reference alongside the key; the key is not transformed into the reference.
Khaled returns key-access information. The result crosses the service boundary to the CABE SDK without application plaintext entering Khaled.
The CABE SDK constructs the CBES envelope. The SDK encrypts the payload locally and serializes the complete envelope inside the application process.

Khaled and the CABE SDK

Khaled

Authenticates the workload’s SVID.
Resolves the current Kubernetes claims.
Evaluates the Cedar policy.
Derives the lease key.
Creates authenticated references.
Returns authorized key-access information.

The CABE SDK

Creates the CABE attribute set.
Calls the CKAP endpoints.
Manages the key-access result.
Constructs the CBES envelope.
Encrypts the payload.
Serializes the envelope.

Khaled receives the authenticated CKAP request and authorizes access to CABE key material; it does not receive the application plaintext or construct the complete CBES envelope. The CABE SDK consumes the authorized result where the payload and the complete envelope remain available.

Implementation evidence

Observed

messier-42/khaledpkg/plugin/clientauthn/tlsspiffe/tlsspiffe.go

Authenticator.Authenticate

Khaled verifies the presented X.509-SVID against its SPIFFE bundle source before producing a client identity.

Observed

messier-42/khaledpkg/plugin/claimsmapping/k8sattestation/k8sattestation.go

Mapper.Map and Mapper.fetchAndAttest

Khaled parses the Pod SPIFFE ID, GETs the current Pod, verifies UID and service account, and derives Kubernetes claims.

Observed

messier-42/khaledpkg/plugin/policyengine/cedar/cedar.go

Engine.DecideEncapsulate and Engine.DecideDecapsulate

The Cedar adapter evaluates Encapsulate or Decapsulate with the principal, claims, attribute set, and time context.

Observed

messier-42/khaledpkg/keyserver/ops.go

Server.Prograde and Server.Retrograde

A permitted non-captive Prograde returns one lease containing both an authenticated LeaseRef and the lease key; Retrograde authenticates the supplied LeaseRef before rederiving access information.

Observed

messier-42/khaledpkg/keyschedule/schedule.go

Schedule.NewLease and Schedule.ResolveLease

The key schedule derives a lease key from the authenticated lease tuple and CABE attribute set; it does not authenticate references itself.

Observed

messier-42/khaledpkg/refwrapper/refwrapper.go

Codec.WrapLeaseRef, Codec.UnwrapLeaseRef, Codec.WrapLKAT, Codec.UnwrapLKAT

The reference wrapper authenticates LeaseRefs and LKATs, binds LeaseRefs to the attribute-set representation, and rejects cross-kind tokens.

Observed

messier-42/khaledpkg/keyserver/ops.go

Server.AssistedEncapsulate and Server.AssistedDecapsulate

In captive mode the lease key stays in Khaled: AssistedEncapsulate returns WrappedCEK and AssistedDecapsulate returns CEK.

Observed

messier-42/khaledpkg/plugin/transport/http/ckap.go

handlePrograde, handleRetrograde, handleAssistedEncapsulate, handleAssistedDecapsulate

The CKAP HTTP transport maps the authenticated request context to keyserver operations and serializes only the operation-specific response fields.

Observed

messier-42/cabe-gocabecap/capsulator.go

Capsulator.Encapsulate and Capsulator.Decapsulate

The CABE client resolves key access through CKAP while retaining the complete CBES envelope and application payload locally.

Observed

messier-42/cabe-gointernal/cbescodec/codec.go

codec.encapsulateNonCaptive, codec.encapsulateCaptive, codec.decapsulateNonCaptive, codec.decapsulateCaptive

The codec constructs and parses CBES, performs payload encryption or decryption, and invokes assisted CEK wrapping only for captive leases.

Observed

messier-42/cabe-gocmd/cabetool/encap.go, cmd/cabetool/decap.go, cmd/cabetool/whoami.go

newEncapCommand, newDecapCommand, newWhoamiCommand

cabetool delegates envelope operations to cabecap and prints Khaled’s mapped principal through GetSelf.

Observed

messier-42/qhx-corepkg/kutest/khaled_test.go and pkg/kutest/cabetool_helpers_test.go

TestKhaledCKAP and cabetool workload helpers

The QHx integration suite corroborates the direct implementations by mounting the selected Workload API socket and exercising whoami plus an encap/decap round trip through the packaged Khaled service.

Opening a CBES envelope

A CBES envelope remains a protected application object when it is stored, forwarded, or transported across a connection. It carries protected metadata that the CABE SDK can inspect before requesting key access. The SDK parses the envelope locally and extracts the CABE attribute set, an opaque LeaseRef, and the content type. It now holds the reference bytes, but only Khaled can authenticate their Khaled-issued lease context. The complete encrypted message remains in the application process.

The SDK sends POST /ckap/Retrograde with the attribute set and opaque LeaseRef over its authenticated workload connection. The request body does not establish the caller’s Pod identity. Khaled separately verifies the connection’s X.509-SVID, parses its SPIFFE ID, retrieves the current Pod, verifies the Pod UID and service account, and creates Kubernetes-derived claims. It then authenticates LeaseRef against the attribute set, recovers the lease context, and evaluates the Cedar Decapsulate action for the verified principal and claims.

When authorization succeeds, Khaled rederives the lease key and returns key-access information. The SDK applies that result locally to decrypt the payload. It returns the plaintext, the CABE attributes, and the content type to the application. The complete CBES envelope never needs to enter the Khaled service.

Step 15 of 15 · The SDK decrypts the payload locally.

Figure 5. The CABE SDK retains the complete CBES envelope while sending its protected attributes and opaque LeaseRef to Khaled. Khaled authenticates the reference, applies the Cedar policy, and returns authorized key access for local decryption.

Figure event transcript

The SDK receives the complete CBES envelope. The encrypted message enters the application-side CABE library.
The SDK parses the protected headers locally. The CABE attribute set, opaque LeaseRef, and content type are extracted without sending the envelope away.
The client obtains the workload’s SVID. The CABE client uses the mounted Workload API identity established earlier.
The SDK sends the Retrograde inputs. Only the CABE attributes and opaque LeaseRef needed for key access enter the CKAP request body.
Khaled authenticates the workload SVID. Khaled verifies the X.509-SVID and parses its SPIFFE ID independently of the Retrograde request body.
Khaled reads the current Pod. The authenticated SPIFFE identity names the Kubernetes Pod that Khaled retrieves.
Khaled creates current Kubernetes claims. The Pod UID and service account are verified before authorization.
Khaled authenticates the opaque LeaseRef. The supplied LeaseRef and CABE attribute set enter the reference-authentication operation.
Khaled recovers the lease context. Only a valid authenticated reference yields the lease context used by authorization.
Cedar evaluates the Decapsulate action. The verified caller claims and CABE request become the Cedar authorization input.
The authenticated lease context constrains authorization. The recovered context accompanies the Decapsulate decision.
Khaled rederives the lease key. A permitted request reaches the CABE key engine without the complete envelope entering Khaled.
Khaled prepares authorized key-access information. The rederived result is packaged for the calling SDK.
Khaled returns the key-access result. The response crosses back to the CABE SDK.
The SDK decrypts the payload locally. The SDK returns plaintext, CABE attributes, and the content type to the application.

The CABE attributes and the opaque LeaseRef cross the Khaled boundary over an authenticated CKAP connection; the complete envelope and its ciphertext stay inside the application. Because Khaled binds the LeaseRef to the attribute set and lease context, the reference cannot act as an unscoped key handle.

A non-captive key-access result may be cached according to its lease semantics, allowing later payload operations under the same authorized context to avoid a Khaled request for every message. That optimization does not move CBES parsing or payload cryptography into Khaled; it changes only how often the SDK needs to refresh key-access information.

Implementation evidence

Observed

messier-42/khaledpkg/plugin/clientauthn/tlsspiffe/tlsspiffe.go

Authenticator.Authenticate

Khaled verifies the presented X.509-SVID against its SPIFFE bundle source before producing a client identity.

Observed

messier-42/khaledpkg/plugin/claimsmapping/k8sattestation/k8sattestation.go

Mapper.Map and Mapper.fetchAndAttest

Khaled parses the Pod SPIFFE ID, GETs the current Pod, verifies UID and service account, and derives Kubernetes claims.

Observed

messier-42/khaledpkg/plugin/policyengine/cedar/cedar.go

Engine.DecideEncapsulate and Engine.DecideDecapsulate

The Cedar adapter evaluates Encapsulate or Decapsulate with the principal, claims, attribute set, and time context.

Observed

messier-42/khaledpkg/keyserver/ops.go

Server.Prograde and Server.Retrograde

A permitted non-captive Prograde returns one lease containing both an authenticated LeaseRef and the lease key; Retrograde authenticates the supplied LeaseRef before rederiving access information.

Observed

messier-42/khaledpkg/keyschedule/schedule.go

Schedule.NewLease and Schedule.ResolveLease

The key schedule derives a lease key from the authenticated lease tuple and CABE attribute set; it does not authenticate references itself.

Observed

messier-42/khaledpkg/refwrapper/refwrapper.go

Codec.WrapLeaseRef, Codec.UnwrapLeaseRef, Codec.WrapLKAT, Codec.UnwrapLKAT

The reference wrapper authenticates LeaseRefs and LKATs, binds LeaseRefs to the attribute-set representation, and rejects cross-kind tokens.

Observed

messier-42/khaledpkg/keyserver/ops.go

Server.AssistedEncapsulate and Server.AssistedDecapsulate

In captive mode the lease key stays in Khaled: AssistedEncapsulate returns WrappedCEK and AssistedDecapsulate returns CEK.

Observed

messier-42/khaledpkg/plugin/transport/http/ckap.go

handlePrograde, handleRetrograde, handleAssistedEncapsulate, handleAssistedDecapsulate

The CKAP HTTP transport maps the authenticated request context to keyserver operations and serializes only the operation-specific response fields.

Observed

messier-42/cabe-gocabecap/capsulator.go

Capsulator.Encapsulate and Capsulator.Decapsulate

The CABE client resolves key access through CKAP while retaining the complete CBES envelope and application payload locally.

Observed

messier-42/cabe-gointernal/cbescodec/codec.go

codec.encapsulateNonCaptive, codec.encapsulateCaptive, codec.decapsulateNonCaptive, codec.decapsulateCaptive

The codec constructs and parses CBES, performs payload encryption or decryption, and invokes assisted CEK wrapping only for captive leases.

Observed

messier-42/cabe-gocmd/cabetool/encap.go, cmd/cabetool/decap.go, cmd/cabetool/whoami.go

newEncapCommand, newDecapCommand, newWhoamiCommand

cabetool delegates envelope operations to cabecap and prints Khaled’s mapped principal through GetSelf.

Observed

messier-42/qhx-corepkg/kutest/khaled_test.go and pkg/kutest/cabetool_helpers_test.go

TestKhaledCKAP and cabetool workload helpers

Captive key custody

In non-captive mode, Khaled returns the lease key as part of the authorized key-access result, and the CABE SDK uses it in the client process. Captive mode changes that custody boundary: the lease key stays inside Khaled, while the client receives a lease-key authorization token, or LKAT, for an assisted operation under the authenticated lease context.

For assisted encapsulation, the CABE SDK generates a content-encryption key, or CEK. It sends the LKAT and CEK to AssistedEncapsulate. Khaled authenticates the token and wraps the CEK under the captive lease-key context. It returns a Wrapped CEK. The SDK still encrypts the application payload locally with the CEK and stores the Wrapped CEK in the protected envelope data.

For assisted decapsulation, the SDK extracts the Wrapped CEK and sends it with the LKAT to AssistedDecapsulate. Khaled authenticates the request and unwraps the CEK. The service returns the CEK to the SDK, which decrypts the payload locally. The distinction among the lease key, the LKAT, the CEK, and the Wrapped CEK is essential: each value crosses a different boundary and grants a different capability.

Step 7 of 7 · AssistedDecapsulate returns the CEK.

Figure 6. Khaled keeps the lease key as an internal input to both assisted operations. Assisted encapsulation returns a Wrapped CEK, while assisted decapsulation returns the recovered CEK to the CABE SDK.

Figure event transcript

The CABE SDK prepares the captive inputs. The client holds the LKAT, generates the CEK, and retains application payload cryptography locally.
LKAT and CEK enter AssistedEncapsulate. The assembled assisted input crosses into Khaled without application plaintext.
The lease key enters AssistedEncapsulate. The captive lease key is an internal input and is never returned or updated by the operation.
AssistedEncapsulate returns the Wrapped CEK. The protected CEK returns to the SDK for storage with the envelope; no lease-key object leaves Khaled.
LKAT and Wrapped CEK enter AssistedDecapsulate. The assembled reverse input crosses into Khaled without the encrypted payload.
The lease key enters AssistedDecapsulate. The captive lease key remains an internal input while the operation recovers the content key.
AssistedDecapsulate returns the CEK. The recovered content key returns to the CABE SDK for local payload decryption; the lease key remains in Khaled.

Captive operation keeps the lease key inside Khaled without moving application payload cryptography there. Khaled uses that key internally for both assisted operations: AssistedEncapsulate produces the Wrapped CEK, and AssistedDecapsulate produces the recovered CEK. Neither operation changes or returns the lease key.

Implementation evidence

Observed

messier-42/khaledpkg/plugin/clientauthn/tlsspiffe/tlsspiffe.go

Authenticator.Authenticate

Khaled verifies the presented X.509-SVID against its SPIFFE bundle source before producing a client identity.

Observed

messier-42/khaledpkg/plugin/claimsmapping/k8sattestation/k8sattestation.go

Mapper.Map and Mapper.fetchAndAttest

Khaled parses the Pod SPIFFE ID, GETs the current Pod, verifies UID and service account, and derives Kubernetes claims.

Observed

messier-42/khaledpkg/plugin/policyengine/cedar/cedar.go

Engine.DecideEncapsulate and Engine.DecideDecapsulate

The Cedar adapter evaluates Encapsulate or Decapsulate with the principal, claims, attribute set, and time context.

Observed

messier-42/khaledpkg/keyserver/ops.go

Server.Prograde and Server.Retrograde

A permitted non-captive Prograde returns one lease containing both an authenticated LeaseRef and the lease key; Retrograde authenticates the supplied LeaseRef before rederiving access information.

Observed

messier-42/khaledpkg/keyschedule/schedule.go

Schedule.NewLease and Schedule.ResolveLease

The key schedule derives a lease key from the authenticated lease tuple and CABE attribute set; it does not authenticate references itself.

Observed

messier-42/khaledpkg/refwrapper/refwrapper.go

Codec.WrapLeaseRef, Codec.UnwrapLeaseRef, Codec.WrapLKAT, Codec.UnwrapLKAT

The reference wrapper authenticates LeaseRefs and LKATs, binds LeaseRefs to the attribute-set representation, and rejects cross-kind tokens.

Observed

messier-42/khaledpkg/keyserver/ops.go

Server.AssistedEncapsulate and Server.AssistedDecapsulate

In captive mode the lease key stays in Khaled: AssistedEncapsulate returns WrappedCEK and AssistedDecapsulate returns CEK.

Observed

messier-42/khaledpkg/plugin/transport/http/ckap.go

handlePrograde, handleRetrograde, handleAssistedEncapsulate, handleAssistedDecapsulate

The CKAP HTTP transport maps the authenticated request context to keyserver operations and serializes only the operation-specific response fields.

Observed

messier-42/cabe-gocabecap/capsulator.go

Capsulator.Encapsulate and Capsulator.Decapsulate

The CABE client resolves key access through CKAP while retaining the complete CBES envelope and application payload locally.

Observed

messier-42/cabe-gointernal/cbescodec/codec.go

codec.encapsulateNonCaptive, codec.encapsulateCaptive, codec.decapsulateNonCaptive, codec.decapsulateCaptive

The codec constructs and parses CBES, performs payload encryption or decryption, and invokes assisted CEK wrapping only for captive leases.

Observed

messier-42/cabe-gocmd/cabetool/encap.go, cmd/cabetool/decap.go, cmd/cabetool/whoami.go

newEncapCommand, newDecapCommand, newWhoamiCommand

cabetool delegates envelope operations to cabecap and prints Khaled’s mapped principal through GetSelf.

Observed

messier-42/qhx-corepkg/kutest/khaled_test.go and pkg/kutest/cabetool_helpers_test.go

TestKhaledCKAP and cabetool workload helpers

`cabetool` as a CABE client

cabetool is a concrete CABE client used by the integration tests. Its Pod explicitly mounts the SPIFFE CSI volume, opens the selected agent.sock, and obtains its workload SVID. It then calls Khaled directly at the representative base URL https://khaled.qhx-system.svc:443/ckap/. The command does not pass through QHx Proxy and does not pass through the QHx Agent.

cabetoolThe CABE client process

agent.sockThe selected Workload API socket

X.509-SVIDThe workload credential

/ckap/Khaled’s CKAP interface

cabetool whoami calls the identity-mapping operation and shows the SPIFFE identity and Kubernetes claims Khaled associates with the caller. The command is useful for verifying that the CSI mount, Workload API, Khaled TLS authentication, SPIFFE parsing, and Pod lookup agree before an application attempts a CABE operation.

cabetool encap supplies attributes and plaintext to the CABE client library, obtains authorized key-access information from Khaled through Prograde, and emits a CBES object. cabetool decap parses that object, supplies the relevant metadata to Retrograde, and returns the decrypted content. Piping the two commands together tests the mounted identity, the CKAP service, the CABE SDK, and the complete CBES round trip while the application process retains the CBES object and its plaintext.

Implementation evidence

Observed

messier-42/khaledpkg/plugin/clientauthn/tlsspiffe/tlsspiffe.go

Authenticator.Authenticate

Khaled verifies the presented X.509-SVID against its SPIFFE bundle source before producing a client identity.

Observed

messier-42/khaledpkg/plugin/claimsmapping/k8sattestation/k8sattestation.go

Mapper.Map and Mapper.fetchAndAttest

Khaled parses the Pod SPIFFE ID, GETs the current Pod, verifies UID and service account, and derives Kubernetes claims.

Observed

messier-42/khaledpkg/plugin/policyengine/cedar/cedar.go

Engine.DecideEncapsulate and Engine.DecideDecapsulate

The Cedar adapter evaluates Encapsulate or Decapsulate with the principal, claims, attribute set, and time context.

Observed

messier-42/khaledpkg/keyserver/ops.go

Server.Prograde and Server.Retrograde

A permitted non-captive Prograde returns one lease containing both an authenticated LeaseRef and the lease key; Retrograde authenticates the supplied LeaseRef before rederiving access information.

Observed

messier-42/khaledpkg/keyschedule/schedule.go

Schedule.NewLease and Schedule.ResolveLease

The key schedule derives a lease key from the authenticated lease tuple and CABE attribute set; it does not authenticate references itself.

Observed

messier-42/khaledpkg/refwrapper/refwrapper.go

Codec.WrapLeaseRef, Codec.UnwrapLeaseRef, Codec.WrapLKAT, Codec.UnwrapLKAT

The reference wrapper authenticates LeaseRefs and LKATs, binds LeaseRefs to the attribute-set representation, and rejects cross-kind tokens.

Observed

messier-42/khaledpkg/keyserver/ops.go

Server.AssistedEncapsulate and Server.AssistedDecapsulate

In captive mode the lease key stays in Khaled: AssistedEncapsulate returns WrappedCEK and AssistedDecapsulate returns CEK.

Observed

messier-42/khaledpkg/plugin/transport/http/ckap.go

handlePrograde, handleRetrograde, handleAssistedEncapsulate, handleAssistedDecapsulate

The CKAP HTTP transport maps the authenticated request context to keyserver operations and serializes only the operation-specific response fields.

Observed

messier-42/cabe-gocabecap/capsulator.go

Capsulator.Encapsulate and Capsulator.Decapsulate

The CABE client resolves key access through CKAP while retaining the complete CBES envelope and application payload locally.

Observed

messier-42/cabe-gointernal/cbescodec/codec.go

codec.encapsulateNonCaptive, codec.encapsulateCaptive, codec.decapsulateNonCaptive, codec.decapsulateCaptive

The codec constructs and parses CBES, performs payload encryption or decryption, and invokes assisted CEK wrapping only for captive leases.

Observed

messier-42/cabe-gocmd/cabetool/encap.go, cmd/cabetool/decap.go, cmd/cabetool/whoami.go

newEncapCommand, newDecapCommand, newWhoamiCommand

cabetool delegates envelope operations to cabecap and prints Khaled’s mapped principal through GetSelf.

Observed

messier-42/qhx-corepkg/kutest/khaled_test.go and pkg/kutest/cabetool_helpers_test.go

TestKhaledCKAP and cabetool workload helpers

Proxy transport and notary evidence

QHx Proxy provides the workload security fabric’s service-mesh capability for authenticated application communications. It is deployed and configured explicitly for an application connection. Its configuration requires a SPIFFE Workload API socket, at least one listener, a local address, a mode, a protocol, and a target. The current admission webhook does not inject the proxy or its CSI volume into arbitrary workloads. A workload specification must request the socket and run the proxy configuration it intends to use.

The listener mode determines which side of the protected connection QHx Proxy serves:

A client-mode listener accepts local plaintext traffic and connects to a SPIFFE-authenticated remote target.
A server-mode listener accepts the authenticated connection and forwards plaintext to its local application.
A central-mode listener combines the remote-facing behavior for a topology in which a central proxy connects to protected services.

Source and target SPIFFE-ID patterns constrain the peers accepted by each configured listener.

HTTP provides the clearest representative sequence because its middleware can associate an application request and response. TCP and MQTT use the same explicit listener and SPIFFE transport boundary, but their protocol handling differs. TCP forwards streams. MQTT interprets sessions and packets, can buffer publishes, and can carry notary identifiers or evidence on QHx-specific topics.

The notary is optional and lives inside the proxy process. After the proxy verifies the upstream peer, it derives a WorkloadRef from that authenticated identity and passes the reference to the notary’s elaborator. The elaborator—not the identity token—issues GET Pod to the Kubernetes API, verifies the returned UID and service account, and returns trusted Pod metadata. The notary uses that metadata and the proxy’s SVID to create a workload statement; configured middleware may also log or sign a request receipt.

Step 13 of 13 · The proxy returns evidence identifiers.

Figure 7. The request and response cross the configured proxy connection in opposite directions. The optional notary resolves the verified upstream workload and records separate workload or request evidence.

Figure event transcript

Application A sends a request to Proxy A. The application uses the local listener configured for this connection.
Proxy A authenticates Proxy B with SPIFFE. The proxies establish the configured protected connection using their workload identities.
Proxy B forwards the request to Application B. The server-side proxy uses its configured plaintext target.
Application B returns the response. The application response returns to its local server-side proxy.
The response crosses the authenticated proxy connection. Proxy B returns the response over the verified transport to Proxy A.
Proxy A identifies the verified upstream peer. The client-side proxy retains the SPIFFE identity authenticated on the connection.
The verified peer becomes an elaborator input. The proxy derives a WorkloadRef from the authenticated upstream identity; the identity token does not call Kubernetes.
The elaborator issues GET Pod. The in-process elaborator—not the peer token—calls the Kubernetes API for the named Pod.
The Kubernetes API returns current Pod metadata. The elaborator verifies the Pod UID and service account before treating the metadata as trusted.
Verified Pod metadata enters the notary. The notary receives the elaborated workload information for evidence construction.
The notary creates a workload statement. The notary signs a statement about the resolved workload using the proxy’s SVID.
The notary may create a request receipt. Configured HTTP middleware and the selected level determine whether request evidence is logged or signed.
The proxy returns evidence identifiers. The response identifies separately retrievable workload, certificate, or receipt evidence.

QHx Proxy neither calls Khaled nor constructs or opens a CBES envelope. If the application sends a CBES envelope through a configured proxy connection, the proxy treats it as opaque application data. The notary’s evidence is a separate object, and HTTP request notarization occurs only when the corresponding middleware is configured.

/.qhx/workload/<id>/.qhx/certificate/<id>/.qhx/receipt/<id>

Implementation evidence

Observed

messier-42/qhx-corepkg/proxy/cmd/config.go

listenerConfig and listenerConfig.Validate

Each proxy listener declares a mode, protocol, address, target, and optional source and target SPIFFE-ID rules.

Observed

messier-42/qhx-corepkg/proxy/pkg/elaborator/elaborator.go

Elaborator.Elaborate

The elaborator accepts a WorkloadRef, GETs the Kubernetes Pod, and verifies the Pod UID and service account before returning trusted metadata.

Observed

messier-42/qhx-corepkg/proxy/pkg/notary/notary.go

Notary.NotarizeRequest

The optional notary calls the elaborator and creates a workload statement plus optional request receipt using the proxy’s SVID.

Observed

messier-42/qhx-corepkg/proxy/pkg/protocol/http/middleware/notaryquery/notaryquery.go

Middleware

The HTTP notary-query middleware serves workload, certificate, and receipt retrieval endpoints under /.qhx/.

Multiple QHx Authorities in one cluster

One QHx Manager operates one Kubernetes cluster. Within that cluster, it may reconcile several QHxAuthority resources. Each resource defines a QHx Authority with a separate SPIRE server, controller-manager, agent configuration, trust domain, trust root, registration set, and socket directory. Adding a QHx Authority creates another local identity domain; it does not create another Manager for the same cluster.

Multiple QHx Authorities allow workloads in the same Kubernetes cluster to use different trust domains and identity profiles. Each authority has its own SPIRE PKI, registrations, socket directory, and identity configuration. Where configured, authorities may use different signature algorithms—including a post-quantum signature profile—or different TPM attestation policies.

Authority selection does not choose the application protocol. HTTP, TCP, and MQTT remain application or QHx Proxy listener configuration.

The cluster still uses one shared CSI driver. When kubelet publishes a workload’s volume, the driver resolves the workload namespace and selects one authority-specific directory. Namespace A can mount socket A while Namespace B mounts socket B. A single CSI mount does not combine the two directories, and a workload does not receive identities from multiple authorities through that mount.

The Manager registers itself in each authority so it can hold the per-authority identities needed by federation services. It also creates local federation relationships among the authorities where required, while their trust domains remain separate. Trust distribution makes an identity from another domain verifiable; it does not merge the domains or erase the authorization boundary.

Figure 8. One QHx Manager operates both local QHx Authorities and their dedicated SPIRE installations. For each workload mount, the shared CSI driver exposes only the socket directory selected for that namespace.

Figure event transcript

The Manager operates QHx Authority A. The local Manager reconciles one complete SPIRE installation for the first QHx Authority.
The Manager also operates QHx Authority B. The same Manager reconciles the second QHx Authority’s SPIRE installation inside the same cluster.
QHx Authority A exposes its own socket directory. The first SPIRE agent socket remains associated with the first trust domain.
QHx Authority B exposes a different socket directory. The second SPIRE agent socket remains associated with the second trust domain.
Namespace A reaches the shared CSI driver. Kubelet publishes the workload’s explicit CSI volume using the Namespace A route.
The CSI driver selects socket A. The driver exposes only QHx Authority A’s socket directory through that mount.
Namespace B reaches the same CSI driver. The shared DaemonSet resolves the different namespace independently.
The CSI driver selects socket B. The second mount exposes only QHx Authority B’s socket directory.

The Manager owns both QHx Authority installations because both belong to its local cluster. The CSI driver exposes exactly one selected socket directory for each mount. The QHx Authority that issues a workload’s SVID therefore follows the resolved namespace route, while each SPIRE PKI remains an independent identity domain.

Implementation evidence

Observed

messier-42/qhx-corepkg/manager/pkg/api/v1/qhxauthority_types.go

QHxAuthoritySpec and QHxAuthorityStatus

Each QHxAuthority represents one SPIRE instance, PKI, trust domain, and allocated agent-metrics endpoint.

Observed

messier-42/qhx-corepkg/manager/pkg/spire/resources.go

ResourceConfig and BuildAgentDaemonSet

The Manager builds one socket directory and SPIRE resource set per authority while the cluster uses one shared CSI DaemonSet.

Needs confirmation

messier-42/qhx-coreconfig/default.nix

ss-khaled

The packaged deployment provides one Khaled service; the package does not establish the intended production tenancy model across several authorities.

Federation between clusters

QHx federation has two stages. Manager-to-Manager, or M2M, exchanges signed bootstrap and update state between peer QHx Managers. SPIRE Server-to-Manager, or S2M, remains local to a cluster: each SPIRE server retrieves accepted foreign trust bundles from its own Manager.

Kubernetes Cluster A and Kubernetes Cluster B each have their own QHx Manager. Each Manager reconciles only the QHx resources and QHx Authorities in its local cluster. They act as federation peers; neither Manager operates the other cluster’s SPIRE installations. Federation extends cross-domain trust by making partner workload identities verifiable across those independently managed clusters.

A local QHxForeignCluster describes the expected remote trust domain, optional endpoint hints, and the fingerprint that anchors bootstrap. Manager A sends GET bootstrap or GET updates?after=<sequence> toward Manager B on port 7500. Manager B returns a signed canonical-CBOR bootstrap package or signed transition entries. Manager A verifies the pinned fingerprint, signatures, remote trust domain, sequence, time, and transition continuity before it records accepted M2M state.

The QHxForeignCluster status holds the accepted M2M state. That state is normative for the local federation relationship. The reconciler derives the local ClusterFederatedTrustDomain objects and bundle cache from it. Derived SPIRE state does not flow backward and replace the accepted Manager-to-Manager record.

After the Manager accepts the M2M state, local S2M delivers the bundle. A local SPIRE server polls the per-authority S2M Service on 8443, which targets the local Manager’s listener on 8444, and requests /bundles/<foreign-trust-domain>. The Manager authenticates with its identity for the polling authority and serves the accepted bundle as a SPIRE-compatible JWKS document.

Step 11 of 11 · The local Manager serves the accepted bundle.

Figure 9. Peer QHx Managers exchange an M2M request and signed response. After Manager A accepts that state, its local SPIRE server retrieves the foreign bundle from Manager A through S2M. The bundle makes a foreign workload identity verifiable without granting access.

Figure event transcript

Manager A requests M2M state. The local Manager sends GET bootstrap or GET updates?after=<sequence> toward Manager B.
The remote Manager prepares an M2M artifact. Manager B serves a signed bootstrap package or transition update on its M2M interface.
Manager B returns signed M2M state. A signed canonical-CBOR bootstrap package or signed transition entries cross toward Manager A on port 7500.
The local Manager verifies the bootstrap anchor. Manager A checks the configured fingerprint and validates signatures and transition continuity.
The local Manager records accepted M2M state. The QHxForeignCluster status becomes the accepted record for this federation relationship.
The local Manager updates the federation object. A local ClusterFederatedTrustDomain is derived only after the M2M state has been accepted.
The federation object updates local SPIRE configuration. The authority-specific controller-manager applies the accepted relationship to the local SPIRE server.
The local SPIRE server accepts the polling configuration. The configured bundle endpoint remains local to Cluster A.
The local SPIRE server calls the local S2M service. SPIRE server A polls the S2M Service inside Cluster A.
S2M reaches the local Manager. The Service forwards the bundle request to Manager A on listener port 8444.
The local Manager serves the accepted bundle. Manager A returns the foreign trust bundle as SPIRE-compatible JWKS to its local SPIRE server.

M2M establishes the accepted federation state between the two QHx Managers. S2M stays inside each Kubernetes cluster, between a local SPIRE server and its local Manager; no remote SPIRE server sends a bundle directly to the local SPIRE server.

A foreign SVID becomes verifiable only after the local SPIRE server receives the accepted bundle through S2M. Verification does not authorize that workload to use an application, a proxy target, or a protected key-access interface. In coalition deployments, a verifiable partner identity receives no automatic application access, proxy permission, key-access permission, or releasability decision. QHx Proxy rules, Khaled’s Cedar policy, or the application must still enforce the decision at its own boundary.

Implementation evidence

Observed

messier-42/qhx-corepkg/manager/pkg/api/v1/qhxforeigncluster_types.go

QHxForeignClusterStatus.M2M

QHxForeignCluster status stores the accepted Manager-to-Manager state that is normative for local federation.

Observed

messier-42/qhx-corepkg/manager/pkg/controller/qhxforeigncluster_controller.go

QHxForeignClusterReconciler.Reconcile

The local Manager verifies bootstrap or update material, records accepted M2M state, and then reconciles derived local federation objects.

Observed

messier-42/qhx-corepkg/manager/pkg/spire/federation.go

BuildClusterFederatedTrustDomain and BuildS2MService

Accepted state is rendered as a local ClusterFederatedTrustDomain whose bundle endpoint points to the authority’s local S2M Service.

Observed

messier-42/qhx-corepkg/manager/pkg/m2m/server.go and pkg/manager/pkg/s2m/server.go

m2m.Server and s2m.Server

M2M serves peer Managers on port 7500; S2M serves accepted bundles from each local Manager to its local SPIRE servers.

Ports, sockets, and endpoints

QHx components use the following network ports, Unix sockets, and HTTP endpoints. The values below are taken from the current source and generated configuration.

The QHx Manager
Interface	Purpose
`9443`	Hosts the admission webhook.
Service `443 → 9443`	Exposes Kubernetes admission.
`7600`	Exposes Manager metrics.
`8081`	Exposes Manager health endpoints.
`8444`	Hosts the S2M listener.
Service `8443 → 8444`	Lets a local SPIRE server retrieve a bundle.
`7500`	Exposes the M2M federation endpoints.

SPIRE and the authority-specific Workload API
Interface	Purpose
Server API `8081`	Accepts agent connections and server API traffic in each authority’s SPIRE installation.
Bundle endpoint `8443`	Publishes that authority’s SPIRE federation bundle endpoint.
Server metrics `7600`	Exposes Prometheus metrics for the authority’s SPIRE server.
Server health `8080`	Exposes the SPIRE server live and ready checks.
Workload API `agent.sock`	Returns SVIDs and bundles to workloads through the selected authority’s Unix socket.
Socket base `/run/spire/sockets/<authority>/`	Separates the host-side socket directory for each authority.
Agent metrics: authority-specific allocated port	Exposes each host-networked agent’s Prometheus endpoint on the stable port allocated in QHxAuthority status.
Agent health `8080`	Exposes the SPIRE agent live and ready checks.
Controller-manager Service `443 → 9443`	Exposes the SPIRE controller-manager admission webhook.
Controller-manager metrics `8082`	Exposes controller-manager metrics.
Controller-manager health `8083`	Exposes controller-manager health checks.

Khaled and CKAP
Interface	Purpose
Service `443 → 8443`	Exposes CKAP over HTTPS.
`8081`	Exposes health and monitoring.
`POST /ckap/GetSelf`	Returns the identity and claims mapped for the caller.
`POST /ckap/Prograde`	Resolves key access for encapsulation.
`POST /ckap/Retrograde`	Resolves key access for decapsulation.
`POST /ckap/AssistedEncapsulate`	Wraps the CEK in captive mode.
`POST /ckap/AssistedDecapsulate`	Recovers the CEK in captive mode.
`GET /ckap/ARINToken`	Currently returns an unsupported-operation error.
`GET /ckap/ARIN`	Currently returns an unsupported-operation error.

QHx Proxy and the notary

The proxy’s application ports are defined by its listener configuration. Each listener supplies the address, mode, protocol, target URL, and identity rules for that connection. The optional HTTP notary-query middleware exposes the literal URL paths below through the configured HTTP listener.

GET /.qhx/workload/<id>GET /.qhx/certificate/<id>GET /.qhx/receipt/<id>

Federation

GET /.well-known/qhx/federationM2M/bootstrapGET /.well-known/qhx/federationM2M/bootstrap/<fingerprint>GET /.well-known/qhx/federationM2M/updates?after=<sequence>GET /bundles/<trust-domain>

The first three endpoints are served to peer Managers on the M2M interface. The bundle endpoint is served by the local Manager to a local SPIRE server through the S2M Service.

Implementation evidence

Observed

messier-42/qhx-coreconfig/default.nix

s-manager-webhook, d-manager, s-khaled, and ss-khaled

The packaged resources derive Manager webhook Service 443 → 9443, Manager metrics 7600, Manager health 8081, Khaled Service 443 → 8443, and Khaled monitoring 8081.

Observed

messier-42/qhx-corepkg/manager/pkg/spire/resources.go

BuildServerStatefulSet, BuildServerService, BuildBundleService, BuildServerMetricsService, BuildAgentMetricsService, BuildWebhookService, and controllerManagerConfig

The authority builders derive SPIRE server 8081, bundle 8443, server metrics 7600, server and agent health 8080, per-authority agent metrics, controller-manager Service 443 → 9443, metrics 8082, and health 8083.

Observed

messier-42/qhx-corepkg/manager/pkg/spire/federation.go

S2MServicePort, S2MListenerPort, and BuildS2MService

The per-authority local S2M Service exposes 8443 and targets the Manager listener on 8444.

Observed

messier-42/qhx-corepkg/manager/cmd/main.go and pkg/manager/pkg/m2m/server.go

m2mBindAddress and DefaultM2MListenPort

The Manager M2M listener defaults to port 7500.

Operational considerations

Some behaviors in the current source snapshot affect deployment or troubleshooting. The table records what the implementation does today, the operational effect, and what an operator should verify, configure, or expect.

Current behavior Operational effect What an operator should expect

When an explicit QHxPolicy reference cannot be resolved, the Manager sets Bound=False and omits the namespace from namespace-map.yaml.

CSI 52.6.5 treats the absent entry as a request to use default-authority, so the workload may still receive an SVID from the default authority.

Monitor the policy condition and verify the authority socket mounted into the workload when an explicit binding fails.

The routing controller accepts an authority name when the QHxAuthority object exists; it does not require Ready=True.

A newly scheduled Pod may select an authority before that authority’s SPIRE socket is usable.

Check the authority conditions and the selected agent socket before treating the namespace binding as ready for workloads.

The CSI driver selects an authority when kubelet publishes the volume.

A mounted Pod is expected to retain the selected socket after a policy change until the Pod is recreated or the volume is published again.

Recreate the Pod or republish its volume when a changed namespace policy must take effect for an existing workload.

The packaged Khaled configuration uses an allow-all Cedar policy.

A successful CABE request demonstrates the integration but does not establish production authorization boundaries.

Replace the packaged policy with rules appropriate to the deployment’s principals, claims, CABE attributes, and operating environment.

Khaled and the CABE SDK implement captive operations, but the current Cedar adapter does not set RequireCaptive.

Cedar-governed requests follow the non-captive result unless another supported mechanism selects captive behavior.

Verify the returned key-access mode before relying on Khaled to retain the lease key.

The ARIN endpoints return unsupported-operation errors.

Clients cannot rely on those optional interfaces in the current package.

Use the supported CKAP operations and handle an unsupported response if a client probes an ARIN endpoint.

The packaged topology exposes one shared Khaled service while a QHx Manager may operate several authorities.

The package does not create authority-scoped Khaled instances or add tenancy isolation automatically.

Verify that the shared service and its Cedar policy match the deployment’s trust-domain and tenancy requirements.

The HTTP notary flow runs through configured middleware.

Enabling the notary database does not automatically notarize every HTTP listener or request.

Enable the required notary middleware on each application connection that must produce workload statements or receipts.

The local notary stores evidence at a configured bbolt database path.

Evidence persists only for the storage and Pod lifecycle configured for that path.

Provision storage, retention, backup, and deletion behavior that matches the deployment’s evidence requirements.

Federation installs trust material that makes foreign SVIDs verifiable.

A verified foreign identity remains subject to authorization by QHx Proxy, Khaled, or the application.

Configure the required cross-cluster authorization rule at each service’s enforcement point.

M2M authenticates pinned fingerprints, signed artifacts, and transition continuity rather than using ordinary browser-oriented Web PKI.

The bootstrap fingerprint is a trust anchor, and recovery-grace behavior affects how state transitions are accepted.

Protect the bootstrap fingerprint and define how operators distribute, verify, and rotate it.

The current implementation identifies algorithms and bundle material but does not establish every desired post-quantum property for every interface.

A broad “post-quantum secure” claim would exceed the available implementation evidence.

Validate the required algorithms and adversary model separately for identity, CABE, proxy, and federation interfaces.

The complete sequence

Workload identity

1.A QHxPolicy object or the QHxCluster default selects the workload’s authority.

2.The QHx Manager publishes the namespace-routing state.

3.The CSI driver mounts the selected QHx Authority’s SPIRE agent socket.

4.SPIRE attests the workload and issues its SVID.

CABE data protection

When the application uses CABE:

1.The application presents its SVID to Khaled over CKAP.

2.Khaled resolves the current Pod, creates Kubernetes-derived claims, evaluates the Cedar policy, and returns authorized key-access information.

3.The CABE SDK constructs or opens the CBES envelope and performs the payload cryptography locally.

Authenticated application communications and cross-domain trust

QHx Proxy uses the workload identity for an explicitly configured SPIFFE-authenticated application connection.
The notary may record workload or request evidence inside that proxy process.
M2M distributes accepted federation state between peer Managers.
S2M supplies accepted trust bundles to each Manager’s local SPIRE servers.

Identity establishes which workload is calling. Khaled evaluates the Cedar policy to decide whether that workload may obtain key-access information. The CABE SDK uses the authorized result to create or open the protected object. Federation extends verifiability across trust domains without removing the authorization decision.

Deployment settings for these components are documented in the Helm reference and the federation overview. Policy and proxy configuration references are forthcoming.

How QHx ties identity, policy, and protected data together

QHx from the application’s point of view

Bootstrapping a QHx Authority

Authority readiness

From namespace policy to a workload SVID

Policy boundaries

Key access for encapsulation

Khaled and the CABE SDK

Khaled

The CABE SDK

Opening a CBES envelope

Captive key custody

cabetool as a CABE client

Proxy transport and notary evidence

Multiple QHx Authorities in one cluster

Federation between clusters

Ports, sockets, and endpoints

QHx Proxy and the notary

Federation

Operational considerations

The complete sequence

`cabetool` as a CABE client