| krono | hi there. I have a system init'ed with cloud init and due to the config it contains sensitive data in /var/lib/cloud/instance/*data.txt | 14:09 |
|---|---|---|
| krono | Do I understand that right that simply deleting these files is _not_ safe? | 14:10 |
| falcojr | krono: what files are you wanting to delete? | 14:40 |
| krono | falcojr: user-data.txt | 14:40 |
| falcojr | yeah, that's not really something that's supposed to be deleted. Off the top of my head, I'm not sure it would hurt anything, but it would probably re-appear next boot anyway | 14:44 |
| falcojr | permissions are root only though, and (depending on the cloud) that data is going to be accessible from the cloud metadata service too | 14:45 |
| krono | well, I'm provisioning with MAAS and I somehow need to convey the existence of a root user and their password -.- | 14:49 |
| krono | (also, I've seen on my ovirt setup that changing network stuff via the "cloud-init" option there has no effect whatsoever after subsequent boots) | 14:52 |
| krono | anyway, thanks for the info, falcojr . I'll just try it out and see what happend :D | 14:54 |
| minimal | krono: I think the general idea would be for user-data to set a random password for root - which then appears on the console during boot - rather than to put an actual password in user-data. When you talk about a root password in user-data do you mean the actual password or the "encrypted" form of it? | 15:10 |
| krono | minimal: I have just observed that the password I put in the cloud-init section of ovirt ended up unencrypted in the user-data.txt on the resulting virtual machine. | 15:11 |
| krono | I now want to provision hardware machines and have to enable and password-ize that ubuntu (for "enterprise" reasons) | 15:12 |
| krono | In the end, If I'm doing things right,I could put a "wrong" initial password there and then override it in postinstall or something | 15:12 |
| minimal | krono: are you setting the "plaintext" password in either the "chpasswd" section or within "users:" section? If within the "users:" section then you really should be using "hashed_passwd". Unfortunately the top-level "chpasswd:" setting only support plaintext passwords | 15:15 |
| krono | minimal: thanks for the info, I'll keep that in mind, makes sense to use hashed password. | 15:16 |
| krono | minimal: this is what oVirt creates from its gui for cloud-init: | 15:17 |
| krono | https://www.irccloud.com/pastebin/1Pcoyk1G/user-data.txt | 15:17 |
| minimal | krono: as falcojr pointed out, depending on how MAAS provided the user-data, there's a risk that the source of user-data (i.e. metadata server) would be accessible by users on the machine | 15:17 |
| krono | aah that makes sense... I'll see whether there's an impact in my case | 15:18 |
| minimal | have a quick look at MAAS datasource and it does use a URL to retrieve the user-data (though with Oauth in place) - I guess the presence of Oauth gives a degree of security to protect the user-data | 15:20 |
| minimal | krono: as you're setting the default user to root then you could put something like this in user-data: | 15:22 |
| minimal | users: \n - default \n hashed_passwd,: <value> | 15:23 |
| minimal | that's 3 sets of lines each indented from the previous one | 15:23 |
| krono | neat! thanks a bunch :D | 15:25 |
| minimal | if you choose a strong hash method (bcrypt? PBKDF2?) it will be harder to bruteforce if someone ever got hold of it | 15:26 |
| === meetingology` is now known as meetingology | ||
| === blackboxsw_ is now known as blackboxsw | ||
| === jchittum_ is now known as jchittum | ||
| === nicolasbock_ is now known as nicolasbock | ||
| === c355E3B_ is now known as c355E3B | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!