Hello, I am having a hard time understanding the authentication mechanism for dgraph.
I made some observations so far,
When connecting from localhost, no password or anything is asked. Anyone can connect and do read write operations. That’s not good in my opinion.
When connecting over the public IP, at least ratel doesn’t want to connect to dgraph without password it seems. Maybe that is just my iptables configuration though. I dont feel comfortable with this at all.
Now I read that ACL are not in the free version. I am getting confused on whats going on here. How am I suppsed to protect the database and how do I set up a password?
I read that its using jwt rather than a password somewhere. In a different place its talking about TLS certifactes. I get that the traffic should be encrypted but its not helping me to authenticate an application or user. Or maybe an application if I Iet dgraph verify the client cert.
All in all it is confusing and seems a bit convoluted. Why isnt there just a user list and password challenge like on any other database?
What mechanism protects dgraph from any client to connect via grpc or http?
Edit:
I just managed to connect over public web without any password. This is super sketchy TBH. No warning in the docs or anything.
There are several ways to do so. The main recommendation is to not expose your database. Create an API between your backend and Dgraph. There’s no reason to expose your DB over the internet.
Some examples:
Create an API and put Dgraph behind a firewall and TLS. No user should connect to it directly.
In addition to the firewall you could use Docker or K8s approach. Using reverse proxy tools like Traefik or NGINX. Also, I believe that NGINX has some password challenging feature. Reverse proxies are great to limit access to gRPC and other endpoints.
Soon you gonna be able to use Poor Man’s ACL. But that fact does not rule out the other recommendations. That is, NEVER expose your DB, no one in the market does or should. e.g WordPress access MySQL in the Backend, the front never have direct access to the DB.
Use the Dgraph’s GraphQL in addition to the recommendations above. GraphQL will give you an Auth system for free. You don’t need an ACL.
GraphQL Auth and Dgraph Cloud provide this.
TLS is important.
Well, in general, who is responsible to create user authentication is your business logic, not the DB. The authentication on the DB is just for administration. No user should, for example, access your MariaDB. But, we get you covered with GraphQL Auth for free.
The other databases have it just for administrative matters. Not for end-user.
Did I ever say end user? I am asking about general protection. Even from localhost.
We agree here. I don’t want user authentication. I want administrator and application authentication. I understand everything you said, but this is not getting to the core of my question. And yes TLS is important, I configure it daily, tell me about it…
Right now any “administrator” can connect and run stuff. There is no protection mechanism at all in place other than my firewall. Do you want to say that is intended? Even my local sysadmins should not be able to mess up my production db, do you agree?
For other databases, you also don’t let end user connect directly BTW. The users in an SQL db user table are as well service or admin accounts and not end user.
So you are saying I need to protect it with firewall, tls and something like basic auth myself. Thats pretty strange TBH. I can certainly do this. As already stated, I am using iptables to block any traffic right now.
But what you are saying also implies i need to do extra shenanigans for local users. They need to go through the proxy as well and do a tls hadshake. This doesn’t sound good. It sounds like a lot of hustle for no reason. I am talking local sys admins, which btw can change any firewall rule anyways.
I’m not sure if it is, I think it just happened. The DB has been developing by worrying about more fundamental and “atomic” things, so to speak. Everything else was superficial. So much so that it was only after a while that Dgraph started looking at these things. I think the DB Core is more important, to refine. And I think it delivers a lot of value to us.
(PS. My personal opinion here) Looking from a developer’s perspective, when I started using Dgraph 3 years ago. I didn’t miss any of that. Because I distinguish between what is Dev or Production. No one, except me, would have access to the DB in prod. Actually, I don’t understand the need for a startup to want ACL right away - Unless you’re already big enough to have a complex administration structure(So enterprise edition would be a choice here). Obviously, it would be nice to have extra goodies, but the people who produce apps already have their strategies. The DB is just a data repository that I want to work fast and have a nice language. I don’t (again, still speaking from my perspective) want anything fancy. I want something that delivers what I need and what comes up next, is profit for us.
You don’t need any of that if you have a pretty solid API. I just gave my opinion based on your security concerns and what we have available.
Well, that’s free software with enterprise services. If you need some “pro” thing you are covered with the EE license.
(More Opinion bellow)
Again, I don’t understand it, this question has come up here a few times(not much). I understand that it is a “different” way of creating apps and dealing with open-source software. But as far as I have experience with it, it is like this everywhere with open-source software. If you want to create a pure Open-source app(from the head to the tail), you will necessarily make a lego of software to build your structure. No single Open-source software will provide everything. And no DB will do all the magic. I particularly think that what Dgraph offers is too much.
I think if you’re just starting out, you don’t need an ACL. And it is possible to protect your DB just by having a solid API.
Well. I am not looking from a startup perspective, we have multiple teams that have access to the servers, like server team, network team, DBA team etc. Maybe you are right and only enterprise edition would be a solution in that case. Its just I am toying around and don’t want to go all in with enterprise from the get go.
I also understand that with open source you need to patch things together. I am doing it all the time and I feel comfortable doing things like this. Its just as you state, dgraph is so different. At least a root password I would expect, that has nothing to do this with wanting a complex auth solution out of the box or anything like that. Just a silly root password how we know it since ancient times. I think relying on networking alone is maybe not secure enough.
Regarding the /graphql endpoint, is this intended to be used from the frontend directly in some ways?
You can spin up several different Dgraph Clusters. And reduce the access to the Prod one when comes time. Also, never let your devs play around with the prod data. For data regulations, this could be a huge problem.
The Poor Man’s ACL will cover this. We already have it protecting Alter and other admin APIs. But soon it will protect Query and Mutations.
Yes. If you use the Auth feature you are safe to use in any GraphQL client out there. Dgraph’s GraphQL is an automated GraphQL API. So almost no coding is necessary to have a fully functional business logic.
