Use existent secrets for sensitive variables in values.yaml for compatibility with ArgoCD

[Mmoncadaisla]

Context

After some initial review of eoAPI via local deployment we decided to go one step further and deploy it to our cluster.

We are on Google Kubernetes Engine (GKE) and leverage ArgoCD for application deployment, using Kubeseal for sensitive information via SealedSecrets. I'm myself no expert on the matter at all, but trying to get familiar with STAC, the eoapi ecosystem and its deployment configurations.

Ultimately, we aim to leverage an existent PostgreSQL database for pgstac that leverages the Cloud Native PG operator, and which for unfortunate reasons lives within a different GKE cluster and region in the same Google Cloud project.

Question

Apologies in advance if the following question is quite basic: from the values.yaml file it looks like some variables are intended to be passed upon helm install or helm template commands. Since we're using ArgoCD, we intended to pre-create the secrets and reference those in the values.yaml file.

  helm install \
      --namespace eoapi \
      --create-namespace \
      --set gitSha=$GITSHA \
      --set db.settings.secrets.PGUSER=$PGUSER \
      --set db.settings.secrets.POSTGRES_USER=$POSTGRES_USER \
      --set db.settings.secrets.PGPASSWORD=$PGPASSWORD \
      --set db.settings.secrets.POSTGRES_PASSWORD=$POSTGRES_PASSWORD \
      eoapi \
      ./eoapi

For example, in other applications we were able to use the following pattern:

# -- Extra environment variables in RAW format that will be passed into pods
extraEnvRaw:
  - name: DB_PASS
    valueFrom:
      secretKeyRef:
        name: postgresql-secrets
        key: postgres-password

So the question is: what is the recommended approach to inject these variables in a secure way that works with ArgoCD and allow us to pre-create the SealedSecrets that expand to Kubernetes Secrets in advance?

Additional information

ArgoCD application manifest

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: eoapi
  namespace: argocd
spec:
  project: default
  sources:
    # Chart from the eoAPI chart repo
    - chart: eoapi
      repoURL: https://devseed.com/eoapi-k8s/
      targetRevision: 0.1.12
      helm:
        valueFiles:
          - $values/releases/dev/eoapi/values.yaml
    # Values from Git repository
    - repoURL: https://github.com/cambium-earth/data-canopy-argocd.git
      targetRevision: HEAD
      ref: values
  destination:
    namespace: eoapi
    server: https://kubernetes.default.svc
  syncPolicy:
    automated:
      selfHeal: true
      prune: true
    syncOptions:
      - CreateNamespace=true

[vincentsarago]

I've transferred the original discussion from the eoapi repo to here. Maybe @ranchodeluxe or @Rub21 might have an answer for you!

[Mmoncadaisla]

Thanks for the prompt reply! I wondered if it was a better place here too (FYI, the "Ask questions" button on eoapi-k8s repo took me to the main eoapi discussions page)

[vincentsarago]

(FYI, the "Ask questions" button on eoapi-k8s repo took me to the main eoapi discussions page)

Oo, that's interesting 😅 hope that's fine here then! I'm pretty sure it will get more visibility from people who know k8s stuff

[ranchodeluxe]

I'm pretty sure it will get more visibility from people who know k8s stuff

Too bad that took 6 months to see 😞. @Mmoncadaisla: I imagine you've come up with a solution but yes, extraEnvRaw would be the recommended way and how folks handle this type of thing