feat: restrict access to secrets

[jnonino]

What does this PR do?

This PR aims to allow to users to restrict the secrets accesible by Traefik on the Kubernetes cluster. For this reason, I have added a new field into RBAC configuration secretResourceNames. By default, that value is an empty list ([]) and the behaviour is the same as before this change, all secrets are accesible from Traefik.

When that field contains one or more secret names, then only those secrets are the ones accessible from Traefik.

Motivation

Access to secrets without limits raises a security concern and Traefik should have access only to the secrets it requires to work properly, for example TLS certificates stored in secrets and used by Traefik. All other secrets in the cluster should not be accessible. This was raised in the issue 1006.

More

• [x] Yes, I updated the tests accordingly
• [x] Yes, I ran make test and all the tests passed

[jnonino]

Hi @darkweaver87, I'll change the name of the field. I was actually expecting feedback about it :smile:

[jnonino]

Linking with issue https://github.com/traefik/traefik/issues/7097 in Traefik repo as the discussion is relevant to the change added in this PR.

[darkweaver87]

@jnonino , it looks like our bot is not able to merge this PR because it can't rebase on master and push to your branch. Would you mind to rebase it ?

[mloiseleur]

@jnonino any chance that you can rebase this PR ?

[jnonino]

@jnonino any chance that you can rebase this PR ?

Done!!! Sorry for the delay

[Alestrix]

With

  - apiGroups:
      - ""
    resources:
      - secrets
    verbs:
      - list

still present in roles.yaml, this

  - apiGroups:
      - ""
    resources:
      - secrets
    {{- if gt (len $.Values.rbac.secretResourceNames) 0 }}
    resourceNames: {{ $.Values.rbac.secretResourceNames }}
    {{- end }}
    verbs:
      - get
      - list

poses no restriction, since the list verb is a superset of get. With this, traefik still has access to every resource in that namespace. I understand that traefik is "broken" in a way that it needs that permission, but being able to define a list of resourceNames gives the user a false feeling of security.

Or what am I missing?