Pilot token should be configured with kubernetes secret instead of plaintext values

[jtcressy]

Welcome!

• [X] Yes, I've searched similar issues on GitHub and didn't find any.
• [X] Yes, I've searched similar issues on the Traefik community forum and didn't find any.

What did you expect to see?

Currently, the only supported way to configure Traefik Pilot is to supply the token credential via values.yaml.

This causes many security issues in environments where the values.yaml cannot be treated as a secret. It is usually configuration that is committed to source control and thus has minimal access protection.

Many other helm charts are following a pattern of using secret references in values.yaml, with the expectation that the operator of the helm chart creates the secret resource separate from the helm workflow.

Take for example the vault helm chart by Hashicorp and how they consume enterprise license info (which is sensitive and should be secured) vault-helm/values.yaml

# [Enterprise Only] This value refers to a Kubernetes secret that you have
# created that contains your enterprise license. If you are not using an
# enterprise image or if you plan to introduce the license key via another
# route, then leave secretName blank ("") or set it to null.
# Requires Vault Enterprise 1.8 or later.
enterpriseLicense:
  # The name of the Kubernetes secret that holds the enterprise license. The
  # secret must be in the same namespace that Vault is installed into.
  secretName: ""
  # The key within the Kubernetes secret that holds the enterprise license.
  secretKey: "license"

Sometimes this doesn't have to be done with an explicit configuration value, but via extra environment variables or volumes. This chart supports both, however Traefik (as of 2.5.3) has mutually exclusive configuration methods which means we cannot use CLI arguments at the same time as environment variables or even configuration files. Since there are CLI configurations hard-coded into this chart, I'm unable to work around this limitation without forking and doing heavier modification.

For example, I attempted this in my own values.yaml in my own repository:

env:
- name: TRAEFIK_PILOT_DASHBOARD
  value: "true"
- name: TRAEFIK_PILOT_TOKEN
  valueFrom:
    secretKeyRef:
      name: traefik-pilot-token
      key: token

I manage the secret resource separately, either manually creating it or using some other solution to manage its lifecycle (I personally use the onepassword connect operator to dynamically pull secrets from my password manager)

Similarly, I was able to setup sidecar containers using this chart and configure them with externally-managed secrets:

deployment:
  additionalContainers:
    - name: cloudflared
      image: cloudflare/cloudflared:2021.4.0
      args:
      - tunnel
      - --config
      - /etc/cloudflared/config/config.yaml
      - run
      volumeMounts:
        - name: config
          mountPath: /etc/cloudflared/config
          readOnly: true
        - name: creds
          mountPath: /etc/cloudflared/creds
          readOnly: true
  additionalVolumes:
    - name: creds
      secret:
        secretName: cf-tunnel-credentials
    - name: config
      configMap:
        name: cloudflared
        items:
        - key: config.yaml
          path: config.yaml

Due to the use of CLI arguments, mutually exclusive configuration and it also being insecure to place credentials in any command: or args: properties of the pod template, I don't anticipate this being an easy problem to solve. At the very least, some direction on which rabbit hole to jump down.

[kevinpollet]

Related to https://github.com/traefik/traefik/issues/3853

[mloiseleur]

Hi!

Thanks for your interest in Traefik!

We dedicate this issue tracker to bug reports and feature requests on traefik helm chart only. So I'll close this issue.

Btw, Pilot deprecation has been announced a few months ago.