The sad state of sysadmin in the age of containers

I agree that the "just curl this into bash" instructions are nightmare - on any platform.

I think a lot of this is a result of what I like to call the "Kumbaya approach to project/team management":

This is where you have a team (either for a single project or a team at a consulting agency, etc) that is effectively all development-focused staff, possibly with some who dabble in Infrastructure/Ops. In this environment, when a decision about something like "how do we get a reliable build of X for our production server deployment system" needs to be made or a system needs to be supported, no idea is "bad", because no one has the experience or confidence to be able to say "that's a stupid idea, we are not making `curl http://bit.ly/foo | sudo bash` the first line of a deployment script"[1]

[1] yes this is an exaggeration, but there are some simply shocking things happening in real environments, that are not far off that mark.

Edit: to make it absolutely clear about what I was referring to with [1]:

The specific point I was making was running something they don't even see (how many people would actually look at the script before piping it to bash/sh ?) from a non-encrypted source, and relying on a redirection service that could remove/change your short url at any time.

Unfortunately I was stupid enough to ddg it (duckduckgo it, as opposed to google it) and apparently this exact use-case was previously the recommended way of installing RVM[2]

[2] http://stackoverflow.com/questions/5421800/rvm-system-wide-i...

-

I'd love a specific counter-example. I've never in my life encountered a sysadmin who read all or even part of the source code of any major package before deploying it. I mean, do you read the source code of the Linux kernel, PostgreSQL, nginx, OpenSSL, ... before installing it?

If Basel requires that level of auditing, I'd love to see a cite. There are some pretty heavy-handed regulations out there, but this would be clearly unworkable.

In defense, it's too expensive to do in house. However, security software and some operating systems, either closed source or open, are evaluated under Common Criteria (https://www.commoncriteriaportal.org/) But the evaluation process is rather long and often lags behind the current version by a year or more in some cases.

Not even close. Docker now has some terribly attempts at signing images on their registry iirc (docker inc signs them for the docker client).

There is no option for me, as a user, to build and sign my own image with my own pgp key afaik. My organization might already have a chain of trust, and docker is asking me to ignore that and just trust their signatures (which also only work on dockerhub as of docker 1.5... don't know about 1.6 because you can't use docker for at least a month after a release else security holes galore).

Docker did nothing to encourage signing containers. At 1.0 they had no capability to do any signature, verification, whatsoever. It's being added as an afterthought, and poorly.

If you look at the AppContainer specs, signatures (pgp based) were built in from the very beginning, it lets me create my own chain of trust (including incorporating other's keys), sign my own images, trust someone elses signature, does not trust the transport or storage medium, and has integration with the clients.

If you want to convince me docker cares, you're going to have to give me examples of where they didn't fuck up...

Tell me how I can use docker's tools to sign my own images, optionally trust my friend Alice, and securely download images that she uploaded to her own registry or dockerhub but signed with her gpg key without me having to trust docker inc.

To my knowledge, all docker has right now is doing a 'tarsum' of images which assumes the registry is trusted and, even given that, can be downgraded for backwards compatibility reasons fairly trivially.

I want to work there too, except if that means that I will be the one having to read through all open-source code before it is deployed.