Ratel not working with DGraph enterprise trial version

Users Dgraph
, ,
1

After we deployed DGraph Enterprise version with --acl_secret_file We were unable to login to ratel. We get " Unauthorized ip address: 172.15.1.2"
Has anyone seen this problem.

This is the deployment file:

# This StatefulSet runs 1 pod with one Zero, one Alpha & one Ratel containers.
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: dgraph
spec:
  serviceName: "dgraph"
  replicas: 1
  selector:
      matchLabels:
        app: dgraph
  template:
    metadata:
      labels:
        app: dgraph
    spec:
      containers:
      - name: ratel
        image: dgraph/dgraph:latest
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 8000
          name: ratel-http
        command:
          - dgraph-ratel
      - name: zero
        image: dgraph/dgraph:latest
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 5080
          name: zero-grpc
        - containerPort: 6080
          name: zero-http
        volumeMounts:
        - name: datadir
          mountPath: /dgraph
        command:
          - bash
          - "-c"
          - |
            set -ex
            dgraph zero --my=$(hostname -f):5080 -v=2 --ludicrous_mode
      - name: alpha
        image: dgraph/dgraph:latest
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 8080
          name: alpha-http
        - containerPort: 9080
          name: alpha-grpc
        volumeMounts:
        - name: datadir
          mountPath: /dgraph
        env:
          - name: POD_NAMESPACE
            valueFrom:
              fieldRef:
                fieldPath: metadata.namespace
        command:
          - bash
          - "-c"
          - |
            set -ex
            dgraph alpha --my=$(hostname -f):7080 --lru_mb 2048 --zero dgraph-0.dgraph.${POD_NAMESPACE}.svc.cluster.local:5080 -v=2 --acl_secret_file /dgraph/hmac-secret --ludicrous_mode
      terminationGracePeriodSeconds: 60
      volumes:
      - name: datadir
        persistentVolumeClaim:
          claimName: dgraphfileclaim
  updateStrategy:
    type: RollingUpdate

and the following service.yaml was also applied.

apiVersion: v1
kind: Service
metadata:
  name: dgraph
  labels:
    app: dgraph
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-internal: "true"
spec:
  type: LoadBalancer
  ports:
  - protocol: TCP
    port: 8000
    targetPort: 8000
    name: ratel-http
  - port: 5080
    targetPort: 5080
    name: zero-grpc
  - port: 6080
    targetPort: 6080
    name: zero-http
  - port: 8080
    targetPort: 8080
    name: alpha-http
  - port: 9080
    targetPort: 9080
    name: alpha-grpc
  selector:
    app: dgraph
2

@joaquin is this a container issue?

3

This is a security measure done by Dgraph automatically. To “fix” this you have to use the whitelisting flag. See https://dgraph.io/docs/deploy/admin/

e.g:

dgraph alpha --whitelist 172.15.1.2

And you should good to go.

Also, Thanks for being proactive and give us more contextual info. But in general, I personally recommend that you share logs, YAMLs, and other “wall of info” as GIST or “Pastebin” or some other service like that. If that info isn’t crucial for the case you can let them on those services. That also helps us to understand the case. Cuz we would know that you probably are just sharing context and not that you suspect that you did some typo or something like that.

PS: That’s only a personal tip for ya. To get better responses from us.

We would waste some time looking on the wrong place. Also, you are probably using this very same YAML dgraph/contrib/config/kubernetes/dgraph-single/dgraph-single.yaml at master · dgraph-io/dgraph · GitHub You could just share this link and tell us what line you have changed something.

Cheers!

4

Is there a way to whitelist any/all ip address? We are currently in an evaluation mode. Our IP addresses are dynamic and coming from a couple of different places.

5

You can add a range, the docs shows an example of how to do it.
Something like

--whitelist 172.15.1.1:172.15.1.77