<p>Your updated question completely changed my understanding :)</p>

<p>Since the db is on a user-defined bridge in both cases, the advantages of using user-defined vs legacy/default bridges discussed in the doc section you referenced (which are applicable in both cases) aren't what differentiates the 2 cases. From that perspective they're equivalent.</p>

<p>Original Answer:</p>

<p>I think most/all of the differences between the legacy/default bridge and the user-defined ones listed in the doc section you referenced are pretty objective advantages :)</p>

<p>For your particular question, in <code>User-defined bridges provide better isolation and interoperability between containerized applications</code> we see:</p>

<blockquote>
  <p>Using a user-defined bridge, only the web port needs to be opened, and
  the database application doesn’t need any ports open, since the web
  front-end can reach it over the user-defined bridge</p>
</blockquote>

<p>Since in such case the db doesn't have open ports it can't be accessed from the outside, so all threats associated with having the db reachable from the outside are avoided.</p>

CC BY-SA 4.0
2019-02-01T12:54:16.217Z
Yes ... but: _"Since in such case the db doesn't have open ports it can't be accessed from the outside, so all threats associated with having the db reachable from the outside are avoided."_ but doesn't it get the same level of protection when attached to the same bridge as the load-balancer? Here again, there are no _exported_ ports (in both architectures, the db ports are _open_). I still don't see the advantage of deploying _two_ virtual bridge networks instead of _only one_ if someone exploits a vulnerability of the web application. Or did I missed something obvious?
Sylvain Leroux
CC BY-SA 4.0
2019-02-01T12:59:02.950Z
I realize my question was not clear. It ws not about "legacy" bridge vs "user-defined" one. It is really about "**one** user-defined bridge" vs "**two** user-defined bridges". I will add a picture to make the question more clear ;)
Sylvain Leroux
CC BY-SA 4.0
2019-02-01T13:31:28.560Z
_"I will add a picture to make the question more clear"_ done
Sylvain Leroux
CC BY-SA 4.0
2019-02-01T14:03:40.607Z
Ah, totally different context :)
Dan Cornilescu
CC BY-SA 4.0
2019-02-01T12:40:49.493Z
2019-02-01T14:27:56.320Z
2019-02-01T14:27:56.320Z
Dan Cornilescu
<p>I have a simple system made of a database backend, several instances of a web application and a load balancer. Each service is running in its own Docker container, all of them being hosted on the same physical server. The load balancer listens on the port 80 which is mapped to the same port on the host. All ingress/egress traffic is supposed to pass through that load balancer.</p>

<p>Currently, all those containers are attached to a single <a href="https://docs.docker.com/network/bridge/#differences-between-user-defined-bridges-and-the-default-bridge" rel="nofollow noreferrer">user-defined bridge</a>.</p>

<p>I read it would be better to connect the load balancer and the app instances through one bridge, and the app instances and the database through a second one. <em>Instinctively</em>, it makes sense to avoid putting the DB on the public-facing bridge. But <em>objectively</em>, in a dockerized environment, <strong>what are the benefits of using two bridge networks instead of only one here?</strong> Which kind of threats is mitigated by doing so?</p>

<p><a href="https://i.sstatic.net/W1CTK.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/W1CTK.png" alt="One user-defined bridge vs two user-defined bridges. Which is the best?"></a></p>

<docker><deployment><networking>
What are the benefits of spreading the various services of a multi-tiers application over several user-define bridges?
Sylvain Leroux
# What are the benefits of spreading the various services of a multi-tiers application over several user-define bridges?

(Asked by: username_0 on 2019-01-31)

I have a simple system made of a database backend, several instances of a web application and a load balancer. Each service is running in its own Docker container, all of them being hosted on the same physical server. The load balancer listens on the port 80 which is mapped to the same port on the host. All ingress/egress traffic is supposed to pass through that load balancer.

Currently, all those containers are attached to a single [user-defined bridge](https://docs.docker.com/network/bridge/#differences-between-user-defined-bridges-and-the-default-bridge).

I read it would be better to connect the load balancer and the app instances through one bridge, and the app instances and the database through a second one. *Instinctively*, it makes sense to avoid putting the DB on the public-facing bridge. But *objectively*, in a dockerized environment, **what are the benefits of using two bridge networks instead of only one here?** Which kind of threats is mitigated by doing so?

[![One user-defined bridge vs two user-defined bridges. Which is the best?](https://i.sstatic.net/W1CTK.png)](https://i.sstatic.net/W1CTK.png)

**Tags:** docker, deployment, networking


---

## 1 answers

### Answer by username_1 on 2019-02-01. Score: 1

Your updated question completely changed my understanding :)

Since the db is on a user-defined bridge in both cases, the advantages of using user-defined vs legacy/default bridges discussed in the doc section you referenced (which are applicable in both cases) aren't what differentiates the 2 cases. From that perspective they're equivalent.

Original Answer:

I think most/all of the differences between the legacy/default bridge and the user-defined ones listed in the doc section you referenced are pretty objective advantages :)

For your particular question, in `User-defined bridges provide better isolation and interoperability between containerized applications` we see:

> Using a user-defined bridge, only the web port needs to be opened, and
> the database application doesn’t need any ports open, since the web
> front-end can reach it over the user-defined bridge

Since in such case the db doesn't have open ports it can't be accessed from the outside, so all threats associated with having the db reachable from the outside are avoided.

> **Comments:**
> **username_0**: Yes ... but: _"Since in such case the db doesn't have open ports it can't be accessed from the outside, so all threats associated with having the db reachable from the outside are avoided."_ but doesn't it get the same level of protection when attached to the same bridge as the load-balancer? Here again, there are no _exported_ ports (in both architectures, the db ports are _open_). I still don't see the advantage of deploying _two_ virtual bridge networks instead of _only one_ if someone exploits a vulnerability of the web application. Or did I missed something obvious?  
> **username_0**: I realize my question was not clear. It ws not about "legacy" bridge vs "user-defined" one. It is really about "**one** user-defined bridge" vs "**two** user-defined bridges". I will add a picture to make the question more clear ;)  
> **username_0**: _"I will add a picture to make the question more clear"_ done  
> **username_1**: Ah, totally different context :)  

---

