I haven’t seen this posted yet here, but anybody self-hosting OwnCloud in a containerized environment may be exposing sensitive environment variables to the public internet. There may be other implications as well.
I haven’t seen this posted yet here, but anybody self-hosting OwnCloud in a containerized environment may be exposing sensitive environment variables to the public internet. There may be other implications as well.
The only thing that makes this case worse in docker is that more info is in ENV variables. The vulnerability has nothing to do with containers though, and using ENV variables to provide sensitive data is in general a bad decision, since they can be leaked to any process with /proc access.
Unfortunately, ENV is still a common way which people use to pass data to applications inside containers, but it is not in any way a requirement imposed by the tech.
I’m using Kubernetes and many of the apps that I use require environment variables to pass secrets. Another option is the pod definition, which is viewable by anybody with read privileges to K8s. Secrets are great to secure it on the K8s side, but the application either needs to read the secret from a file or you build your own helm chart with a shell front end to create app config files on the fly. I’m sure there are other options, but there’s no “one size fits all” type solution.
The real issue here is that the app is happy to expose it’s environment variables with no consideration given to the fact that it may contain data that can be misused by bad actors. It’s security 101 to not expose any more than the user needs to see which is why stack dumps are disabled on production implementations.
what are the other alternatives to ENV that are more preferred in terms of security?
A named volume for the config directory for one.
That’s just as insecure lol, env vars are far better
It’s probably best to look at what the devops industry is embracing, environment variables are as secure as any of the alternatives but poor implementations will always introduce attack vectors. Secret management stores require you to authenticate, which requires you to store the credential for it somewhere - no matter what there’s no way to secure an insecure implementation of secrets access
No, but it only happens because this tech exists in the first place and things got way more cumbersome and way overcomplicated than they should be.