Mailing List Archive

Security of docker is still a hot topic. Some people believe that the
fact that the application runs in a container adds a layer of security
that allows for a somewhat slower adoption of security patches. I
don't share that vision at all. The applications are running for a
reason - they might be processing customer data, hosting credential
information, ... which in case of vulnerabilities can still be
disclosed.

So it is wise to first take a step back and see what you see under security.

There is the security of the underlying host, and the CIA
(Confidentiality, Integrity, Availability) concerns of all
applications (including docker containers) that are running on that
host. Hosts that support Docker containers will very much want to
harden the environment to provide at least resilience against attacks
and have some sort of protective measures so that problems on one
container cannot jeopardize other containers/customers.

Then you have the security of the docker platform itself: mostly the
daemon, but also the processes that are involved. Running only trusted
containers, making sure the authentication/authorization aspects are
up to par, etc.

Then there is the security of the container infrastructure
(namespaces, kernel itself, ...) which has to be closely followed up
on.

And then finally you have the security of the applications running
inside the container.

For a truly secure environment, all four areas need to be under
control. In most cases, containers do not improve security, because
they do not improve the controls that are in place on the application
level. And after all, docker containers are running applications
(possibly business applications) and it is vulnerabilities or
misconfigurations in those applications that are readily visible as a
"secure" versus "non-secure" setup. That it runs on Docker, or a
virtualization layer like VMWare or Xen or KVM, or on dedicated
systems, or somewhere in the cloud, has no bearings on that.

My 2 cents,

Sven Vermeulen

On Wed, Feb 25, 2015 at 9:11 PM, Alex Efros <powerman@powerman.name> wrote:
> Hi!
>
> What is recommended way to update Docker containers with Gentoo?
>
> I mean, each container is supposed to be small and unique, having
> installed only packages needed for app which will run in this container.
> So, with 100 different apps we may have 100 different containers with
> Gentoo, each with custom set of packages, and even same packages may be
> built with different USE-flags or using different versions - that's the
> main point of Docker, provide each app with environment it needs.
>
> But Gentoo release updates every few hours, some of them are important
> security updates, so at a glance it looks like we'll have to rebuild and
> restart all containers every few hours/days, and we'll have to compile all
> packages multiple times - once per each container - which isn't acceptable
> at all because of too much CPU resources needed (but it should be possible
> to mitigate this by using binary packages in cases when USE flags match
> and ccache to speedup other cases).
>
> Am I missing something, or only way to keep Docker containers secure is
> rebuild all containers each time I run `emerge --sync && emerge -uDN world`
> on host?
>
> --
> WBR, Alex.
>

I agree with containers do not improve security. It is a business solution
quite useful for Cloud services, developers, and maybe in the future to
isolate desktop apps like QubeOS with Xen, but is fairly new so it lacks
certain security requirements. Imho this basically add more complexity to
exploitation, but not a mitigation or a real solution.

However there are a interesting talk I attended in DevConf from Dan Walsh
https://www.youtube.com/watch?v=725rsC7NS44.




On Thu, Feb 26, 2015 at 8:53 AM, Sven Vermeulen <sven.vermeulen@siphos.be>
wrote:

> Security of docker is still a hot topic. Some people believe that the
> fact that the application runs in a container adds a layer of security
> that allows for a somewhat slower adoption of security patches. I
> don't share that vision at all. The applications are running for a
> reason - they might be processing customer data, hosting credential
> information, ... which in case of vulnerabilities can still be
> disclosed.
>
> So it is wise to first take a step back and see what you see under
> security.
>
> There is the security of the underlying host, and the CIA
> (Confidentiality, Integrity, Availability) concerns of all
> applications (including docker containers) that are running on that
> host. Hosts that support Docker containers will very much want to
> harden the environment to provide at least resilience against attacks
> and have some sort of protective measures so that problems on one
> container cannot jeopardize other containers/customers.
>
> Then you have the security of the docker platform itself: mostly the
> daemon, but also the processes that are involved. Running only trusted
> containers, making sure the authentication/authorization aspects are
> up to par, etc.
>
> Then there is the security of the container infrastructure
> (namespaces, kernel itself, ...) which has to be closely followed up
> on.
>
> And then finally you have the security of the applications running
> inside the container.
>
> For a truly secure environment, all four areas need to be under
> control. In most cases, containers do not improve security, because
> they do not improve the controls that are in place on the application
> level. And after all, docker containers are running applications
> (possibly business applications) and it is vulnerabilities or
> misconfigurations in those applications that are readily visible as a
> "secure" versus "non-secure" setup. That it runs on Docker, or a
> virtualization layer like VMWare or Xen or KVM, or on dedicated
> systems, or somewhere in the cloud, has no bearings on that.
>
> My 2 cents,
>
> Sven Vermeulen
>
> On Wed, Feb 25, 2015 at 9:11 PM, Alex Efros <powerman@powerman.name>
> wrote:
> > Hi!
> >
> > What is recommended way to update Docker containers with Gentoo?
> >
> > I mean, each container is supposed to be small and unique, having
> > installed only packages needed for app which will run in this container.
> > So, with 100 different apps we may have 100 different containers with
> > Gentoo, each with custom set of packages, and even same packages may be
> > built with different USE-flags or using different versions - that's the
> > main point of Docker, provide each app with environment it needs.
> >
> > But Gentoo release updates every few hours, some of them are important
> > security updates, so at a glance it looks like we'll have to rebuild and
> > restart all containers every few hours/days, and we'll have to compile
> all
> > packages multiple times - once per each container - which isn't
> acceptable
> > at all because of too much CPU resources needed (but it should be
> possible
> > to mitigate this by using binary packages in cases when USE flags match
> > and ccache to speedup other cases).
> >
> > Am I missing something, or only way to keep Docker containers secure is
> > rebuild all containers each time I run `emerge --sync && emerge -uDN
> world`
> > on host?
> >
> > --
> > WBR, Alex.
> >
>
>


--

Francisco Alonso.
http://twitter.com/revskills
PGP: 0xE2E64DCA
--

Hi!

On Thu, Feb 26, 2015 at 11:35:34AM +0100, F. Alonso wrote:
> I agree with containers do not improve security.

I agree too, but my original question was about how to avoid LOWERING
security if we move ours apps/services into containers.

I didn't expect containers to really increase security (but some extra
isolation and resource management doesn't harm, and extra cost of running
docker daemon looks like acceptable trade-off for LXC ease to use).

--
WBR, Alex.

On Wednesday, February 25, 2015 22:11:55 Alex Efros wrote:
> What is recommended way to update Docker containers with
Gentoo?

docker pull ${NEW_IMAGE}

Somewhat sarcastic but actually true. I don't recommend running
production applications inside of Gentoo based containers.

I highly recommend making containers as small as possible. That
means using statically linked executables and removing all
traces of what we know as a distribution. Production containers
should not be based on Gentoo images.

I see the Gentoo docker images as bases for testing Gentoo
itself which includes making Gentoo an appropriate environment
for running the docker daemon.

I'm sure this *opinion* won't be popular but I feel it's the
right way to go with containerization.

This would still necessitate rebuilding your containers to get
security updates but you could do that in response to CVEs or
other problems in your application without worrying about being
on the bleeding edge.

If you haven't seen gentoo-bb you should check it out.

Regards,

--
Alex Brandt
Cloud Evangelist for Rackspace and Developer for Gentoo
http://blog.alunduil.com

Hi!

On Fri, Feb 27, 2015 at 10:38:34AM -0600, Alex Brandt wrote:
> Somewhat sarcastic but actually true. I don't recommend running
> production applications inside of Gentoo based containers.

This makes sense for Gentoo, but my question was CC: to this list not as
off-topic, my host will be Hardened Gentoo, so kernel used by docker
images will support GrSecurity&PaX, and I wanna have protection provided
by hardened gcc for binaries run inside docker images.

> I highly recommend making containers as small as possible. That
> means using statically linked executables and removing all
> traces of what we know as a distribution. Production containers
> should not be based on Gentoo images.

Okay, not sure why it's so important, but this doesn't change anything -
these statically linked executables without any traces of Gentoo still
should be compiled with hardened gcc.

> docker pull ${NEW_IMAGE}

So, what $NEW_IMAGE should be to let me get small nice image with
up-to-date binaries built with hardened gcc? :-)

--
WBR, Alex.

Let's turn this around.

What is the business case for containerization when security is so
loose and ill-defined right now?

On Thu, Feb 26, 2015 at 7:20 PM, Alex Efros <powerman@powerman.name> wrote:
> Hi!
>
> On Thu, Feb 26, 2015 at 11:35:34AM +0100, F. Alonso wrote:
>> I agree with containers do not improve security.
>
> I agree too, but my original question was about how to avoid LOWERING
> security if we move ours apps/services into containers.
>
> I didn't expect containers to really increase security (but some extra
> isolation and resource management doesn't harm, and extra cost of running
> docker daemon looks like acceptable trade-off for LXC ease to use).
>
> --
> WBR, Alex.
>

On Fri, Feb 27, 2015 at 08:04:52PM +0200, Alex Efros wrote:
> Hi!
>
> On Fri, Feb 27, 2015 at 10:38:34AM -0600, Alex Brandt wrote:
> > Somewhat sarcastic but actually true. I don't recommend running
> > production applications inside of Gentoo based containers.
>
> This makes sense for Gentoo, but my question was CC: to this list not as
> off-topic, my host will be Hardened Gentoo, so kernel used by docker
> images will support GrSecurity&PaX, and I wanna have protection provided
> by hardened gcc for binaries run inside docker images.
>
> > I highly recommend making containers as small as possible. That
> > means using statically linked executables and removing all
> > traces of what we know as a distribution. Production containers
> > should not be based on Gentoo images.
>
> Okay, not sure why it's so important, but this doesn't change anything -
> these statically linked executables without any traces of Gentoo still
> should be compiled with hardened gcc.
>
> > docker pull ${NEW_IMAGE}
>
> So, what $NEW_IMAGE should be to let me get small nice image with
> up-to-date binaries built with hardened gcc? :-)

I am not that familiar with docker, but I thought the idea was that you
build your own container images with your requirements? ie re-build the
image just once on only one server and then send it around to all the
others.

Alternatively, if you did not want to re-build the images themselves,
you could always setup a gentoo binhost on one machine and make all the
other containers pull those packages so there will not be the wasted
time compiling.

-- Jason
>
> --
> WBR, Alex.
>

On Sat, Feb 28, 2015 at 3:58 AM, eric gisse <jowr.pi@gmail.com> wrote:
> Let's turn this around.
>
> What is the business case for containerization when security is so
> loose and ill-defined right now?

The promise (and depending on your context and regulations, this might
be true already as well) is that you can offer faster deployment of
application(s).

For instance, without containers development teams might need to
deploy to a non-production environment that is "shared" for all teams,
requiring rigid change management processes to make sure projects
don't step on other projects' toes.

With containers, development teams deploy their containers on a
non-production docker cluster without impact to other development
teams.

Security requirements here are a bit less than in production (due to
the non-production environment). When changes are matured, then change
management can bring this to the (non-Docker) production environment.

There are also of course possibilities to use containers in
production, but then the security management needs to be taken into
account again (which is definitely doable, just requires some
"different" thinking).

Wkr,
Sven Vermeulen