WEBVTT

00:00:00.000 --> 00:00:02.070
>> SQL Server big
data clusters provide

00:00:02.070 --> 00:00:03.960
security mechanisms to make sure

00:00:03.960 --> 00:00:06.150
your data access is always secure.

00:00:06.150 --> 00:00:08.220
Nellie is here to tell
us everything about

00:00:08.220 --> 00:00:10.350
it today on Data Exposed.

00:00:10.350 --> 00:00:21.210
[MUSIC]

00:00:21.210 --> 00:00:24.165
>> Hi and welcome to another
episode of Data Exposed.

00:00:24.165 --> 00:00:27.570
I'm Jeroen your host and
we have Nellie today with

00:00:27.570 --> 00:00:30.990
us to talk about security for big
data clusters. So hi, Nellie.

00:00:30.990 --> 00:00:31.860
>> Hi, Jeroen.

00:00:31.860 --> 00:00:32.700
>> How are you?

00:00:32.700 --> 00:00:33.750
>> I'm good. Thanks.

00:00:33.750 --> 00:00:36.930
>> Okay. So security
for big data clusters,

00:00:36.930 --> 00:00:38.340
that must sound important.

00:00:38.340 --> 00:00:41.355
So can you tell us how it works?

00:00:41.355 --> 00:00:44.970
>> Sure. So if you're
familiar with SQL Server,

00:00:44.970 --> 00:00:47.735
you probably know that
security is always

00:00:47.735 --> 00:00:49.820
a top priority for us

00:00:49.820 --> 00:00:53.540
and it's the same thing
with big data clusters.

00:00:53.540 --> 00:00:56.180
We prioritize this work

00:00:56.180 --> 00:00:59.015
and note how important
it is to our customers.

00:00:59.015 --> 00:01:04.340
So I'm going to highlight some
things around the security today.

00:01:04.340 --> 00:01:06.485
We're not going to
cover all the details,

00:01:06.485 --> 00:01:10.430
but we're basically going to cover

00:01:10.430 --> 00:01:12.080
on high level so that you know

00:01:12.080 --> 00:01:15.170
the security capabilities
of the big data cluster.

00:01:15.170 --> 00:01:16.220
>> Okay.

00:01:16.220 --> 00:01:17.870
>> As you know, a lot of

00:01:17.870 --> 00:01:20.440
our SQL Server customers
are enterprise customers,

00:01:20.440 --> 00:01:23.720
big enterprises who
run Active Directory.

00:01:23.720 --> 00:01:27.125
We need to make sure that all
your applications including

00:01:27.125 --> 00:01:29.420
SQL Server and big data
clusters and all of

00:01:29.420 --> 00:01:32.525
these solutions can
integrate well with AD.

00:01:32.525 --> 00:01:33.515
>> Yeah.

00:01:33.515 --> 00:01:36.680
>> That's the key
capability that we're

00:01:36.680 --> 00:01:40.355
enabling in big data clusters in 2019

00:01:40.355 --> 00:01:44.060
is to actually for
you to be able to do

00:01:44.060 --> 00:01:47.945
this in a seamless and easy way.

00:01:47.945 --> 00:01:51.425
Now I'll tell you why
I emphasized easy and

00:01:51.425 --> 00:01:56.150
seamless because typically when
you're dealing with applications,

00:01:56.150 --> 00:01:58.070
let's say any type of application,

00:01:58.070 --> 00:02:01.220
joining an application to AD
is not a big deal, right?

00:02:01.220 --> 00:02:04.280
We just assume that any application
supports AD integration.

00:02:04.280 --> 00:02:04.730
>> Sure.

00:02:04.730 --> 00:02:07.640
>> Now for big data clusters,
it's the same thing.

00:02:07.640 --> 00:02:09.185
It should just work.

00:02:09.185 --> 00:02:11.090
It's just that we have to

00:02:11.090 --> 00:02:13.890
highlight that we're
running in a fully sort of

00:02:13.890 --> 00:02:18.255
completely containerized
solution here where

00:02:18.255 --> 00:02:20.240
all the services are running in

00:02:20.240 --> 00:02:22.160
containers and all the
supporting services

00:02:22.160 --> 00:02:23.470
are running in containers,

00:02:23.470 --> 00:02:25.370
and this is running
on top of Kubernetes.

00:02:25.370 --> 00:02:25.955
>> Right.

00:02:25.955 --> 00:02:30.200
>> So we've spent a lot of work
on making sure that you get

00:02:30.200 --> 00:02:33.200
a fully automated and
seamless experience of

00:02:33.200 --> 00:02:37.130
this completely containerized
big data solution

00:02:37.130 --> 00:02:39.560
on top of Kubernetes.

00:02:39.560 --> 00:02:41.600
>> So basically, this all
runs in container so that's

00:02:41.600 --> 00:02:43.820
why the integration is interesting.

00:02:43.820 --> 00:02:45.170
So what does it mean to have

00:02:45.170 --> 00:02:47.360
a fully automated
integration? What do I get?

00:02:47.360 --> 00:02:50.510
>> Yes. So for that,

00:02:50.510 --> 00:02:52.415
you might need a little
bit of background.

00:02:52.415 --> 00:02:52.530
>> Okay.

00:02:52.530 --> 00:02:55.700
>> So when you're joining
sort of a service to

00:02:55.700 --> 00:02:58.099
Active Directory or Kerberos

00:02:58.099 --> 00:03:00.410
that's running inside
a Linux container,

00:03:00.410 --> 00:03:03.320
for example, it's
absolutely possible.

00:03:03.320 --> 00:03:04.670
It's just that you have to apply

00:03:04.670 --> 00:03:07.655
some manual steps to
get that to work.

00:03:07.655 --> 00:03:10.430
Now imagine you have a
solution with hundreds

00:03:10.430 --> 00:03:14.255
of these containers with hundreds
of services running in there.

00:03:14.255 --> 00:03:16.580
To do this manually
obviously would not be

00:03:16.580 --> 00:03:19.730
realistic and we don't want
to ask that from our users.

00:03:19.730 --> 00:03:22.130
So by fully automated,

00:03:22.130 --> 00:03:23.795
I basically mean that we are

00:03:23.795 --> 00:03:25.970
taking care of the
complexity for you.

00:03:25.970 --> 00:03:29.105
We have a service that's called
the security support service.

00:03:29.105 --> 00:03:30.695
So as part of deployment,

00:03:30.695 --> 00:03:32.090
that service is going to take

00:03:32.090 --> 00:03:34.430
some information from you
as a user who is deploying

00:03:34.430 --> 00:03:39.005
the cluster and then the service
is going to basically perform

00:03:39.005 --> 00:03:41.480
all of these steps for every
single service in the cluster

00:03:41.480 --> 00:03:44.045
to make sure that
everything is AD joined.

00:03:44.045 --> 00:03:46.850
>> Wow, that's impressive.
That's very cool.

00:03:46.850 --> 00:03:48.890
So basically, I can just let

00:03:48.890 --> 00:03:51.410
the cluster configure it
and there we go, right?

00:03:51.410 --> 00:03:52.475
>> Yes, exactly.

00:03:52.475 --> 00:03:53.005
>> Cool.

00:03:53.005 --> 00:03:55.145
>> Now in addition to that,

00:03:55.145 --> 00:03:58.370
we also spend a lot of time to

00:03:58.370 --> 00:04:01.100
make sure that we get an
integrated security experience.

00:04:01.100 --> 00:04:04.730
By that, I mean that, for example,

00:04:04.730 --> 00:04:07.864
when you're passing a
query from Spark to HDFS,

00:04:07.864 --> 00:04:10.060
because in the big data
cluster we have Spark,

00:04:10.060 --> 00:04:12.090
you can query data in HDFS.

00:04:12.090 --> 00:04:15.920
These components already
play pretty well together.

00:04:15.920 --> 00:04:19.700
So these components are
part of the same stack,

00:04:19.700 --> 00:04:22.440
you can say, part of
the Apache stack.

00:04:23.620 --> 00:04:27.260
So there's a lot of functionality
we can already leverage there.

00:04:27.260 --> 00:04:29.780
But when it comes to SQL
Server and SQL Server

00:04:29.780 --> 00:04:32.965
natively talking to a
component like HDFS,

00:04:32.965 --> 00:04:35.480
that's actually a new functionality

00:04:35.480 --> 00:04:37.250
that we're introducing where we

00:04:37.250 --> 00:04:41.280
have the capability for SQL
Server query scenarios,

00:04:41.280 --> 00:04:43.110
I have to highlight, that if I

00:04:43.110 --> 00:04:45.495
pass a query to the SQL
Server master instance,

00:04:45.495 --> 00:04:47.540
it's just a SQL query
that is querying

00:04:47.540 --> 00:04:49.970
over an external table
sitting in HDFS, right?

00:04:49.970 --> 00:04:52.295
So when I do that,

00:04:52.295 --> 00:04:57.020
we make sure that my
identity as a person who's

00:04:57.020 --> 00:05:01.070
issuing this query flows all the way

00:05:01.070 --> 00:05:03.410
through all of these
different components

00:05:03.410 --> 00:05:05.600
on the way down to
HDFS where the data

00:05:05.600 --> 00:05:10.400
is so that we can do an authorization
check on the actual data,

00:05:10.400 --> 00:05:12.590
and that's what I mean
with integrated security.

00:05:12.590 --> 00:05:14.615
It's integrated through
all of these components.

00:05:14.615 --> 00:05:16.760
So no matter where I issue the query,

00:05:16.760 --> 00:05:18.515
from Spark or SQL Server,

00:05:18.515 --> 00:05:20.450
the user's identity is always going

00:05:20.450 --> 00:05:22.895
to flow through all
the way to the source.

00:05:22.895 --> 00:05:25.640
>> Okay. That's very impressive
and very important to

00:05:25.640 --> 00:05:27.560
any enterprise working with this kind

00:05:27.560 --> 00:05:29.570
of stuff because you want to
know your data is secure.

00:05:29.570 --> 00:05:31.430
>> Exactly. I mean,
you have auditing,

00:05:31.430 --> 00:05:33.860
you have your audit logs to make
sure that they are up-to-date,

00:05:33.860 --> 00:05:36.425
and you don't want some service
account to show up in those.

00:05:36.425 --> 00:05:37.190
>> Exactly.

00:05:37.190 --> 00:05:40.940
>> So it's one of the key requirements
from our customers as well.

00:05:40.940 --> 00:05:42.860
In addition to this,

00:05:42.860 --> 00:05:49.340
we also have the integrated
experience in forms of how you,

00:05:49.340 --> 00:05:51.305
for example, interact
with the cluster.

00:05:51.305 --> 00:05:53.150
We have Azure Data
Studio that you can

00:05:53.150 --> 00:05:56.370
use to connect to big
data cluster, right?

00:05:56.540 --> 00:05:59.480
We want to give the
experience of a single

00:05:59.480 --> 00:06:03.110
sign-on for as many
scenarios as possible.

00:06:03.110 --> 00:06:05.295
So when I connect to
a big data cluster,

00:06:05.295 --> 00:06:07.345
I actually connect to
the master instance,

00:06:07.345 --> 00:06:11.030
but our tools will make sure
that I also get access to Spark,

00:06:11.030 --> 00:06:12.590
in HDFS, and all these other

00:06:12.590 --> 00:06:15.010
components that are interesting
in the big data cluster.

00:06:15.010 --> 00:06:16.895
>> So that's all handled
transparently to me?

00:06:16.895 --> 00:06:18.185
>> Yes, exactly.

00:06:18.185 --> 00:06:19.250
>> Okay. Cool.

00:06:19.250 --> 00:06:22.375
>> Yes. Last but not least,

00:06:22.375 --> 00:06:24.650
we have encryption and

00:06:24.650 --> 00:06:27.125
encryption is very important
for our users, right?

00:06:27.125 --> 00:06:27.890
>> Of course.

00:06:27.890 --> 00:06:30.965
>> We have made sure that
all the communication,

00:06:30.965 --> 00:06:33.950
even internal and
external communication,

00:06:33.950 --> 00:06:39.290
with the big data cluster
is SSL or TLS encrypted.

00:06:39.290 --> 00:06:41.285
In addition to that,

00:06:41.285 --> 00:06:43.325
you can of course leverage

00:06:43.325 --> 00:06:45.635
the many different
encryption features of

00:06:45.635 --> 00:06:48.470
SQL Server that we have
and all of them that are

00:06:48.470 --> 00:06:49.985
supported on SQL Server on Linux

00:06:49.985 --> 00:06:52.430
because we're running on
Linux containers here.

00:06:52.430 --> 00:06:57.485
We're also working on expanding
these capabilities and add

00:06:57.485 --> 00:07:00.710
HDFS encryption soon
so that we also have

00:07:00.710 --> 00:07:04.745
those capabilities for data
that's encrypted at risk.

00:07:04.745 --> 00:07:07.920
>> Okay. Cool. So can you

00:07:07.920 --> 00:07:09.410
explain to us a little
bit more about how

00:07:09.410 --> 00:07:11.570
this works under Kerberos?

00:07:11.570 --> 00:07:16.070
>> Absolutely. So let's
focus on authentication

00:07:16.070 --> 00:07:18.770
first because it's
important for you to

00:07:18.770 --> 00:07:20.485
know what difference or

00:07:20.485 --> 00:07:22.785
entry points there are
to the cluster, right?

00:07:22.785 --> 00:07:26.360
Here you see the five
different endpoints

00:07:26.360 --> 00:07:28.490
or entry points to the cluster.

00:07:28.490 --> 00:07:30.485
Now we have this Kubernetes cluster,

00:07:30.485 --> 00:07:32.660
so we have to basically specifically

00:07:32.660 --> 00:07:35.360
expose certain endpoints that users

00:07:35.360 --> 00:07:37.430
or client tools or
any applications can

00:07:37.430 --> 00:07:40.865
interact with in the cluster.

00:07:40.865 --> 00:07:44.475
So if we start with controller,

00:07:44.475 --> 00:07:46.685
as you might be familiar with,

00:07:46.685 --> 00:07:48.860
controller is the
brain of the cluster.

00:07:48.860 --> 00:07:52.715
Controller is the one that
keeps track of everything,

00:07:52.715 --> 00:07:54.229
that deploys the cluster,

00:07:54.229 --> 00:07:55.775
and all of these things.

00:07:55.775 --> 00:07:58.580
Now to reach the
controller endpoints,

00:07:58.580 --> 00:08:02.500
you can see here that the main
method you would interact

00:08:02.500 --> 00:08:04.885
with it would be
through the azdata CLI

00:08:04.885 --> 00:08:06.850
but also through our tools.

00:08:06.850 --> 00:08:11.860
It's mainly the endpoint that
an administrator would use,

00:08:11.860 --> 00:08:14.005
for example, to interact
with the cluster.

00:08:14.005 --> 00:08:16.180
But controller also has magic powers.

00:08:16.180 --> 00:08:20.470
You can say controller can sort
of reach out to other endpoints.

00:08:20.470 --> 00:08:23.890
So for example, you can log into

00:08:23.890 --> 00:08:27.485
controller through azdata and from

00:08:27.485 --> 00:08:29.920
there issue commands that will

00:08:29.920 --> 00:08:32.710
take you to SQL Server master
instance and you just start running

00:08:32.710 --> 00:08:35.380
T-SQL or you can run HDFS commands

00:08:35.380 --> 00:08:38.665
directly in an HDFS shell
in these type of things.

00:08:38.665 --> 00:08:42.470
So that's what that endpoint allows
you to do among other things.

00:08:42.470 --> 00:08:43.275
>> Okay. Very cool.

00:08:43.275 --> 00:08:45.830
>> Yeah. Next, an endpoint that you

00:08:45.830 --> 00:08:47.690
might have heard about if you've

00:08:47.690 --> 00:08:49.860
used big data clusters
is the gateway.

00:08:49.860 --> 00:08:52.055
Now, the gateway is
actually the same thing.

00:08:52.055 --> 00:08:53.885
The implementation detail behind this

00:08:53.885 --> 00:08:56.735
is that it's the Apache Knox Gateway.

00:08:56.735 --> 00:08:59.900
This is a gateway that typically
protects, you can say,

00:08:59.900 --> 00:09:06.210
the Apache components such as
basically on the Hadoop side.

00:09:06.210 --> 00:09:06.510
>> Right.

00:09:06.510 --> 00:09:07.980
>> So we have Spark, Livy,

00:09:07.980 --> 00:09:11.999
YARN if you want to connect
to HDFS through web HDFS,

00:09:11.999 --> 00:09:13.705
this is the endpoint that you use,

00:09:13.705 --> 00:09:17.165
as well as from Azure Data Studio.

00:09:17.165 --> 00:09:19.160
So that's good to know when

00:09:19.160 --> 00:09:21.505
we're talking about the
gateway what we mean there.

00:09:21.505 --> 00:09:23.990
Then we have the
management proxy which

00:09:23.990 --> 00:09:28.070
is the gateway to metrics
and logging tools,

00:09:28.070 --> 00:09:31.490
and then we have obviously
SQL Server master instance.

00:09:31.490 --> 00:09:33.830
It's just SQL. It's just
a TDS endpoint where you

00:09:33.830 --> 00:09:37.025
connect to from whatever tools
that you're familiar with.

00:09:37.025 --> 00:09:39.200
The app proxy, last
but not the least,

00:09:39.200 --> 00:09:41.780
which is the way that you can

00:09:41.780 --> 00:09:43.310
access the applications that

00:09:43.310 --> 00:09:45.290
you deployed inside
the big data cluster.

00:09:45.290 --> 00:09:47.820
Now, all these different
endpoints when you're running,

00:09:47.820 --> 00:09:49.305
for example, in a secure mode,

00:09:49.305 --> 00:09:50.760
when the cluster is
running in secure mode,

00:09:50.760 --> 00:09:53.175
I mean AD integration mode,

00:09:53.175 --> 00:09:58.210
all these endpoints are
allowing AD authentication.

00:09:58.210 --> 00:10:00.200
So that's what I wanted
to highlight here.

00:10:00.200 --> 00:10:02.510
So when we're talking
about AD authentication,

00:10:02.510 --> 00:10:06.740
it's a full integration with
AD for all the endpoints.

00:10:06.740 --> 00:10:08.645
>> Right. In front of one of the
five endpoints across the board.

00:10:08.645 --> 00:10:09.335
>> Exactly.

00:10:09.335 --> 00:10:11.490
>> Wow. Okay.

00:10:12.740 --> 00:10:16.590
>> Yeah. So that's authentication
basically for you.

00:10:16.590 --> 00:10:19.755
Moving on, we also
have authorization.

00:10:19.755 --> 00:10:21.290
It's very important to protect

00:10:21.290 --> 00:10:23.780
your data once it's
inside the cluster,

00:10:23.780 --> 00:10:26.720
once you actually manage to
log in and authenticate.

00:10:26.720 --> 00:10:30.675
Yes. So the key parts I
wanted to highlight here,

00:10:30.675 --> 00:10:31.920
and this is still high level.

00:10:31.920 --> 00:10:33.485
I'm sure that we're going to have

00:10:33.485 --> 00:10:35.660
additional talks about the
details of these things.

00:10:35.660 --> 00:10:37.335
But on a high level,

00:10:37.335 --> 00:10:38.510
there are two levels of

00:10:38.510 --> 00:10:42.050
authorization checks that you
do in the big data clusters.

00:10:42.050 --> 00:10:44.750
If we start with SQL
Server, for example,

00:10:44.750 --> 00:10:48.050
if I'm issuing a SQL Server query,

00:10:48.050 --> 00:10:50.420
first of all, there are
authorization checks

00:10:50.420 --> 00:10:52.100
on SQL Server objects.

00:10:52.100 --> 00:10:54.920
I need to have access to the
tables that I want to query,

00:10:54.920 --> 00:10:58.730
for example, so that we can make
sure that I can access the data.

00:10:58.730 --> 00:11:00.860
>> But that's the same
authorization checks

00:11:00.860 --> 00:11:02.330
as we had in previous
releases with SQL?

00:11:02.330 --> 00:11:02.780
>> Yes, it's SQL.

00:11:02.780 --> 00:11:03.530
>> That hasn't changed?

00:11:03.530 --> 00:11:04.280
>> This is just SQL.

00:11:04.280 --> 00:11:04.610
>> Okay.

00:11:04.610 --> 00:11:07.160
>> So basically, the
permission model of

00:11:07.160 --> 00:11:08.945
SQL Server is the same

00:11:08.945 --> 00:11:11.285
whether it's running in big
data cluster or anywhere else.

00:11:11.285 --> 00:11:13.490
So you can still grant permissions on

00:11:13.490 --> 00:11:16.950
specific tables and specific
objects in SQL Server, right?

00:11:16.950 --> 00:11:17.915
>> Okay.

00:11:17.915 --> 00:11:19.945
>> But in addition to that,

00:11:19.945 --> 00:11:21.845
now let's take the scenario when I'm

00:11:21.845 --> 00:11:23.990
issuing a query against data that's

00:11:23.990 --> 00:11:26.060
sitting in HDFS and I'm querying

00:11:26.060 --> 00:11:28.715
an external table over
HDFS in this case.

00:11:28.715 --> 00:11:31.790
Not only do I need to have
access to this table,

00:11:31.790 --> 00:11:34.025
to the database where
this table sits,

00:11:34.025 --> 00:11:36.320
I also need to have access to

00:11:36.320 --> 00:11:39.905
the actual files and data
that's sitting in HDFS.

00:11:39.905 --> 00:11:40.145
>> Sure.

00:11:40.145 --> 00:11:43.430
>> That's what I meant with the
two-level authorization checks.

00:11:43.430 --> 00:11:45.035
So in this case, there's a check in

00:11:45.035 --> 00:11:48.620
SQL Server and there's an
additional check in HDFS.

00:11:48.620 --> 00:11:48.920
>> Okay.

00:11:48.920 --> 00:11:50.510
>> On the Spark side,

00:11:50.510 --> 00:11:53.660
basically the Spark
queries will flow and

00:11:53.660 --> 00:11:56.000
the HDFS authorization check will

00:11:56.000 --> 00:11:58.505
make sure that the
permissions are honored.

00:11:58.505 --> 00:12:00.200
>> Okay. So with all of this,

00:12:00.200 --> 00:12:01.820
I can be sure that

00:12:01.820 --> 00:12:04.370
the original user's
identity is passed through

00:12:04.370 --> 00:12:06.590
SQL Server to wherever
the data is, right?

00:12:06.590 --> 00:12:09.455
HDFS or however I access it, correct?

00:12:09.455 --> 00:12:15.390
>> Exactly. Yes. Then as we
sort of touched on before,

00:12:15.390 --> 00:12:18.825
we'll have this pass-through identity

00:12:18.825 --> 00:12:22.670
which means that the original
user's identity will flow

00:12:22.670 --> 00:12:26.810
all the way down to the
data so we can actually

00:12:26.810 --> 00:12:27.980
verify all the way

00:12:27.980 --> 00:12:31.730
that this was the user that
wanted to access the data.

00:12:31.730 --> 00:12:32.800
>> Okay.

00:12:32.800 --> 00:12:38.820
>> Yeah. So that
basically is a summary on

00:12:38.820 --> 00:12:41.390
high level on the security
capabilities around

00:12:41.390 --> 00:12:44.780
the AD integrations specifically
for big data clusters.

00:12:44.780 --> 00:12:47.710
>> So where can I find out
more if I want to dive deeper?

00:12:47.710 --> 00:12:50.420
>> Yeah. So if

00:12:50.420 --> 00:12:52.580
you want to learn more about
big data clusters in general

00:12:52.580 --> 00:12:56.495
and we have security docs

00:12:56.495 --> 00:12:59.675
covering details of what
I just explained today,

00:12:59.675 --> 00:13:04.280
you should go to this
short link: aka.ms/sqlbdc.

00:13:04.280 --> 00:13:05.615
>> Okay.

00:13:05.615 --> 00:13:09.455
>> If you go there, you can learn
tons about big data clusters.

00:13:09.455 --> 00:13:10.835
>> All that there is to learn, right?

00:13:10.835 --> 00:13:11.255
>> Yeah.

00:13:11.255 --> 00:13:12.560
>> Awesome. So okay.

00:13:12.560 --> 00:13:14.210
So basically, I need to go there

00:13:14.210 --> 00:13:16.750
and start learning and
start downloading.

00:13:16.750 --> 00:13:18.810
Can I export it to a big PDF and

00:13:18.810 --> 00:13:21.990
then read it in the
nighttime to learn?

00:13:21.990 --> 00:13:25.095
>> Yeah. Actually, I think
you can do that. Yeah.

00:13:25.095 --> 00:13:27.120
>> Don't print it,
though. Just PDF, right?

00:13:27.120 --> 00:13:27.300
>> Yes.

00:13:27.300 --> 00:13:29.390
>> Okay. Cool. So thanks a lot.

00:13:29.390 --> 00:13:31.295
This was very useful.
Thanks a lot for sharing.

00:13:31.295 --> 00:13:32.030
>> Thank you.

00:13:32.030 --> 00:13:33.950
>> Thank you for watching.

00:13:33.950 --> 00:13:35.960
Please like, subscribe,
and comment on

00:13:35.960 --> 00:13:37.940
the video and I hope to
see you next time. Thanks.

00:13:37.940 --> 00:13:52.600
[MUSIC]