-
Notifications
You must be signed in to change notification settings - Fork 193
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
Draft: Rest gateway #1355
base: master
Are you sure you want to change the base?
Draft: Rest gateway #1355
Conversation
The rest gateway exposes a rest api to access th opencue grpc api. See README.md for more information
Hi there. A drive-by comment prompted by this PR getting surfaced in the TSC meeting. I understand that this REST gateway is being designed without authorization/authentication, with an expectation that perimeter/firewall security is sufficient protection. As a point against this posture, please do consider the possibility of phishing attacks, or internal threat actors. For example, it is possible for an attacker to send someone inside of the network a phishing email that contains code or clickable links that send a web request to the webservice that's, otherwise, only accessible within the network. This becomes relatively trivial if the webservice is completely unauthenticated, and opens the render farm up to remote exploits. Similarly, an internal threat actor could send whatever requests they would like to the gateway to affect behavior of the farm. Render farms are remote execution platforms, by definition, so an attacker gaining access to the webservice could submit work (mining bitcoin, for instance), or exfiltrate information about secret projects that are running on the farm. I would suggest a threat modelling exercise be undertaken to understand the risks inherent in a component such as this, and the implementation be modified to mitigate the threats uncovered. Some things to think about include: How would the threat be mitigated? How would an attack be detected? What audit trail exists to discover the source of the attack? etc. |
Thanks for the feedback Daniel, I acknowledge the risks involved in exposing a REST API, even on an internal network environment. I'm working on adding oauth authentication to the REST gateway module to ensure any non-authorized access gets blocked. |
Summarize your change
Create a service to expose a REST endpoint for the grpc interface. The motivation behind having a REST endpoint is to create a web version of cuegui (coming soon).
How does it work
This is a go serviced based on the official grpc-gateway project
that compiles opencue's proto files into a go service that provides a REST interface and redirect calls to the
grpc endpoint.
Running the service
Running the service is very simple:
CUEBOT_ENDPOINT=your.cuebot.server:8443
REST interface
All service rpc calls are accessible:
Example (getting a show):
show.proto:
request (gateway running on
http://opencue-gateway.apps.com
):curl -i -X POST http://opencue-gateway.apps.com/show.ShowInterface/FindShow -d '{"name": "ashow"}`
response
Example (getting frames for a job):
job.proto:
Note: it is important to include 'page' and 'limit' when getting frames for a job.
curl -i -X POST http://opencue-gateway.apps.com/job.JobInterface/GetFrames -d '{"job":{"id":"9999999999-b8d7-9999-a29c-99999999999999"}, "req": {"include_finished":true,"page":1,"limit":100}}'
response