From dae1f8897192e89931a4224b76b5768ae374394e Mon Sep 17 00:00:00 2001 From: Mathieu Leplatre Date: Tue, 12 Nov 2024 17:35:30 +0100 Subject: [PATCH] Update documentation about scheduled ingestion scripts (#699) --- docs/support.rst | 25 ++++++++++++++++--------- 1 file changed, 16 insertions(+), 9 deletions(-) diff --git a/docs/support.rst b/docs/support.rst index f5e14c41..78d67a9b 100644 --- a/docs/support.rst +++ b/docs/support.rst @@ -122,12 +122,12 @@ If it is a one time run, then you can run the script as if it was you: How do I automate the publication of records? (forever) ''''''''''''''''''''''''''''''''''''''''''''''''''''''' -If the automation is meant to last (eg. cronjob, lambda, server to server) then the procedure would look like this: +If the automation is meant to last (eg. cronjob, server to server) then the procedure would look like this: 1. Get in touch with us on ``#delivery`` ;) -2. Fork `this repo `_ as a base example -3. `Request a dedicated Kinto internal account `_ to be created for you (eg. ``password-rules-publisher``). Secret password should remain in a vault and managed by Ops. -4. Request the Ops team to run your ingestion job (`Bugzilla template `_) +2. Fork `this repo `_ as a base example (or `this Node.js one `_) +3. Rename the repo ``remote-settings-{collection-id}-updater`` +4. Request a deployment of your job `using this Bugzilla template `_ With regards to the script: @@ -147,20 +147,27 @@ With regards to the script: See :ref:`multi-signoff tutorial ` for more information about requesting and approving review. -With regards to the repository: +With regards to the Github repository: - MUST build a Docker container -- MUST have Github Webhook configured so that container gets redeployed on version tag - -We recommend the use of `kinto-http.py `_ (`script example `_), but Node JS is also possible (See `mdn-browser-compat-data `_ or `HIBP `_ examples). +- MUST give admin permissions to `Remote Settings SREs `_ +- MUST have version tag format ``vX.Y.Z`` .. note:: Even if publication of records is done by a script, a human will have to approve the changes manually. Generally speaking, disabling dual sign-off is possible, but only in **very** specific cases. - If you want to skip manual approval, request a review of your design by the cloud operations security team. + If you want to skip manual approval, you will have to request a review of your design by the cloud operations security team. + + They will need answers to the following points: + + - summary / context / problem statement + - data dictionary (name, private/public, comments) + - threat scenarios (what impact, what happens if...) + - `See more details `_ + For the threat scenarios, think of what would be the impact if bad/malicious data is published, in terms of product, integrity, availability (eg. perfs if 100000 items are published), etc... .. _duplicate_data: