Unify the api key used for `api/notify` with the new api keys

[dpsutton]

We have a user-provided api key for api/notify, allowing people to programatically hit the endpoints

• POST api/notify/db/:id
• POST "/db/:id/new-table"

The endpoints let users sync databases when they like, and do not require a user session token to do so. This mechanism was built a long time ago and is seeded in the env with a key of the user's choosing.

This endpoint is secured by an API key that needs to be passed as a X-METABASE-APIKEY header which needs to be defined in the MB_API_KEY environment variable

We added api keys to enable precisely this kind of interaction so we could deprecate and remove this feature.

Ideally we allow new api keys to hit these endpoints in 51, and log a warning if an old api key hits this in 51. And then in 52 remove the old api key in totality.

NOTE: there is one feature that the old style api key allows that the new ones do not: knowing what an api key before instance creation or without any admin action in the UI. To obtain a new style api key, you must log in with an admin account and get the secret key. The old key could be decided on beforehand and set at startup (MB_API_KEY=kittens java -jar metabase.jar).

[sansolovyov]

Why remove old api keys rather than unify them under the same mechanics?

[dpsutton]

The older style keys are set in the environment and cannot be disabled (absent restarting the process without the key in the env) nor do they have complexity requirements. They only allow access to the api/notify endpoints. The new keys are configured through the UI and allow api access to all routes. They can be rotated and revoked. They are seen once and then may be regenerated but not seen again.

I'm not sure what unifying the two means here.

[sansolovyov]

Just thought that ability to seed API key without looking at interface is quite useful. But given that you have to know serial DB id it doesn't seem that necessary after some thinking.

[amit-armis]

Why is the MB_API_KEY doesn't work for all endpoints? you documentation says it should @paoliniluis @piranha

MB_API_KEY
Type: string
Default: null
When set, this API key is required for all API requests.

Middleware that enforces validation of the client via the request header X-Metabase-Apikey. If the header is available, then it’s validated against MB_API_KEY. When it matches, the request continues; otherwise it’s blocked with a 403 Forbidden response.

[dragonsahead]

@amit-armis it's technical debt, we need to unify this as the title of the issue says

[amit-armis]

Do you know when this will be fixed? @paoliniluis @piranha i'm using the enterprise version, and this is essential for me.

My use case involves programmatically creating dashboards so that my on-prem customers don't have to configure them manually—my backend will handle it instead.

[dragonsahead]

@amit-armis if you’re a paid customer please contact support

[likeshumidity]

Another customer has requested this as well. Current Cloud workflow is customer has to send us their API key or we generate one and send via email which is less than preferred.