Traefik CRDs and annotations management

[urbaman]

Hi,

I'm trying to manage Traefik CRDs (ingressRoutes, certificates...) and some sensible annotations with argoCD.

I'd like to be able to manage domains and the hompage.key annotation in my git repo without exposing them.
What are the best practices?

Thank you.

Example: I'd like to sync this manifest, without exposing https://argocd.domain.com or gethomepage.dev/widget.key: "<token>"

apiVersion: traefik.io/v1alpha1
kind: IngressRoute
metadata:
  name: traefik-argocd
  namespace: traefik
  annotations:
    # For Homepage service discovery
    gethomepage.dev/href: "https://argocd.domain.com"
    gethomepage.dev/enabled: "true"
    gethomepage.dev/description: "Argo CD"
    gethomepage.dev/group: Automation
    gethomepage.dev/icon: argocd.svg
    gethomepage.dev/app: argocd # optional, may be needed if app.kubernetes.io/name != ingressRoute metadata.name
    gethomepage.dev/name: "Argo CD"
    gethomepage.dev/widget.type: "argocd"
    gethomepage.dev/widget.url: "https://argocd.domain.com"
    gethomepage.dev/widget.key: "<token>"
spec:
  entryPoints:
    - websecure
  routes:
    - kind: Rule
      match: Host(`argocd.domain.com`)
      priority: 10
      services:
        - name: argocd-server
          port: 80
          serversTransport: argocd
      middlewares:
        - name: security
    - kind: Rule
      match: Host(`argocd.domain.com`) && Header(`Content-Type`, `application/grpc`)
      priority: 11
      services:
        - name: argocd-server
          port: 80
          scheme: h2c
          serversTransport: argocd
      middlewares:
        - name: security
  tls:
    secretName: argocd-urbaman-cloud
    options:
      name: tlsoptions

[MentalOfCrow]

Treat the hostname and the widget token differently. The hostname is configuration; the widget key is a credential and should not be stored in an IngressRoute annotation.

Kubernetes annotations are literal strings. They do not support valueFrom.secretKeyRef, and anyone who can read the IngressRoute can read every annotation. Argo CD also renders the complete desired manifest, so substituting a token into that annotation during manifest generation still exposes it in the live CR and potentially in Argo CD's manifest cache.

For Homepage, a safer arrangement is:

1. Keep only non-secret discovery metadata on the IngressRoute (name, group, icon, href, etc.).
2. Put the widget configuration in Homepage's services.yaml rather than in discovery annotations.
3. Inject the key into the Homepage pod from a Kubernetes Secret and reference it with Homepage's supported secret-variable syntax.

For example, in the Homepage Deployment:

env:
  - name: HOMEPAGE_VAR_ARGOCD_KEY
    valueFrom:
      secretKeyRef:
        name: homepage-widget-secrets
        key: argocd-key

Then in the mounted services.yaml:

- Automation:
    - Argo CD:
        icon: argocd.svg
        href: https://argocd.example.com
        widget:
          type: argocd
          url: https://argocd.example.com
          key: "{{HOMEPAGE_VAR_ARGOCD_KEY}}"

Homepage documents that only HOMEPAGE_VAR_*/HOMEPAGE_FILE_* variables are substituted in configuration files: https://gethomepage.dev/installation/docker/#using-environment-secrets

Create homepage-widget-secrets with one of these GitOps patterns:

• External Secrets Operator/Vault/cloud secret manager: Git contains only an ExternalSecret; the credential stays in the external store.
• Sealed Secrets/SOPS: Git contains ciphertext, with decryption restricted to the intended cluster or controller.

Argo CD's own secret-management guide lists these patterns and also warns that secret-injection plugins may leave rendered secrets in repo-server/Redis: https://argo-cd.readthedocs.io/en/release-2.3/operator-manual/secret-management/

For the domain, remember that an externally reachable hostname is usually observable through DNS, certificates, and the live IngressRoute, so hiding it in public Git is not a security boundary. If it is still sensitive inventory, keep only the reusable chart/base public and put environment overlays/values containing the real domain in a private configuration repository. Do not put the widget token in either repository as plaintext.

Finally, rotate the token shown in any committed history or already-applied annotation before switching approaches; removing it from the latest commit does not invalidate an exposed credential.

If this answers the question, please mark it as the accepted answer so future readers can find the safer pattern.