Security concerns

[charlesreid1]

When we run mkdocs build with Uncle Archie, there is no real security concern, barring an mkdocs bug that allows remote code execution.

However, some Uncle Archie tasks are running Snakemake, which can run shell commands. This renders Uncle Archie (and the server that runs it) open to attack by a malicious Github "contributor" who opens a pull request with a modification to the Snakefile that dumps all the secret keys into the htdocs directory.

For this reason, we need to implement the following:

• Github source IP address checks (already implemented but not turned on in the config file). Disable when testing.

• Webhook secrets (already implemented and activated)

• Detect when certain files have been changed (e.g., Snakefile) and require whitelisted users to trigger/kick off a build if those particular files have changed

  • Optimal tradeoff between automation and security

  • Also need to send pull request comment webhook events

  • Keep it simple: don't introduce asynchronicities

  • Mark commit as failed if a Snakefile has been modified by non-whitelisted user

  • If whitelisted user comments go go uncle archie that will trigger uncle archie to build the prior commit (and only the prior commit). If the build succeeds, it will change the status of the commit from fail to success.

[charlesreid1]

Something we forgot to mention here but is also a concern with hosting the output of the mkdocs build step: if we are building the internal site, we don't want a bunch of copies of the internal site to be publicly available via archie.

We protect the htdocs build URLs.

This requires a more consistent URL scheme for htdocs output, so that we can easily and consistently filter any traffic going to the actual hosted documentation and password-protect it.