Secure Grafana Mimir on Grafana Labs

Grafana Mimir authentication and authorization

Mon, 13 Apr 2026 22:46:07 +0000

Grafana Mimir authentication and authorization

Grafana Mimir is a multi-tenant system where tenants can query metrics and alerts that include their tenant ID. The query takes the tenant ID from the X-Scope-OrgID parameter that exists in the HTTP header of each request, for example X-Scope-OrgID: <TENANT-ID>. You can federate queries across multiple tenants by using true in -tenant-federation.enabled=true. When you specify tenant IDs, separate them with a pipe (|) character in the X-Scope-OrgID header, as in the example X-Scope-OrgID: tenant-1|tenant-2|tenant-3.

To protect Grafana Mimir from accidental or malicious calls, you must add a layer of protection such as a reverse proxy that authenticates requests and injects the appropriate tenant ID into the X-Scope-OrgID header.

Configuring Prometheus remote write

For more information about Prometheus remote write configuration, refer to remote write.

With an authenticating reverse proxy

To use bearer authentication with a token stored in a file, the remote write configuration block includes the following parameters:

authorization:
  type: Bearer
  credentials_file: <PATH TO BEARER TOKEN FILE>

To use basic authentication with a username and password stored in a file, the remote write configuration block includes the following parameters:

basic_auth:
  username: <AUTHENTICATION PROXY USERNAME>
  password_file: <PATH TO AUTHENTICATION PROXY PASSWORD FILE>

Without an authenticating reverse proxy

To configure the X-Scope-OrgID header directly, the remote write configuration block includes the following parameters:

headers:
  "X-Scope-OrgID": <TENANT ID>

Extracting tenant ID from Prometheus labels

In trusted environments where you want to split series on Prometheus labels, you can run cortex-tenant between a Prometheus server and Grafana Mimir.

Note: cortex-tenant is a third-party community project that is not maintained by Grafana Labs.

When proxying the timeseries to Grafana Mimir, you can configure cortex-tenant to use specified labels as the X-Scope-OrgID header.

To configure cortex-tenant, refer to configuration.

Disabling multi-tenancy

To disable multi-tenant functionality, pass the following argument to every Grafana Mimir component:

-auth.multitenancy-enabled=false

After you disable multi-tenancy, Grafana Mimir components internally set the tenant ID to the string anonymous for every request.

To set an alternative tenant ID, use the -auth.no-auth-tenant flag.

Note: Not all tenant IDs are valid. For more information about tenant ID restrictions, refer to About tenant IDs.

Encrypting Grafana Mimir data at rest

Mon, 13 Apr 2026 22:46:07 +0000

Encrypting Grafana Mimir data at rest

Grafana Mimir supports encrypting data at rest in object storage using server-side encryption (SSE). Configuration of SSE depends on your storage backend.

Google Cloud Storage

Google Cloud Storage (GCS) encrypts data before writing it to disk. SSE is enabled by default and you cannot turn it off. For more information about GCS encryption at rest, refer to Data encryption options. Grafana Mimir requires no additional configuration to use GCS with SSE.

AWS S3

Configuring SSE with AWS S3 requires configuration in the Grafana Mimir S3 client. The S3 client is only used when the storage backend is s3. Grafana Mimir supports the following AWS S3 SSE modes:

You can configure AWS S3 SSE globally or for specific tenants.

Configuring AWS S3 SSE globally

Configuring AWS S3 SSE globally requires setting SSE for each of the following storage backends:

For more information about AWS S3 SSE configuration parameters, refer to s3_storage_backend.

The following code sample shows a snippet of a Grafana Mimir configuration file with every backend storage configured to use AWS S3 SSE with and Amazon S3-managed key.

alertmanager_storage:
  backend: "s3"
  s3:
    sse:
      type: "SSE-S3"
blocks_storage:
  backend: "s3"
  s3:
    sse:
      type: "SSE-S3"
ruler_storage:
  backend: "s3"
  s3:
    sse:
      type: "SSE-S3"

Configuring AWS S3 SSE for a specific tenant

You can use the following settings to override AWS S3 SSE for each tenant:

s3_sse_type
S3 server-side encryption type. This setting must be applied to enable the SSE configuration override for a given tenant.
s3_sse_kms_key_id
S3 server-side encryption KMS Key ID. This setting is ignored if the SSE type override is not set or the type is not SSE-KMS.
s3_sse_kms_encryption_context
S3 server-side encryption KMS encryption context. If this setting is not applied, and the key ID override is set, the encryption context is not be provided to S3. This setting is ignored if the SSE type override is not set or the type is not SSE-KMS.

To configure AWS S3 SSE for a specific tenant:

Ensure Grafana Mimir uses a runtime configuration file by verifying that the flag -runtime-config.file is set to a non-null value. For more information about supported runtime configuration parameters, refer to Runtime configuration.
In the runtime configuration file, apply the overrides.<TENANT> SSE settings.

A partial runtime configuration file that has AWS S3 SSE with Amazon S3-managed keys set for a tenant called “tenant-a” appears as follows:
YAML
```
overrides:
  "tenant-a":
    s3_sse_type: "SSE-S3"
```
Save and deploy the runtime configuration file.
After the -runtime-config.reload-period has elapsed, components reload the runtime configuration file and use the updated configuration.

Other storage

Other storage backends might support encryption at rest if it is configured at the storage level.

Securing Grafana Mimir Alertmanager

Mon, 13 Apr 2026 22:46:07 +0000

Securing Grafana Mimir Alertmanager

By default, the Alertmanager exposes API endpoints that enable a user to configure the Alertmanager. The Alertmanager configuration includes receivers that create network connections to send the alerting notifications. For example, the webhook receiver enables a user to configure an arbitrary URL to which the Alertmanager sends a customizable request for every alerting notification. If the Alertmanager network security is not hardened, Grafana Mimir users might configure the Alertmanager to issue requests to any network address both in the local network and the Internet.

We recommend hardening the network on which the Alertmanager runs. Although hardening the network is out of the scope for Grafana Mimir, Grafana Mimir provides a basic built-in firewall that blocks connections created by Alertmanager receivers:

To block specific network addresses in Alertmanager receivers, set -alertmanager.receivers-firewall-block-cidr-networks to a comma-separated list of network CIDRs to block.
To block private and local addresses in Alertmanager receivers, set -alertmanager.receivers-firewall-block-private-addresses=true.

You can override the Alertmanager built-in firewall settings on a per-tenant basis in the overrides section of the runtime configuration.

Note: You can disable the Alertmanager configuration API by setting -alertmanager.enable-api=false.

Securing Grafana Mimir communications with TLS

Mon, 13 Apr 2026 22:46:07 +0000

Securing Grafana Mimir communications with TLS

Grafana Mimir is a distributed system with significant traffic between its components. To allow for secure communication, Grafana Mimir supports TLS between its components. This topic describes the process used to set up TLS.

Generation of certificates to configure TLS

To establish secure inter-component communication in Grafana Mimir with TLS, you must generate certificates using a certificate authority (CA). The CA should be private to the organization because certificates signed by the CA will have permissions to communicate with the cluster.

Note: The generated certificates are valid for 100,000 days. You can change the duration by adjusting the -days option in the command. We recommend that you replace the certificates every two years.

The following script generates self-signed certificates for the cluster. The script generates private keys client.key, server.key and certificates client.crt, server.crt for both the client and server. The script generates the CA cert as root.crt.

# keys
openssl genrsa -out root.key
openssl genrsa -out client.key
openssl genrsa -out server.key

# root cert / certifying authority
openssl req -x509 -new -nodes -key root.key -subj "/C=US/ST=KY/O=Org/CN=root" -sha256 -days 100000 -out root.crt

# csrs - certificate signing requests
openssl req -new -sha256 -key client.key -subj "/C=US/ST=KY/O=Org/CN=client" -out client.csr
openssl req -new -sha256 -key server.key -subj "/C=US/ST=KY/O=Org/CN=localhost" -out server.csr

# certificates
openssl x509 -req -in client.csr -CA root.crt -CAkey root.key -CAcreateserial -out client.crt -days 100000 -sha256
openssl x509 -req -in server.csr -CA root.crt -CAkey root.key -CAcreateserial -out server.crt -days 100000 -sha256

Configure TLS certificates in Grafana Mimir

Every gRPC connection between Grafana Mimir components supports TLS configuration as specified in server flags and client flags.

Server flags

You can set the cipher suites and minimum TLS version that the server will accept:

-server.tls-cipher-suites: Comma-separated list of cipher suites to use. If blank, the default Go cipher suites is used. Possible values, from https://pkg.go.dev/crypto/tls#pkg-constants:
- TLS_RSA_WITH_RC4_128_SHA
- TLS_RSA_WITH_3DES_EDE_CBC_SHA
- TLS_RSA_WITH_AES_128_CBC_SHA
- TLS_RSA_WITH_AES_256_CBC_SHA
- TLS_RSA_WITH_AES_128_CBC_SHA256
- TLS_RSA_WITH_AES_128_GCM_SHA256
- TLS_RSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
- TLS_ECDHE_RSA_WITH_RC4_128_SHA
- TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
- TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
-server.tls-min-version: Minimum TLS version to use. Allowed values: “VersionTLS10”, “VersionTLS11”, “VersionTLS12”, “VersionTLS13”. If blank, the Go TLS minimum version is used.

The following server flag settings determine if a server requires a client to provide a valid certificate back to the server. The flags support all the values defined in the crypto/tls standard library.

For all values except NoClientCert, the policy defines that the server requests a client certificate during the handshake. The values determine whether the client must send certificates and if the server must verify them.

Use the following options to define the server certificate policy:

NoClientCert: The server does not request a client certificate.
RequestClientCert: The server requests a client certificate, but the client is not required to send it.
RequireClientCert: The server requests a client to send at least one certificate, but a valid certificate is not required.
VerifyClientCertIfGiven: The server does not require the client to send a certificate, but if it does, the certificate must be valid.
RequireAndVerifyClientCert: The server requires the client to send at least one valid certificate.

In the following example, both of the server authorization flags, -server.http-tls-client-auth and -server.grpc-tls-client-auth, are shown with the most restrictive option, which is RequiredAndVerifyClientCert.

    # Path to the TLS Cert for the HTTP Server
    -server.http-tls-cert-path=/path/to/server.crt

    # Path to the TLS Key for the HTTP Server
    -server.http-tls-key-path=/path/to/server.key

    # Type of Client Auth for the HTTP Server
    -server.http-tls-client-auth="RequireAndVerifyClientCert"

    # Path to the Client CA Cert for the HTTP Server
    -server.http-tls-ca-path="/path/to/root.crt"

    # Path to the TLS Cert for the gRPC Server
    -server.grpc-tls-cert-path=/path/to/server.crt

    # Path to the TLS Key for the gRPC Server
    -server.grpc-tls-key-path=/path/to/server.key

    # Type of Client Auth for the gRPC Server
    -server.grpc-tls-client-auth="RequireAndVerifyClientCert"

    # Path to the Client CA Cert for the gRPC Server
    -server.grpc-tls-ca-path=/path/to/root.crt

Client flags

You can configure TLS private keys, certificates, and certificate authorities in a similar fashion for gRPC clients in Grafana Mimir.

To enable TLS for a component, use the client configuration flag that contains the suffix *.tls-enabled=true, for example, -querier.frontend-client.tls-enabled=true.

The following Grafana Mimir components support TLS for inter-communication, which are shown with their corresponding configuration flag prefixes:

Query-scheduler gRPC client used to connect to query-frontends: -query-scheduler.grpc-client-config.*
Querier gRPC client used to connect to store-gateways: -querier.store-gateway-client.*
Querier gRPC client used to connect to query-frontends and query-schedulers: -querier.frontend-client.*
Query-frontend gRPC client used to connect to query-schedulers: -query-frontend.grpc-client-config.*
Ruler gRPC client used to connect to other ruler instances: -ruler.client.*
Ruler gRPC client used to connect to query-frontend: -ruler.query-frontend.grpc-client-config.*
Distributor gRPC client used to forward series matching a configured set to a dedicated remote endpoint: -distributor.forwarding.grpc-client.*
Alertmanager gRPC client used to connect to other Alertmanager instances: -alertmanager.alertmanager-client.*
gRPC client used by distributors, queriers, and rulers to connect to ingesters: -ingester.client.*
etcd client used by all Mimir components to connect to etcd, which is required only if you’re running the hash ring or HA tracker on the etcd backend: -<prefix>.etcd.*
Memberlist client used by all Mimir components to gossip the hash ring, which is required only if you’re running the hash ring on memberlist: -memberlist.

Each of the components listed above support the following TLS configuration options, which are shown with their corresponding flag suffixes:

*.tls-enabled=<boolean>: Enable TLS in the client.
*.tls-server-name=<string>: Override the expected name on the server certificate.
*.tls-insecure-skip-verify=<boolean>: Skip validating the server certificate.
*.tls-cipher-suites=<string>: Comma-separated list of accepted cipher suites. For the list of supported cipher suites, refer to Grafana Mimir configuration parameters.
*.tls-min-version=<string>: Minimum TLS version required. For the list of supported versions, refer to Grafana Mimir configuration parameters.

The following example shows how to configure the gRPC client flags in the querier used to connect to the query-frontend:

    # Path to the TLS Cert for the gRPC Client
    -querier.frontend-client.tls-cert-path=/path/to/client.crt

    # Path to the TLS Key for the gRPC Client
    -querier.frontend-client.tls-key-path=/path/to/client.key

    # Path to the TLS CA for the gRPC Client
    -querier.frontend-client.tls-ca-path=/path/to/root.crt