4 ms·
With modern software distribution infrastructure you are entirely fucked at this point. It’s number one business critical risk from our analysis. And it’s not j
by hvgk 5y ago
With modern software distribution infrastructure you are entirely fucked at this point. It’s number one business critical risk from our analysis. And it’s not just from developer workstations but from stuff sneaking into production during a build cycle as well which is flagged through or missed by any of the participating tools which are supposed to stop stuff going through. The developer workstations aren’t even a worthy target.
Imagine if someone managed to inject malware into a core kubernetes component which gets pulled from docker hub or something.
The only reasonable way to prevent this is do development work in a fully constrained environment both from a hardware and software perspective and that means taking on a hell of a lot of compromises which will cripple your productivity entirely.
My efforts to investigate this pretty much lead to the conclusion that you need to have two computers available attached to different physical networks. The first computer has internet access and allows things like email, www access but has no administrative capabilities and no development tools installed and no way of installing tools as an unprivileged user. The second computer is the only one you are allowed to do development work on and has no internet connection.
Obviously when proposing this, it was laughed out of the room. This is exactly what I intended to prove: you can’t fix this reasonably at this point so don’t bother doing it.
At least not unless you have an airgapped machine and solely write in something standardised, with no external dependencies or libraries and no possibility of pulling something from outside your trust boundary.
I hope you sleep better than I do knowing this as well.
Edit: I was actually most happy writing C in an airgapped network about 25 years ago on a Sun machine with some manuals and some Oreilly books on my desk. The very thought of downloading something there was laughed out of the room. I wonder what they do now.
- Kranar 5y ago>Imagine if someone managed to inject malware into a core kubernetes component which gets pulled from docker hub or something. Digital signatures are a typical way to protect against this. Pretty robust as far as I know.
- deleted 5y ago[deleted]
- hvgk 5y agoDigital signature tells you that the owner of the key signed it. Not who currently owns the key.
- adolph 5y agoafaik: No K8s core components are containers that come from a registry, see below. Random app/container running in your orchestrator could have sketchy provenance, sure. https://kubernetes.io/docs/concepts/overview/components/ https://kubernetes.io/docs/concepts/overview/components/
- MrDresden 5y agoI actually worked as a software dev at a genetics laboratory a few years ago where there was a complete network split implemented matching your description. All resulting research data was on the airgaped network where each terminal was heavily restricted in what it was allowed to do and by whom. We the software devs were on the open network, with less restrictions. Due to the concern of a supply chain attack there was a heavy feel of not invented here. Over its ~25 years of operation the lab has created immense amounts of internal software from scratch. It was an interesting look into a small dev team that had mostly never worked anywhere else (yes, the code was often very messy), and had a xenophobic view of off-the-shelve software and solutions.
- hvgk 5y agoI have worked in the defence sector on similar things and agree with the not invented here thing. At the same time it breeds tools out of necessity. My only tale on tale is that I pretty much designed and built ansible in Perl in 1999. Of course, young and inexperienced, I did not see the potential preferring mild alcoholism and socialising. Doh!
- dharmab 5y agoYou're not the only one who built a configuration management system before Ansible; CFEngine's first release was in 1993, for example. Ansible's success was its appeal to people who did not think of themselves as traditional programmers.