As I work more and more with dgraph, I find that I really like it and am excited to use it in the project that is currently underway.
Not really sure if this qualifies as an issue, but its more of a security access question that could be looked at as an issue since it is rather important to deployment of dgraph nodes across the LAN/WAN.
The one thing that just occurred to me is a question of security and injection attacks that could result from an open call like in the examples:
# Make Alice follow Bob, and give them names.
$ curl localhost:80/query -X POST -d $'mutation { set {<alice> <follows> <bob> . \n <alice> <name> "Alice" . \n <bob> <name> "Bob" . }}'
# Now run a query to find all the people Alice follows 2 levels deep. The query would only result in 1 connection, Alice to Bob.
$ curl localhost:80/query -X POST -d '{me(_xid_: alice) { name _xid_ follows { name _xid_ follows {name _xid_ } } }}'
# Make Bob follow Greg.
$ curl localhost:80/query -X POST -d $'mutation { set {<bob> <follows> <greg> . \n <greg> <name> "Greg" .}}'
# The same query as above now would now show 2 connections, one from Alice to Bob, another from Bob to Greg.
$ curl localhost:80/query -X POST -d '{me(_xid_: alice) { name _xid_ follows { name _xid_ follows {name _xid_ } } }}'
I need to be able to find a way to add some simple security to regulate, with perhaps passwords or access control lists, or keys, etc… as to who & what can be written or read from any shard in the collective graph database cluster.
With this in mind, can you please advise me on what might be achievable in this regard?
We’ve thought about a feature like this – this is an advanced feature that I think would be relevant and useful once we’ve crossed v1.0. Until then, we have a lot of GraphQL features to bake into the database, to make it respond to the kind of queries people expect from a graph database.
If your Dgraph nodes are distributed across different networks, and you’re concerned about man in the middle attacks, we could provide an option to encrypt the communication between nodes using TLS. That wouldn’t give you ACL, but it would help specifically with man in the middle attacks.
You could potentially bake in ACLs on top of Dgraph, a security layer which sits right above it, and interacts with your application. That might be one solution to this problem – that typically would be necessary for other databases as well, for e.g. MySQL.
Let me know how this sounds. I’m very curious to learn what usage you have, and if we can help you in any way. We can definitely expedite any planned features for v1.0 release – if you have any particular needs. Here’s a list of all planned features:
Thanks for moving over the DGraph security discussion as this is a better place to talk about this idea.
At this time, I would rather discuss with you, off-forum, the specifics of the project as it is still in the molding state but is starting to form well based upon projects like DGraph.
As to the security concerns, in my initial basic testing to the single-instance dgraph example (I plan to set up a distributed multi-instance across 2 physical servers for testing over the next couple of days) I found in my first setup that you can easily add information to the graph database with simple “curl” and POST commands which is great, but as this systems is to be physically spread out I need to be able to ensure that only specific users can read/write to any of the nodes.
The TLS communications might be very useful to help protect against the man-in-the-middle attack as you have mentioned but I also wonder about latency with this approach.
The idea of an ACL layer might be very useful as well even if a simple one to get things moving along since I could see needing this before a live system is ready.
Your current demo (https://dgraph.io/ - which is very nice by the way and is what I am going to replicate this weekend if I get time) is very functional, but given that curl POST can be utilized, I do not see how you can protect the demo data from becoming corrupt by someone sending information into the dgraph database and some kind of basic protection seems warrented.
Anyway, maybe we can talk more about my specific project and how we can work together but I do see great potential for DGraph and its use in this way.
We have a flag which can turn off mutations, so only read-only queries would be run on the server. We should have such a flag set for our demo server – though I’ll have to double check if that’s the case. Otherwise, you’re right. Someone can just send bad data and mess it up – it won’t corrupt the database per se, the data would just be wrong.