Time: 16:30 UTC (same as normal) on Wednesday June 1st
Location: meet.google.com/sfc-fbzb-psd (will be recorded)
Agenda/Notes: https://hackmd.io/Hc7KaotVSByOm0dxsGzmLA
We will go over our high level goals for FCOS and cover recent updates and
then start digging into CoreOS layering some more and the steps we need to
take to implement the rest of the puzzle.
See you all next Wednesday!
Dusty
Hi, thank you for this update!
I tried to understand how this works on bare metal. After installation with
ignition file provided on a local file system, is the file still accessible
unencrypted anywhere after the installation completes?
For machines that are remote and no human interaction is possible, I don't
see how credentials in ignition can be avoided. Even if hashicorp is used,
then some credentials for hashicorp should be present. Or am I mistaken?
Thank you!
On Fri, May 20, 2022 at 12:38 AM Benjamin Gilbert <bgilbert(a)redhat.com>
wrote:
> 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
> _______________________________________________
> coreos-status mailing list -- coreos-status(a)lists.fedoraproject.org
> To unsubscribe send an email to
> coreos-status-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/coreos-status@lists.fedorapro…
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
Time: 16:30 UTC (same as normal) on Wednesday May 4th
Location: meet.google.com/meo-enbb-rur (will be recorded)
Agenda/Notes: https://hackmd.io/agQyAznoTSyWP8DZOZAQ9A
Brian Tomlinson will join us to discuss his project that automates bringup
on the Raspberry Pi 4. This was originally shared with the community in a
discussion forum post. We will also carry forward discussion last week
about nmstate and Fedora CoreOS.
See you all tomorrow!
Dusty