-
Notifications
You must be signed in to change notification settings - Fork 245
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Security when using vmware to store the ignition config? #1300
Comments
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 |
The next release of Ignition will delete Ignition configs from VMware guestinfo during first boot by default (#1350). Thanks for reporting this! |
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: