You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We thought that only root should be able to view the config but it turns out any user seems to be able so get the whole config from vmware? vmtoolsd --cmd 'info-get guestinfo.ignition.config.data'
How can we handle secrets in ignition config? For example disk enctyption keys or other sensitivt config for systemd services we declare there?
The text was updated successfully, but these errors were encountered:
Thanks for the report. There's a similar problem with network metadata services on other platforms (coreos/fedora-coreos-docs#306), which is possible to mitigate by firewalling off the metadata service, but we hadn't realized VMware guestinfo was also affected.
VMware's guest-facing API supports setting guestinfo variables, so we could delete the Ignition config after we're done with it. I think we should consider having Ignition do this automatically on platforms that allow it (#1315) but that change likely won't happen soon.
In the short term, you should be able to mitigate this by creating a systemd service that runs on first boot and resets the guestinfo variable, using something like vmtoolsd --cmd "info-set guestinfo.ignition.config.data REMOVED=". Note that in VMs where the config is passed via an OVF property, the config will be wrapped in XML in the guestinfo.ovfenv variable instead.
We thought that only root should be able to view the config but it turns out any user seems to be able so get the whole config from vmware?
vmtoolsd --cmd 'info-get guestinfo.ignition.config.data'
How can we handle secrets in ignition config? For example disk enctyption keys or other sensitivt config for systemd services we declare there?
The text was updated successfully, but these errors were encountered: