| EvanCarroll | (question about hostnames/fqdn and not getting the hostname set to fqdn) | 00:41 |
|---|---|---|
| jorjick | Hi all. Do I understand correctly that scripts/per-instance does not work with NoCloud data source (iso)? | 00:42 |
| EvanCarroll | oh my god. | 01:01 |
| EvanCarroll | that's a bu. | 01:01 |
| EvanCarroll | bug* | 01:01 |
| jorjick | Already found. It's not implemented yet. Thanks all. | 01:01 |
| EvanCarroll | filed the bug here https://bugs.launchpad.net/cloud-init/+bug/1966533 | 01:19 |
| ubottu | Launchpad bug 1966533 in cloud-init "fqdn does not accept terminal dot" [Undecided, New] | 01:19 |
| minimal | jorjick: look at logs for a machine using NoCloud (ISO) I do see log entries for "Running module scripts-per-instance" | 01:22 |
| minimal | jorlick: in your /etc/cloud/cloud.cfg, in the cloud_final_modules section does the list include screipts-per-instance? | 01:23 |
| jorjick | minimal: Thank You, but I already see log entries, try adding scripts-per-instance. And recently found that https://github.com/canonical/cloud-init/blob/main/cloudinit/sources/DataSourceNoCloud.py looks only "meta-data", "user-data", "vendor-data" and "network-config" | 01:27 |
| minimal | jorjick: the only DataSources that make any mention of scripts are OVF and SmartOS | 02:23 |
| minimal | I believe you are supposed to place the per-instance script in the /var/lib/cloud/scripts/per-instance/ directory of the OS image you are booting, not to supply them as part of the NoCloud ISO | 02:24 |
| minimal | jorjick: ah, this looks more relevant: https://cloudinit.readthedocs.io/en/latest/topics/format.html?highlight=per-instance#examples | 02:28 |
| minimal | creating a multi-part MIME encoded user-data file... | 02:28 |
| jorjick | minimal: With trying multi-part MIME encoded user-data get tthis error: fileUnhandled unknown content-type (text/x-shellscript-per-instance) userdata: 'b'#!/usr/bin/env bash | 04:07 |
| EvanCarroll | Would someone tell me if this is sane and good practice (installing a user's private and public keys with terraform/cloud-init) https://devops.stackexchange.com/q/15628/18965 | 18:59 |
| minimal | EvanCarroll: which DataSource are you using? | 19:21 |
| minimal | the problem is that in general user-data is not very "secure" - if its being obtained from a metadata server then potentially someone else could query that, if it is coming from an ISO (i.e. NoCloud) then how is the ISO secured? | 19:23 |
| EvanCarroll | I'm supplying user-data (which is a cloud-init) I'm providing values that I read from file(), produced externally by a makefile. | 19:24 |
| minimal | and how do you provide those? which cloud-init DataSource is being used? NoCloud? | 19:25 |
| EvanCarroll | I'm not using any datasource. | 19:26 |
| minimal | you must be, cloud-init uses datasources... | 19:26 |
| minimal | how else can cloud-init get user-data? | 19:26 |
| EvanCarroll | From a template variable... | 19:26 |
| minimal | a template where? | 19:27 |
| minimal | look at the /var/log/cloud-init.log on the machine do see which DataSource is being used | 19:27 |
| EvanCarroll | resource "openstack_compute_instance_v2" "test-server" { user_data = data.template_file.user_data.rendered } | 19:27 |
| minimal | that sounds like you are using the OpenStack DataSource then... | 19:27 |
| EvanCarroll | 2022-03-26 06:30:25,599 - stages.py[INFO]: Loaded datasource DataSourceOpenStackLocal - DataSourceOpenStackLocal [net,ver=2] | 19:27 |
| minimal | https://cloudinit.readthedocs.io/en/latest/topics/datasources/openstack.html | 19:28 |
| minimal | so you are using that as your DataSource | 19:28 |
| EvanCarroll | gotcha | 19:28 |
| EvanCarroll | is that a problem? | 19:29 |
| minimal | so the point, in that scenario, I'm making is that the user-data can be access via http://169.254.169.254/ | 19:29 |
| minimal | and so if you are embedding private keys in the user-data then some other person/program could potentially fetch them from that url | 19:30 |
| EvanCarroll | oh, that's terrifying | 19:30 |
| EvanCarroll | so what's the right way to do this? | 19:31 |
| minimal | that's why I would say it would be better to generate keys on the machine and then use something like the phone-home module to "post" the public keys to another server (like your Git server) | 19:31 |
| minimal | https://cloudinit.readthedocs.io/en/latest/topics/modules.html#phone-home | 19:31 |
| EvanCarroll | Yea, but that's just putting off the problem. How will the server that genreates the keys know how ot authenticate with the git server? | 19:33 |
| minimal | I meant that you use phone_server to trigger something to copy the public keys into authorized_keys in any other machines (such as Git server) that needs to trust the user on the cloud-init configured machine | 19:35 |
| EvanCarroll | I'm not sure I understand. So terraform is provisioning a new box Foo, and Foo generates keys and uses phone home to send them to an end-point which stores them in the authorized_keys? | 19:39 |
| EvanCarroll | How do I make this end-point (which stores the keys in authorized_keys) authenticated such that a hostile user can't post new keys to it, and get access to the trusted resource? | 19:40 |
| minimal | you mentioned a git server - so on the new machine Foo if you've used user-data to create a user "evan" then I assume you want that account to get able to access git via SSH. So therefore you need to get the public key created for user "evan" into the ~/.authorized_keys file for whichever user is used on the git server | 19:42 |
| minimal | how you do this is up to you. I suggested as phone-home module as one way to get the public key out, there are multiple other possible methods. | 19:42 |
| minimal | e.g. if you use something like Ansible/Puppet/Salt to manage boxes then they could retrieve it as part of their initial work on the box | 19:43 |
| minimal | or in the user-data you could use "runcmd" to run some command to push it out, or you could pull it from another box | 19:44 |
| EvanCarroll | Yes, but I don't want a new user on machine Foo to be able to post their own keys to the post-home end point and then obtain access to the SSH box. | 19:44 |
| minimal | Ok. I merely pointed out that user-data is not a very secure method to provide *private* keys via | 19:45 |
| EvanCarroll | Right but all of these are just begging the question: whether I push the key _itself_ to the box, or the authentication secret to end point that phone-home users to supply a key, how do I get either that key or that authentication secret on the box? | 19:45 |
| minimal | you could push it via Ansible/Puppet etc if you use those already | 19:46 |
| minimal | or via a another mechanism (i.e. rsync) etc | 19:46 |
| EvanCarroll | I mean, that's one method that would work, and I guess I could rsync it too with like a local-command. | 19:46 |
| EvanCarroll | or whatever in terraform | 19:46 |
| EvanCarroll | so yeah, that's undesirable but that makes sense to me ansible/rsync. | 19:46 |
| minimal | in an AWS context, Amazon have this to say about user-data: | 19:47 |
| minimal | "Although you can only access instance metadata and user data from within the instance itself, the data is not protected by authentication or cryptographic methods. Anyone who has direct access to the instance, and potentially any software running on the instance, can view its metadata. Therefore, you should not store sensitive data, such as passwords or long-lived encryption keys, as user data." | 19:47 |
| minimal | note the last sentence | 19:48 |
| EvanCarroll | So just to be clear, when provisioning a machine there is no method `openstack_compute_instance_v2` provides to send private data to the machine that doesn't proxy it to a publically available meta-data end point | 19:48 |
| minimal | the meta-data, network-config, and user-data is provided via the http://169.254.169.254/ (metadata server) url | 19:49 |
| EvanCarroll | yep, well. That's perfect, I wish https://registry.terraform.io/providers/terraform-provider-openstack/openstack/latest/docs/resources/compute_instance_v2 had a notice like that. | 19:49 |
| minimal | I guess its a general "well known fact" (i.e. not so well known) that user-data isn't secure | 19:50 |
| EvanCarroll | Yeah, well I'm pretty new to terra-form, but I thought the only vulnerability was that it was stored in tfstate | 19:51 |
| EvanCarroll | I didn't realize it was publically available and unencrypted. | 19:51 |
| minimal | its ok for ssh *public* keys, just not for private keys | 19:51 |
| EvanCarroll | Good thing I ask first! | 19:51 |
| minimal | I'm not sure what, if any, security features Openstack may have to reduce the access to it | 19:52 |
| minimal | ah, here we go: https://docs.openstack.org/nova/rocky/admin/security.html | 19:52 |
| minimal | "OpenStack supports encrypting Compute metadata traffic with HTTPS" | 19:52 |
| minimal | that seems to rely on TLS client certs (unless you set "nova_metadata_insecure" to True) | 19:53 |
| minimal | so then its a question of how to handle client certs in your VMs (i.e. you'd need to have them already in the VM image in order for metadata server requests to work) | 19:54 |
| minimal | EvanCarroll: I see you're getting similar opinions in the terraform channel | 20:15 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!