-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Description
Experience Report
The current Kubernetes deployment config of DGraph is completely broken. No point using it.
What you wanted to do
I wanted to deploy DGraph to my Kubernetes cluster. Specifically, I wanted to use the new GraphQL endpoint. But either way, I wanted to deploy DGraph to K8s.
What you actually did
- Deployed the single instance yaml.
- Deployed the HA instance yaml.
- Eventually deleted all DGraph deployments.
Why that wasn't great, with examples
- Not even bare minimum security.
- No password / token / secret on the Ratel Console. Just nothing.
- All ports exposed to the open internet.
- Not even single password to secure anything.
- Everything exposed as LoadBalancer
- Hosted K8s charges per LoadBalancer, means exposing everything incurs unnecessary fees
- What is the actual need to exposed alpha & zero to the open internet?
- Again, no basic protection
For a meaningful cluster deployment, a few very basic things must change:
- Secure any exposed endpoints. There is no excuse.
- Do not expose the entire database unsecured to the open internet. There is no excuse.
- Do not expose all internal ports to the open internet. That goes without saying.
One practical way to add at least some basic security would be to use an http proxy for authentication. In fact, there is an example with DGraph & Nginx as a proxy. So technically, one can configure Nginx for authentication and I think it is the most sensible approach for the time being:
https://gist.github.com/MichelDiz/42954e321620159c872c35c20e9d85c6
https://docs.nginx.com/nginx/admin-guide/security-controls/configuring-http-basic-authentication/
Base security must be there by default.