Skip to content

Policy management

The support reference describes the signed v0.5.5 native Linux release. Check the build-specific support reference before planning an upgrade. Legacy algorithm-preference objects are not executable TLS policy.

Exact TLS policy

CryptoPolicySpec remains schema v1. Cipher suites and key-exchange groups are separate fields. This example requires hybrid TLS 1.3 key establishment:

{
  "schemaVersion": 1,
  "minTlsVersion": "1.3",
  "maxTlsVersion": "1.3",
  "cipherSuites": ["TLS_AES_256_GCM_SHA384"],
  "keyExchangeGroups": ["X25519MLKEM768"],
  "clientAuth": "none",
  "requirePostQuantum": true
}

A policy with requirePostQuantum: true requires only the hybrid group and TLS 1.3. It does not silently negotiate a classical group. Client authentication required also needs a usable configured trust store on every target. This policy controls the gateway's TLS handshakes, not storage encryption, signatures, Messenger sessions, or all service-mesh adapters.

Draft, review, and apply

  1. Open Crypto Policies in Axis and choose a profile from an approved release catalog, or enter a custom schema-v1 specification.
  2. Select the environment and exact agents. Saving a versioned draft leaves active policy delivery unchanged.
  3. Preview the candidate, previous policy, target membership, and compatibility reasons. All targets need fresh matching capabilities; an unavailable target blocks the preview rather than disappearing from its scope.
  4. Review the fixed canary phases, observation thresholds, and rollback baseline, then explicitly apply the reviewed plan. Apply rechecks the draft revision, target membership, baseline, and capability fingerprint transactionally.
  5. Follow each phase's acknowledged version and fresh handshake observations. Zero traffic, missing acknowledgments, stale reports, and failed handshakes do not establish success.

The API sequence is versioned draft creation under /api/crypto/policy-drafts, preview under /api/rollouts/plan, and explicit /api/rollouts/apply for the returned plan ID. Use the authenticated Axis workflow and its current request contracts. Older direct policy-deploy routes are unavailable; this guide does not claim an unimplemented SDK or CLI create/apply method.

Rollout receipt verification

The authenticated, tenant-scoped Axis receipt API reports signatureValid for HMAC-SHA256 receipts. Verification uses Axis's shared secret; it is not a public-key signature for independent offline verification. A false or null result does not establish verified receipt integrity. Retain the receipt ID and API result alongside the acknowledged policy version and observed TLS results.

Configuration changes and recovery

A policy switch prepares a complete immutable TLS configuration and affects new handshakes. Connections already established retain their configuration. An implementation missing from the installed build needs a new binary release; policy changes do not download native plugins.

A canary changes only its frozen cohort. Completion records each cohort member's stable policy; other environments and later arrivals do not inherit the candidate. Promotion creates a destination review from that environment's current baseline and checks that the successful parent cohort still runs its promoted version.

Rollback first restores the previous desired policy and reports rolling_back. It becomes rolled_back only after every affected agent acknowledges restoration. Restoring an inactive baseline removes that policy through an acknowledged rollback delivery. Missing acknowledgments remain pending. A newer deployment cannot be overwritten by an older rollback.

For a binary downgrade, verify the signed binary/catalog pair and compatibility with both current and saved rollback policies. Restore a compatible baseline before downgrading to a catalog-unaware agent. Do not downgrade the controller below the capability-reader version while reporting agents depend on it.