nebari-dev / nebari-dev/rayserve-pack

Follow-up: in-transit mTLS for Ray channels (RAY_USE_TLS + cert-manager)

Open
#29 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Makefile
Stars
1
Forks
4
Avg merge
3d 14h
Merged PRs (30d)
5

Description

Context

The hardening PR makes NetworkPolicy the in-cluster authorization boundary for Ray's unauthenticated ports (10001 client, 6379 GCS, 8265 dashboard/job API). That restricts who can connect, but:

  • traffic between Ray nodes and from clients is plaintext
  • any allow-listed client is fully trusted by GCS — there is no per-client identity, no authn, no authz once a connection is admitted

Proposal

Support Ray's in-transit TLS (tls-auth docs) as an opt-in chart feature:

  • tls.enabled values gate
  • a cert-manager Certificate per cluster (chart-templated, cert-manager becomes a soft dependency)
  • RAY_USE_TLS=1 + RAY_TLS_SERVER_CERT / RAY_TLS_SERVER_KEY / RAY_TLS_CA_CERT env on head and worker
  • an initContainer (or cert-manager csi-driver) producing per-pod certs with correct SANs

Known blockers / open questions

  • SAN generation vs RayService naming: RayService generates RayCluster names with a random suffix, so head/worker pod DNS names aren't statically known at template time. Options: wildcard SANs for the namespace (*.<ns>.svc), or per-pod cert issuance via csi-driver.
  • Performance: Ray docs note TLS on gRPC channels costs meaningful GCS throughput (benchmarks ~10–20%).
  • Client-side distribution: every client (checkmaite api, Jupyter notebooks via data-science-pack) needs the CA cert + a client cert mounted and the same RAY_USE_TLS env — needs a documented pattern per consumer pack.
  • Interaction with the zero-downtime upgrade flow (two clusters live simultaneously, one Certificate?).

References

  • Hardening PR: #28
  • README Security section documents this as the known residual risk.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the README Security section and hardening PR #28, then review the Ray TLS-auth documentation linked in the proposal. Resolve the SAN and RayService naming, client certificate distribution, cert-manager dependency, and zero-downtime upgrade questions before implementing the opt-in chart feature. Done means head, worker, and documented clients can use TLS without breaking upgrades.

Written by the indexing model from the issue text.

Assessment

Tech stack
kubernetes
Domain
infrastructure, security
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.