Variables that are environment specific - API key for the Meteor users (ex: Administrator) about bugzilla-customisation HOT 23 CLOSED

When I deploy, I test the Meteor front end works by creating a new user. If it doesn't, it's typically due to the BUGZILLA_ADMIN_KEY not matching with Bugzilla.

If it doesn't, I regenerate an API key in Bugzilla and update BUGZILLA_ADMIN_KEY in AWS parameter store (aka ssm) and re-deploy Meteor front end.

from bugzilla-customisation.

@kaihendry that's clever but why not generate a totally new API key each time we do a deployment then? This would have the same result with the added benefit of having a different API key for each envo

from bugzilla-customisation.

Generating an API key with Bugzilla is manual. It should be static once it's there. I don't see why it should change.

from bugzilla-customisation.

Unless I am missing something there the API key for the admin user for the DEV and PROD environment should be secret or else anyone with this API key could wreak havoc in these envos.

If we have dockers using the same API for the admin user each time an envo is deployed then we need an additional step in the DEV and PROD: change the default API key to something that is not public.

Generating random API key each time we deploy a new envo should eliminate this step right?

from bugzilla-customisation.

The BUGZILLA_ADMIN_KEY is not public. It's a secret, maintained in AWS's secure store that's derived by the environment setting step:

• https://github.com/unee-t/bugzilla-customisation/blob/master/aws-env.prod
• https://github.com/unee-t/bugzilla-customisation/blob/master/aws-env

from bugzilla-customisation.

The BUGZILLA_ADMIN_KEY is visible in the database for each user in the table 'user_api_key' too.
Anyone with access to the database can see all these keys.

from bugzilla-customisation.

I thought there there was one global key set by the administrator.

I assumed this key would be hidden from users. If users are expected to work on their individual keys then I think this will get messy indeed.

from bugzilla-customisation.

API keys are set individually by/for each BZ user. This is how BZ knows which permissions and privileges are granted to the user that is making an API call.
A BZ user can have several API keys too.
Administrator is a BZ user and behave as any other users as far as API keys are concerned.

from bugzilla-customisation.

Oh, I didn't realise it was like that. I guess in that case Meteor needs to generate and store the API key itself? cc @nbiton

For the purposes of a prototype I was hoping we could get away with an administrator account and then perhaps move away from Bugzilla. Fine grained permissions surely aren't required for a MVP?

from bugzilla-customisation.

We need to see how it could be done via the REST API

from bugzilla-customisation.

@kaihendry "Fine grained permissions surely aren't required for a MVP?"

Fine grained permission is an absolute must have for the MVP unfortunately

from bugzilla-customisation.

@nbiton "We need to see how it could be done via the REST API"
It looks like a chicken and egg story for the administrator user: you need an API key so you can use the REST API
For the other users it might be possible to use the REST API and the API key for the administrator to create the API key for the newly created BZ user (not too sure about that).

This should not be critical for the MVP though as all the users will be first created manually in both systems so we can work around that somehow...

But making sure that the API key for the Administrator user is correctly protected and not unintentionally exposed to the world is a must have for the MVP though.

from bugzilla-customisation.

I think there's no way going around the Admin key being in the SQL database, as that's the only source of "truth". If anyone has direct access to the DB, he could manipualte anything anyway. On the MEFE side, it is stored as an env variable which is protected by the AWS creds.
The part about generating API keys for each individual user to be used for the requests sent by MEFE is what I was referring to when I said we need to check how it can be done via the API. Currently, we're storing only the user creds and API tokens on the MEFE side for making the requests.

from bugzilla-customisation.

"I think there's no way going around the Admin key being in the SQL database"
I totally agree with that and this is why it is important that this key is not the same across every installation. If this is the case then you can just lift the API key for the administrator from one of the dev environment and use it to access any other envo as adminitrator (inculding the production) using this API key.

from bugzilla-customisation.

As far as I can tell, BZ is generating a unique key on every new installation, so I don't think this would be an issue

from bugzilla-customisation.

"As far as I can tell, BZ is generating a unique key on every new installation"
Unfortunately and as far as I understand it this is NOT the case for API Keys for BZ users.
API key have to be generated by the BZ user AFTER the user is created.
This is done in the BZ "preferences" menu in the BZ interface.

from bugzilla-customisation.

Just testing this morning on d7577e9, where my demo.sql.gz doesn't set an API at all.

When trying to generate one, I get a "no sender" error.

Working around the issue by adjusting Email parameters to "nomail"

from bugzilla-customisation.

"Just testing this morning on d7577e9, where my demo.sql.gz doesn't set an API at all."
This is correct. The current demo.sql.gz does not set the user_api_key for the administrator.

The reason I did not set this in the demo.sql.gz file is because the user API key for the administrator should be environment specific.

The "no sender" error is due to a missing parameter in your environment.
You need to configure the maintainer email address and the mail delivery method for this to work.

Adjusting Email parameters to "nomail" is not a workaround but a valid solution if you choose to leave the email configuration parameters blank.

Email parameters can be configured in adminstration >> parameters >> emails.

from bugzilla-customisation.

How is "no sender" configured and what should it be for local env?

from bugzilla-customisation.

it's configured in the local-params.json file
For local env
line 51 should read
"mail_delivery_method" : "Test",

from bugzilla-customisation.

Is this bug done? What's outstanding? The logic to handle more granular API keys?

from bugzilla-customisation.

The reason I did not set this in the demo.sql.gz file is because the user API key for the administrator should be environment specific.

IIUC demo.sql.gz is only used for local development. I.e. to get Frontend developers up and running as quickly as possible. Currently the manual steps of generating the [email protected] API key and setting BUGZILLA_ADMIN_KEY costs precious time and creates barriers to entry.

Could there please be a default Administrator API key set in demo.sql.gz

from bugzilla-customisation.

Environments variables are described in AWS Systems Manager Parameter Store.

#!/bin/bash

if test "$2"
then
        echo aws --profile $1 ssm get-parameters --names $2 --with-decryption --query Parameters[0].Value --output text
        aws --profile $1 ssm get-parameters --names $2 --with-decryption --query Parameters[0].Value --output text
else
        aws --profile ${1:-uneet-dev} ssm describe-parameters
fi

from bugzilla-customisation.