Reduce the importance of masterKey

[brunoocasali]

The idea is simple and still raw, but I feel that the breaking changes will be massive!

This mindset is not new, but since we received this issue, it raises the concern that we could address or at least think of an upgrade path to it before the v1.

The issue points to an undesirable behavior that puts the masterKey and the data security in danger.
Since we do not warn or prevent the users from making bad choices about master keys, they can do things like this:

• using only masterKey to do everything, from search to index management.
• exposing masterKey in front-end environments.
• creating weak keys like 12345678 or even masterKey.

To change this behavior, we could take some actions to improve the security of the masterKey:

• Master keys do not make search requests anymore.
  • I wrote this because, in my understanding, having the possibility to expose Meili's instance on the front-end is the main reason the keys get leaked somehow (Algolia handles this key as the admin key).
• Prevent master keys to do search only in the front-end tools.
  • This is a sub-topic from the first one, but I believe it makes it harder to implement since it is not easy to know when a request came from where (and it would be harder to explain).
• Warn the user about the usage of masterKey in the Meilisearch logs.
  • This will imply that the developer can read/has access to the logs.
  • This will not prevent bad things happen.
• Disable "all the masterKey powers" only in the production environment.
  We accept everything during the development, but when things get deployed, we need to respect some security guidelines. In this case, we could prevent every action from being made using masterKey besides other key generations.

I'm ok with don't take real action to prevent the problems, but at least I think we should warn the user somehow, the docs do a great job but for me isn't enough.

Anyway, I'm open to discussing more the concerns about each possibility. Just let me know if this idea is too "crazy." 😄

[gmourier]

Hey @brunoocasali 👋

I agreed on this personally and it's surely not too "crazy".

Disable "all the masterKey powers" only in the production environment.
We accept everything during the development, but when things get deployed, we need to respect some security guidelines. In this case, we could prevent every action from being made using masterKey besides other key generations.

It seems to be a straightforward solution that is clear to understand, plus it could still be warned in the logs.

I wonder if we can't rely on the production or development env since I'm 100% sure users are running Meilisearch in production architecture with the development flag. We could maybe apply this restriction as soon as a master key is defined no matter the env.

A user that wants to develop in his local env is not forced to set a master key. As soon it enters a staging environment I expect a master key to be set which could be a good thing to have this restriction bound to the master-key presence or not.

Did I miss something in your opinion?

[brunoocasali]

Yes, I think this could work! :D

[bidoubiwa]

I know I'm late to the ship, I'm giving my opinion in case someone else agrees after the v0.28.

I'm very not convinced by the decision of limiting the masterKey for multiple reasons:

• It is counterintuitive as master implies access to everything.
• I'm not aware of another database that decided on the same behaviour (for example: the root in SQL).
• It adds a complex step in getting a Meilisearch up and running.
• We sacrifice ease of use for security purposes that I think shouldn't be our responsibility.
• A huge lot of demo's/tutorials/scripts using the master key will have to be updated or made obsolete.

And most importantly, because we cannot /keys/:name the user will have to a lot of processing to fetch its key.
Handling and using keys is not always done using the human eyes and by copy pasting manually. User might create processes to provide keys to other members working on the instance. Thus they'll have to create "hacky" scripts like the following:

const keys = await client.getKeys();
const key = keys.find(key => key.name === "Admin" );

Nonetheless, I am very happy that we have the field name! This code is better than the previous example showed here.

[gmourier]

The change explained here #443 (comment), initially planned for the v0.28 has been discarded due to raised issues by other teams that we won't treat now.

Cloud team concerns

Cons

The Master Key is currently used for every action on the SaaS. A new process must be implemented in case of changes.

If the master key is restricted, an API key must be used to perform all actions. Since API keys can be removed by a user using /keysendpoint, it's possible that the SaaS would have no key to perform the actions.

Solutions could be to create a dedicated key for the SaaS that cannot be removed.

• Should the default keys be updatable/deletable?

For now, the SaaS needs an unrestricted master key.

Pro

Master-key cannot be automatically changed in the SaaS, which means that if the user exposes it, they will have to shut down their instance or contact the SaaS team to make the change.

By forcing the user to use an Admin key instead of the Master key, in case of a leak, it would be very easy for the SaaS team to regenerate one.

Integrations Team concerns

Cons

A lot of work needs to be done in:

• Testing
• Getting started
• Playgrounds

Pros

• Implementation should not be an argument against design choices.

Possible DevRel concerns

Cons

• Most articles/tutorials/Demos use the master key in their tutorial to set up the environment, for example, to show how to add the documents as a step of the tutorial. They need to be all updated.

Pros

• It is a way better practice to push the user into using the Admin key than the Master Key.
• Implementation should not be an argument against design choices.

Overall User Experience subject

Cons

• A additional step is introduced, which could add complexity.
• master word implies full control and access.
• Other databases could have a master key with full access (needs to be explored and confirmed)

Pros

• Security is improved.
• description fields in the default API keys body explain to the user the risks and the use-case for each key.

---

Decision:

We will get back to it when an interface for the management of the keys is planned to evaluate corner cases.

In the meantime, a suggestion would be to push the guide on securing a Meilisearch instance in the documentation quick-start to let users know more easily that the master key should absolutely not be used on the client-side, and as little as possible.