Allow for an existing cloudProviderApiKey secret

[pieterv-icloud-com]

The helm chart allows for the use of an existing prometheus secret

https://github.com/opencost/opencost-helm-chart/blob/c86ac7031c2965c839a757591a73d3f32f2a9e93/charts/opencost/templates/deployment.yaml#L149

However an existing cloudProviderApiKey secret cannot be specified.

https://github.com/opencost/opencost-helm-chart/blob/c86ac7031c2965c839a757591a73d3f32f2a9e93/charts/opencost/templates/deployment.yaml#L126C46-L126C65

[mattray]

You want to use a cloudProviderApiKey to access Prometheus? Would that be a separate block of

name: DB_BASIC_AUTH_USERNAME
              valueFrom:
                secretKeyRef:

? Could you provide an redacted example of what you'd want this to look like?

[andersbulderbank]

If the OP is in the same situation as us, we already have a Secret created by other means, ie external-secrets, which has the cloudProviderApiKey in it, and want to use this Secret instead of hard coding the API key in the helm values. This would be similar to how the opencost.cloudIntegrationSecret values is set up.

If we configure opencost.exporter.cloudProviderApiKey in values, the helm chart will also create a Secret, and if we do not configure this setting, the Deployment manifest will not add the environment variable CLOUD_PROVIDER_API_KEY to the Deployment manifest using the pre-existing Secret.

To get around this we would need to use kustomize to avoid putting secrets in our git repositories (we use ArgoCD to deploy all our apps).

If something like this could be added to the Deployment manifest, it could fill this usecase:

            {{- if .Values.opencost.exporter.cloudProviderApiKeySecret }}
            - name: CLOUD_PROVIDER_API_KEY
              valueFrom:
                secretKeyRef:
                  name: {{ include "opencost.exporter.cloudProviderApiKeySecret" . }}
                  key: CLOUD_PROVIDER_API_KEY
            {{- end }}

[mattray]

@andersbulderbank we'd definitely take a test PR for that

[Sadzeih]

I've made a PR that should resolve this issue "indirectly".

We could now add extra env this way:

extraEnv:
- name: FOO
  value: BAR
- name: SECRET_FOO
  valueFrom:
    secretKeyRef:
      name: secret-foo
      key: bar

[toscott]

Sorry for coming in super late here, but there are 2 existing environment properties, one that accepts a list of custom formatted env entries and one that accepts a map of key/value pairs. List - opencost.exporter.env Map - opencost.exporter.extraEnv

opencost:
  exporter:
    env:
      - name: CLOUD_PROVIDER_API_KEY
         valueFrom:
         secretKeyRef:
           name: my-secret-key
           key: CLOUD_PROVIDER_API_KEY

The combination of these two should be usable for any environment variable you want to pass. Please let me know if I am misunderstanding and this doesn't solve your use case.