Hacker News Reader

Comment by eikenberry | Hacker News Reader

> but if you are doing container security correctly

Doing it correctly should be the case using the default settings. Defaulting to an insecure setup is a bug.

Hmm. Perhaps this is a difference between dev and ops, but almost every tool we use comes out of the box with settings unfit for production. Instead, they're tuned for development, and in some cases, deploying to a staging environment. At least, this has been the case in my experience.

Ah, dev... ops... How about DevOps? As a (originally) dev I bring my app to production. How do I stand a fighting chance to reconfigure the defaults in the way you suggest, without suddenly gaining a whole new set of skills? Good defaults would be helpful, even if they're very conservative. I can break things open, but at least then I know what to read up on.

100% agree here. Ship with secure settings by default and have simple "developer guides" that show what to crack open for easier use in non-production environments.

I would argue the opposite. As a developer I want to have tools that make my life easier to - you guessed it - develop. Enabling unnecessary secure defaults that either hinder or don't apply to my use case is silly.

There's a reason most users choose Ubuntu over OpenBSD as their workstation. I would put good money on the reason is because it's "secure enough" without getting too heavy handed on production use cases.

However, I do agree that there has to be a balance. Most tooling I write tends to lean more towards the "good user experience" side first, and then document the production use case. Either that or release two separate (but similar) products; one for developers, one for operations teams. Docker's doing that with the Community Edition/Enterprise Edition, but I still think the Community Edition is far too heavy-handed when it comes to things like pulling images from "insecure" registries.

> As a developer I want to have tools that make my life easier to - you guessed it - develop. Enabling unnecessary secure defaults that either hinder or don't apply to my use case is silly.

The problem is a lot of these insecure defaults will be rolled to production by a "developer" only to get hacked later. Because the marketing and friction-less dev is more important then sane default security

> Over a quarter of MongoDB databases left open to the internet have been ransacked by online extortionists.[0]

They "forgot"/"did not know" the password is not set. This was for db tech.

Now you want your average dev, who is getting "forced" to use docker more and more. To know how to setup container tech secure?

But hey, I need to get this on my CV and it is just click click install. So what can go wrong?

[0]: http://www.zdnet.com/article/mongodb-ransacked-now-27000-dat...

You're touching upon a natural tension, where developers take certain shortcuts that operations people then have to solve, which, I suppose, DevOps practices try to solve. The developers pay the price of less freedom for that, or if you will, the price of (production) reality. If that's not what your shop is doing, then what you say makes sense to me, and clearly DevOps practices aren't for everyone.

I don't think the contention is necessary in most cases. You can make something developer friendly and secure at the same time, you just have to allow for both. Simple things, like taking any credentials from environment settings, can make it easy for both dev and ops/prod to work with and be secure.

Reply on news.ycombinator.com