Format change for Nutanix artifact
by Sohan Kunkerkar
Hi all,
The format of the Fedora CoreOS Nutanix image will change [1] in the next release of the Fedora CoreOS `next` and `testing` streams. Current releases ship the Nutanix image as a qcow2 file wrapped with xz compression (`qcow2.xz`). Future releases will switch to a qcow2 file without any wrapper (`qcow2`), internally compressed with qcow2's built-in compression support. Following the usual release schedule, this change will promote to the `stable` stream two weeks after the `next` and `testing` releases.
We are making this change to support direct uploading of Fedora CoreOS images into Nutanix AHV using the Nutanix Prism API. This allows users to avoid manually downloading, decompressing, and re-uploading Fedora CoreOS images when adding them to Nutanix Prism Central.
If you use the Nutanix image, you will need to adjust your workflow [2] for adding Fedora CoreOS images to Nutanix AHV. If you do not use the Nutanix image, this change will not affect you.
If you have any questions or concerns, or expect this change to break a critical workflow, please contact us via `#fedora-coreos` on Libera.Chat or file an issue in the Fedora CoreOS tracker [3].
--Sohan Kunkerkar, for the Fedora CoreOS team
[1]: https://github.com/coreos/coreos-assembler/pull/2848
[2]: https://docs.fedoraproject.org/en-US/fedora-coreos/provisioning-nutanix/#...
[3]: https://github.com/coreos/fedora-coreos-tracker/issues/new/choose
1 year, 4 months
Ignition config accessible to unprivileged software on VMware
by Benjamin Gilbert
Hi all,
Unprivileged software in VMware VMs, including software running in
unprivileged containers, can retrieve an Ignition config stored in a
hypervisor guestinfo variable or OVF environment. If the Ignition config
contains secrets, this can result in the compromise of sensitive
information.
Starting with next week's Fedora CoreOS `testing` and `next` releases,
Ignition will delete the Ignition config from supported hypervisors
(currently VMware and VirtualBox) during the first boot. This ensures that
unprivileged software cannot retrieve the Ignition config from the
hypervisor. Existing machines will likewise delete the config when first
upgraded to a new release. This change will be promoted to Fedora CoreOS
`stable` after two weeks, as usual.
Note that in general, we do not recommend storing secrets in Ignition
configs [1]. In addition to VMware, many cloud platforms allow unprivileged
software in a VM to retrieve the Ignition config from a networked cloud
metadata service. While platform-specific mitigation is possible, such as
firewall rules that prevent access to the metadata service, it's better to
store secrets in a dedicated platform such as Hashicorp Vault [2].
If you have external tooling that requires the Ignition config to remain
accessible in VM metadata after provisioning, and your Ignition config does
not include sensitive information, you can prevent deletion by masking
ignition-delete-config.service. For newly-launched machines:
variant: fcos
version: 1.0.0
systemd:
units:
- name: ignition-delete-config.service
mask: true
To prevent upgrades from affecting existing machines:
$ sudo systemctl mask ignition-delete-config.service
If you have any questions or concerns, contact us in #fedora-coreos on
Libera.Chat or open an issue in the Fedora CoreOS tracker [3].
--Benjamin Gilbert, for the Fedora CoreOS team
[1]: https://coreos.github.io/ignition/operator-notes/#secrets
[2]: https://www.vaultproject.io/
[3]: https://github.com/coreos/fedora-coreos-tracker/issues/new/choose
1 year, 4 months
