Satellite PKI Trust Chain

Satellite PKI Trust & Revocation Policy

Trust Hierarchy

CloudHSM Root CA (20-year, offline, FIPS 140-2 Level 3)
  │  Stored: AWS CloudHSM backup in S3 (cluster-ew6yff4wjkx)
  │  Access: Ceremony-only (2+ key custodians, air-gapped laptop)
  │  NEVER woken for satellite ops — only for hub intermediate renewal
  │
  └─ Hub Intermediate CA (10-year, OpenBao, pathlen:2)
       │  Stored: OpenBao on hub cluster (auto-unsealed via Shamir cronjob)
       │  Scope: *.kuiperdesk.ai, *.arivaran.ai
       │  Issuer: openbao-pki ClusterIssuer (cert-manager)
       │  ISSUES satellite intermediates — no CloudHSM involvement
       │
       ├─ Hub Service Certs (90-day, auto-renew)
       │    aaHashSvc, aaTwinSvc, aaEnrollSvc, aaDash, Keycloak, etc.
       │
       └─ Satellite Intermediate CA (5-year or contract+3mo, pathlen:1)
            │  ← ONE PER SATELLITE, issued by Hub Intermediate (NOT CloudHSM)
            │  Stored: Satellite's step-ca (or OpenBao / K8s Secret)
            │  Scope: Name-constrained to:
            │         - *.satellite-<id>.kuiperdesk.ai  (default subdomain)
            │         - *.<custom-domain>               (customer domain, if set)
            │  Issued: During satellite bootstrap (hub-registration-job)
            │  pathlen:1 allows step-ca to act as sub-CA for service certs
            │
            │  IMPORTANT: Name constraints are set HERE (per-satellite), NOT on
            │  the root or hub intermediate. Root and hub intermediate have NO
            │  name constraints — this allows satellites to issue certs for any
            │  customer domain without re-issuing the root CA.
            │
            ├─ Satellite Service Certs (90-day, auto-renew via step-ca)
            │    Local aaHashSvc, aaTwinSvc, aaEnrollSvc, SeaweedFS, etc.
            │
            ├─ Agent mTLS Certs (1-year, renewable via step-ca)
            │    Endpoint agents enrolled to this satellite
            │    TPM-bound private key (non-exportable)
            │
            ├─ Keycloak Signing Keys (OIDC/SAML)
            │    Tier A: own Keycloak instance on satellite
            │
            └─ Internal S3 TLS (90-day, auto-renew via step-ca)
                 SeaweedFS/CubeFS inter-node communication

CloudHSM Wake Schedule

Name Constraints Strategy

CloudHSM Root CA              → NO name constraints (trust anchor, max flexibility)
Hub Intermediate CA           → NO name constraints (must issue for any tenant domain)
Satellite Intermediate CA     → NAME-CONSTRAINED per tenant:
                                 permitted: *.satellite-<id>.kuiperdesk.ai
                                 permitted: *.<customer-domain>  (if custom domain set)

Why constraints only at satellite level:

• Root/hub with *.kuiperdesk.ai constraint would block custom domains entirely
• Adding customer domains to root would require CloudHSM ceremony per customer
• Per-satellite constraints provide the same security (each satellite can only issue for its own domains) without limiting the root
• If a satellite is compromised, the name constraint limits what certs the attacker can forge

Custom domain flow:

1. Tenant sets custom_domain: backup.megacorp.com in dashboard
2. Hub issues satellite intermediate with permitted_dns: [*.satellite-xxx.kuiperdesk.ai, *.megacorp.com]
3. Satellite's step-ca can now issue certs for api.backup.megacorp.com, backup.megacorp.com, etc.
4. Agent's ca-bundle.pem contains root + hub intermediate + satellite intermediate → full chain
5. Browsers trust the chain after root is installed to trust stores (CATrust.cpp)

If root was already issued WITH name constraints (from the CloudHSM ceremony):

• Check: openssl x509 -in root-ca.crt -text | grep -A5 "Name Constraints"
• If constrained to *.kuiperdesk.ai: custom domains require a separate trust path
  • Option: satellite generates its own self-signed root for custom domain → included in ca-bundle.pem
  • Both roots in the bundle → agent/browser trusts both chains
• If no constraints: proceed as designed above

Satellite CA Issuance (Bootstrap)

During satellite provisioning, the hub-registration-job in the Helm chart:

1. Generates an ECDSA P-384 keypair on the satellite
2. Creates a CSR with name constraints:
   • Permitted DNS: *.satellite-<uuid>.kuiperdesk.ai, *.<custom-domain> (if set)
   • pathlen: 0 (cannot issue further intermediates)
3. Sends CSR to hub's OpenBao PKI endpoint (authenticated via bootstrap JWT)
4. Hub OpenBao signs and returns the intermediate certificate
5. Satellite stores the signed cert + private key in its local OpenBao (or K8s Secret)
6. Satellite's cert-manager is configured with this intermediate as a ClusterIssuer
7. All satellite service certs are issued by this intermediate

POST https://api.kuiperdesk.arivaran.ai/v1/pki/satellite/sign-intermediate
Authorization: Bearer <bootstrap-jwt>
{
  "csr": "<PEM-encoded CSR>",
  "satellite_id": "uuid",
  "custom_domain": "sat.customer.com",  // optional
  "ttl": "43800h"  // 5 years
}

Response:
{
  "certificate": "<PEM-encoded signed intermediate>",
  "ca_chain": ["<hub-intermediate>", "<root-ca>"],
  "serial_number": "hex",
  "expiry": "2031-03-22T00:00:00Z"
}

Revocation

Mechanisms

Revocation Procedure

Standard Revocation (contract termination, non-renewal)

# 1. Revoke satellite intermediate in OpenBao
vault write pki_int/revoke serial_number=<satellite-cert-serial>

# 2. Publish updated CRL
vault write pki_int/crl/rotate

# 3. Remove satellite from hub registry
grpcurl hub:50052 TwinService/DeregisterSatellite -d '{"satellite_id":"uuid"}'

# 4. Drop the satellite's live satgw tunnel session (the revoked cert above
#    blocks reconnection via OCSP/CRL). Terminate its active SatelliteConnect
#    stream via the aaSatGwSvc admin interface for <satellite-id>.

# 5. Notify tenant (email + dashboard banner)

Emergency Revocation (security breach, hostile actor)

# 1. IMMEDIATE: Add to hub blocklist (takes effect in seconds)
kubectl exec -n kd-services aahashsvc-xxx -- \
  curl -X POST http://localhost:9090/admin/blocklist \
  -d '{"satellite_id":"uuid","reason":"security_breach"}'

# 2. Drop the satellite's live satgw tunnel session (cert revocation in step 3
#    blocks reconnection) — terminate its active SatelliteConnect stream via
#    the aaSatGwSvc admin interface (kills network in seconds)

# 3. Revoke certificate (standard CRL/OCSP flow)
vault write pki_int/revoke serial_number=<serial>
vault write pki_int/crl/rotate

# 4. Disable Keycloak realm/org (prevents any SSO)
curl -X PUT https://id.app.arivaran.ai/admin/realms/<realm> \
  -H "Authorization: Bearer $KC_TOKEN" \
  -d '{"enabled": false}'

# 5. Audit log entry (immutable)
# 6. Security team notification

Revocation Scenarios

Effects of Revocation

What stops working:

• Agent backups (mTLS certs rejected by satellite services)
• Agent command channel (gRPC connection fails TLS handshake)
• Dashboard file browsing (satellite API unreachable from hub)
• New agent enrollments (aaEnrollSvc certs invalid)
• Hub ↔ satellite metadata sync (overlay disconnected)
• All satellite service-to-service communication (certs issued by revoked CA)

What continues working:

• Data at rest on satellite hardware (encrypted, key in local OpenBao/TPM)
• Existing backups in satellite S3 (files on disk, not deleted)
• Hub's copy of tenant metadata (endpoints, snapshots, audit log)
• Other satellites for the same tenant (each has independent CA)

What we explicitly do NOT do:

• Delete customer data (their hardware, their data)
• Brick the machine (only KuiperDesk services stop)
• Expose the revocation reason publicly (only in audit log)
• Revoke without documented justification (audit trail required)

Certificate Monitoring

Hub monitors all satellite intermediate CAs:

Compliance Mapping

Revision History