install: Add support for --root-ssh-authorized-keys

[cgwalters]

install: Rename clashing variable

I will need to access the outer state here in a later PR.

---

install: Add support for --root-ssh-authorized-keys

The current bootc install model is VERY opinionated: we install
the running container image to disk, and that is (almost!) it.

The only non-container out of band state that we support injecting right now
is kargs (via --karg) - we know we need this for machine local
kernel arguments.

(We do have a current outstanding PR to add a highly generic mechanism
to inject arbitrary files in /etc, but I want to think about that more)

THis current strict stance is quite painful for
a use case like "take a generic container image and bootc install to-filesystem --alongside"
in a cloud environment, because the generic container may not
have cloud-init.

With this change it becomes extremely convenient to:

• Boot generic cloud image (e.g. AMI with apt/dnf + cloud-init)
• cloud-init fetches SSH keys from hypervisor (instance metadata)
• podman run -v /root/.ssh/authorized_keys:/keys:ro bootc install ... --root-ssh-authorized-keys=/keys`

And then the instance will carry forward those hypervisor-provided
keys but without a dependency on cloud-init.

Another use case for this of course is being the backend of things
like Anaconda's kickstart verbs which support injecting SSH keys.

Signed-off-by: Colin Walters [email protected]

---

[openshift-ci]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[cgwalters]

OK now tested and working!

[cgwalters]

There is an argument that we should support something like a more declarative full-blown user/ssh configuration. Some higher level projects do that (e.g. kairos). There's of course also Ignition etc.

I am hesitant a bit, but (a bit like install configuration) I think we could perhaps ship a bare minimum while avoiding scope creep here potentially. (edit: and that's what IMO this is: the bare minimum here is logging in as root via SSH. Passwords are IMO just a really really bad idea in general. Non-root users...not in the critical path, there are other ways to do that)

That said, such a thing would have immediate tension with user configuration as part of container builds. It's a messy topic.

[jmarrero]

I do like this and I think it's the minimum thing needed if we want to enable bootc install to be used by admins to install a domain specific system and give access to the new admins of that system.

Run this with the science officer ;) ssh key and that's it.

...lgtm

[jmarrero]

There is an argument that we should support something like a more declarative full-blown user/ssh configuration. Some higher level projects do that (e.g. kairos). There's of course also Ignition etc.

This would not be enabled by the config map/bare containers injection of files? I think if we enable that functionality anything declarative can be a very specific tool that writes configmaps/etc... like butane for bootc or so. People write a yaml and get a container with files/config map

[cgwalters]

This would not be enabled by the config map/bare containers injection of files

Right, #267 and/or configmaps would be a lot more powerful than this.