1687813 - Please create a Kinto account named "related-realms-publisher"

Status: RESOLVED FIXED

(Cloud Services :: Server: Remote Settings, task)

Description

[Tim Giles [:tgiles]]

The password manager team wants to utilize Apple's open sourced "websites-with-shared-credential-backends" data to improve the password manager experience. This will require a Kinto account named "related-realms-publisher" in order to automate the publication of any upstream changes to the shared credential data.

Thanks!

Comment 1

[Sven Marnach :sven]

Did you already have an rapid risk assessment with the security team? We usually require that all changes to Remote Settings are signed by two humans; if you want to automate one of the steps, please talk to :arroway.

Comment 2

[Mathieu Leplatre [:leplatrem]]

Quick precision: we usually require one editor and one reviewer to sign the changes.

(Note for :arroway: this use-case is exactly the same as fxmonitor-breaches, some data is pulled from Github with a script/cronjob and a human approves)

Comment 3

[Tim Giles [:tgiles]]

Looks like I was not as clear as I thought, thanks :leplatrem for the clarification! The intended case of this account is to pull data from Github and have a script/cronjob submit a review request to Remote Settings, then have that data reviewed by the editors/reviewers on the password manager team. I want to be able to automate the review creation process, so apologies about the confusion!

Comment 4

[Mathieu Leplatre [:leplatrem]]

Yes, that's exactly what I had in mind, the script pulls the data from Github, updates the records on the writer instance API, and toggles the status field to request a review. An email is sent to the reviewers group and they can login on the VPN, review the changes, and approve them.

In the collection definition, I added you and :dlee as editors too (in addition to account:related-realms-publisher). That means you could technically also edit the records on the admin UI and request a review. And of course, the server won't let you approve your own changes.

Comment 5

[Stephanie Ouillon [:arroway] (needinfo me)]

Hi,
sorry for the delay, and thank you for the clarifications in the meantime. From your last two comments, this change sounds fine.
However (and that's why I was delayed in replying), I can't seem to find a RRA for Remote Settings. Would anyone of your team remember if one was actually done? If not, I'd be interested in hosting one to get an overview of the way Remote Settings currently works.

Comment 6

[Sven Marnach :sven]

Remote Settings was designed in collaboration with the secops team long before I joined. I don't know the specifics, since it's all far too long ago, and I can't find any documents or Mana pages that would be relevant. We should either find the relevant documentation, or start writing it ourselves, and it may certainly make sense to start this process soon, but that's kind of off topic for this ticket. I'll start a new discussion in a separate ticket.

I gather that nobody has concerns about adding this bot user, and I agree with that assessment – it's the same we do in the case Mat mentioned, so I consider this approved now, and will go ahead and create the account.

Comment 7

[Sven Marnach :sven]

There is one more caveat: We generally won't hand out passwords for bot accounts to people outside of the Services Ops teams. So if you want to automatically update the collection, we need to manage and run that job for you. We need to discuss how much work this will be for us, and if and when we have the resources to do that. It sounds like this job could be some simple job we run every day on our Jenkins instance, in which case this should be relatively quick and easy, but we should meet and discuss the specifics.

All other jobs writing directly to remote settings are also managed by either Services Ops or Data Ops, including the job updating the fxmonitory-breaches collection that Mat mentioned.

Comment 8

[Mathieu Leplatre [:leplatrem]]

Tim, what would be ideal for you? Are you ready to work on the client side?

Based on your feedback, we can use your request as an incentive to start writing down that document, or we can proceed and parallelize stuff.

Comment 9

[Tim Giles [:tgiles]]

There are still some implementation details I have to figure out on the client side script, so I don't need the account created immediately, but yeah I believe I'm ready to work on the client side

Comment 10

[Sven Marnach :sven]

Since there aren't any big open questions, I'll go ahead and create the accounts in stage and prod. For testing purposes I can give you the password of the stage account once you need it.

Comment 11

[Tim Giles [:tgiles]]

Sounds great, thanks for the help Sven!

Comment 12

[Sven Marnach :sven]

I've created the accounts and stored the credentials in our vault. Let me know when you are ready to test this, so I can send you the password for the stage env.