-
Notifications
You must be signed in to change notification settings - Fork 129
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
Strongly suggest removing access to Ignition config / metadata after first boot #306
Comments
It's a concern on any provider. I didn't know there was a way to remove userdata; that's neat. See also #272 for the firewalling approach to this problem. |
The OpenShift SDN layer denies all link-local access from the pod network. See also https://github.com/4ARMED/kubeletmein Note that some privileged containers in the ecosystem rely on accessing the metadata server, so a host-level firewall can break those. |
Because the config is commonly expected to have secret values, use mode 0600. xref coreos/fedora-coreos-docs#306
Because the config is commonly expected to have secret values, use mode 0600. xref coreos/fedora-coreos-docs#306
@travier - where do we stand on this? need more discussion or someone to execute? |
We need to add a warning and steps in the doc for the different platforms where this is possible. |
Or instructions for #272 where doing this at the platform level is not possible. |
Taking this one but feel free to comment here if you'd like to do it as I won't be able to get to it soon and might be good first issue for someone with access to a lot of platforms for testing. |
I wouldn't necessarily try to tackle every provider which supports this in one card. Maybe we can make this one about GCP, and have separate cards for others? That way it can be divided up more easily. |
Agree, keeping this one for global tracking of this issue and creating a card for each platform will be best. |
I'm still planning to work on this issue but as I don't have a timeline, I don't want to give a misleading impression that this is in progress thus I'm removing myself from assignee. Feel free to take this or I'll re-assign myself to it when I start working on it. |
Some upstream docs in coreos/ignition#1365. |
…boot The configuraton may contains sensitive data. As any subsequent container may be able to access the s3 bucket it is advised to clear it. See #306
…boot The configuraton may contains sensitive data. As any subsequent container may be able to access the s3 bucket it is advised to clear it. See #306 Also remove one level in the s3 config title so it appear in the TOC
…boot The configuraton may contains sensitive data. As any subsequent container may be able to access the s3 bucket it is advised to clear it. See #306 Also remove one level in the s3 config title so it appear in the TOC
On GCP at least, any local process can query
metadata.google.internal
and get the Ignition config used to provision the instance:See https://cloud.google.com/appengine/docs/standard/java/accessing-instance-metadata
We should probably add instructions to remove that metadata once the system has booted (https://cloud.google.com/sdk/gcloud/reference/compute/instances/remove-metadata).
I don't know yet if that's a concern for other cloud providers.
The text was updated successfully, but these errors were encountered: