Permission and access controll of snippets in custom cloud init

[riedel]

Hi,

we want to use some passwords inside the custom init scripts (to actually register a VM). So the snippet with the password should not be visible to all users and ideally not even to the user running the vm.

I wonder how the access control of snippets is handled.

1. Who can access snippets or attach them to VMs?
2. What is the user group that one needs to use on the file system, so snippets can be called from custom init.

Best

Till

 

[dj423]

Are you talking about cloud-init files usually stored in /var/lib/vz/snippets?

Far as I know, whatever you set the permissions on the files will have access to read/write them. I wouldn't know how to call them from within an instance with cloud-init however, you can only call files that are within the VM/container/instance during the initial run. I have had cloud-init run scripts on init under the "runcmd:" stanza, and call a script that is on an NFS share, for example to setup FreeIPA clients.

As for password hashing, you can do that within the cloud-init file. When you say register a VM, I would assume you want to seed a username and password, or possibly an SSH key to do that? What elements do you need for the registration process?

FWIW: I usually call the cloud-init script at VM provisioning from templates, to setup users, passwords, SSH keys, NFS mounts, packages, guest agents, logging server, etc. and I use the vendor-data file to seed the settings with:

qm set "$ID_VM" --cicustom "vendor=local:snippets/vendor-data.yaml"

Guessing I am way off of what your goal is, so ignore me if I am way off track. But this is how I use cloud-init from snippets, but I call them at VM provisioning, so that all my settings, packages, mounts, etc. are setup so ansible can take over the provisioning process.

 

[riedel]

Thanks. Actually, i guess it totally makes sense use the standard cloud init and not the custom cloud init snippets to provide 'secrets' as the template itself is subject to pool permissions whereas the snippet storage is not.

So I guess the normal stuff is run after the vendor l, so I could first inject a script and the run it with a username/password argument.

Actually I need this for registering with a monitoring/metrics server.

It seems that pve running as root just need root permissions on snippet storage. But I guess and your comment reaffirms me, that the anyone can 'attach' a snippet to a new VM (where root is someone one does not trust and could exfiltrate anything inside custom ci).

 

[dj423]

Yeah, I had struggled with the "built-in" cloud-init since pve populates user-data for some reason, rather than using the vendor-data file. So you can seed your user info with the --ciuser, --cicustom and --sshkeys and pve will render the values on init. Then any "custom" settings you need in addition to the user info, you can put into vendor-data - such as packages, any scripts you need to run, mounts, etc. to have ready at provisioning.

The way I execute this in the provisioning script for reference:

qm set "$ID_VM" --cicustom "vendor=local:snippets/vendor-data.yaml"
qm set "$ID_VM" --ciuser ansible --cipassword MySecret
qm set "$ID_VM" --sshkeys <(echo "ssh-ed25519 AAA//..//Zw7txhcuaydkj1DGH XX-ed25519-ansible")
qm cloudinit update "$ID_VM"