The Users category is meant for asking questions and discussing things. However, we have specific categories for some things. We would appreciate if you could post in the correct category.
Now that I’ve successfully launched an ALB by enabling the ingress like using Dgraph’s helm chart v23.0.1.
However, I wish to add a custom action, which is to return fixed response with status code 403 for path /admin to block unauthorized users from mutating schema.
I tried the following annotations and spec but it doesn’t work. I need some guidance.
This is a really good use case. I thought of doing this myself at some point. For this, I think you may need to make a separate ingress resource that scoops up exactly that path, so that path comes with the annotation. Since they use the same group, all the ingress resources will be collected to make a combined rule set.
For alternatives, if you use ACL feature (which requires enterprise license), you have have logins with non admin accounts. The admins have to be members of the group Guardians.
You can also test the pattern out with ingress-nginx for a compare point, in case there’s something funky with ALB.
I exported the ingress to a separate yaml file, added exact paths in it and removed the ingress config in dgraph values’ yaml, which works well! But I’m going to try to add the ingress config back in dgraph values’ yaml, then add only specific paths to the separate ingress resources of the same group to verify if they’re collected to make a combined rule set.
We haven’t purchased the enterprise license yet but ACL feature is quite necessary for releasing on Prod.
Verified true to the combined settings applied to the same ingress per your suggested solution. But I’ll keep the ingress config empty in dgraph values yaml file and use the separate ingress yaml file to fully control the ingress and ALB so that when Dgraph gets uninstalled somehow the ALB will stay, otherwise the ALB will be gone with Dgraph being uninstalled.
One alternative way to handle the management of this is to use an internal reverse proxy to handle ingresses, but use ALB for security and other features, such as using WAF. This makes it easier to handle changes that churn more frequently. For the ALB side, a little known trick is to not specify a host key in the rules, and just have the path. This will default to wildcard, so you make ALB a robust that just passes the routing to the next layer.
The upside of this is that you can use ALB features, such as TLS termination and security features. You can also get more permanent IP addresses that won’t change as you install or uninstall Dgraph. The downside is that this could add latency as it goes through an extra hop, and also it is a different type of complexity to have both external and internal LB for that flexibility to have the two layers. So that would be the trade off.
For using logins like JWT, you could either use the enterprise feature, or put a proxy in front of Dgraph, such as a side care that requires login. The trade off for this is that obvious cost, but also with Dgraph feature, you can put ACLs on things like admin vs regular usage, and also access to certain predicates. This plays nicely with mult-tenant, where you can have one group that access one tenant, and another group accesses a different tenant. Enterprise gives you backups, both full and incremental backups from the last full backup, and you can use encryption, while non-enterprise is just the full export in clear text. Both ACL and encryption features can also save the ACL and the Ecnryption secret saved externally using Hashicorp Vault AppRole feature, so that such credentials can be reused and versioned.
