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