Security¶

This document summarizes the security posture and configuration of Pleiades GSLB.

Principles - Secure by default: HTTPS health checks verify TLS certificates unless explicitly disabled. - Least privilege: NATS accounts/creds should grant only the subjects required by a cluster. - Defense in depth: Git commits must be signed; runtime communications use mTLS.

Health check TLS - health.http.tls: true enables HTTPS checks. - health.http.insecureSkipVerify controls certificate verification (default false).

GitOps signing (GPG) - gitops.requireSignature: true enforces that HEAD is GPG-signed. - gitops.allowedSigners (optional) restricts signers to a fingerprint allowlist. - Trust store: rely on host GPG trustdb (documented by Git) and import your org keys.

NATS mTLS and Auth - Use server-side TLS with a trusted CA; clients should provide a certificate or JWT creds. - Options: - mTLS: state.nats.tls.caFile, certFile, keyFile. - NATS JWT creds: state.nats.auth.credsFile. - User/password or NKey are also supported. - Scope accounts/permissions to gslb.<cluster>.* subjects only.

DNSSEC (online signing) - Algorithm 13 (ECDSA P-256 / ECDSAP256SHA256). KSK signs the DNSKEY RRset; ZSK signs all other RRsets. - Keys are loaded from PEM files or environment variables at startup. Vault/NATS KV backends are planned.

Key generation (openssl):

# KSK
openssl ecparam -name prime256v1 -genkey -noout | \
  openssl pkcs8 -topk8 -nocrypt -out /etc/gslb/ksk.pem

# ZSK
openssl ecparam -name prime256v1 -genkey -noout | \
  openssl pkcs8 -topk8 -nocrypt -out /etc/gslb/zsk.pem

chmod 640 /etc/gslb/ksk.pem /etc/gslb/zsk.pem
chown root:gslbd /etc/gslb/ksk.pem /etc/gslb/zsk.pem

DS record export (submit to registrar after key rollover):

gslbctl dnssec ds --zone example.com. --ksk-file /etc/gslb/ksk.pem

Key rotation: 1. Generate new ZSK; update config to point at new file. 2. Restart gslbd — new signatures use new ZSK immediately. 3. For KSK rotation, generate new KSK, export new DS record, submit to registrar, wait for TTL expiry, then restart. 4. Monitor gslbd_dnssec_key_days_remaining and alert before expiry (see docs/Metrics.md).

Configuration:

dnssec:
  enabled: true
  zone: "example.com."
  ksk:
    pemFile: "/etc/gslb/ksk.pem"
    expiryDate: "2027-01-01"   # drives gslbd_dnssec_key_days_remaining gauge
  zsk:
    pemFile: "/etc/gslb/zsk.pem"
    expiryDate: "2026-07-01"
  signatureValidityDays: 7

Alternatively load keys from environment variables (useful for containers/secrets managers):

dnssec:
  enabled: true
  zone: "example.com."
  ksk:
    envVar: "GSLB_KSK_PEM"
  zsk:
    envVar: "GSLB_ZSK_PEM"

NSEC3 White Lies: denial-of-existence records are generated on-the-fly per RFC 5155 §7.1. No static NSEC3 chain is maintained — suitable for dynamic GSLB zones.

Secrets management - Store SSH keys, TLS keys, and creds in secure paths with restrictive permissions. - Consider using a secret manager and mounting files into the container/host.

Ports and exposure - DNS: UDP (and optionally TCP) on configured port (5353 by default; 53 in production). Place behind a firewall. - Metrics: HTTP on configured port; expose internally only. - NATS: as deployed by your ops team; ensure inter-region links are encrypted.

Operational guidance

• Rotate GPG keys and NATS creds regularly; provide roll-forward plans.
• Enable logging for signature verification failures and rejected reconciles.
• Audit Git history; enforce branch protection and signed pushes.