sealing /etc + config management integration

[cgwalters]

Dumping here a random idea I had the other day. As we continue on the path of sealing the system (making /boot readonly e.g.), I'd like to support doing this for /etc too.

For the "site specific ostree compose" case, it makes a lot of sense to do the config management on the server side. However for the "OS vendor golden image" case (e.g. Fedora Atomic Host), one thing I think would be cool is a mode where one can configure rpm-ostree to run a set of configuration management scripts.

In other words, in this model, /etc would only be written by e.g. ansible-playbook. Rather than the default /etc merge logic, every time we upgrade, we copy the defaults and rerun the playbook (or config management script). This hence means /etc is no longer subject to Hysteresis.

And further, I'd like to inject metadata from the playbook run, saying which exact git commit of ansible it came from. Something like:

# rpm-ostree status
● atomic-ws:atomicws/fedora/x86_64/continuous
             Version: 25.2017.95 (2017-03-22 13:12:15)
          BaseCommit: f26bcc53ecc820bf2c31ca744f165f2b2aeedd78e2ed45e8836b5633cdc833be
          ConfigMgmt:
              - ansible-playbook: git:cgwalters/ansible-personal@v2015.2-17-g319c5e8

[cgwalters]

I see this as an incremental step towards "fully sealed" systems, like "pure dm-verity". See also https://blog.verbum.org/2017/06/12/on-dm-verity-and-operating-systems/

[cgwalters]

For Fedora CoreOS we're going to use Ignition. It might be interesting to have Ignition support providing this metadata with the config. Some little bit of extra metadata in the JSON, and rpm-ostree could learn to pull that out of /var and render in status too.

[dustymabe]

do you mind providing a more complete proposal? I think I like it :) - basically what we are saying is that any changes to /etc/ have been defined by ignition configs and we otherwise seal /etc/ ?