phillxnet
commented
1 year ago An alternative, but a little more complex/heavy-weight approach here, could be to 'standardise' on keyring: https://github.com/jaraco/keyring
The Python keyring library provides an easy way to access the system keyring service from python. It can be used in any application that needs safe password storage.
This library is more naively concerned with desktop associated keystores, i.e. from the README.rst again:
These recommended keyring backends are supported:
- macOS Keychain
- Freedesktop Secret Service supports many DE including GNOME (requires secretstorage)
- KDE4 & KDE5 KWallet (requires dbus)
- Windows Credential Locker
However we have also the option of:
Other keyring implementations are available through Third-Party Backends.
Among these indicated "third-party-backends" we have a potential candidate of:
- keyrings.cryptfile - Encrypted text file storage.
Where from the linked (in PyPi) GitHub homepage of this project we have:
https://github.com/frispete/keyrings.cryptfile#notes
You can avoid the interactive getpass() request for the keyring password by supplying kr.keyring_key = "your keyring password" before calling any other methods on the keyring. The following example shows a simple way to retrieve the password from an environment variable KEYRING_CRYPTFILE_PASSWORD, when present:
So all a little tricky as we ultimately have to have a de-crypt key (password) for any encryption we rely-upon such as the encrypted local file storage, but I like the idea that we could, without only superficial extensions, switch out the secrets backend used by keyring.
Maybe a half way step here is to at lease adopt the maturity of keyring, to gain our standard interface, and initially side step the tricky encryption requirement for interaction, i.e. entry of a decrypt secret (our host OS has no appropriate user logged in) and initially go with say: (again from https://github.com/jaraco/keyring#third-party-backends):
- keyrings.alt - "alternate", possibly-insecure backends, originally part of the core package, but available for opt-in.
PyPi page: https://pypi.org/project/keyrings.alt/ Homepage: https://github.com/jaraco/keyrings.alt
But:
Keyrings in this package may have security risks or other implications. These backends were extracted from the main keyring project to make them available for those who wish to employ them, but are discouraged for general production use. Include this module and use its backends at your own risk.
However this is the exact same scenario we face with the use of say python-dotenv: i.e. plain text passwords/secrets !!
But we can iterate to more advanced back-ends as we progress. But this route does seem like a lot of dependencies to move plain-text secrets from one file to another !! Suggestions welcome here. We are, after all, sitting on a base OS with all required options available: but we ultimately still need to open a keystore of some sorts automatically give we have no OS login as-such.
Hooverdan96
FroggyFlox
We have an ongoing need to centralise our secrets management. This need has more recently been highlighted within the following PR/Issue: "Update django-oauth-toolkit #2710" #2727 where we had need to establish a new means to maintain an install-persistent OAUTH_INTERNAL_APP client secret. As this function was deemed to be outside the scope of the linked issue/PR the proposal is being made in this issue. The temporary work-around in #2727 was to establish a per-boot/rockstor-bootstrap.service persistent secret. This however is inappropriate for such facilities as replication where we require install persistence for secrets.
Popular candidates would be:
Proposed initial focus would be our settings.py file.