=== Windir_ is now known as Windir [19:54] hi [19:55] isn't it a security issue, if vfat, iso9660 or http(s) is used as datasource? [19:56] if i put f.e. private ssh hostkeys into user-data, and the datasource is available via http [19:56] anybody can see the private ssh host keys with wget or curl [19:57] with vfat or iso9660 it's not that easy, but [19:58] 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] it's mounted as user and the user has full read access to vfat or iso9660 [20:00] afaik xfs, ext4 or btrfs ... are not supported as datasource filesystem [20:01] but they could solve that problem and make the data on the datasource virtual drive as secure as on the rootfs. [20:01] anybody thought about that yet? [20:03] I know, it's not the fault of cloud-init, because it only implements what cloud providers did. [20:07] probably i'm here at the wrong time to ask and should ask again, when people write each other here. [20:07] my conclusion is: do not put sensitive data into meta-data, user-data, vendor-data. [20:10] hoonetorg: it's irc. just stick around. for a long time. if you can't try the mailinglists. [20:10] sometimes it's quiet here for days, sometimes a lot of activity. [20:13] 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] 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] will put this channel to my list and stay and reconnect and wait for "traffic" :) [20:17] 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] if your 'cloud provider' is simply you/your employer, ie, a private cloud, the issue should remain on the internal network anyway. [20:19] but i'm sure others can give you better answers. [20:19] should only be an example [20:20] i thought on deploying my salt minion keys via cloud-init [20:21] instances are deployed and redeployed multiple times, so salt-minion-keys must find their way to the instance. [20:22] once salt is running i can deploy ssh host keys and certificates and other sensitive stuff more or less secure via salt. [20:23] ...... but to get salt running .... i scratch my head [20:24] probably it's a better approach to do this more dynamic [20:24] create new keys on every new deploy of the same instance. [20:26] .... 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] ------> yes [20:26] (did i reinstall that machine???) [20:27] kwadronaut: thx so far, your answer implies somehow my initial conclusion: no sensitive data in datasources. [20:45] 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] and there will be sensitive data in there, but we try to minimalise it. [20:51] 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] that way data on the stick should be as secure as on rootfs (/) [20:54] but with vfat or iso9660 it's difficult [21:00] yeah but entropy is still an issue, for sad i hv no QKD device lying around for producing real random :) [21:02] (sorry for OT, i'm quite now)