5 ms·

What happens if there is a security flaw somewhere in your software stack? (kernel, web server, etc.) Do you end up having to update multiple containers with t

by jfoster 11y ago

What happens if there is a security flaw somewhere in your software stack? (kernel, web server, etc.) Do you end up having to update multiple containers with the same patch? Context: I've looked at Docker, but not used any containerization yet.

geggam 11y ago
Security ? How do you find out what libraries / versions are in a container ? ... you are pulling the curtain dont look back there :)
- NeutronBoy 11y ago
  > Security ? How do you find out what libraries / versions are in a container ? ... The same way you do in any application, container or not - you look up your documentation ;)
- jfoster 11y ago
  Is that really the state of things? It is what I concluded after looking into this a bit for Docker, but it seems incredible to me that so many companies are jumping into this idea of containerization without any good & available solutions for this problem. One potential solution that came to mind was that if there was a standard way of deploying an application into containers, and Google/Amazon/Microsoft provided auto-updating containers, the maintenance of a secure container would be in the hands of companies who (hopefully) have the resources necessary to keep the entire stack up-to-date.
  - digi_owl 11y ago
    They seem to be betting the farm on the containerization will contain (heh) whatever security issues that come up. This in the sense, i guess, that if they have a security flaw in their php that gives disk access, all the attacker will see is the content of the php container as the database will be on the next container over. Then again the containerization seems to have come alongside devops, where the mantra seems to be "update early, update often, to hell with stable branches".
    - jfoster 11y ago
      I've heard of that approach (breaches being limited to a container), but I don't think it makes sense. If a security flaw exists in one container due to the stack not being updated, isn't there a pretty good chance that it also exists in the other containers? Also, for any given container, there probably still is a way for an attacker to do immense amounts of damage. With the database container you can steal customer data. With the PHP container you can remotely instruct the database to do whatever you want, or just point the code at your own database.
      - u02sgb 11y ago
        Depends what the security flaw is. If it's (as discussed above) a php error, it's unlikely to be in your database container.
  - justingood 11y ago
    We tend to handle that part inhouse. We're using Jenkins and have it set up to build a standard set of base images with all the latest updates daily. It can be run on-demand as well. All containers running code are based on these images, so the updates are picked up on the next build/deploy.
- superuser2 11y ago
  If you are SSHing into a container, interrogating the version, and upgrading it manually, you're doing it wrong. Pull a new base image, have your build system rebuild and deploy the relevant containers.
voltagex_ 11y ago
What do people think about building static binaries in Docker containers? I'm a big fan of the busybox base image and nothing else.
- ubercow 11y ago
  When building a container, I personally look at the docker-alpine [1] image and see if I can just use that. Since it's musl instead of glibc, there are some incompatibilities with things like Oracle JVM, but it's a great runtime container for dynamic languages like Ruby and Python, especially if you need some additional libraries or helper programs. Love it for quick scripting containers (like netcat) too since it downloads in line 2 seconds. [1]: https://github.com/gliderlabs/docker-alpine https://github.com/gliderlabs/docker-alpine
transitorykris 11y ago
We've had some success with auditing containers and saving the results to a DB (for instance, running containers you can easily exec, say, 'dpkg -l'). If a package has a security issue, you know which containers have it, and you kick of your CI/CD to rebuild and redeploy with the fixed package.
cpuguy83 11y ago
I don't see how containerization changes your security strategy in this regard, except instead of ssh'ing into a system and running `apt-get update && apt-get install ...`, you `docker build && docker run`

by jfoster 11y ago

geggam 11y ago

Security ? How do you find out what libraries / versions are in a container ? ... you are pulling the curtain dont look back there :)

NeutronBoy 11y ago
> Security ? How do you find out what libraries / versions are in a container ? ... The same way you do in any application, container or not - you look up your documentation ;)
jfoster 11y ago
Is that really the state of things? It is what I concluded after looking into this a bit for Docker, but it seems incredible to me that so many companies are jumping into this idea of containerization without any good & available solutions for this problem. One potential solution that came to mind was that if there was a standard way of deploying an application into containers, and Google/Amazon/Microsoft provided auto-updating containers, the maintenance of a secure container would be in the hands of companies who (hopefully) have the resources necessary to keep the entire stack up-to-date.
- digi_owl 11y ago
  They seem to be betting the farm on the containerization will contain (heh) whatever security issues that come up. This in the sense, i guess, that if they have a security flaw in their php that gives disk access, all the attacker will see is the content of the php container as the database will be on the next container over. Then again the containerization seems to have come alongside devops, where the mantra seems to be "update early, update often, to hell with stable branches".
  - jfoster 11y ago
    I've heard of that approach (breaches being limited to a container), but I don't think it makes sense. If a security flaw exists in one container due to the stack not being updated, isn't there a pretty good chance that it also exists in the other containers? Also, for any given container, there probably still is a way for an attacker to do immense amounts of damage. With the database container you can steal customer data. With the PHP container you can remotely instruct the database to do whatever you want, or just point the code at your own database.
    - u02sgb 11y ago
      Depends what the security flaw is. If it's (as discussed above) a php error, it's unlikely to be in your database container.
- justingood 11y ago
  We tend to handle that part inhouse. We're using Jenkins and have it set up to build a standard set of base images with all the latest updates daily. It can be run on-demand as well. All containers running code are based on these images, so the updates are picked up on the next build/deploy.
superuser2 11y ago
If you are SSHing into a container, interrogating the version, and upgrading it manually, you're doing it wrong. Pull a new base image, have your build system rebuild and deploy the relevant containers.

voltagex_ 11y ago

What do people think about building static binaries in Docker containers? I'm a big fan of the busybox base image and nothing else.

ubercow 11y ago
When building a container, I personally look at the docker-alpine [1] image and see if I can just use that. Since it's musl instead of glibc, there are some incompatibilities with things like Oracle JVM, but it's a great runtime container for dynamic languages like Ruby and Python, especially if you need some additional libraries or helper programs. Love it for quick scripting containers (like netcat) too since it downloads in line 2 seconds. [1]: https://github.com/gliderlabs/docker-alpine https://github.com/gliderlabs/docker-alpine

transitorykris 11y ago

We've had some success with auditing containers and saving the results to a DB (for instance, running containers you can easily exec, say, 'dpkg -l'). If a package has a security issue, you know which containers have it, and you kick of your CI/CD to rebuild and redeploy with the fixed package.

cpuguy83 11y ago

I don't see how containerization changes your security strategy in this regard, except instead of ssh'ing into a system and running `apt-get update && apt-get install ...`, you `docker build && docker run`