Live data from Hacker News

The sad state of sysadmin in the age of containers

vitavonni.de

71–80 of 466 posts

Re: The sad state of sysadmin in the age of containers

#71
post #19

Earlier quoted context omitted.

it's also still standard practice in most companies to either read the source code of open-source stuff before deploying it to production Eh, no.

I'd love a specific example? Because in many countries if they're publicly-traded or subject to other regulations (such as Basel, etc.) any company that didn't would be breaking the law.

I'd be interested to hear if you have an example of a company that did read the source code of apps. used?

Also which law do you think they would be breaking by not reading the source code of products used?

Re: The sad state of sysadmin in the age of containers

#72
post #62
post #49

Earlier quoted context omitted.

Docker didn't fuck up when they hired the square guys. http://blog.docker.com/2015/03/secured-at-docker-diogo-monic... I agree that security and provenance is a real issue in Docker. It is however being worked on, and it will be solved. Presumably we will end up with some sort of app-store like framework with proper signatures and verification. Docker can't do everything at once. Give them a chance. The new version o…

Cool, they hired some people, but I haven't noticed better security for it yet. Security is a real issue in docker and it is being worked on, but I don't think "give them a chance" is a justifiable response. They're not focusing on it strongly. They already should have focussed on it and didn't. Their entire codebase was written without a security design in place, so there's likely deep-seated refactoring that'll nee…

>> Security is a real issue in docker and it is being worked on, but I don't think "give them a chance" is a justifiable response.

For a public facing system I would agree that means it's not ready for production use yet...

Re: The sad state of sysadmin in the age of containers

#73
Every once in a while someone figures out that we could entirely solve the dependency problem by packaging all the dependencies with the application. Everyone gets excited. After a while everyone gets unexcited when the problems associated with this approach become obvious.

Docker is merely a more extreme example of the "package everything with the application" idea...

Re: The sad state of sysadmin in the age of containers

#74
post #67

> »Docker is the new 'curl | sudo bash'«. Fully agree with this. Maybe I am just only another grey beard grumpy developer, but the new generations that grew up with GNU/Linux instead of UNIX, bash the security of other OSes and then go running such commands all the time.

Sad really.

docker and any user in the group docker, or lets say, any user capable of sending commands to the docker daemon running as root - is root on that system.

docker -v /:/f -w /f yourimage /bin/bash -c "echo root:and:so:on > /f/etc/shadow"

Re: The sad state of sysadmin in the age of containers

#75
post #61

I was doing sysadmin the "right way" a long, long time ago, and I don't see much difference. Maybe the author regularly does full audits of the source code of every package he downloads, and of course disassembles every executable and library in the underlying OS, but most of us don't. There's no wisdom or security to be gained from the act of running "make", much less "make install".

There's a huge difference. > Maybe the author regularly does full audits of the source code of every package he downloads, and of course disassembles every executable and library in the underlying OS, but most of us don't. What matters is that the source code is auditable. It only takes one person to investigate something suspicious, raise a flag and get it fixed. This is certainly still true for Debian - not being a…

Assuming you:

- trust your compiler and linker

- trust your tar extractor / package manager / whatever

- trust your editor

- trust your http library (or whatever you used to download/distribute the code)

Re: The sad state of sysadmin in the age of containers

#76
post #7

So, asking the obvious question: what's the solution to that?

The obvious question is: what's the real problem with that? A container is a container, as long as docker itself has not bug, the container can only harm the containers content. Most problems exists in the custom created software in the container (e.g. web-services with bugs, backdoors, ....), this will be a problem for Docker, VMs, Real-Servers, whatever too. The real problem is the interoperability of different con…

> A container is a container, as long as docker itself has not bug, the container can only harm the containers content.

So given that there are no bugs and as long as the Linux kernel is free from local privilege escalation exploits. That seems long odds to trust in.

Re: The sad state of sysadmin in the age of containers

#77
post #75
post #61

Earlier quoted context omitted.

There's a huge difference. > Maybe the author regularly does full audits of the source code of every package he downloads, and of course disassembles every executable and library in the underlying OS, but most of us don't. What matters is that the source code is auditable. It only takes one person to investigate something suspicious, raise a flag and get it fixed. This is certainly still true for Debian - not being a…

Assuming you: - trust your compiler and linker - trust your tar extractor / package manager / whatever - trust your editor - trust your http library (or whatever you used to download/distribute the code)

>> - trust your http library (or whatever you used to download/distribute the code)

This can be overcome with signing.

We're all well aware of how deep this rabbit-hole goes, however that doesn't mean that it's a good idea to throw all trust away.

Re: The sad state of sysadmin in the age of containers

#78
post #54
post #37

Earlier quoted context omitted.

Same for "framework" which is: I have no idea what I'm doing

Sometimes yes, but sometimes you started writing CGIs in C, then Perl, than you wrote your microframework, then you decided to use a standard one. This has been my evolution and even if I don't understand everything inside the frameworks I'm using now I have a general idea. And furthermore, what can we do about it? Writing code from scratch or maintaining or own frameworks is more or less the way to losing customers,…

If more people went through that process, the frameworks we have might be fewer and of better quality.

Re: The sad state of sysadmin in the age of containers

#79
post #11

make is the least-auditable build tool imaginable. You don't have to obfuscate a Makefile, they come pre-obfuscated; you could put the "own me" commands right there in "plain" Make. Not to mention that it's often easier to tell whether a Java .class file is doing anything nefarious than whether a .c file is. How many sysadmins read the entire source of everything they install anyway? Maven, on the contrary, is the bi…

"Small jars that do one thing well. "

Oh, the "unix" philosophy.

Re: The sad state of sysadmin in the age of containers

#80

    This rant is about containers, prebuilt VMs, and the incredible mess they cause because their concept lacks notions of "trust" and "upgrades".
Prebuild VMs? Sure, I wouldn't touch them except for evaluating a project, and for commercial software you may not have a choice.

But docker containers at least usually provide a dockerfile that describes exactly how a binary image is built. You just clone the source repo, audit the few lines of build commands and then build your own private registry. It's nearly no more trust than following the instructions of README or INSTALL. Just because fools are pulling down pre-build images and running in their datacentre, doesn't mean that's what way you should do it. And the problem with 'old-school' sysadmins is they are often far too quick to reject new practices, citing tired excuses based on misunderstandings of the technologies.

    Ever tried to security update a container?
Yeah I have. It's easy if you have already built your 'stack' to scale horizontally (which means you have at least 2 or more of everything in a HA or LB config). You rebuild against a fully patched base-OS container, spin-up, send some test load to it & validate, then bring into service. Repeat for rest of nodes at that tier.

If you are trying to be an old-school sysadmin that expects to console or SSH in and run 'yum upgrade' or 'apt-get upgrade' your containers then you are doing containers wrong...

Post reply on HN