[19:54] <hoonetorg> hi
[19:55] <hoonetorg> isn't it a security issue, if vfat, iso9660 or http(s) is used as datasource?
[19:56] <hoonetorg> if i put f.e. private ssh hostkeys into user-data, and the datasource is available via http
[19:56] <hoonetorg> anybody can see the private ssh host keys with wget or curl
[19:57] <hoonetorg> with vfat or iso9660 it's not that easy, but
[19:58] <hoonetorg> imagine you use a cloud instance as terminal server (x2go+lxde or similar f.e.), then could any user mount the datasource via filemanager
[19:59] <hoonetorg> it's mounted as user and the user has full read access to vfat or iso9660
[20:00] <hoonetorg> afaik xfs, ext4 or btrfs ... are not supported as datasource filesystem
[20:01] <hoonetorg> but they could solve that problem and make the data on the datasource virtual drive as secure as on the rootfs.
[20:01] <hoonetorg> anybody thought about that yet?
[20:03] <hoonetorg> I know, it's not the fault of cloud-init, because it only implements what cloud providers did.
[20:07] <hoonetorg> probably i'm here at the wrong time to ask and should ask again, when people write each other here.
[20:07] <hoonetorg> my conclusion is: do not put sensitive data into meta-data, user-data, vendor-data.
[20:10] <kwadronaut> hoonetorg: it's irc. just stick around. for a long time. if you can't try the mailinglists.
[20:10] <kwadronaut> sometimes it's quiet here for days, sometimes a lot of activity.
[20:13] <hoonetorg> kwadronaut: hi, that's exactly what i thought. normally i connect to a channel, am quiet as a little mouse and hv a look what's going on in that channel
[20:14] <hoonetorg> kwadronaut: but today i did opposite. i was so surprised, that datasources are so insecure, that i must ask immediately if somebody else thinks the same way.
[20:16] <hoonetorg> will put this channel to my list and stay and reconnect and wait for "traffic" :)
[20:17] <kwadronaut> if you take the example of private host keys, i wonder why you would preseed them and not generate them on your 'secure' cloud instance? entropy is already a big issue there, in general.
[20:18] <kwadronaut> if your 'cloud provider' is simply you/your employer, ie, a private cloud, the issue should remain on the internal network anyway.
[20:19] <kwadronaut> but i'm sure others can give you better answers.
[20:19] <hoonetorg> should only be an example
[20:20] <hoonetorg> i thought on deploying my salt minion keys via cloud-init
[20:21] <hoonetorg> instances are deployed and redeployed multiple times, so salt-minion-keys must find their way to the instance.
[20:22] <hoonetorg> once salt is running i can deploy ssh host keys and certificates and other sensitive stuff more or less secure via salt.
[20:23] <hoonetorg> ...... but to get salt running .... i scratch my head
[20:24] <hoonetorg> probably it's a better approach to do this more dynamic
[20:24] <hoonetorg> create new keys on every new deploy of the same instance.
[20:26] <hoonetorg> .... but that is like with ssh host keys then: your ssh hostkey changed.... man in the middle attack... do you want to remove the old key from ...line...
[20:26] <hoonetorg> ------> yes
[20:26] <hoonetorg> (did i reinstall that machine???)
[20:27] <hoonetorg> kwadronaut: thx so far, your answer implies somehow my initial conclusion: no sensitive data in datasources.
[20:45] <kwadronaut> yeah, i've also ran into that problem, and distributing changed ssh keys upon reinstalling yadayada, i'm not happy with how we do things now, and improvements would be welcome, as usual.
[20:46] <kwadronaut> and there will be sensitive data in there, but we try to minimalise it.
[20:51] <hoonetorg> every new  bare metal i use, gets an usbstick formatted with ext4 label "sensitive".  i put salt-keys on it (manually generated), chmod 400, chattr +i
[20:52] <hoonetorg> that way data on the stick should be as secure as on rootfs (/)
[20:54] <hoonetorg> but with vfat or iso9660 it's difficult
[21:00] <hoonetorg> yeah but entropy is still an issue, for sad i hv no QKD device lying around for producing real random :)
[21:02] <hoonetorg> (sorry for OT, i'm quite now)