lib.ec.secret_store: Add and use framework #146
Loading…
Reference in a new issue
No description provided.
Delete branch "jan/feature/20261017-lib-ec-secret-store-add-and-use-framework"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
lib.ec.secret_store: Add and use framework
jw-pkg secrets installcopies secret material from a GPG-encrypted tar archive to dotenv.jw-secretfiles on a target host. This commit refactors the underlying code and adds hooks for the inverse copy direction, and for more secret sources and targets.The peers between which secrets are copied are represented by the new abstract
secret_store.Base class, and the existing tar blob and host storages, inheriting from that class, are TarGpg and KvFile. Moreover,secret_store.Base is inheriting from FileContext, so all ofjw-pkg's file-like operations are available as hooks.Secrets inside instances of two file contexts are addressable as (targpg|kvfile)://target.host.com/path/to/file.conf.jw-secret. The on-host KvFile will look either locally or via SSH for that file, and TarGpg will look inside a tar archive specified in the
JW_SECRETS_TARGPG_TARenvironment variable.Uris with these schemas can be passed to
FileContext.create(), which will return a chrooted file context of the correct type.KvFile.stat(``/path/to/file.conf.jw-secret).ftype isFT_SECRETwhich inherits fromFT_COMPOUND- which means thatreaddir()works on such animals. Not entirely sure if that's a good idea, but it feels pretty generic. Let's see where that takes us.DistroContext.install()after this refactor reads its source through the store interface and writes the landing through the KvFile store.Both secret stores are exercised through the existing unit test of
jw-pkgsecrets install, and unit tests for both stores are also added by this commit."jw-pkg secrets install" copies secret material from a GPG-encrypted tar archive to dotenv .jw-secret files on a target host. This commit refactors the underlying code and adds hooks for the inverse copy direction, and for more secret sources and targets. The peers between which secrets are copied are represented by the new abstract secret_store.Base class, and the existing tar blob and host storages, inheriting from that class, are TarGpg and KvFile. Moreover, secret_store.Base is inheriting from FileContext, so all of jw-pkg's file-like operations are available as hooks. Secrets inside instances of two file contexts are addressable as (targpg|kvfile)://target.host.com/path/to/file.conf.jw-secret. The on-host KvFile will look either locally or via SSH for that file, and TarGpg will look inside a tar archive specified in the JW_SECRETS_TARGPG_TAR environment variable. Uris with these schemas can be passed to FileContext.create(), which will return a chrooted file context of the correct type. KvFile.stat("/path/to/file.conf.jw-secret").ftype is FT_SECRET which inherits from FT_COMPOUND - which means that readdir() works on such animals. Not entirely sure if that's a good idea, but it feels pretty generic. Let's see where that takes us. DistroContext.install() after this refactor reads its source through the store interface and writes the landing through the KvFile store. Both secret stores are exercised through the existing unit test of jw-pkg secrets install, and unit tests for both stores are also added by this commit. Signed-off-by: Jan Lindemann <jan@janware.com>