[Feature Request] Kubernetes Automatic Service Discovery Secrets

[ImDevinC]

Description

I'm using Kubernetes automatic service discovery to read my httproute resources and build widgets. I would like to be able to include API keys and such, but I don't want to store those raw secrets on the resource. It would be great if I could pass a variable or something and then have homepage use a mounted secret (environment variable, file, etc)

Other

No response

[scme0]

I only just discovered the Kubernetes Service Discovery feature and I would like the same enhancement.

I've put together a branch that will do this by allowing a user to set the value of the annotation to reference a secret. Eg:

  annotations:
    gethomepage.dev/widget.key: 'sec.ref#pihole/pihole-credentials/password'

The syntax is <sec | cm>.ref#<namespace>/<name>/<property>
(sec for secret, cm for configmap)

This isn't some common kubernetes syntax or anything so I'm not sure if it's acceptable.

I've made a draft PR on my fork to show the changes: scme0#1

[scme0]

I've published a test image: docker.io/scottyjoe9/homepage:v1.7.0-scme0-2

[urbaman]

I'm in the very same situation, where I'm unable to do gitops on kubernetes because of this.

I would add: it's a security issue having keys plainly coded in the resource manifest.

[mscreations]

The easiest way is to use a volume and volumeMount for this. The biggest downside, however, is that Kubernetes won't allow cross-namespace secret access. My solution that I've been using is that I have everything stored in an external secret store (in my case I'm using Infisical). I include the manifest for the ExternalSecret from the other namespace directly in my kustomization.yaml file. Then I mount it to the deployment with a volume and volumemount and also set the env HOMEPAGE_FILE_WHATEVER to point to the file that is mounted. In my services.yaml you then just have to put "{{ HOMEPAGE_FILE_WHATEVER }}" and homepage will take the value stored in the file from that environment variable and plug it in. Even better, the key is not available as an environment variable which has it's own security issues.

As an example, here is the overlay for Grafana that I'm using:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: homepage
spec:
  template:
    spec:
      volumes:
        - name: grafana-admin-secret
          secret:
            secretName: grafana-admin-secret
            defaultMode: 420
      containers:
        - name: homepage
          env:
            - name: HOMEPAGE_FILE_GRAFANA_USER
              value: /var/run/grafana-admin-secret/admin-user
            - name: HOMEPAGE_FILE_GRAFANA_PASSWORD
              value: /var/run/grafana-admin-secret/admin-password
          volumeMounts:
            - name: grafana-admin-secret
              readOnly: true
              mountPath: /var/run/grafana-admin-secret

I "cheat" in my kustomization.yaml by including the ExternalSecret from the other namespace, e.g.:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
  - serviceaccount.yaml
  - deployment.yaml
  - service.yaml
  - httproute.yaml
  - rbac.yaml
  - ../../../monitoring-system/kube-prometheus-stack/app/grafana.secret.yaml
  - root-secrets.yaml

patches:
  - path: ./overlay/grafana-secret.yaml

[femxiii]

I'm surprised this hasn't been considered yet! It would be nice if even the {{HOMEPAGE_VAR_XXXX}} env vars were picked up by automatically discovered service, then you could at least specify

    gethomepage.dev/widget.key: "{{HOMEPAGE_VAR_SOME_API_KEY}}"

And inject it into your deployment with

envFrom:
  - secretRef:
      name: homepage-secrets