Does the intent behind the QVM features feature () make it safe to add them to the Salt pillar?
Context
I am currently experimenting with a few different ways to target Salt states.
As part of doing that, I’ve added QVM tags to the Salt pillar. (I’m using @brian’s example – gist.)
Because I needed a value to hold a list, I’m also using QVM features in dom0. (And defining a space-separated string that I interpret as a list of VM names, like the AppMenu feature seems to do.)
In order to use that list from Salt, I added all QVM features to the pillar, with code that’s very similar to he one that extends pillar with QVM tags.
Question
I don’t see anything in the currently defined QVM features that I think should be kept out of pillar, so I’m adding all features to the pillar.
Am I missing something?
More generally: what is the intention behind QVM features, is it likely that some features (current or future) shouldn’t be published in the pillar?
The trade-off that I identify is: adding all features at once makes for (a smaller amount of) more general code; putting in pillar only the features I currently need requires more code and more maintenance but makes less assumptions about other features.
I don’t want to be over-optimizing for imagined security risks, hence my question about the intent behind QVM features. If they’re aready considered like “public” information as far as the corresponding VMs are concerned, then I’m less worried about about putting them all at once in the Salt pillar.
(Note: I’m broadly assuming that anything in the Salt pillar is visible to the VMs being managed, which might not be true, but my question about the intended use of QVM features still stands. )
@marmarek@unman Pardon the direct mention: I suspect this might not have been the best place to ask about development intent, but maybe it was only a bad time.
Do you have thoughts on including QVM tags and features to the Salt pillar, or thoughts about who might have some?
Using tags for this purpose has the same issue as features. They are both for Qubes usage and end-user usage. The Admin API will add tags that aren’t intended for users to modify, and we don’t know whether those Qubes-defined tags are sensitive.
It would be great to know whether Qubes will add any data to features or tags that shouldn’t be exposed to VMs through Salt. But it would be better to have a place to set attributes on VMs through admin CLI tools that only the end user controls.
Yep. I haven’t seen any feature or tag that was (to me) obviously an issue to expose to the VM. Most information I find can either be inferred from the packages installed in the VM, or from generic knowledge about what a default Qubes OS installation looks like.
I feel a bit uneasy about asking any kind of committment to not define new tags or features that should noy be exposed to the VM. The future is the future (that is essentially unknown), and it seems somewhat unfair to me to over-constrain the use of those tools.
On the other hand, I also feel uneasy about asking for new tools to be added for this specific purpose when features and tags do the job reasonably well.
So that leaves me keeping an eye on the features / tags that my VMs use and deferring any further decision to change on my side until such a decision MUST be made.
I’ve Salt’d exposing QVM features and tags in pillar (separately) so that I can make that a requisite in states/formulas that require it.
I haven’t packaged any of that yet, but it seems those would be simple packages with no dependencies themselves.
On the bigger picture I still need to validate my plan to package those and define them as RPM dependencies of packages that contain states that include/require them. That seems like a good approach to me in theory but I suppose I won’t be sure until I validate what it feels like to maintain in practice. I’ll drop a note here when I get there
To be fair, there is definitely a world where each formula that relies on a tag or a feature includes a state that selectively exposes that tag or feature in pillar. So that’s another avenue worth exploring if it becomes desirable to keep some of the Qubes OS-maintained information out the pillar. Maintainability trade-offs!
Another tangentially related aspect to keep in mind is the potential for naming conflicts. There, namespaces come to my mind immediately, and could be an alternative to creating entirely separate tools. If qvm-features and qvm-tags had a notion of namespace, most of the risks we’ve been identifying around exposing unwanted information in pillar when cutting that maintainabiltity trade-off potentially go away.
To be fair, there is definitely a world where each formula that relies on a tag or a feature includes a state that selectively exposes that tag or feature in pillar. So that’s another avenue worth exploring if it becomes desirable to keep some of the Qubes OS-maintained information out the pillar. Maintainability trade-offs!
How would the tag/feature selection state work? Would it require the end user to edit pillar data for this state after installing a dependent formulas?
Another tangentially related aspect to keep in mind is the potential for naming conflicts. There, namespaces come to my mind immediately, and could be an alternative to creating entirely separate tools. If qvm-features and qvm-tags had a notion of namespace, most of the risks we’ve been identifying around exposing unwanted information in pillar when cutting that maintainabiltity trade-off potentially go away.
Right, I have no desire for another tool. Namespace capabilities in features or tags would be great if it came with some guarantee that Qubes won’t create or remove data in user-defined namespaces.
Is the supported-service. prefix in features prior art? Since tags only support hyphen separators, could we (ab)use the dot separator to add a user-defined prefix to features right now? Then /srv/salt/_pillar/qvm_features.py could filter out non-user-defined features. What in Qubes, besides the qvm services functionality, cares about dot-separated prefixes in features?
Let me see if I can get some code out. Unless I’m missing something while thinking about this in abstract, it should be quicker to show than to describe in words.
I did some preliminary work on this today, and opened an issue to help you keep track of progress. (It may take me a little while to find the time to do it. )
Edit: I’ve opened a draft pull request that contains the two formulas so you can take a look now. There are no supporting files, README but I don’t doubt you’ll find your way browsing the code for now. The PR is linked in the issue.
This is fabulous. Thank you, @gonzalo-bulnes! I incorporated these into my Salt files and they work as we expect. It will be great to seamlessly migrate to the RPM versions.
I’m obviously motivated to help with packaging the new formulas. And I’d love to learn RPM packaging. Maybe I’ll find time before you do
I’ve set up packaging for the qvm-features-in-pillar formula! And I forgot adding a direct link in the README next time.
The packages are not reproducible, so I don’t really recommend anyone to get the package that I’ve published for my own use, because there is little way to confirm it’s been built from the source you see in GitHub (unless maybe if you’re very familiar with the internal structure of an RPM package and can make sense of a diffoscope report, at this point I can’t.)
However, with the setup done, creating the packages yourself can be as straightforward as (eighteen steps follow ):
add a signed tag so that the packaging tooling can verify the integrity of the sources (you’ll see mine gb_8e1f8f82 there, so it’s all about creating a similar one locally that’s signed with a key you control, see below for how to do that)
set a few (simple) environment variables (same README)
run make packages
If you want to test the package in a dispVM:
make sure RPM knows about the signing (public) key for the purpose of verifying signatures: sudo rpm --import <mykey.gpg>
install the package you’ve just built: sudo dnf install ./qubes-mgmt-salt-user-qvm-features-in-pillar-1.0.0-1.noarch.rpm
confirm that /srv was populated as expected
Once in dom0, don’t forget that:
user directories are assumed to be enabled (see below if needed)
the package installation will overwrite /srv/user_salt/qvm-features-in-pillar
top files need to be enabled, this one is no exception: sudo qubesctl top.enable qvm-features-in-pillar
The qvm-tags-in-pillar packaging setup is done as well, and this time the package should be reproducible, or very close to be.
Otherwise, the same observations apply that I wrote in the previous post, and this time I added all relevant links to the main README.
This concludes the side-topic in this thread I think. For those who’re curious, the next target is making the packages reproducible, but that’s best discussed in:
Please join that conversation if you’re interested in testing / learning about reproducible builds with a Qubes OS, Salt-flavored motivation!
) make it safe to add them to the Salt pillar?
)
next time.