Namespace Policy

Overview

The QHxPolicy CRD enables namespace-level configuration of cryptographic algorithms for SVID signing and key exchange. This allows different namespaces to use different post-quantum algorithms or traditional algorithms based on security requirements.

Use cases:

• Testing post-quantum algorithms in specific namespaces before wider deployment
• Meeting different security requirements across workload types
• Gradual migration from traditional to post-quantum cryptography

QHxPolicy CRD

API Version: qhx.dev/v1

Kind: QHxPolicy

Scope: Namespace

Short Name: qhxp

Specification

apiVersion: qhx.dev/v1
kind: QHxPolicy
metadata:
  name: qhx-policy
  namespace: production
spec:
  signatureAlgorithm: mldsa65
  kemAlgorithm: p384-mlkem1024
  tpm:
    enable: false
    trustedEKs:
      - |
        -----BEGIN CERTIFICATE-----
        ...
        -----END CERTIFICATE-----
    pcrs:
      "0":
        - cfdff6cf749bdef553e754c04001e92efff6cc9fa05a639e5a14ce28c9738e2b
        - 9db76a831f70243c8d606018163b25b35a102685e84f7383ca919a7995dadb73

Only one QHxPolicy can exist per namespace.

Fields

signatureAlgorithm

Type: String

Default: inherit

Digital signature algorithm used for X.509-SVID certificates issued to workloads in this namespace.

Valid values:

• inherit - Use algorithm from QHxClusterPolicy or system default (default)
• mldsa44 - ML-DSA-44 (FIPS 204, post-quantum, security level 2)
• mldsa65 - ML-DSA-65 (FIPS 204, post-quantum, security level 3)
• mldsa87 - ML-DSA-87 (FIPS 204, post-quantum, security level 5)
• dilithium3 - Legacy Dilithium Round 3 (deprecated, use mldsa65)
• ec-p256 - ECDSA with NIST P-256 curve (traditional)†
• ec-p384 - ECDSA with NIST P-384 curve (traditional)†
• rsa-2048 - RSA 2048-bit (traditional)†
• rsa-4096 - RSA 4096-bit (traditional)†

† Non-quantum-safe conventional algorithms supported for compatibility.

Example:

spec:
  signatureAlgorithm: mldsa65

Workloads in this namespace receive SVIDs signed with ML-DSA-65.

Note: dilithium3 is a legacy algorithm name from pre-FIPS standardization. Use mldsa65 for equivalent security level.

kemAlgorithm

Type: String

Default: inherit

Key Encapsulation Mechanism used for TLS connections established by QHx Proxy in this namespace.

Valid values:

• inherit - Use algorithm from QHxClusterPolicy or system default
• ecdhe-p256 - ECDHE with NIST P-256 (traditional)
• ecdhe-p384 - ECDHE with NIST P-384 (traditional)
• p256-mlkem768 - Hybrid: P-256 + ML-KEM-768 (FIPS 203)
• p384-mlkem1024 - Hybrid: P-384 + ML-KEM-1024 (FIPS 203)
• mlkem768 - Pure post-quantum: ML-KEM-768
• mlkem1024 - Pure post-quantum: ML-KEM-1024

Example:

spec:
  kemAlgorithm: p384-mlkem1024

QHx Proxy connections in this namespace use hybrid P-384 + ML-KEM-1024 key exchange.

tpm

This object defines TPM/PCR-based attestation settings used as the namespace-level attestation policy. Settings here override cluster-level policy. TPM-based attestation is disabled by default at cluster level.

Fields:

• enable (boolean): Enable TPM-based node attestation. Defaults to inheriting from cluster policy (or false).
• trustedEKs (array of strings): Array of PEM-encoded trusted TPM EK root certificates. These are a TPM vendor’s TPM endorsement key hierarchy root CA certificates.
• pcrs: One or more allowed PCR values (as an array of hex strings) for each given PCR.

Example:

spec:
  tpm:
    enable: true
    trustedEKs:
      - |
        -----BEGIN CERTIFICATE-----
        ...
        -----END CERTIFICATE-----
    pcrs:
      "0":
        - cfdff6cf749bdef553e754c04001e92efff6cc9fa05a639e5a14ce28c9738e2b
        - 9db76a831f70243c8d606018163b25b35a102685e84f7383ca919a7995dadb73

Algorithm Selection Guide

Security Levels

ML-DSA (Digital Signatures):

• ML-DSA-44: Security level 2 (comparable to AES-128)
• ML-DSA-65: Security level 3 (comparable to AES-192)
• ML-DSA-87: Security level 5 (comparable to AES-256)

ML-KEM (Key Encapsulation):

• ML-KEM-768: Security level 3 (comparable to AES-192)
• ML-KEM-1024: Security level 5 (comparable to AES-256)

Recommendations

High-security environments (classified data):

spec:
  signatureAlgorithm: mldsa87
  kemAlgorithm: p384-mlkem1024

Standard production environments:

spec:
  signatureAlgorithm: mldsa65
  kemAlgorithm: p384-mlkem1024

Testing/development:

spec:
  signatureAlgorithm: ec-p256
  kemAlgorithm: ecdhe-p256

Gradual migration (hybrid):

spec:
  signatureAlgorithm: ec-p384
  kemAlgorithm: p384-mlkem1024  # Start with hybrid KEM

Traditional vs Post-Quantum

Traditional algorithms (ECDSA, ECDHE):

• Proven security track record
• Smaller key and signature sizes
• Better performance
• Vulnerable to quantum computers

Post-quantum algorithms (ML-DSA, ML-KEM):

• Quantum-resistant security
• Larger key and signature sizes
• Higher computational overhead
• Future-proof against quantum threats

Hybrid algorithms:

• Security of both traditional and post-quantum
• Recommended for production deployments
• Larger overhead than either alone
• Quantum-resistant while maintaining classical security

Inheritance

If signatureAlgorithm or kemAlgorithm is unset or set to inherit, the value is inherited from QHxClusterPolicy:

# QHxClusterPolicy (cluster-wide default)
apiVersion: qhx.dev/v1
kind: QHxClusterPolicy
metadata:
  name: qhx-cluster-policy
spec:
  defaultSignatureAlgorithm: mldsa65
  defaultKemAlgorithm: p384-mlkem1024

---
# QHxPolicy (namespace-specific, inherits from cluster)
apiVersion: qhx.dev/v1
kind: QHxPolicy
metadata:
  name: qhx-policy
  namespace: production
spec:
  signatureAlgorithm: inherit  # Uses mldsa65 from cluster policy
  kemAlgorithm: inherit         # Uses p384-mlkem1024 from cluster policy

If QHxClusterPolicy doesn’t specify defaults, system defaults are used (currently ecdsa-p256 and ecdhe-p256).

Implementation Details

Multiple PKI Server Instances

QHx Manager dynamically creates PKI Server instances based on unique algorithm configurations.

Example:

Three namespaces with policies:

# Namespace A
signatureAlgorithm: ecdsa-p256

# Namespace B
signatureAlgorithm: mldsa65

# Namespace C
signatureAlgorithm: mldsa65

Result: Two PKI Server instances created:

1. PKI Server with ECDSA P-256 CA (serves namespace A)
2. PKI Server with ML-DSA-65 CA (serves namespaces B and C)

Agent Socket Routing

Each unique configuration requires a separate agent on every node.

Example:

If namespaces require both ECDSA P-256 and ML-DSA-65:

• Two agent DaemonSets are created
• Every node runs two agents
• SPIFFE CSI driver routes pods to correct agent based on namespace policy

Pod scheduling:

When a pod is scheduled:

1. SPIFFE CSI driver reads QHxPolicy for pod’s namespace
2. CSI driver determines which agent socket to mount
3. Pod receives correct agent socket without manual configuration

This happens transparently - no changes to pod specifications required.

Examples

Post-Quantum Namespace

Use pure post-quantum algorithms:

apiVersion: qhx.dev/v1
kind: QHxPolicy
metadata:
  name: qhx-policy
  namespace: classified
spec:
  signatureAlgorithm: mldsa87
  kemAlgorithm: mlkem1024

Mixed Environment

Production uses post-quantum, development uses traditional:

# Production namespace
apiVersion: qhx.dev/v1
kind: QHxPolicy
metadata:
  name: qhx-policy
  namespace: production
spec:
  signatureAlgorithm: mldsa65
  kemAlgorithm: p384-mlkem1024

---
# Development namespace
apiVersion: qhx.dev/v1
kind: QHxPolicy
metadata:
  name: qhx-policy
  namespace: development
spec:
  signatureAlgorithm: ec-p256
  kemAlgorithm: ecdhe-p256

Inherit from Cluster Default

Namespace uses cluster-wide defaults:

apiVersion: qhx.dev/v1
kind: QHxPolicy
metadata:
  name: qhx-policy
  namespace: staging
# spec is empty or omitted - inherits from QHxClusterPolicy

Or explicitly:

spec:
  signatureAlgorithm: inherit
  kemAlgorithm: inherit

Operations

Creating a Policy

kubectl apply -f - <<EOF
apiVersion: qhx.dev/v1
kind: QHxPolicy
metadata:
  name: qhx-policy
  namespace: production
spec:
  signatureAlgorithm: mldsa65
  kemAlgorithm: p384-mlkem1024
EOF

Viewing Current Policy

kubectl get qhxpolicy -n production
kubectl describe qhxpolicy qhx-policy -n production

Updating Policy

Edit the QHxPolicy:

kubectl edit qhxpolicy qhx-policy -n production

Note: Existing workloads must be restarted to receive new SVIDs with updated algorithm:

kubectl rollout restart deployment -n production

Deleting Policy

kubectl delete qhxpolicy qhx-policy -n production

After deletion, namespace inherits from QHxClusterPolicy.

Checking Effective Algorithm

Verify which algorithm a workload is using:

# Get SVID from workload
kubectl exec <pod-name> -n production -- \
  qhx agent api show-svid --socket-path /run/qhx/agent.sock

# Inspect certificate signature algorithm
kubectl exec <pod-name> -n production -- \
  openssl x509 -in /tmp/svid.pem -text -noout | grep "Signature Algorithm"

Troubleshooting

Policy Not Applied

Check if QHxPolicy exists:

kubectl get qhxpolicy -n <namespace>

If missing, create the policy or confirm namespace should inherit from cluster.

Wrong Algorithm in Use

Verify QHxPolicy configuration:

kubectl get qhxpolicy qhx-policy -n <namespace> -o yaml

Check if algorithm is set to inherit and verify QHxClusterPolicy:

kubectl get qhxclusterpolicy qhx-cluster-policy -o yaml

Restart workloads to receive new SVIDs:

kubectl rollout restart deployment -n <namespace>

Agent Socket Not Found

Check if agent for the configured algorithm is running:

# List all QHx agents
kubectl get pods -n qhx-system -l app=qhx-agent

# Check agent logs
kubectl logs -n qhx-system <agent-pod>

If agent is missing, QHx Manager should create it automatically. Check qhx-manager logs:

kubectl logs -n qhx-system -l app=qhx-manager | grep "agent-creation"

Performance Issues

Post-quantum algorithms have higher overhead:

Signature size comparison:

• ECDSA P-256: ~64 bytes
• ML-DSA-44: ~2,420 bytes
• ML-DSA-65: ~3,293 bytes
• ML-DSA-87: ~4,627 bytes

Impact:

• Larger SVID certificates
• Higher CPU usage for signature verification
• Increased network traffic for SVID fetches

Mitigation:

• Use ML-DSA-44 for lower-security workloads
• Cache SVIDs aggressively (QHx does this by default)
• Use hybrid algorithms for better performance vs pure post-quantum

Security Considerations

Algorithm Migration

Changing algorithms requires workload restart to receive new SVIDs. During migration:

• Both old and new algorithm SVIDs may exist briefly
• Trust bundles must include both old and new CAs
• Plan migration during maintenance windows

Cross-Namespace Communication

Workloads in different namespaces with different signature algorithms can communicate:

• Trust bundles include all CA certificates cluster-wide
• QHx Proxy validates signatures regardless of algorithm
• Post-quantum workload can verify traditional signature and vice versa

Downgrade Attacks

Prevent algorithm downgrade attacks:

• Use signed resources to control QHxPolicy changes
• Seal QHxPolicy in high-security namespaces
• Monitor for unauthorized policy changes

Performance Characteristics

Signature Verification Time

Approximate timings on modern CPU:

• ECDSA P-256: ~0.1ms
• ML-DSA-44: ~0.2ms
• ML-DSA-65: ~0.3ms
• ML-DSA-87: ~0.4ms

Key Exchange Time

Approximate timings:

• ECDHE P-256: ~0.5ms
• Hybrid P-256 + ML-KEM-768: ~0.8ms
• Hybrid P-384 + ML-KEM-1024: ~1.0ms
• Pure ML-KEM-1024: ~0.6ms

Certificate Size

Larger certificates impact:

• SVID fetch time over network
• Storage requirements for certificate caches
• Memory usage for trust bundles

Recommendation: Use ML-DSA-65 for most workloads (good balance of security and performance).

Related Documentation

• QHx Architecture
• Cluster Policy Reference