SvenKieske | mhm, anybody in here knows if we have somewhere some sane documentation on cors configuration for openstack http services? I only found this so far:https://docs.openstack.org/oslo.middleware/latest/reference/cors.html#configuration-for-oslo-config | 09:33 |
---|---|---|
SvenKieske | which is not that encouraging with phrasings like "include a configuration block something like this" <- this does not inspire much confidence | 09:34 |
SvenKieske | specifically, I'm asking about securing the glance-api via cors in kolla-ansible, because we currently only set allowed_origin here: https://review.opendev.org/c/openstack/kolla-ansible/+/900056/6/ansible/roles/glance/templates/glance-api.conf.j2 | 09:38 |
SvenKieske | and maybe that could/should be hardened a little more :) | 09:38 |
SvenKieske | I think I'm gonna steal what openstack-ansible did: https://github.com/openstack/openstack-ansible-os_glance/blob/289ce991c420d7114b3a71a95602404e8ad7b0a0/templates/glance-api.conf.j2#L126 | 09:43 |
fungi | SvenKieske: i haven't looked, but i guess you checked the security guide and it doesn't have anything? might be a good section to add if so, and then deployment projects can just refer to that in their documentation rather than duplicating content | 13:18 |
fungi | also i'm happy to add more core reviewers, especially domain-specific experts, to that guide if people are willing to get it updated with more/fresher content | 13:20 |
SvenKieske | fungi: I actually didn't there is a section for glance, but it has nothing with regards to cors: https://docs.openstack.org/security-guide/image-storage/checklist.html | 13:25 |
SvenKieske | tbh I think a more modern approach would be to provide scripts for a service that check that $service is configured $secure, which is a little bit more work I guess, but might be more userfriendly | 13:26 |
fungi | yeah, some sort of (either local or network, but maybe a little of both?) scanner would be an interesting project if anyone has time to make (and more importantly, maintain) such a thing | 13:27 |
fungi | maybe something like an openvas plugin would be less work | 13:28 |
fungi | openvas basically just uses nasl, if you're familiar with the language | 13:29 |
SvenKieske | I did some stuff with openvas in the past, but didn't really dive deep | 13:30 |
fungi | was an example, i've been out of that space for a long time now so there are probably newer open source tools for vulnerability assessment anyway | 13:31 |
SvenKieske | what would be nice, is to "shift left" this whole stuff. So I would ask: "why do we write a guide to configure X secure?" why isn't it secure out of the box? I think it's more bang for the buck spending time on this stuff | 13:31 |
fungi | in part because security isn't binary, but rather depends a lot on context | 13:32 |
fungi | security is like safety. is a knife "safe"? it depends on which end you're holding and how you use it | 13:33 |
fungi | security is a mindset, an approach. it's not something you have or you don't, it's something you practice or you don't | 13:34 |
fungi | and you may practice it a little or a lot, but there's always more you could do. it's usually a trade-off against convenience. you can make a system more secure at the expense of making it less convenient. where to find that balance is hard, and it's not the same for every situation | 13:36 |
fungi | if we did produce a scanner, it would be a set of checks and recommendations, but it can't really relieve the user of the need to think about these topics and understand the software and their use cases | 13:37 |
fungi | probably a good example is jenkins. one of the reasons we stopped running it was because our use case is for a ci/cd system that runs arbitrary code from completely untrusted users and gives them detailed feedback on the results including an accessible, queryable dashboard | 13:40 |
fungi | the jenkins community considers its software "secure" as long as you run it behind a firewall and only allow trusted users to execute things with it | 13:40 |
fungi | that may be "secure" but not for our use case | 13:41 |
opendevreview | Jeremy Stanley proposed openstack/ossa master: Update stable branch terminology for unmaintained https://review.opendev.org/c/openstack/ossa/+/901137 | 14:10 |
SvenKieske | fungi: yeah, I don't know if you maybe saw the presentation "mostly bags of giant water" from a kernel security talk a few years ago? that shifted my view on computer security by some degree. | 14:38 |
SvenKieske | ah I had the title wrong "giant bags of mostly water" it was, really some fun slides in there, and some hard truths, I think: http://kernsec.org/files/lss2015/giant-bags-of-mostly-water.pdf | 14:39 |
SvenKieske | back to actual openstack security, I filed https://bugs.launchpad.net/kolla-ansible/+bug/2043709 publicly because the information therein is already public. I honestly don't know if this is a security issue, just mentioning it here for completeness. | 14:40 |
fungi | SvenKieske: oh, yeah that's a great talk! | 15:05 |
fungi | as for 2043709, do kolla deployments generally expose the qemu-console port (e.g. to guest instances) without going through novnc-proxy? | 15:07 |
fungi | that's usually only bound to the maintenance interface of the compute nodes, right? | 15:08 |
* fungi doesn't actually run any production openstack systems so my understanding of the relationship between those bits is not as strong as it could be | 15:09 | |
SvenKieske | so I just listened to a user report here, which at least claimed it's exposed on the internal network, I also didn't check myself, yet. | 15:13 |
SvenKieske | but I checked with nova aka sean-k aka the-one-who-knows-everything-about-openstack and he said that connections via novncproxy to qemu are only enforced by nova when setting the necessary aut_schemes, which we don't do in k-a | 15:15 |
SvenKieske | so it at least seemed sensible to note a bugreport to improve that, maybe. doesn't imho matter much from a user perspective if it's exposed on internal or external network, even if the latter might be slightly worse. | 15:16 |
SvenKieske | I also think the security of your vm should not depend on others not seeing the content of a serial|vnc console, but it's a good defense in depth to not expose this (by accident). | 15:17 |
fungi | yep. this sounds like configuration guidance worthy of including prominently somewhere (security guide? security note?), doesn't seem kolla-specific | 15:20 |
SvenKieske | in which repo does the security guide reside? maybe I can write something up for that at least. | 15:27 |
fungi | SvenKieske: openstack/security-doc | 15:29 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!