<p>Just had word from the Grafana team that this is not supported, will raise a feature request</p>

CC BY-SA 4.0
2023-09-28T10:02:23.400Z
can you provide some context for this answer?
Bruce Becker
CC BY-SA 4.0
2023-09-30T07:58:05.113Z
My understanding from Grafana team is that the code base isn't expecting a file path and is only expecting a string, thus it doesn't know what to do with the file
Phil
CC BY-SA 4.0
2023-09-28T08:33:32.223Z
2023-09-28T08:33:32.223Z
Phil
<p>We have kyverno on our work k8 cluster with a policy that says  Secrets must not come from envFrom statements.</p>
<p>So I am trying to setup mimir-distributed chart (version 5.1.0) to use secrets from Volume Mounts.</p>
<p>I can get the volumes mounted and I can see the correct contents of each secret in there files.</p>
<p>My Values file looks like this:</p>
<pre class="lang-yaml prettyprint-override"><code>alertmanager:
  extraVolumes:
    - name: secret-grafana-mimir
      secret:
        secretName: secret-grafana-mimir
  # Extra volume mounts that will be added to the alertmanager container
  extraVolumeMounts:
    - name: secret-grafana-mimir
      mountPath: &quot;/etc/secret&quot;
      readOnly: true

mimir:
  structuredConfig:
    
    alertmanager_storage:
      backend: azure
      azure:
        ## Recplaced the ${} var with the file path
        account_name: /etc/secret/MIMIR_STORAGE_ACCOUNT_NAME
        account_key: /etc/secret/MIMIR_STORAGE_ACCOUNT_KEY
        container_name: mimir-alaertmanager
    compactor:
      data_dir: &quot;/data&quot;
...
</code></pre>
<p>But each service in the Mimir stack then gives pretty much the same error:</p>
<p>This error is from Mimir Alert manager:</p>
<pre><code>ts=2023-09-28T06:03:38.93765098Z caller=main.go:225 level=info msg=&quot;Starting application&quot; version=&quot;(version=2.10.0, branch=HEAD, revision=77906f7)&quot;
ts=2023-09-28T06:03:39.337442912Z caller=server.go:335 level=info msg=&quot;server listening on addresses&quot; http=[::]:8080 grpc=[::]:9095
ts=2023-09-28T06:03:39.537634469Z caller=multitenant.go:156 level=warn msg=&quot;The configured Alertmanager HTTP prefix '/alertmanager' is different than the path specified in the external URL 'http://prometheus-alertmanager.observability:9093': the Alertmanager UI and API may not work as expected unless you have a reverse proxy exposing the Alertmanager endpoints under '/alertmanager' prefix&quot;
ts=2023-09-28T06:03:39.538016272Z caller=log.go:87 level=error msg=&quot;error running application&quot; err=&quot;decode account key: illegal base64 data at input byte 17\nerror initialising module: alertmanager\ngithub.com/grafana/dskit/modules.(*Manager).initModule\n\t/__w/mimir/mimir/vendor/github.com/grafana/dskit/modules/modules.go:138\ngithub.com/grafana/dskit/modules.(*Manager).InitModuleServices\n\t/__w/mimir/mimir/vendor/github.com/grafana/dskit/modules/modules.go:108\ngithub.com/grafana/mimir/pkg/mimir.(*Mimir).Run\n\t/__w/mimir/mimir/pkg/mimir/mimir.go:800\nmain.main\n\t/__w/mimir/mimir/cmd/mimir/main.go:227\nruntime.main\n\t/usr/local/go/src/runtime/proc.go:267\nruntime.goexit\n\t/usr/local/go/src/runtime/asm_amd64.s:1650&quot;
</code></pre>

<kubernetes><helm><grafana>
Can Mimir read secrets from Volume mounts?
Phil
# Can Mimir read secrets from Volume mounts?

(Asked by: username_0 on 2023-09-28)

We have kyverno on our work k8 cluster with a policy that says  Secrets must not come from envFrom statements.
So I am trying to setup mimir-distributed chart (version 5.1.0) to use secrets from Volume Mounts.
I can get the volumes mounted and I can see the correct contents of each secret in there files.
My Values file looks like this:
alertmanager:
  extraVolumes:
    - name: secret-grafana-mimir
      secret:
        secretName: secret-grafana-mimir
  # Extra volume mounts that will be added to the alertmanager container
  extraVolumeMounts:
    - name: secret-grafana-mimir
      mountPath: "/etc/secret"
      readOnly: true

mimir:
  structuredConfig:
    
    alertmanager_storage:
      backend: azure
      azure:
        ## Recplaced the ${} var with the file path
        account_name: /etc/secret/MIMIR_STORAGE_ACCOUNT_NAME
        account_key: /etc/secret/MIMIR_STORAGE_ACCOUNT_KEY
        container_name: mimir-alaertmanager
    compactor:
      data_dir: "/data"
...

But each service in the Mimir stack then gives pretty much the same error:
This error is from Mimir Alert manager:
ts=2023-09-28T06:03:38.93765098Z caller=main.go:225 level=info msg="Starting application" version="(version=2.10.0, branch=HEAD, revision=77906f7)"
ts=2023-09-28T06:03:39.337442912Z caller=server.go:335 level=info msg="server listening on addresses" http=[::]:8080 grpc=[::]:9095
ts=2023-09-28T06:03:39.537634469Z caller=multitenant.go:156 level=warn msg="The configured Alertmanager HTTP prefix '/alertmanager' is different than the path specified in the external URL 'http://prometheus-alertmanager.observability:9093': the Alertmanager UI and API may not work as expected unless you have a reverse proxy exposing the Alertmanager endpoints under '/alertmanager' prefix"
ts=2023-09-28T06:03:39.538016272Z caller=log.go:87 level=error msg="error running application" err="decode account key: illegal base64 data at input byte 17\nerror initialising module: alertmanager\ngithub.com/grafana/dskit/modules.(*Manager).initModule\n\t/__w/mimir/mimir/vendor/github.com/grafana/dskit/modules/modules.go:138\ngithub.com/grafana/dskit/modules.(*Manager).InitModuleServices\n\t/__w/mimir/mimir/vendor/github.com/grafana/dskit/modules/modules.go:108\ngithub.com/grafana/mimir/pkg/mimir.(*Mimir).Run\n\t/__w/mimir/mimir/pkg/mimir/mimir.go:800\nmain.main\n\t/__w/mimir/mimir/cmd/mimir/main.go:227\nruntime.main\n\t/usr/local/go/src/runtime/proc.go:267\nruntime.goexit\n\t/usr/local/go/src/runtime/asm_amd64.s:1650"

**Tags:** kubernetes, helm, grafana


---

## 1 answers

### Answer by username_0 on 2023-09-28. Score: 0

Just had word from the Grafana team that this is not supported, will raise a feature request

> **Comments:**
> **username_1**: can you provide some context for this answer?  
> **username_0**: My understanding from Grafana team is that the code base isn't expecting a file path and is only expecting a string, thus it doesn't know what to do with the file  

---

