Container-based OS - user configuration story

[msheiny]

Feature request

Description

As of SecureDrop 0.4.4, we depend on an ansible bootstrap workflow
in order to inject user configuration bits onto both mon and application
servers. With the move to CoreOS (or possibly another container-focused OS)
we'll need a story surrounding where we store these bits of information and
better-yet how we get this data onto the host OS in the first place.

CoreOS has their distributed key-value store,
etcd, for sharing configuration between
machines but it looks too complex for our single-machine use-case. I'd prefer
to have a directory of yaml files, that are mounted into the relevant
containers.

A few possible ways to get user data on there (not a comprehensive list, feel
free to suggest anything I missed):

• a small local network facing web-app - will have basic web-forms to
  manipulate data that goes into the configuration files for other containers to
  read. This seems the most user friendly and in-line with what other appliances
  do.
• ansible playbook run - similar to what we have now, the end-user would have an
  admin stick where they are prompted for user parameters and those are run
  through ansible and slapped into place on the CoreOS host. I'm honestly not a
  huge fan of this method, people often lose or misplace the stick because they
  rarely use it and we are requiring full ssh just to drop a few files.
• manual manipulation of yaml config - this is problematic because we are
  relying on users to ssh in, read the docs for correct syntax, and then utilize
  a terminal editor. As we try to make securedrop more of a guard-rail type
  experience (prevent the user from hurting themselves), this is a bad strategy.
• console onto server, run CLI config tool - similar to the idea above except the
  user would run a guided tool for input of parameters. I like this because it
  kills the need for SSH staying open and provides rails. Obviously the physical
  access can be problematic for some admins and I'm also not sure we should
  really mandate console access just for configuration updates.
• ssh onto server, run CLI config tool - like the console method but with ssh
  access. not a horrible idea not sure how the team feels about our security
  model when it comes to SSH on this green-field project. on 0.4.4 we mandate
  SSH over tor which seems silly if you just want to restrict traffic to a
  single local network. We could also tightly control the commands allowed over
  SSH and throw the users into a special shell that allows limited system
  access.

One of the biggest things to avoid with any configuration lay-out is to avoid
the current perdicament when it comes ot updating the config.py file. See
specifically issue #1966 - which outlines problems attempting to update the
current configuration via ansible. So keep in mind whatever lay-out needs an
update method to be able to add additional key/values when the code-base is
updated.

User Stories

As a securedrop administrator, I want to be able to easily configure and update
securedrop settings.

As a securedrop developer, I'd like user configuration to be stored in a central
location that allows future updating of schema paramters.

As a securedrop support provider, I want configuration updating to be
relatively straight-forward and provide guard-rails/sanity checking so users can can't
blow up the appication accidentally.

[heartsucker]

so users can blow up the appication accidentally.

Found the fed.

[msheiny]

Found the fed.

[squeed]

How is it managed right now? The easiest thing to do is keep the configuration file on-disk and bind-mount it in to the application container. Easy enough.

[eloquence]

We've not made a final commitment to a container-based OS in general or CoreOS in particular. We'll re-evaluate our options after the transition to Ubuntu 20.04 is complete (#4768). See #5517. Closing this old issue and retiring the associated label for now.