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