/srv/irclogs.ubuntu.com/2015/10/04/#cloud-init.txt

=== Windir_ is now known as Windir
hoonetorghi19:54
hoonetorgisn't it a security issue, if vfat, iso9660 or http(s) is used as datasource?19:55
hoonetorgif i put f.e. private ssh hostkeys into user-data, and the datasource is available via http19:56
hoonetorganybody can see the private ssh host keys with wget or curl19:56
hoonetorgwith vfat or iso9660 it's not that easy, but19:57
hoonetorgimagine you use a cloud instance as terminal server (x2go+lxde or similar f.e.), then could any user mount the datasource via filemanager19:58
hoonetorgit's mounted as user and the user has full read access to vfat or iso966019:59
hoonetorgafaik xfs, ext4 or btrfs ... are not supported as datasource filesystem20:00
hoonetorgbut they could solve that problem and make the data on the datasource virtual drive as secure as on the rootfs.20:01
hoonetorganybody thought about that yet?20:01
hoonetorgI know, it's not the fault of cloud-init, because it only implements what cloud providers did.20:03
hoonetorgprobably i'm here at the wrong time to ask and should ask again, when people write each other here.20:07
hoonetorgmy conclusion is: do not put sensitive data into meta-data, user-data, vendor-data.20:07
kwadronauthoonetorg: it's irc. just stick around. for a long time. if you can't try the mailinglists.20:10
kwadronautsometimes it's quiet here for days, sometimes a lot of activity.20:10
hoonetorgkwadronaut: 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 channel20:13
hoonetorgkwadronaut: 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:14
hoonetorgwill put this channel to my list and stay and reconnect and wait for "traffic" :)20:16
kwadronautif 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:17
kwadronautif your 'cloud provider' is simply you/your employer, ie, a private cloud, the issue should remain on the internal network anyway.20:18
kwadronautbut i'm sure others can give you better answers.20:19
hoonetorgshould only be an example20:19
hoonetorgi thought on deploying my salt minion keys via cloud-init20:20
hoonetorginstances are deployed and redeployed multiple times, so salt-minion-keys must find their way to the instance.20:21
hoonetorgonce salt is running i can deploy ssh host keys and certificates and other sensitive stuff more or less secure via salt.20:22
hoonetorg...... but to get salt running .... i scratch my head20:23
hoonetorgprobably it's a better approach to do this more dynamic20:24
hoonetorgcreate new keys on every new deploy of the same instance.20:24
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------> yes20:26
hoonetorg(did i reinstall that machine???)20:26
hoonetorgkwadronaut: thx so far, your answer implies somehow my initial conclusion: no sensitive data in datasources.20:27
kwadronautyeah, 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:45
kwadronautand there will be sensitive data in there, but we try to minimalise it.20:46
hoonetorgevery new  bare metal i use, gets an usbstick formatted with ext4 label "sensitive".  i put salt-keys on it (manually generated), chmod 400, chattr +i20:51
hoonetorgthat way data on the stick should be as secure as on rootfs (/)20:52
hoonetorgbut with vfat or iso9660 it's difficult20:54
hoonetorgyeah but entropy is still an issue, for sad i hv no QKD device lying around for producing real random :)21:00
hoonetorg(sorry for OT, i'm quite now)21:02

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!