Kubernetes Security: 10 Best Practices from the Industry and Community | Hacker News Reader

Kubernetes Security: 10 Best Practices from the Industry and Community

cast.ai

31 pointsItchyner17 comments

> It’s a good practice to have your objects use a secret in an environment variable since other parts of your system can access environment variables.

Was this generated by ML?

They didn't even mention the alternative to this statement. I've only ran applications with environment variables. And since they're allowed everywhere (lambdas, docker images, heroku and whatnot), It's hard to imagine how passing credentials into code, could've been done otherwise.

The two other ways I’ve seen is a direct dependency on the secrets manager or injecting files.

Environment variables seem to be the standard.

Direct dependency is usually bad and injecting files violates the immutable nature of a container.

I wouldn't consider binding files to be a violation of container immutability, which is how K8S secrets work.

It sounds confusing but is correct. Passing secret environment variables in a way that protects from someone gaining either RCE or another information disclosure avenue (e.g. a Symfony debug toolbar exposing PHP's $_SERVER) is hard. Using k8s-managed secret files (that are technically done as a Docker bind-mount) helps against unintentional information disclosure avenues, but still are vulnerable against an attacker who has achieved RCE (as they can simply execute a cat /var/run/secrets/...)

I think it's confusing because it was really poorly phrased:

    1. DON'T keep secrets in an environment variable

    It's a GOOD PRACTICE to have your objects use a secret in an environment variable

So which one is it? Don't keep secrets in env vars, or it's good practice to keep secrets in env vars?

Personal opinion: the second. If the container is popped so you can read environment variables, you can read files too.

Not always. Stuff like exposed debug toolbars or over-exposing stacktraces can leak environment variables, but (usually not) files.

It's not correct because he states "That’s why it’s best to use secrets as files", this is event worse than store in on ENV because in this case you just need read access to the file system instead of needing code execution, if you have RCE with the same privilege level of the application you will have access to the secret anyway.

RCE is game over, no matter what you do, but leaking environment variables can easily happen via stacktraces or debug settings.

We're using Vault to create ephemeral database credentials for our services that are rotated every other hour, for that use case envs are not even viable because they're injected at startup and then never again.

So how do you get the pods to read the new credentials?

The pods would have to either read directly from Vault, or a k8s controller which has vault access. In big brain fashion, one could also hard fail on a db auth failure so new pods - with the new secrets - can be spun up.

Also unless your business is being a cloud provider: don’t install kubernetes - this genuinely solves almost all k8s security issues and lets you spend time on what’s unique to your business. There’s a reason kubernetes has become synonymous with overengineering.

This should probably be flagged as a product pitch, since it ends with "oh, look, this is challenging, but we have this solution for ... all of it".

There really isn't a lot of structure here, although disabling NET_RAW is always a good tip (unless you're shoving telco workloads into containers, that is).

I haven't used Kubernetes for a while, but shouldn't kube-bench (1) be enough? Do you have to check anything manually?

(1) https://github.com/aquasecurity/kube-bench

maybe I've missed but also it's important to protect etcd with TLS, firewall

Reply on news.ycombinator.com