s390x: generate GPG keys for Ignition config protection

[nikita-dubrovskii]

This is a proof-of-concept, part of coreos/fedora-coreos-config#1939.

During cosa buildextend-secex a pair of GPG keys is randomly generated,
where private key becomes part of sdboot image, and public key becomes
part of build artifacts.

User than can encrypt his Ignition config:

gpg --recipient-file /path/to/ignition.gpg.pub --output /path/to/config.ign.gpg --armor --encrypt /path/to/config.ign

And attach it to qemu-kvm as a disk:

-drive if=none,id=ignition,format=raw,file=/path/to/config.ign.gpg,readonly=on \
-device virtio-blk,serial=ignition.gpg,iommu_platform=on,drive=ignition

[jlebon]

Sorry, typed Enter too fast, will retry! :)

[jlebon]

LGTM! Two thoughts:

1. I wish we didn't have to support both the external genprotimg flow and the "local dev" one. Maybe we can get rid of the latter and add instructions on how to create your own genprotimg qcow2 for local testing. Though that's probably actually more complex to support than this. Let me know if you have ideas around this.
2. How are we planning to test this? If this isn't tested by CI, we could easily regress on it. Ideally we'd have something like kola run -p qemu-secex, but maybe easier is to keep relying on the qemu platform code, but add a --qemu-secex flag which tells kola to encrypt the Ignition config and present it as the expected virtio device? I guess the hurdle there is that we need to inject the host key in the Ignition config, which depends on whatever the builder we're testing on. We could define some APIs for that to wire it through, though short-term, we could just inject a bogus key; as long as we run tests that don't require regenerating the initramfs, it should work. (Honestly, even just running basic to start would be really helpful since it still exercises the Ignition config path.)

[nikita-dubrovskii]

1. I wish we didn't have to support both the external genprotimg flow and the "local dev" one. Maybe we can get rid of the latter and add instructions on how to create your own genprotimg qcow2 for local testing. Though that's probably actually more complex to support than this. Let me know if you have ideas around this.

I was thinking about it, but removing external VM seems more attractive (rdcore is awesome). I'd say we can wait til 4.13/4.14 and see how it goes with SE+OCP, maybe some build policies would change (i hope they would). If not - than i'll create test-vm/docker container to imitate genprotimg-vm.

2. How are we planning to test this? If this isn't tested by CI, we could easily regress on it. 

That's smth to discuss with IBM team. As far as i remember, we were discussing how-to add CI/CD on our side. Will open this question again

P.S.: thank you for the help and review )

[jschintag]

I was thinking about it, but removing external VM seems more attractive (rdcore is awesome).

I agree that doing it via rdcore would be awesome. But i don't think the restrictions on the universal hostkey are going to be lifted, so the genprotimgvm is not going away...

[jschintag]

LGTM

[jlebon]

To be clear, I don't think we should consider this feature completed until we've fleshed out the testing story. But I think this is in a good state now to get in and we can iterate from there.

Nice work!

[jlebon]

Opened a follow-up in #3362.