Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Docs] Update Security Guidance on Dashboard Ingress #1413

Merged
merged 2 commits into from
Sep 12, 2023
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions docs/guidance/ingress.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,6 +5,9 @@ Here we provide some examples to show how to use ingress to access your Ray clus
* [Example: AWS Application Load Balancer (ALB) Ingress support on AWS EKS](#example-aws-application-load-balancer-alb-ingress-support-on-aws-eks)
* [Example: Manually setting up NGINX Ingress on KinD](#example-manually-setting-up-nginx-ingress-on-kind)


> :warning: **Only expose Ingresses to authorized users.** The Ray Dashboard provides read and write access to the Ray Cluster. Anyone with access to this Ingress can execute arbitrary code on the Ray Cluster.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would you mind updating the documentation at this link? We have already transferred most of the documents to the Ray repository. The documents here will be removed to maintain a single, authoritative source of information.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Working on a PR with this as well!


### Example: AWS Application Load Balancer (ALB) Ingress support on AWS EKS
#### Prerequisite
* Follow the document [Getting started with Amazon EKS – AWS Management Console and AWS CLI](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-console.html#eks-configure-kubectl) to create an EKS cluster.
Expand Down
2 changes: 2 additions & 0 deletions docs/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -54,6 +54,8 @@ by some organizations to back user interfaces for KubeRay resource management.

## Security

**Security and isolation must be enforced outside of the Ray Cluster.** Restrict network access with Kubernetes or other external controls. Refer to [**Ray security documentation**](https://docs.ray.io/en/master/ray-security/index.html) for more guidance on what controls to implement.

Please report security issues to [email protected].

## The Ray docs
Expand Down
5 changes: 4 additions & 1 deletion ray-operator/config/samples/ray-cluster-alb-ingress.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +3,10 @@ kind: Ingress
metadata:
name: ray-cluster-ingress
annotations:
alb.ingress.kubernetes.io/scheme: internet-facing
# WARNING: Do not expose this ALB publicly without additional authentication/authorization.
# The Ray Dashboard provides read and write access to the cluster. Anyone with access to the
# ALB can launch arbitrary code execution on the Ray Cluster.
alb.ingress.kubernetes.io/scheme: internal
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this doc still work after the change? In addition, would you mind explaining what's the difference from security perspective between internal and internal-facing?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The difference between internal and **internet**-facing is that internal requires access from within the VPC, whereas internet-facing is exposed on the public internet. It is unsafe to publicly expose the Ray Dashboard on the internet because that allows anyone to submit Ray Jobs (and thus execute arbitrary code) on the cluster.

internal requires a VPC or similar technology to reach, but is more safe by default.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the explanation! Based on the explanation, this doc seems to no longer work without modification.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm going to update that as well. It will technically get the ALB up and running, but will not give immediate access.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we cherry-pick the doc update to Ray 2.7.0? I guess the doc uses the YAML file in the KubeRay master branch. If we merge this PR at this moment, users may have issues when they try the doc on the Ray website.

alb.ingress.kubernetes.io/tags: Environment=dev,Team=test
# See `ingress.md` for more details about how to choose subnets.
alb.ingress.kubernetes.io/subnets: subnet-0930d6b677fb40a74, subnet-0066ab2e15925618c
Expand Down
3 changes: 3 additions & 0 deletions ray-operator/config/samples/ray-cluster.separate-ingress.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -36,6 +36,9 @@ spec:
name: client
---
# Ingress for raycluster
# WARNING: Nginx must handle authentcation/access control. The Ray Dashboard provides
# read and write access to the cluster. Anyone with access through Nginx can launch
# arbitrary code execution on the Ray Cluster.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
Expand Down
Loading