1221529 - Allow multiple owners to be associated with API credentials

Status: RESOLVED WONTFIX

Description

[Ed Morley (Away 13-16th and 18th Dec-1st Jan) [:emorley]]

At the moment the API credentials are tied to just one user (the user that requested them, though it can be updated by an admin to point at another user instead).

However some submitters want multiple people to be able to access their credentials - so at the moment the only solution is for them to create a shared persona account and have the credentials linked to that.

We should instead allow multiple owners (or at least "additional people who can access") for credentials.

Comment 1

[Ed Morley (Away 13-16th and 18th Dec-1st Jan) [:emorley]]

Henrik - Mauro and I were talking and we were slightly unsure as to the exact use-case here.

The things we could think of were:
1) Wanting multiple people to be able to view the credentials
2) Wanting to allow someone else to reset/regenerate the credentials in the case of PTO + credential leak

Now for #1, presumably these credentials are already stored in your own environment, so surely people could look them up there? However more importantly - why are they looking them up? If it's so people can copy and paste them to their local development environment - then we'd much prefer they create their own credentials (eg `mozauto_whimboo_testing`) rather than use the `mozauto` account used in production. (Similar to how we'd prefer multiple projects to not use the same credentials). This will help with accountability etc.

For #2, the user accessibly dashboard currently doesn't allow for resetting the credential (it's only on the admin panel), however we could add that if needed. However in the "the credentials owner is on PTO and another person on a project wants to regenerate the credentials" case - they could always ask a Treeherder admin to do it. Or is it a concern that it might be on a weekend or similar?

We're happy to try and make various use-cases/workflows easier - but without knowing the exact motivations, we may end up creating a suboptimal solution for them :-)

Thanks!

Comment 2

[Henrik Skupin (:whimboo) [away 12/05-12/16]]

(In reply to Ed Morley [:emorley] from comment #1)
> The things we could think of were:
> 1) Wanting multiple people to be able to view the credentials
> 2) Wanting to allow someone else to reset/regenerate the credentials in the
> case of PTO + credential leak
> 
> Now for #1, presumably these credentials are already stored in your own
> environment, so surely people could look them up there? However more
> importantly - why are they looking them up? If it's so people can copy and
> paste them to their local development environment - then we'd much prefer
> they create their own credentials (eg `mozauto_whimboo_testing`) rather than
> use the `mozauto` account used in production. (Similar to how we'd prefer
> multiple projects to not use the same credentials). This will help with
> accountability etc.

In our case it would be all for the same project. And in case one of our systems has a fallout everyone could simply check for the client id and secret to set it up again. Keep in mind that most people might store it at an unsafe location on the local disk, so it's still more secured in Treeherder itself.

> For #2, the user accessibly dashboard currently doesn't allow for resetting
> the credential (it's only on the admin panel), however we could add that if
> needed. However in the "the credentials owner is on PTO and another person
> on a project wants to regenerate the credentials" case - they could always
> ask a Treeherder admin to do it. Or is it a concern that it might be on a
> weekend or similar?

The fallback to the treeherder team would always be there, right. But not sure if you always want to manually do those tasks. With the current feature set of Treeherder there might be not such a great need for it compared to Pulseguardian where you have to manage queues. So it can have lower priority.

In general we want to make it easier for all of our team members to take over maintenance work in case the default maintainer is not around.

Comment 3

[Ed Morley (Away 13-16th and 18th Dec-1st Jan) [:emorley]]

Wontfix given we're removing the ability to submit jobs via the API (bug 1349182).