Add possibility to configure API keys with environment variables

[agodard]

Description
As a cloud developer, I love using Meilisearch in my kubernetes cluster with the dedicated Meilisearch helm chart. I use terraform to set up and configure all my infrastructure and lack the possibility to easily setup Meilisearch API keys with it.
I'm currently using a hack to send HTTP requests to my Meilisearch instance through terraform but it requires my VPN to be active in order to access it. I would love to configure Meilisearch API keys with Environment variables or kubernetes secrets to fix it.

Basic example
A quick update would be to set up Default Search API Key and Default Admin API Key directly by environment variables :

resource "helm_release" "meilisearch" {
  name        = "meilisearch"
  repository  = "https://meilisearch.github.io/meilisearch-kubernetes"
  chart       = "meilisearch"
  version     = "0.1.44"
  namespace   = "default"
  timeout     = 200
  max_history = 3
  set {
    name = "environment.MEILI_ENV"
    value = "production"
  }
  set {
    name = "environment.MEILI_MASTER_KEY"
    value = "masterkeyexample"
  } 
  set {
    name = "environment.MEILI_DEFAULT_SEARCH_API_KEY"
    value = "defaultsearchapikeyexample"
  } 
  set {
    name = "environment.MEILI_DEFAULT_ADMIN_API_KEY"
    value = "defaultadminapikeyexample"
  }

A more advanced configuration would allow us to configure any API key from environment variables or kubernetes secrets :

resource "helm_release" "meilisearch" {
  name        = "meilisearch"
  repository  = "https://meilisearch.github.io/meilisearch-kubernetes"
  chart       = "meilisearch"
  version     = "0.1.44"
  namespace   = "default"
  timeout     = 200
  max_history = 3
  set {
    name = "environment.MEILI_ENV"
    value = "production"
  }
  set {
    name = "environment.MEILI_MASTER_KEY"
    value = "masterkeyexample"
  }
  set {
    name = "environment.MEILI_API_KEYS"
    value = jsonencode([
      {
        name:"XXX Search API Key",
        description:"XXX use it to search from the frontend",
        key:"somesearchapiexample",
        actions: ["search"],
        indexes: ["*"],
        expiresAt: null
      }
    ])
  }
}

Other
I have found an other issue which could benefit from it : meilisearch/meilisearch#605
It would also greatly help users using infrastructure as code to follow best practices regarding master key and API keys : #443

[dureuill]

Hello, @agodard 👋

Thank you for this feature request, the use case is well articulated!

Unfortunately, it is my understanding that the value of an API key is currently derived from the Master Key, so it is unclear to me how much of a change to the security model and its implementation your proposal entails.

The current scheme allows for the mass revocation of API keys simply by changing the Master Key. It also makes it impossible for a malevolent user who would have found a database or database dump to find back the Master Key (which is never stored in the database or any dump) or any API key (since only their UUID is stored and the value is derived at runtime from the UUID + the Master Key). An unfortunate side-effect of having the keys hard to guess before runtime and adding the Master Key is that... the keys are hard to guess before runtime.

My understanding is that you'd like to have the possibility to eschew the native Meilisearch API Key-derived-from-Master-Key scheme and provide all secrets from the infrastructure. Is that correct?

Am I correctly identifying that the pain point is having to send HTTP requests to a running Meilisearch instance to fetch the API keys "early" in your setup? If so, would a local command line utility that would accept a Master Key + UUID and return the corresponding API key be an effective way of addressing this pain point? Not saying this is necessarily a good solution (we may want to limit the number of CLI utilities we provide) but just exploring a bit the problem space to see what alternatives we have.

Thank you again for your feature proposal!

[agodard]

Hello @dureuill,

Thank you for your interest in my demand. Unfortunately, I didn't know that the value of API keys was derived from the master key.

As you understood it, a solution would be to change the native Meilisearch API Key-derived-from-Master-Key scheme in order to provide keys from the infrastructure.

The pain point is having to create and maintain the API keys manually from Terraform providers without a dedicate way to provide them from the ground up or and easy way to configure and retrieve them to pass it to other applications. I will continue managing them from the HTTP API for now. The null_ressource Hashicorp provider will help me managing them after the instance startup and then store it in a Kubernetes secret to avoid sending HTTP requests each time I update my infrastructure from Terraform.

[gmourier]

Hey @agodard 👋

For your information, we added the API key derivation from the master key to have a deterministic API Key if needed (related to continuous deployment needs). See #421. If you deploy an instance with the same master key and the same uid field for the API keys you can keep the exact same key.

Just to be sure, the HTTP API is not accessible because the VPN is inactive? Is it problematic to have it started and accessible right away to ease your workflow?

Could you explain a bit more about why you do this K8S deployment regularly?

Thank you!