nebari-dev / nebari-dev/rayserve-pack
Follow-up: in-transit mTLS for Ray channels (RAY_USE_TLS + cert-manager)
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.enabledvalues gate- a cert-manager
Certificateper cluster (chart-templated, cert-manager becomes a soft dependency) RAY_USE_TLS=1+RAY_TLS_SERVER_CERT/RAY_TLS_SERVER_KEY/RAY_TLS_CA_CERTenv 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_TLSenv — 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
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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