feat(ha): harden gateway peer transport and expand failover conformance
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 35/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- helm, kubernetes, rust
- Área
- documentation, infrastructure, security, testing
Línea de trabajo
Start by reviewing PR #1868 and its three linked discussions, then trace the HA end-to-end coverage and Helm-generated and custom TLS configuration described in this issue. Done means the fail-closed transport rules, documented operation inventory, negative cases, and failover coverage all match the acceptance criteria.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
User Story
As an OpenShell cluster operator, I want gateway peer routing to require an explicitly trusted encrypted transport and to be validated across supported sandbox operations, so that HA does not weaken confidentiality or fail only on less-common workflows.
Problem Statement
PR #1868 authenticates gateway peers with Kubernetes ServiceAccount identity, but the current transport and validation contract has gaps:
- HTTPS peer clients fall back to the platform trust store when no peer CA is configured, widening the trust surface for internal peer traffic.
- A multi-replica gateway that itself serves plaintext accepts an
http://peer endpoint with only a warning, even though peer relays carry supervisor traffic and projected peer credentials. - The HA e2e keeps a sandbox alive through scaling and pod rotation and covers create/watch, exec, upload, and download, but does not exercise the full supported set of operations that depend on owner routing, such as forwarding/service traffic and configuration changes.
Impact / Why This Matters
A deployment mistake can leave internal peer traffic unencrypted or trusted through roots unrelated to the cluster peer identity. Separately, operators can pass the current HA smoke test while encountering failures in untested session-bound or configuration workflows after scaling or rolling gateway pods. The workaround is manual cluster-specific testing and inspection, which is inconsistent and easy to omit.
Proposed Design
Define and enforce a fail-closed peer transport contract for multi-replica gateways:
- Peer routing requires TLS with an explicit peer CA or an equivalently scoped cluster trust source; it does not silently fall back to general platform roots.
- Multi-replica startup rejects plaintext peer endpoints.
- Documentation identifies the operations expected to remain available through a non-owner gateway and during gateway scaling, failover, and rolling replacement.
- HA conformance keeps a long-running sandbox active while exercising representative operations from that documented inventory through different gateway replicas.
Acceptance Criteria
- Multi-replica gateway startup rejects an
http://peer endpoint. - HTTPS peer routing fails closed when no explicitly scoped peer trust source is configured.
- Helm-generated and custom TLS configurations document the required peer CA, server identity, and client identity contract.
- The supported HA operation inventory includes sandbox create/watch, exec, file transfer, TCP or service forwarding, and relevant policy/provider configuration workflows.
- Automated HA tests exercise that inventory against a long-running sandbox across scale-up, scale-down, owner loss, and rolling pod replacement.
- Negative tests cover plaintext endpoints, missing peer CA material, and peer identity mismatch.
- Architecture and gateway-configuration documentation match the enforced transport and conformance behavior.
Alternatives Considered
Continuing to warn for plaintext preserves development configurations but permits an insecure production mistake. Platform trust roots are convenient for public endpoints, but internal gateway peers already have a chart-managed identity and should use narrowly scoped trust. Testing every RPC independently would be expensive and brittle, so the conformance suite should test the documented operation classes and shared routing paths instead.
Agent Investigation
This groups the remaining peer-security and coverage review discussions from PR #1868:
- Native-root fallback for peer TLS: https://github.com/NVIDIA/OpenShell/pull/1868#discussion_r3951069251
- Plaintext peer endpoint acceptance: https://github.com/NVIDIA/OpenShell/pull/1868#discussion_r3951174195
- Long-running sandbox and operation coverage: https://github.com/NVIDIA/OpenShell/pull/1868#discussion_r3491913235
Related umbrella issue: #1021.
- Lenguaje dominante
- Rust
- Estrellas
- 8.7k
- Forks
- 1.3k
- Merge medio
- 2 d 6 h
- PR fusionados (30 d)
- 301
Guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de NVIDIA/OpenShell
-
area:docs
Dificultad 1/5 Menos de una hora Aptitud para principiantes 88/100
-
state:triage-needed
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
-
area:cli state:validated
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
-
state:triage-needed
Dificultad 1/5 Menos de una hora Aptitud para principiantes 90/100
-
area:build spike state:review-ready state:stale
Dificultad 2/5 Medio día Aptitud para principiantes 68/100
Todos los issues de NVIDIA/OpenShell
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
TheLarkInn/aipm#2413 ·
-
documentation
Dificultad 1/5 Menos de una hora Aptitud para principiantes 90/100
alexgorbatchev/simple-ptt#15 ·
-
tooling
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
todo:ticket
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
taikoxyz/taiko-mono#22168 · 1 comentario ·