Ignition config accessible to unprivileged software on VMware

Cross-posted with this coreos-status email.

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. 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.

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.