Skip to content

feat(security): verify GridSite gateway identity during health evaluation #11

Description

@nerdalert

Summary

Make GridSite gateway health evidence identity-aware. A reachable TCP port is
not sufficient evidence that a remote endpoint is the expected Grid gateway.

Grid should perform a bounded TLS handshake, validate the presented identity,
and report precise failure and rotation state before an endpoint becomes
eligible for routing.

Motivation

Reachability, authentication, and authorization are different properties:

  • TCP reachability proves that something accepted a connection.
  • A TLS handshake proves possession of a private key.
  • Certificate validation proves that the peer chains to an accepted trust
    anchor and presents the expected identity.
  • Grid policy determines whether that authenticated identity is eligible.

Conflating these checks can publish an endpoint that is reachable but belongs
to the wrong site, uses an expired certificate, or presents an untrusted
identity.

Scope

Implement identity-verified GridSite gateway probing with:

  • TLS handshake and bounded connect/handshake timeouts;
  • configured SNI and hostname or URI identity verification;
  • certificate-chain and validity-period validation;
  • proof of private-key possession through the handshake;
  • canonical DER-based certificate or SPKI fingerprints where pinning is used;
  • a defined trust-source and trust-anchor lifecycle;
  • explicit probe results for unreachable, timeout, TLS failure, untrusted
    issuer, identity mismatch, expired/not-yet-valid certificate, pin mismatch,
    and success;
  • fail-closed routing eligibility;
  • bounded retry/backoff behavior;
  • certificate-rotation overlap and recovery semantics; and
  • status, Events, logs, and metrics that do not disclose certificate private
    material or create unbounded cardinality.

Public certificates and bounded trust metadata may be distributed through Grid
state when the trust model permits it. Private keys, API credentials, bearer
tokens, and complete Kubernetes Secrets must never be distributed through
SWIM or a routing overlay.

Rotation Requirements

  • Define how old and new certificate identities overlap during rotation.
  • Do not require all sites to switch at one instant.
  • Reject an unexpected third identity even during a rotation window.
  • Define behavior when a rotation is partially deployed or rolled back.
  • Ensure cached probe state expires and cannot outlive the accepted trust
    window.
  • Preserve routing through a still-valid identity when policy permits it.

Acceptance Criteria

  • A valid gateway certificate, chain, SNI, and expected identity produce a
    healthy result.
  • TCP-only listeners cannot become healthy.
  • Missing, wrong-CA, wrong-SNI, wrong-identity, expired, not-yet-valid, and
    pin-mismatch certificates fail closed with distinct bounded reasons.
  • Fingerprints are derived from canonical certificate material, not PEM
    formatting.
  • Successful probing proves private-key possession.
  • Rotation overlap, partial rollout, rollback, expiry, and recovery are
    runtime-tested.
  • Probe timeouts, concurrency, retries, memory, and retained state are
    bounded.
  • Multiple operator replicas and restarts converge on the same eligibility
    result.
  • No secret or private-key material appears in SWIM state, ConfigMaps,
    status, logs, metrics, or test evidence.
  • GridSite conditions clearly distinguish reachability from verified
    identity.

Non-Goals

  • Distributing private keys or complete Secrets between sites.
  • Treating a certificate fingerprint as the complete authorization policy.
  • Disabling normal X.509 validation in favor of an insecure probe.
  • Replacing provider-gateway request authorization or downstream mTLS policy.
  • Creating a Grid-specific certificate authority service.

Open-Source Requirements

Use standard TLS and X.509 behavior with portable Kubernetes configuration.
The design must work with common certificate issuers and secret-management
systems without requiring a proprietary PKI or distribution-specific
controller.

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request

Type

Projects

  • Status
    Next

Relationships

None yet

Development

No branches or pull requests

Issue actions