External-dns: msg="services is forbidden: User \"system:serviceaccount:default:default\" cannot list services at the cluster scope"

Created on 18 Sep 2018  路  4Comments  路  Source: kubernetes-sigs/external-dns

While trying to use the kops with route53 to handle the creation of new subdomains and attach them to services, I end up seeing this error inside the log of the external-dns pod log.

time="2018-09-18T09:51:09Z" level=error msg="services is forbidden: User \"system:serviceaccount:default:default\" cannot list services at the cluster scope"

My kops cluster configuration is:

`# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: kops/v1alpha2
kind: Cluster
metadata:
  creationTimestamp: 2018-09-18T08:18:09Z
  name: test.my-cluster-name.de # my-cluster-name was renamed here
spec:
  additionalPolicies:
    node: |
      [
        {
          "Effect": "Allow",
          "Action": [
            "route53:ChangeResourceRecordSets"
          ],
          "Resource": [
            "arn:aws:route53:::hostedzone/*"
          ]
        },
        {
          "Effect": "Allow",
          "Action": [
            "route53:ListHostedZones",
            "route53:ListResourceRecordSets"
          ],
          "Resource": [
            "*"
          ]
        }
      ]
  api:
    dns: {}
  authorization:
"/var/folders/lb/43cytbwj2y99s7nzcg4wd74mdchdlv/T/kops-edit-5nc6eyaml" 74L, 1681C
`

my external-dns configuration, and my service/pod configuration

`
apiVersion: v1
kind: Service
metadata:
  name: nginx
  annotations:
    external-dns.alpha.kubernetes.io/hostname: nginx.test.my-cluster-name.de
spec:
  type: LoadBalancer
  ports:
  - port: 80
    name: http
    targetPort: 80
  selector:
    app: nginx

---

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx
spec:
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx
        name: nginx
        ports:
        - containerPort: 80
          name: http

---

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: external-dns
spec:
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: external-dns
    spec:
      containers:
      - name: external-dns
        image: registry.opensource.zalan.do/teapot/external-dns:latest
        args:
        - --source=service
        - --provider=aws
        - --domain-filter=test.my-cluster-name.de`

Most helpful comment

after long fighting. this command solved somewho my issue:

kubectl create clusterrolebinding default-admin --clusterrole cluster-admin --serviceaccount=default:default

and I still dont understand what it does and what service account is.

All 4 comments

after long fighting. this command solved somewho my issue:

kubectl create clusterrolebinding default-admin --clusterrole cluster-admin --serviceaccount=default:default

and I still dont understand what it does and what service account is.

@Fettah I think that you have RBAC activated so you have to configure it.

For more info to RBAC you can check this link it was very helpful for me: rbac tutorial

And if you are using AWS you can follow this tutorial for RBAC configuration: external-dns for aws

Good luck!

I would assume that the default when rbac.create=true that the clusterrole created by this helm chart would include all the roles required for the external-dns service account.

I am see this:

time="2019-06-24T03:58:21Z" level=error msg="dnsendpoints.externaldns.k8s.io is forbidden: User \"system:serviceaccount:routing:external-dns\" cannot list resource \"dnsendpoints\" in API group \"externaldns.k8s.io\" at the cluster scope"

Maybe we are missing the dnsendpoints.externaldns.k8s.io permission in the external-dns cluster role among others? Could it be that it is a problem since I am not deploying in the right namespace?

It's different than the original post, so I'm not sure if this issue is related. Either way, assigning a cluster role binding of cluster-admin will work, but it gives the app complete access to the cluster.

@Fettah thx,this works for me

Was this page helpful?
0 / 5 - 0 ratings