Authentication for admin endpoints

Starting with this PR, all the admin endpoints now require three kinds of auth:

  1. IP White-listing, if --whitelist flag is passed to alpha.
  2. Poor-man’s auth, if --auth_token flag is passed to alpha (means you will need to pass the auth_token as X-Dgraph-AuthToken header while making the HTTP request if this is enabled).
  3. Guardian only access, if ACL is enabled (means you need to pass the ACL JWT of a Guardian user as X-Dgraph-AccessToken header while making the HTTP request if this is enabled).

Admin endpoint means any http endpoint which provides admin functionalities. Normally, the path starts with /admin for such endpoints, except a few. So, at present this list includes:

  • /admin
  • /admin/backup
  • /admin/config/lru_mb
  • /admin/draining
  • /admin/export
  • /admin/shutdown
  • /admin/schema
  • /alter
  • /login

There are a few exceptions to the general rule described above:

  1. /admin: This endpoint provides GraphQL queries/mutations for administration purposes. All the queries/mutations on /admin have all the 3 auth checks, except for the following one:
    • login (mutation): This mutation logs-in an ACL user, and provides them with JWT. Only IP Whitelisting and Poor-man’s auth checks are performed for this. As one won’t be able to login using ACL if we mandate Guardian only access on this.
  2. /login: The same behavior as the above GraphQL admin login mutation.

Apart from the above-mentioned points, when ACL is enabled, querying dgraph schema now returns only those predicates for which the ACL user has read access.

cc: @pawan, @michaelcompton, @gja, @mrjn

Related PRs:

1 Like

I think we should consider what their behavior “should be”, not what it has been. We can make breaking changes in major releases. So, let’s think about that and apply the checks accordingly.

I’d think that GQL schema retrievals and updates would require all 3 checks, just based on a cursory look.

IP whitelisting was introduced for Admin operations and updating and fetching the schema are Admin operations. So it should apply to Alter and updateGQLSchema. We can also apply it to getGQLSchema but then we should probably also apply it to the schema {} query within Dgraph.

Changes to Alter and schema {} affects the behavior for all client libraries, the Tour, and Play (to name a few). For folks altering the schema or running schema queries, they’d need to set the whitelist flag appropriately.

So finally IP whitelisting was only applied for Alter and not for getting the schema, so it shouldn’t affect play. It would affect Tour though and we should modify it so that it works with the new changes. Not sure who is the right person to do it though.

The person making the changes that necessitates an update to Tour would be a good candidate. They have the most context.

@abhimanyusinghgaur could you please add a task for yourself to check this and send a PR over to Tour? We shouldn’t be merging it until 20.07.0 goes out though.

Updated Tour.
Merged because it was a backward compatible change.

FYI. If auth-tokens are enabled, ACLs with accessJWT token will no longer work in v20.07.0:

This worked fine before together with v20.03.4.

As far as I can tell, the message from server.go indicates that metadata auth-token is not there, despite that it was configured:

2 things:

  1. Is this all an enterprise feature?

docker run -it -p 7080:7080 --network dgraph_default -p 8080:8080 -p 9080:9080 -v ~/dgraph/alpha/s1:/dgraph dgraph/dgraph:v21.03.2 dgraph alpha --zero= --my= --whitelist=
Error: unknown flag: --whitelist

I’m in this topic because

curl -X POST localhost:8080/admin/schema --data-binary '@schema.graphql'

{"errors":[{"message":"resolving updateGQLSchema failed because unauthorized ip address: (Locations: [{Line: 3, Column: 4}])","extensions":{"code":"Error"}}]}%      

You should make a new post - this topic is old enough that the flags referenced have changed, see the docs on the new flags for version v21.03+