Deployment & operations

Install QHx Core alongside the workloads.

The documented package installs on Kubernetes using the QHx CLI or Helm. The cluster may run on premises, in cloud infrastructure or on deployed compute. The managed package supplies the identity, configuration and communication services; operators set their authorities, registrations and service rules.

Non-Kubernetes integration needs a defined credential source, compatible interfaces and an operating model for these services. The architecture’s portability does not imply an equivalent ready-made package for every device or operating system.

The component responsibilities distinguish the Manager, PKI services, node agents and proxies. Start an evaluation with permitted and refused connections, then test renewal, service replacement and recovery in the intended environment.

Keep issuance and recovery available.

QHx issues short-lived workload credentials and rotates them before expiry when the issuance path is available. Applications using QHx Proxy do not need to manage that rotation themselves. Successful renewal still depends on the required PKI services, current registration and policy state, and acceptable attestation evidence. An unavailable issuer cannot provide a replacement credential.

CA rotation needs overlapping trust and timely distribution of updated bundles. Keep the old and new trust material available for the planned transition, verify peer acceptance, and account for systems that may be disconnected during the change. A cryptographic-profile change also requires compatible peers and issuance configuration; see identity and cryptography.

Maintain protected recovery copies of CA key material, or a tested key-recovery mechanism, together with trust material, registrations, policy, and deployment configuration. Establish who can restore them and test the sequence before an outage. Recovery must preserve the intended trust relationships rather than silently recreating a different authority.

Track credential expiry, rotation failures, issuance latency, and attestation failures. These signals help distinguish an unavailable dependency from a workload that no longer satisfies policy. Capacity and datastore choices should follow the deployment's measured requirements.

Verify changes before applying them.

QHx signed resources package one or more Kubernetes resources with a signature and version. An approved signing authority can distribute policies, deployments, or services; QHx Manager verifies the bundle before applying it. Critical resources can be protected from ordinary modification and updated through the configured signed path.

Version checks support rollback resistance by rejecting older signed states. That protection depends on preserving trusted version state. Restoring an old snapshot, losing that state, or allowing an attacker to replace it can change which versions the system accepts. Include version-state recovery in the same operational plan as resource recovery.

A valid signature establishes that the covered bundle was signed by an accepted authority and has not been altered. It does not establish that the change is harmless or operationally correct. Signing authority, review, and deployment validation remain separate responsibilities.

Bundles can be carried across an offline or manually mediated transport and verified at the destination. The destination still needs the approved trust material and a working verification path. This mechanism supports controlled field updates without requiring continuous access to the original distributor.

Test the exchange with the remote link disconnected.

In this test, disconnect the link to the remote operating site while keeping the local network available. Running an established exchange is a different question from starting the site cold, issuing an identity or retrieving a new object key.

Before disconnection, inventory credential lifetimes, cached trust bundles, local issuers, policy state, required services, and storage. Decide whether renewal remains possible locally and how long the intended communication paths can operate without fresh external trust or policy information. Rehearse the expected outage duration.

During disconnection, existing credentials remain bounded by their validity and acceptance policy. Cached trust can become stale; signatures cannot deliver a revocation or policy change that has not reached the system. Local dependencies, clocks, storage, and application transport still determine whether useful work can continue. QHx does not provide indefinite credential renewal or a general-purpose delay-tolerant routing service.

The documented MQTT buffer queues outgoing publishes in memory and retries them. Process restart can lose that queue; it is not durable store-and-forward. Evaluate persistence, acknowledgments and duplicate handling at the application and transport boundaries that actually implement them.

Retain selected request evidence and signed bundles with the material needed for later verification. Where data must remain protected after transport, CABE object protection is a separate layer with its own key-access requirements.

After reconnection, refresh trust and policy, reconcile accepted resource versions, and review evidence gaps or failed renewals. Test recovery of communication as well as restoration of services. The security model sets out the limits that remain when trust information is unavailable or stale.