spike: sd-admin VM via RPM

[conorsch]

This PR adopts the "admin-config" RPM spec file by @zenmonkeykstop in #1554. It also pulls in the simplified RPM build logic from #1565; therefore, #1565 should be reviewed and merged first.

Based on @zenmonkeykstop's work, I added an sd-admin VM based on Debian 13 Trixie. There's no grsec kernel or keyring package yet, but the securedrop-admin tooling is installed:

securedrop-admin help text

[conor@dom0 securedrop-workstation]$ qvm-run -p sd-admin "securedrop-admin --help"
usage: securedrop-admin [-h] [-v] [-d] [--force]
                        {sdconfig,install,localconfig,tailsconfig,qubesconfig,generate_v3_keys,backup,restore,check_for_updates,logs,reset_admin_access,verify} ...

SecureDrop Admin Toolkit.

For use by administrators to install, maintain, and manage their SD
instances.

positional arguments:
  {sdconfig,install,localconfig,tailsconfig,qubesconfig,generate_v3_keys,backup,restore,check_for_updates,logs,reset_admin_access,verify}
    sdconfig            Configure SD site settings
    install             Install/Update SecureDrop
    localconfig (tailsconfig, qubesconfig)
                        Configure either Tails or Qubes environment post SD install
    generate_v3_keys    
                        This method will either read v3 Tor onion service keys if found or generate
                        a new public/private keypair.
    backup              Perform backup of the SecureDrop Application Server.
                        Creates a tarball of submissions and server config, and fetches
                        back to the Admin Workstation. Future `restore` actions can be performed
                        with the backup tarball.
    restore             Perform restore of the SecureDrop Application Server.
                        Requires a tarball of submissions and server config, created via
                        the `backup` action.
    check_for_updates   Check for SecureDrop updates
    logs                Get logs for forensics and debugging purposes
    reset_admin_access  Resets SSH access to the SecureDrop servers, locking it to
                        this Admin Workstation.
    verify              Run configuration tests against SecureDrop servers

options:
  -h, --help            show this help message and exit
  -v                    Increase verbosity on output (default: False)
  -d                    Developer mode. Not to be used in production. (default: False)
  --force               force command execution without update check (default: False)
[conor@dom0 securedrop-workstation]$ 

The RPM setup reuses Salt state files between the two RPMs, but installs them to unique dest paths, ensuring both RPMs can be installed independently of one another, without triggering dnf conflicts. We can lean into this and port more of the pre-existing Salt config if we desire.

Towards #1507.

Test plan

1. Ensure that make clone && make dev passes without error
2. Run make sd-admin to configure the sd-admin VM; check that securedrop-admin CLI is installed within it.
3. Build the RPMs locally and run rpm -qlp <path> on them; inspect their file contents and ensure no conflicts or overlaps between them, because any duplication of dest paths will cause problems.

Checklist

This change accounts for:

• any necessary RPM packaging updates (e.g., added/removed files, see MANIFEST.in and rpm-build/SPECS/securedrop-workstation-dom0-config.spec)
• any required documentation

[micahflee]

This looks good to me. I haven't looked into why the GitHub checks aren't running/passing, and main needs to be merged into this branch still.

As far as the test plan:

1. make clone && make dev works without error
2. make sd-admin configures the sd-admin VM, and securedrop-client is installed and worked
3. after building the RPMs locally, I confirm that they don't have any conflicting files

After creating sd-admin, I also went ahead and used it to install a SecureDrop server, and it works! One thing we might want to put some thought into is what tags to put on sd-admin, because the lack of copy/paste and file transfer made it very difficult at first to copy my ssh key into sd-admin. There might be various legit reasons the admin needs to use copy/paste and to transfer files.

[legoktm]

For the CI checks, the PR just needs to be rebased on top of main to pick up the new names.

[conorsch]

One thing we might want to put some thought into is what tags to put on sd-admin, because the lack of copy/paste and file transfer made it very difficult at first to copy my ssh key into sd-admin. There might be various legit reasons the admin needs to use copy/paste and to transfer files.

Great call. I took a look at the diff, and I don't see an easy answer here: nowhere do we authorize the use of sd-dev which is explicitly a development VM, nor should we start here; we also can't know what source VM the Admin will use for such copying—but we can certainly recommend it. Absent an obvious immediate solution, I've opened #1578 for further discussion, and left the changeset in this PR as-is: the clipboard access issue remains.

For the CI checks, the PR just needs to be rebased on top of main to pick up the new names.

Done: all CI checks are now passing.

[zenmonkeykstop]

https://workstation.securedrop.org/en/stable/admin/reference/managing_clipboard.html shows how optional copy/paste config (vault to sd-app) is handled, that logic can probably be adapted for this case.

[legoktm]

I'm slightly concerned about having this be enabled by default just because in the past we've worked hard to avoid having things that get built but intentionally discarded; we're at the point that it should be a blind thing that you just copy all the packages that get built to apt/yum repo (especially once we have CI do it) and I'd like to preserve that.

RPM makes it easier to have conditional builds, could we try adding %bcond_with admin so that builds need to have --with=admin to include that RPM? And then a separate make build-rpm-admin target.

[conorsch]

Heard. I didn't get to this today, but I'll adjust the logic to ensure that the new RPM is off-by-default for both building and installing.

[conorsch]

Alright, I rewrote the RPM build logic to use %bcond. It's a significant enough change to the PR to require a full re-review.

There's still a bit of non-DRY duplication in the shell scripts that build the RPM, but I feel that's warranted here during the WIP phase, to ensure that the pre-existing logic for building the securedrop-workstation-dom0-config remains completely separate from the new logic for securedrop-admin-dom0-config. If folks disagree, we could easily toggle the --with admin flag to be conditional on an env var. Given the state of the spike, I suggest we punt on reconciling the duplication until we're ready to build and host the package somewhere like yum-test.

Ready for re-review, @micahflee!

[legoktm]

Alright, I rewrote the RPM build logic to use %bcond. It's a significant enough change to the PR to require a full re-review.

Thank you!

There's still a bit of non-DRY duplication in the shell scripts that build the RPM, but I feel that's warranted here during the WIP phase, to ensure that the pre-existing logic for building the securedrop-workstation-dom0-config remains completely separate from the new logic for securedrop-admin-dom0-config. If folks disagree, we could easily toggle the --with admin flag to be conditional on an env var. Given the state of the spike, I suggest we punt on reconciling the duplication until we're ready to build and host the package somewhere like yum-test.

Sounds good but also I think the bar to enable --with=admin for the CI nightlies that end up on yum-test should be pretty low, so even if this isn't resolved by that point, whenever having nightlies will be useful, we should just do it.

addressed

[micahflee]

I tested again and everything works great. I built both RPMs and compared them, and they still don't have any overlapping files.