* Daniel P. Berrangé: > On Thu, Nov 21, 2019 at 11:52:26AM +0100, Florian Weimer wrote: >> * Daniel P. Berrangé: >> >> >> This goes probably in a different direction of what has been implement >> >> so far, but would it actually harm to enable the network-based >> >> instance-data injection by default? The advantage would be that it also >> >> blocks these requests from leaking to untrusted parties, which could >> >> then serve bogus data to compromise the virtual machine. >> > >> > I don't understand what you mean by leaking data to untrusted parties >> > here in contetx of config drive ? I've considerd the config drive to >> > be more secure / less risky than network service. >> >> I'm assuming that cloud-init will try all sources in parallel, given >> that there's a delay for both the network coming about and hardware >> being detected. > > IIRC, the network sources all use link-local addresses, so by default > you would need to have configured the 169.254.169.254 on one of the > NICs on the host that the guest can reach. It connects to port 80 on > this address. Too many IPv4 deployment treat 169.254.0.0/16 as global unicast addresses and forward them via the default route. Only once they reach the DFZ, these packets get dropped, but only if no one has announced a route for it. The instance-data DNS lookup is typically forwarded to the DNS root servers. Local resolvers will only filter it if they are DNSSEC-enabled. I have argued for a long time that separate cloud and local KVM images are needed because the cloud images are dangerous in a non-cloud environment, but so far without success. Thanks, Florian _______________________________________________ virt-tools-list mailing list virt-tools-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/virt-tools-list
