Skip to content

Feat: in-process provisionerd uses in-process communication; disable provisionerd http endpoint #1375

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.

Sign up for GitHub

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

Jump to bottom
Closed
Tracked by #694
spikecurtis opened this issue May 10, 2022 · 4 comments · Fixed by #1614
Closed
Tracked by #694

Feat: in-process provisionerd uses in-process communication; disable provisionerd http endpoint #1375

spikecurtis opened this issue May 10, 2022 · 4 comments · Fixed by #1614
Assignees
@spikecurtis
Labels
api Area: HTTP API
Milestone
Community MVP

Comments

@spikecurtis
Copy link
Contributor

What is your suggestion?

Disable the provisionerd HTTP endpoint and migrate the in-process provisionerd to an in-process communication mechanism.

Why do you want this feature?

Right now we start provisionerd in the same process as coderd, and we don't have any mechanism to start a stand-alone provisionerd. However, that provisionerd communicates with coderd over an unsecured http endpoint.

The endpoint is needed when we have a stand-alone provisionerd, and it needs to be secure, but securing it now feels premature because the security needs will be very different compared with an in-process provisionerd.

Are there any workarounds to get this functionality today?

n/a

Are you interested in submitting a PR for this?

yes
@spikecurtis spikecurtis mentioned this issue May 10, 2022
Closed
3 tasks
@misskniss misskniss added this to the Community MVP milestone May 11, 2022
@misskniss
Copy link

Hey team! Please add your planning poker estimate with ZenHub @spikecurtis @kylecarbs

This was referenced May 12, 2022
Closed
Closed
@ketang
Copy link
Contributor

ketang commented May 15, 2022

What happens if we don't do this?

@spikecurtis
Copy link
Contributor Author

@ketang @misskniss If we don't do either this or #44 , it's Bad News Bears.

Right now the endpoint provisionerd uses to connect to coderd is wide open for anyone to connect to. A malicious person could connect and steal cloud credentials, user SSH private keys, etc. It's real bad; like we shouldn't even be dogfooding until this is fixed. The only thing mitigating this now is that we're the only ones who have the protobuf definitions for what that endpoint expects to get. That changes as soon as we open source, so either this or #44 should be a hard switch blocker.

@greyscaled
Copy link
Contributor

greyscaled commented May 16, 2022 •
edited
Loading

Should we group this in with #44 (since it's an epic) and label the epic as a switch blocker?

Edit: Nvm, I see this is tracked in a similar epic, but for CE

@spikecurtis spikecurtis self-assigned this May 16, 2022
This was referenced May 18, 2022
Merged
Closed
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@spikecurtis spikecurtis

Labels
api Area: HTTP API
Projects
None yet
Milestone
Community MVP
4 participants
@ketang @misskniss @spikecurtis @greyscaled