Juniper Networks Network Isolation with Contrail Demo

0:09 hi everybody my name is prasad i would

0:11 like to introduce three things here one

0:14 is the namespace isolation next is the

0:16 network policy

0:18 and the virtual network topology

0:22 so as michael mentioned earlier quest

0:25 when we create a cluster

0:27 typically we have a pod network and

0:29 service network

0:30 so we are calling that as a default pod

0:32 network and default service network

0:35 so all default part network on the

0:38 regular name spaces

0:39 when the pod is created it will be

0:42 working with this default part network

0:45 and the same thing if when we create a

0:46 service it's going to use the default

0:48 service network

0:50 so

0:51 as larry and others were asking earlier

0:54 like you know when we have the network

0:55 these networks are nothing but virtual

0:57 networks

0:58 which are based on the bgp

1:01 and uh each of this virtual network uh

1:03 would have a route target

1:06 uh you know when we create a virtual

1:08 network what we do is like you know we

1:09 have a export route target let's say rt1

1:12 and the import route target rt1

1:15 so so what that means is when we are

1:17 exchanging the routes for a given

1:19 virtual network

1:21 we will export with that route target

1:23 and

1:24 same thing when we import it we import

1:27 with that target

1:29 so

1:30 now if you see here we also can create

1:33 additional virtual networks

1:35 and

1:36 these virtual networks are not typically

1:38 connected until you know we use other

1:40 constructs to connect them using uh

1:43 import export

1:45 route targets

1:47 so so i will also demonstrate like you

1:49 know how we are going to control this uh

1:52 connectivity between virtual networks

1:54 so now given this namespace and you know

1:57 the basic power networking virtual

1:59 networks

2:01 i wanted to introduce this isolated

2:03 namespace

2:04 isolated namespace means like you know

2:06 we are trying to isolate that namespace

2:08 the pod network connectivity service

2:11 network and the uh any other virtual

2:13 networks

2:14 so that means

2:16 it's all internal and you know it can go

2:18 outside world towards to the you know

2:21 internet but

2:22 it won't be interacting with the other

2:24 isolated namespaces

2:27 you could do this with the you know

2:29 network policies but you know it's going

2:30 to be pretty cumbersome to do with that

2:36 so so let me go back to a

2:40 demo on that

2:51 so so here i'm creating a regular

2:52 namespaces called ns1 and ns2

2:57 um it looks like i already created them

3:01 and so then you know uh the uh i'm

3:04 creating the two parts on that uh

3:07 those isolated uh sorry those namespaces

3:12 after that like you know i'm creating

3:14 isolated namespaces

3:17 and creating two parts

3:22 so so as you can see here i have

3:25 two parts which are part one and part

3:27 two which are in ns1 and ns2 namespaces

3:32 and the other parts which are uh you

3:34 know iso uh a part isolated one iso iso

3:38 one in isolated namespace

3:40 isolated two is an isolated namespace

3:42 too

3:44 now

3:45 if i wanted to

3:47 cuddle exec minus i t

3:54 so i wanted to communicate between

3:57 test part one

4:00 which is in the regular isolated

4:02 namespace

4:10 link to the other

4:12 part which is in the other namespace

4:17 so i would be able to communicate or

4:18 vice versa

4:24 so so whereas if i go to the isolated

4:26 namespace parts

4:28 you know which is uh

4:33 so i'm bringing from

4:37 isolated namespace 1 to isolated

4:39 namespace 2.

4:42 and

4:43 you know the thing won't go through

4:44 because they are in two different

4:46 networks

4:47 and until they are connected you know uh

4:50 the

4:50 communication won't happen

4:54 so so this is uh the isolated namespace

4:56 concept

4:58 and the next one i wanted to demonstrate

5:00 is the network regular network policies

5:04 so as you see here i'm creating uh three

5:06 uh different uh tiers you know web

5:09 apptair and you know db tier

5:12 my network policies uh

5:14 uh you know this is a regular kubernetes

5:17 network policies

5:18 to show that like you know we work in

5:20 the application base to firewalling

5:23 so here i have three network policies uh

5:26 one is connecting between web to app and

5:29 app to db

5:31 so

5:32 because of this you know i should have

5:33 only communication between app to app

5:35 and app to db but not from you know web

5:38 to db

5:39 and if i don't have these network

5:41 policies you know i would be able to

5:42 communicate freely because uh there are

5:45 no network policies

5:46 so so let me uh

5:48 show that

5:50 so here as you see here i have um you

5:53 know network policies which are three

5:55 network policies

5:56 web tier app tier and db tier and also

6:00 you know there are three parts running

6:01 in the same default name space

6:09 so i'm going to take from part one

6:14 and try to communicate with part 2 which

6:17 is the

6:18 app web to app

6:28 and

6:29 so now i will try to communicate to the

6:31 db which is uh you know it should not

6:35 happen because you know we have the

6:36 network policies which are preventing

6:37 the traffic

6:40 and whereas if i go to part um

6:43 you know which is the web par sorry app

6:45 pod then i should be able to reach to

6:48 the dbe

6:50 and

6:52 if i remove the network policies

6:56 and i should be able to do the

6:58 communication between uh

7:00 you know any any to any

7:02 uh hence you know i have the

7:04 communication path

7:07 so

7:08 so this is a regular network policies uh

7:11 you know i just wanted to demonstrate

7:13 that

7:14 sorry prasad if you don't mind real

7:15 quick i think on that network policies

7:17 what's what's really interesting there

7:19 is also the way that we implement that

7:21 right is based upon some of those tags

7:23 um so you're not having to go through

7:24 and define by ip address right it's uh

7:26 it's really based upon the tags to to

7:28 define that policy

7:31 layers and layers in nicely too with the

7:33 name space isolation

7:35 that prasad kind of kind of walked

7:37 through initially you may ask yourself

7:39 kind of like well kubernetes provides

7:41 name space isolation right like what's

7:43 different here and really what's

7:45 different is that it's not done at a

7:46 networking layer um it's up to the cni

7:49 to do that so uh contrail is a cni we're

7:51 providing that segmentation for name

7:53 space isolation down to the networking

7:55 layers that's going to help prevent

7:56 things like lateral attacks uh some of

7:58 those types of scenarios you know if one

8:00 of your isolated pods for example

8:02 uh did get compromised when you have

8:05 name space isolation all the way down in

8:06 the network

8:08 that's correct so and just to add on on

8:10 top of what sean mentioned is uh

8:13 so so the v router when it implements we

8:16 use the tag based uh uh you know

8:18 comparisons instead of ip addresses

8:22 and also what that means is like you

8:23 know these stacks are exchanged through

8:25 the bgp

8:26 so for example as the let's say i have i

8:29 bring up a part called webpart

8:31 and which is tagged with you know tier

8:33 equal to web

8:35 and when we are exchanging this route

8:37 for this particular uh you know part

8:40 with tagged with the web

8:42 in addition to sending the route we also

8:44 send the tags along with it

8:46 in the uh bgp

8:48 so that makes it you know pretty

8:49 scalable and it reaches to the all the

8:52 other uh you know we routers

8:54 and all we're going to do is we're going

8:56 to use the tag id to do the our

8:58 comparisons so it becomes you know

9:00 pretty efficient uh

9:02 you know and pretty scalable

9:04 at the um you know we routed data path

9:07 layer so we don't have to have the

9:09 indirections uh

9:11 uh you know like ip tables or any other

9:13 things

9:14 yeah that's a great point two percent

9:16 because because we just you know you

9:17 just declare that through the ml files

9:19 so we go ahead and conceal the

9:20 complexity under the hood of handling

9:22 that between vgp

9:24 yeah great point so

9:27 so so the other area i i mean i wanted

9:30 to introduce is the virtual network

9:31 topology or the virtual network routing

9:34 so so as uh you know

9:37 michael demonstrated like you know we

9:38 have multiple clusters like you know a

9:42 virtual network which is a default

9:43 depart network in cluster one and you

9:46 have another uh uh default port

9:48 networking cluster two

9:50 so right now to communicate among those

9:53 we have constructs called like you know

9:54 a mesh network if we want you know we

9:56 can create a mesh network between

9:58 clusters

9:59 or this doesn't have to be across

10:01 clusters this could be inside a cluster

10:04 and same thing you know we have another

10:06 construct where like you know hub and

10:07 spoke relation between the virtual

10:09 networks

10:10 so what it gives you is the very

10:12 additional flexibility for the consumer

10:16 to do how these networks can be stitched

10:18 together

10:20 if you don't have this construct like

10:21 you know if everything is a flat network

10:24 you know it may not be advisable for

10:26 certain uh you know use cases

10:28 so that's where like you know we have

10:29 virtual networks using the bgp and you

10:32 know we stitch them as needed basically

10:34 so one is the you know mesh construct

10:36 other is the hub and spoke

10:39 so the big difference is like you know

10:40 when we have the you know mesh

10:42 everything is communicating to each

10:44 other

10:45 and when we have a hub and spoke like

10:47 you know hub hub and spokes can

10:49 communicate each other but not just

10:51 folks basically

10:53 all this is done through the uh you know

10:55 simple concepts like you know

10:57 using the rt import and exports

10:59 basically in a given virtual network

11:02 and everything is taken care by the bgp

11:04 constructs in the back end

11:07 yeah i think if i could add on to that

11:08 two percent the nice part here right

11:10 think about like your hub being some um

11:13 some common services that you want to be

11:15 able to support to these different spoke

11:17 uh virtual networks

11:18 but really the key takeaway here is that

11:20 the hub is non-transitive

11:22 right so you still have segmentation and

11:25 isolation done to your spoke virtual

11:26 networks um however you can you can also

11:30 you don't have to replicate services

11:31 within each one of those right you can

11:33 basically tie in some services into your

11:35 hub

11:36 that need to support the various

11:38 different spokes so it gives you that

11:39 layer of isolation

11:41 again down to the network level and that

11:43 can be applied across you know

11:45 multiple different environments whether

11:47 that's you know on-premises cloud what

11:49 have you um

11:51 all all with control so

11:53 so let me demonstrate that

11:58 so i have a namespace called

12:02 testns

12:03 and in here i have

12:05 created two labels for each virtual

12:08 network

12:10 one label is to create a vnr1 vnr1 mesh

12:12 other label is like you know vnr2

12:15 with a hub and spoke

12:17 so first let me create a

12:19 you know

12:20 you know mesh network and you know try

12:22 to ping each other so before that like

12:24 you know let me

12:27 uh show the parts which are in these uh

12:29 three networks

12:31 and cube cattle

12:33 get uh

12:35 vlr

12:36 minus and test ns

12:39 so i don't have any vnr's uh created um

12:42 uh here

12:44 so what that means is uh uh as you see

12:46 here test part 2 belongs to vn2 3

12:49 belongs to vn3 and 4 belongs to vn4

12:52 if i try to communicate among those

12:55 it it won't work because they are all

12:57 isolated virtual networks

13:06 actually let me have uh

13:08 why you're doing that prasad too i think

13:09 like you know the nice part about this

13:11 is like that default behavior of having

13:13 that isolation between your virtual

13:14 networks

13:16 it's a little bit of a different method

13:18 when you're when you're turning around

13:19 and deploying these uh these networks

13:21 for your kubernetes environment with

13:22 control right just gives you uh by

13:24 default um each one of those are gonna

13:27 provide this level of isolation from a

13:29 virtual network perspective

13:31 um and then you can declare where you

13:33 want connectivity

13:35 easily

13:37 as deans and kind of fits your

13:39 organizational policy

13:41 you may have different applications for

13:42 different uh different use cases some

13:45 things maybe internal other things may

13:46 be like external facing applications

13:49 as well

13:51 i have a question uh regarding the

13:54 assignment of virtual networks and what

13:55 the boundaries are um

13:58 if you want to assign something to a

14:00 virtual network is that done at the name

14:01 space level is that done at the pod

14:03 level um and can these virtual networks

14:06 i guess they can span clusters am i also

14:09 understanding that correctly

14:11 yes so basically when you create virtual

14:13 networks

14:14 uh it is you know under the name space

14:17 you can create

14:18 or you can create

14:21 at the higher level at the cluster level

14:24 so

14:25 if you see into the beginning uh

14:28 you know i we have a default part

14:29 network so which spans across multiple

14:32 namespaces

14:34 and whereas um you can create a virtual

14:36 network inside a namespace

14:38 uh you know as we are showing it here

14:41 and the other construct which you are

14:43 asking is among clusters

14:45 uh

14:46 you know we if it is a kubernetes uh i

14:50 mean if it is a cn2 cluster we can

14:52 create across the clusters but if you

14:55 have a c multiple c cn2 different

14:57 clusters as michael shown

14:59 then you know we use the connectivity

15:02 between these networks uh cluster one to

15:04 the other cluster

15:06 using the uh

15:07 one of the constructs which we are going

15:09 to use either mesh network or the hub

15:11 and spoke just to conclude on that yes

15:14 we definitely can span

15:16 a virtual network across clusters it

15:19 basically means what what do you what do

15:20 you mean by spanning so we can create

15:23 one layer two domain across multiple

15:26 clusters

15:27 serving the same

15:28 ip address of the same subnet across

15:31 clusters

15:32 the only thing you need to do is because

15:34 the ipaddress assignment is not going to

15:36 be synchronized but what we support is

15:38 in the subnet we can define a range out

15:42 of which we will assign ip addresses

15:45 to the pots so basically you can say

15:48 on my first cluster i'm going to use

15:51 dot one to 100 on my second cluster i'm

15:54 using 101 to 200 on my third cluster i'm

15:57 using 201 to

15:59 uh yeah 255 or 250 for depending on your

16:02 subnet size

16:03 um but the workloads themselves they

16:06 will think they are in one hugely true

16:09 domain so they can communicate

16:11 using uh normal layer two lookups

16:14 that is true or if you choose to have

16:17 each cluster has its own virtual default

16:19 virtual network and connect them also we

16:21 can connect

16:23 okay and any pod that gets created in a

16:25 name space that has a virtual network

16:28 will automatically be part of that

16:29 virtual network or is that something you

16:31 have to assign at the pod level

16:33 you have to assign that at the pot level

16:35 so per default the pod is

16:38 created in the default port network if

16:41 that part is part of a isolated

16:43 namespace it is going to

16:45 be created in the isolated namespace

16:48 default port network

16:50 which is different from the normal

16:52 default port network but if you want

16:54 then to even connect that pot to a

16:56 non-default port network so let's say

16:59 you want a secondary interface on your

17:00 port or third interface or fourth

17:02 interface you have to configure that on

17:05 the pod level so you need to tell the

17:06 pod as part of the annotation using the

17:09 network plumbing working group style

17:12 connect me a second interface or third

17:14 interface to a given virtual network

17:17 and just uh just to add at the the

17:19 distinction between

17:21 pod network assignment um at a pod level

17:24 or a name space level sorry um that

17:26 makes sense when you're when you're

17:28 isolating a set of workloads so

17:29 basically i want this whole set of

17:31 workloads to have their own virtual

17:32 network and to be kind of jailed off

17:34 from the rest of the pods but from the

17:36 pods perspective

17:38 it has a normal pod network connection

17:39 it has a normal service network

17:41 connection it just has its own little

17:42 copy of it

17:43 and then for multi-interface workloads

17:45 or whenever you're creating these

17:46 arbitrary virtual networks you want that

17:48 to be on an interface by interface basis

17:50 because you'll have like a network for

17:52 say inbound internet traffic and a

17:54 network for you know outbound

17:56 um services traffic or something you're

17:59 basically recreating a multi-interface

18:01 server using these network attachment

18:03 definitions within each cluster you've

18:05 got a virtual router that's handling

18:08 communication between the virtual

18:09 networks

18:11 um

18:12 is that also part of the architecture

18:14 yeah uh contral actually has a

18:15 distributed virtual router so the

18:17 routing takes place on every node in the

18:19 cluster so the the concept of the router

18:22 is logical it's it's everywhere in the

18:23 cluster so it's running as like a daemon

18:25 set on each each node in the cluster

18:31 and is there an opportunity to insert

18:33 firewalling and

18:35 you know rules of communication between

18:37 subnets

18:39 yeah there's a couple ways that we do

18:40 that network policy is the way that we

18:43 create firewall filters inside

18:45 kubernetes to filter out traffic and you

18:47 saw a little bit of that during prasad's

18:49 demo and then also we have another

18:51 construct that allows you to create

18:53 very flexible import and export policies

18:55 and a per prefix basis between all of

18:58 the virtual networks

18:59 so you've got a big stick and then

19:00 you've got the scalpel as well

19:02 okay

19:03 thank you

19:04 thank you

19:05 okay so so here

19:08 in this

19:09 use case we have created three parts

19:12 and as you see here

19:14 there are two interfaces for this part

19:17 one is in the default part network other

19:19 is in the test vn2

19:21 test vn3 and test pn4

19:23 so right now what we have done is uh

19:26 you know if i try to ping between this

19:30 the secondary interface which is the

19:31 test vn2 3 and 4

19:34 that communication won't happen because

19:36 there is no uh you know virtual network

19:39 router which is connecting them

19:42 so that work and i'm trying to do the

19:44 ping test between test part vn2

19:47 to vn3 rbn4

19:55 so i'm going to create a mesh network

19:58 control create minus f

20:01 test vnr mesh

20:07 so now the same ping test would go

20:09 through because um you know we have

20:11 created a mesh network

20:13 what that means is the each virtual

20:15 network is going to do the

20:18 import and export route targets

20:21 uh to the same route target so that the

20:23 mesh communication happens

20:26 and so i would like to demonstrate the

20:28 other

20:29 option which is the hub and spoke

20:36 so so with this like you know what we

20:38 have done is uh you know we have one hub

20:40 and you know two spokes which is vn2 is

20:43 the hub and you know vn 3 and 4 are

20:46 spokes

20:47 now i'm going to do another ping test uh

20:52 so so in this here like you know we are

20:54 doing um you know how to spoke

20:56 communication

20:57 then after that like you know we are

20:59 trying to do a spoke to sport

21:00 communication you know which should not

21:02 happen

21:03 uh because

21:04 that's what is the intended uh here

21:07 so all we are doing here is like you

21:09 know we have virtual networks using the

21:11 route targets to manipulate the way we

21:13 want whether we wanted to have one

21:15 direction communication

21:16 or bi-directional communication or

21:19 coming

21:20 having a communication among all the

21:22 virtual networks

21:24 so

21:25 so now so far what we have shown is uh

21:28 how to isolate an namespace

21:30 then regular kubernetes and network

21:32 policies and the third is like you know

21:34 how do we connect the virtual networks

21:37 so that they know we can communicate

21:38 each other at the network level

21:41 and also another key takeaway is the in

21:43 the network policies the way our

21:45 implementation is uh we use the tag

21:47 based uh

21:48 uh you know implementation at the v

21:51 router level so that it's you know

21:53 pretty fast and uh

21:55 and also we use the bgp to exchange

21:58 these

21:59 tags