Adopt dedicated secrets management library #2728

[phillxnet]

Adopt password-store by Jason A. Donenfeld of wireguard fame as our base OS password store; under the root user. Employ as backed to python-keyring via adaptor shim keyring-pass. Enabling lightweight/secure (via GPG encryption) secrets management from both an OS level and from within our Python Poetry venv.

Includes:

• Keyring-pass additional dependency, with secondary dependency on python-keyring.
• ExecStartPre additions to initialise GNUPG, pass, and rotate/generate Django's SECRET_KEY.
• PASSWORD_STORE_DIR environmental variable in all main rockstor systemd services.
• Add Django's new-in-4.1 SECRET_KEY_FALLBACKS setting.
• Incidental update to cryptography: 41.0.5 to 41.0.7.
• Incidental update to idna: 3.4 to 3.6.
• Set CLIENT_SECRET in keyring via initrock.py, and maintain as install instance persistent. Set only during db initialisation, or if it does not exist: i.e. updating from pre keyring install.
• Get CLIENT_SECRET (settings.py) from keyring.
• Update build.sh with developer instructions re GnuPG & pass.
• Incidental addition of Poetry 1.2 style dev dependencies group, with the addition of black as an optional install.
• Incidental black re-format of initrock.py
• Simplify logging within initrock.py.

[Hooverdan96]

does it have to be in the root directory? Or would it be better to also have it somewhere below the /opt/rockstor tree to be part of the Rockstor package "boundaries"?

[phillxnet]

@Hooverdan96 Thanks for the interest here, I'll answer piece-meal:

does it have to be in the root directory?

No.

Or would it be better to also have it somewhere below the /opt/rockstor tree to be part of the Rockstor package "boundaries"?

No, and my reasoning here is that the most secure location on the "/" system is /root at least with the default fs arrangement, we also use this (our) users gpg (GnuPG) key (generated via the new rockstor-pre.service additions) to encrypt these passwords (or 'pass' does it for us anyway). Plus we currently run under this user. So just a security thing really. If in /opt/rockstor or any other user home (with default group setting for users) other users can at least get to the parent directly. We will likely revisit these locations and concerns when we approach: #2700
as at that time we ourselves will not be able to access /root. But there is likely always going to be a need for us to assume root at some point (but likely through specific capabilities) but again, this can be approached as we consider the dedicated user issue. But this is not on the Milestone for our coming stable release.

For now I'm trying to use defaults of the user we run under and for pass this is it for the 'root' user, which we are currently. But as we are in the constrained env of systemd it needed to be re-established.

[phillxnet]

Another element here, given it's all default for the 'root' user is that one can interact easily via the pass command when simply logged in as root. I.e.:

lbuildvm:~ # pass
Password Store
└── python-keyring
    └── rockstor
        ├── CLIENT_SECRET
        └── SECRET_KEY

Is what the code here creates on first services start / first boot/install.

[phillxnet]

And on subsequent (second in this case) reboots we get our current stable/full set of:

lbuildvm:~ # pass
Password Store
└── python-keyring
    └── rockstor
        ├── CLIENT_SECRET
        ├── SECRET_KEY_FALLBACK
        └── SECRET_KEY

Making use of Django's 4.1 onwards fallback mechanism to smooth over CLIENT_SECRET signing key rotation. Which we now do in this branch on every 'cycle' of rockstor-pre.service by renaming SECRET_KEY to SECRET_KEY_FALLBACK each service start and creating a new SECRET_KEY: thus honouring the current and last in-play SECRET_KEY. Hopefully allowing for a smoother transition and less failed sessions. But also maintaining a robust key rotation.

[Hooverdan96]

Good stuff!

[phillxnet]

Moving to squash and represent given the testing of this and the partnered/linked rockstor-rpmbulid repo PR:
rockstor/rockstor-rpmbuild#54

See comments of above for details.