5 ms·

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

by geggam 11y ago

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.

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

by 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.