Authentik proxy outposts for Traefik, Docker and K8S
By Christian Lempa
Summary
Topics Covered
- Outposts Offload Authentication for Performance
- Managed Integrations Auto-Update Outposts
- TLS Secures Remote Docker Socket Access
- Kubernetes Outposts Simpler Than Docker
- Single Auth Centralizes Multi-Cluster Protection
Full Transcript
hey everybody this is Christian and today we will cover how to use proxy outposts in authentic authentic as some of you might know is the free and open source identity provider that I'm using
to lock into my home lab devices and applications in my first tutorial about authentic I've already explained how to install and deploy this using Docker compost and even integrated the traffic
reverse proxy to be able to protect applications that don't have any form of user login by themselves today I'd like to follow up on this topic because one question I haven't answered yet was how
do you actually connect authentic to traffic that might be deployed on a separate server or maybe to a traffic Ingress controller in kubernetes the solution is called authentic Outpost and
as a bonus tip I'm also going to show you how you can use them to easily protect the traffic dashboard with a secure lock in hope you're going to enjoy it and yeah this will help you to
make your home lab and it environment more safe and secure let's get started by the the way if you're not using authentic yet and you're entirely new to this topic of course I link you the
first video tutorial in the description box down below so you definitely should watch this tutorial first otherwise it might be a bit difficult to follow and just to let you know since the last
video I've made some changes to my authentic setup for example I've migrated my production authentic installation from using darker compose to my new Raspberry Pi kubernetes
cluster using Helm so here you can see the helm deployment running in kubernetes however for using authentic Outpost it's actually not really relevant where or how you have deployed
authentic just install it somewhere using darker compost or kubernetes or Helm whatever technology you feel the most comfortable with and you can still use the authentic Outpost to handle
authentication and authorization requests on any other server Docker kubernetes so in my case it looks like this authentic again is running on kubernetes and then I'm using it to
securely lock into any administrative system such as my gitlab platform that is deployed on an entirely different server using doer compost or my grafana monitoring system that's also running on
the same server but I can also log into any other system like Longhorn for example so this is running on the same kubernetes cluster as authentic is but I can also authenticate to applications
that are running on different kubernetes clusters or separate servers using doer compos like my traffic installations you can see I have deployed across the different virtual machines in my home
lab this is running on my first production application server this traffic installation is running on a different kumis cluster and I can just lock into any service from this single
authentic installation this is really amazing and I'm even planning to expand this authentication system to other platforms and services that I might deploy in the future and I can simply
add any lockin form to any service or in any environment or server that I want don't worry we'll cover exactly how to do this in a minute I just quickly want to remind you about another important
topic when we are talking about authentication and that is remote access because I'm using authentic only on my local network but sometimes when I want to loog in from an external network for
instance when I'm in a hotel traveling or somewhere at work I'm using twin gate the sponsor of today's video twin gate is a zero trust network access platform that is so much better and more secure
than using traditional vpns because it always verifies each access request if the user isn't authenticated the device isn't verified or the context is suspicious then twin gate doesn't let
the network request even leave the device I've by the way also made some tutorials about twin gate in the past it is super simple to get access to SSH web interfaces basically anything that
you're running locally it creates secure and blazing fast tunnels from inside your network to your client machine no matter where it's connecting from or if there are any nut firewalls in between
it just magically works and the best is you can use twin gate entirely for free up to five users and 10 different remote networks so definitely check out twin gate start making your network more
secure and safe of course I will leave you a link to their website in the description box down below now let's get back to authentic Outpost so these are basically just a small authentic
component essentially a service that you have to deploy on all your environments that you want to connect such as any Docker host or a kubernetes cluster and
it allows for a secure connection between the authentic Outpost and the authentic API that is running on the main server and just to let you know in this video I'm just going to focus on
the proxy provider types of the authentic Outpost but there are also three other types existing such as the Elder provider the radius or r i provider these type of outposts allow
you to connect authentic to other types of authentication systems you might have in your environments also there's another interesting advantage of using authentic output that you should know
because they allow you to offload the authentication logic from the main authentic platform to these smaller components so this can help a lot to improve the performance of your
authentication requests so they offer a lot of flexibility when it comes to integrating different networks and environments the permission to access the authentic API is done by using a
service account and a token which are autogenerated by the authentic Outpost integration so it's not such a big deal to deploy these small Outpost somewhere there are just a few things you have to
consider when you connect to it in traffic using Docker or kuat but let's go through this step by step all right so first of all I will show you the embedded Outpost that is running an
authentic by default so when you go to Applications and outposts you see a list of all the authentic outposts that you have deployed in your network and you can even create new ones to connect to
different servers and environments the embedded Outpost is always running by by default in authentic and if this is a fresh installation this is the only Outpost that you should see here and
this was introduced in some previous version of authentic to simplify the proxy deployment and this is also managed by authentic itself so it can be disabled and you should not delete it
because if you restart authentic it's just going to recreate this embedded Outpost and usually the embedded Outpost is needed on the environment where the authentic main platform is installed so
when you want to integrate it with other Pro that are running on the same host as authentic this is the embedded integration that you can choose but if you want to connect different environments you have to create these uh
different outposts as you can see I'm running them for each server or integration that I have created such as a different kubernetes cluster or also my other Docker servers that I have
connected here so I think it will be best to just show you how to create such an integration and we will just start with the docker integration this obviously will work a bit different than a kubernetes integration and I'm just
going to show you both here I think for most people the docker integration will be the most interesting one so I'm going to start with that here and uh one thing that I probably should also mention
about The Outpost integration there is a way of manually deploy those outposts using darker compose or also kubernetes environments but those deployments have
one downside here because they are not managed by the authentic main platform themselves they are not automatically updated so if you use those manual Outpost deployments it is your
responsibility to update those deployments one by one when the main platform updates and I think it is better to use the Integrations so that the main authentic platform will handle
the deployment of these Outpost and it will also automatically update them if you update the main authentic platform it will also uh push an update to all these Outpost as well and you don't have
to worry about it anymore and the docker integration can be done in several ways here you can use the remote host TS connection so this will use a trusted
certificate authentication to securely connect to the darker socket or you can use the remote host SSH connections so let us just go through this uh step by step so first of all I'm going to
connect to a test server that I have deployed so here I'm just running the docker demon I have deployed a couple of containers that are running here there's also a traffic instance running I just
have access to the dock socket locally not via the network usually it's not a good idea to expose a network connection to the docker socket because then anyone
can connect to this open port and uh yeah do whatever he wants with these containers so be careful when you're doing this you have to add a strong protection such as TLS encryption and
authentication using certificates so that only trusted devices can connect to the docker socket using the network connection so let us do this I'm just
going to switch to the uh root user because that's that's then much simpler to execute all these commands and I'm creating a new folder it's called Sears
and I'm also CD into that directory so you can choose any other directory that you want it's really not that much important where your certificate files are located I just picked this directory it just makes the most sense for me and
then I'm just following the documentation basically you can just copy and paste these commands here I'm just customized a few things here so the first command this will hold the private key of the certificate Authority and
then I'm going to create a certificate for this certificate Authority note you can pick any certificate expiry date um here that you want you can also make it a bit longer valid but one year is the
default and then you have to fill in some information for the country name for the state locality name organization name if you want so this is really not that much important for a local test
environment all right so now that we have the certificate Authority certificate and private key we need to generate a server certificate so this is the certificate that the docker engine
will use we just start again with creating a new private key for the server certificate and then instead of creating this certificate directly we will create a new certificate signing
request because our server certificate of course need to be signed by the certificate Authority that we have just created so I'm going to pick this CN here the server test one again you can
add any subject that you want but usually I'm using the fully qualified domain name of the server and now it is important that we uh make this certificate valid for the fully
qualified domain name uh and the IP address so we will create a new file here so first we will write these entries to a configuration file so we will add the subject alternative names
to the fully qualified domain name uh the IP address of the internal network interface and the local IP address as well and write it to the X file. CNF and we
also have to add another line to this configuration file this will make sure we can later use this certificate for a secure authentication all right so now we can generate the certificate based on
the certificate signing request that we've created we will sign it with the certificate authorities certificate use the certificate authorities private key
and we use the extensions file the X file. CNF that we've configured with all
file. CNF that we've configured with all of these settings here all right so then we if we execute it you can see that the Certificate request self signature is
okay because we've used the correct CA and the key and stuff all right so now uh we can use this certificate to configure the docker engine however we also should create a corresponding
client certificate that the authentic platform later is using to connect to the doer server so let's do the same thing again we start again with a
private key we will create a certificate signing request for this client certificate as a CN I just pick client I think that should be fine and we also need to generate a new extensions
client. CNF file so here we just use the
client. CNF file so here we just use the extended key usage client authentication so that this certificate can be used to authenticate to the server and then we
generate the certificate with an expiry date of yeah one year and that's it so now we should have the following files in the directory we have the certificate
Authority private key and certificate we have the client certificate and private key and we have the server certificate and private key so now according to the
docker documentation we have to follow a few cleanup steps here so first of all we should uh make sure that we remove all the unnecessary files we don't need the certificate signing requests here
for the server and client anymore we don't need the configuration file so we can just remove them and we also should make sure that the permissions are configured correctly for the private key
only the root user should have access to the private key and for the certificates anyone could have read access so to configure remote access to the docker
demon uh using TLS certificates can enable the remote access by configuring the docker service in system D here is the system D unit file so if we take a look at this file here are all the
important flexs and what we have to do is we have to override this line here the ex execution start command it is not a good idea to make any modifications in this file directly instead it is
recommended to create a new overwrite Doon configuration file so this will overwrite only specific Flex here that you want to change without having to
modify the unit file that is managed by the docker installation so otherwise you might run into some problems so let's create a new directory and then we will
create a new file that is called over right Doon here we can modify those flexs first of all I'm going to paste the information that I've copied from the main Docker service and now it is
important that we add the uh group where this flag is configured in this case it is used in service group and now you can't directly override this execution
start command you have to clean it first so that's why we have to add one empty line here and the second line will set this to new parameters so here in this
file we can app hand any Flex to the docker DEC command first thing that we want to do is we want to add another host here and I want to pick the IP address on the eth0 interface of the
server so that the docker socket will only accept connections coming from a one IP address on this local network and we will use the port
2376 and then we will just add the flx to add our TLS certificate we will add TLS very ify and then we will add TLS
caert that is located in this directory the ca. pem then we will use the TLs
the ca. pem then we will use the TLs cert so this is the server certificates file in my case the server D.P and as a
TLS key we will use the private key or the corresponding private key to the server certificate in this case server Das key.pem all right so that should be
Das key.pem all right so that should be all now we can write and exit you can see there is a warning line so the unit file Source configuration file of the
docker service changed on the disk and it instructs us to run this command here system ctld demon reload to make sure the system unit files that we've just
modified are reloaded by the system D unit of we should execute this as root user and then what we can do is we can restart the docker demon so obviously
this failed so maybe I made a mistake but we can just have a look in the lock files so here you can see unknown Shand flag uh TLS so probably I made a typing
with stake somewhere here so let's check ah yeah okay I forgot the Double Dash of course it has to be dash dash uh like any other flag here all right so now the
docker demon should be started and it started with the correct Flex you can see it here in this line so this is using the certificates and now you should also see that the server is exposing the docker socket here in this
line when you uh check the open ports by the system on this IP address that we have defined on the port 2376 and now what we have to do is let's go back to authentic I know this was
much about Docker and not about authentic but if we go back now to the authentic Outpost we can now create a new Outpost that will use our client certificate that we've generated to
securely authenticate to the doer socket on the test server and how you're going to do this in authentic is also pretty easy so first of all we need to upload the certificates that we have generated or at least the certificate Authority
that we need to verify and the client certificate that we use to um authenticate so here in authentic in the system settings you can go to certificates and here you can see
a list of all the certificates that you have created generated or uploaded on the authentic server usually it's only the authentic self sign certificate so let's create a new one here and we will
start with the certificate Authority so now we go back to the server and go in the ETC Docker SE directories where we have created all the relevant
certificate files and private keys and we will start with the ca. pem so this is the uh certificate Authority certificate we will just copy everything
in here and just paste it here so one thing that is a bit uh weird in authentic usually the private key of the certificate is optional here so in
theory you should not need to add the private key here because authentic doesn't need to to generate new certificates using the ca right it doesn't make any sense but for some reason I could not select the
certificate uh authori certificate from the drop down list if I don't add the private key so I don't know if this is a small buck in authentic but if if we need it we will just add it here so um
we will cut the output of the private key of our certificate make sure to copy everything paste it here and click
create now we also need to create a new client certificate so I will just call it client remove uh the content from the old command what was the name of the
certificate I I think it's just CT server CT is the server CT and CT is the client CT all right yeah uh now we got that copy it put it in here and now we
have to use the private key otherwise we can't use the client certificate to authenticate always make sure you select the correct corresponding files
otherwise it uh would not work obviously and let's create this as well and now that we have these certificates you can also see uh if the private key is
available here and the expiry date so when the certificate expires you can see for my production instance I have made those certificates valid for for 10
years uh until I need to uh recreate them for the demo one it's just one year so if you want to avoid creating all these certificates every year you have to uh extend the expiry date obviously
that will make things easier for you trust me and then we go into Outpost Integrations so now we can create new um Outpost Integrations for connecting to a Docker
service connection that's what we want or kubernetes service Integrations so here I just picked Docker and then I'm just going to give this a name server test one of course this is not a local
connection this will use a TCP connection and here we have to add the URL of the service so we can use the name or or the IP address because the certificate is valid for both the IP
address and the name it is up to you what you pick here so I'm using https and I'm just using the IP address I think that's be easier and the port number again was uh
2376 all right so that's the um Docker socket URL and now we need to uh pick the TLs verification certificate so this is the certificate Authority which the
endpoint certificate is verified against with so here we pick the certificate althor and here the TLs authentication certificate or the SSH
key pair here we will pick the client certificate so now we can click on finish here in the state you can also see if everything is working fine it should um give you the version of the
docker engine that is running on this integration and with the green check mark you can see the connection is valid the certificate uh is trusted and so on
so everything is working fine now now that we have the Outpost integration we could start creating The Outpost however there's also a stupid problem and
authentic you can't create a new Outpost without having a provider assigned to it you can see on the test server I'm currently not running any web applications that I want to protect with
a login so if you have an an engine X web server or maybe uh a different application without a login that you want to secure you can use that however I thought it would be nice to just show
you how to protect the traffic dashboard you can usually see those statistics here about the traffic proxy of the entry points the HTTP routers and stuff and this of course should not be exposed
without any secure look in so let's have a look how to do this and I'm going to start with our provider remember this is what I've shown you in the first tutorial so just follow the same steps
like I've described here we will pick the proxy provider for a new uh provider we will give it a name something like uh traffic
test one for example we will use the um explicit consent authentication flow and we will use forward authentication the external Host this is URL that we will
later use to authenticate against this will be traffic. server test
one. homec creative. so on my DNS server I have created a wildcard DNS record for the server test one to forward anything in front of this uh name to the the IP
address of the server test one that's everything we should need for the proxy provider now we have to create an application as well so uh let's start again with traffic test one and now we
will pick the traffic test one proxy provider that we've just created uh where is it ah here and now that we have that let's go to outposts
and create a new authentic Outpost the type is of course proxy and now it is important to use the integration so that authentic will deploy this Outpost for
us on the remote server and of course we will pick server test one so the integration that we've just created and the application that I want to make available uh via this Outpost and this
is the traffic test one application so let's move it into these selected apps and now it is important that you not directly start uh create it's important
to configure one or two settings here so let's go into advanced settings this would show you the configuration of the authentic proxy and here you can see a template that is valid for both Docker
but it also has some kubernetes flxs in here that we actually don't need because it's not a kubernetes integration so we can just remove it and leave those by default these settings I have found out to be very important so the first one is
the authentic Host this is usually the default so we can leave it or we can remove this setting it doesn't matter authentic host insecure host browser we don't need these flexs here and the lock
level Trace yeah you can uh configure the lock level just like you want but I'm also going to remove it and leave it by default also refresh interval the
container image uh that is all uh default is also fine so I'm just going to use these settings the docker Network so this will be important because as you
might know if you want to connect from the traffic reverse proxy that's running on the remote Docker server to the authentic Outpost they have to be in the same Docker Network right so that's important on the remote server Docker
Network LS and see I have created like a backend Network I've created a front end Network and the default Bridge Network and the traffic reverse proxy on my remote
server by the way is located in both networks front end or back end so we could use either of those um it doesn't matter uh but I'm just going to pick uh
front end I think that will be fine right and those settings here Docker map PS and labels we can also remove so those are important and if you want to customize so when authentic will start
generating this Outpost it will use an object naming template so this is the name of the darker container that is deployed later and I like to customize
it and use the same name as the server name so I like to get rid of this prefix here and just replace it those are important to set anything else um is
optional or up to you and now we can hit create so no the magic is happening in the background hopefully everything is is working fine but we can check so um here we can refresh from time to time to
see if the authentic proxy Outpost is been deployed and is able to connect to the authentic main platform we can uh check if on the uh remote server there
should be a new container uh generated uh currently it's not there ah there it is so you can see it is created but it's not running yet so for some reason it's
not starting automatically but I will just uh try to start it okay so this is now starting up I don't know why I have to start it manually so maybe I'm going to check later what's what's the problem
with that but as I can see here now the container is up and it seems to be healthy so if we go back to the authentic dashboard and just hit refresh the uh server test authentic Outpost is
uh up and running it shows up the version last seen 10 seconds ago so it is connected to the main authentic platform and we can use this uh proxy
Outpost all right so what we have left to do we have created The Outpost this is running on our remote server and what we've also done is we have created the
application and the provider for the traffic dashboard what I haven't done yet is modified the traffic reverse proxy added the correct labels and also
enabled the dashboard so that's the first thing that I want to do and now I'm going to add the traffic labels to make sure this is is uh
exposed I want to use the traffic reverse proxy itself to generate a new router and then I want to uh make this available on the host name traffic.
server test one. home. C creative. so
make sure this matches exactly what you have configured here in the provider as the external host name so those have to match here that's important of course I
want to expose it using TLS so make sure to add it on the entry point web secure enable TLS and I also need a trusted certificate using Cloud flare so I'm
using my certificate resolver and I also want to make sure that this is using the internal port 8080 because otherwise it might use a different port and remember
the traffic dashboard is running on the internal port 8080 so that's why we have to set it here in the load V server settings we now have to do is we have to generate a middleware for the authentic
proxy this is the same process like we've done in the first tutorial just that the application was running on the local server where authentic was deployed now it's running on a remote
server so let's generate a new configuration file and just pay it from the documentation and now what we have to change is we have to change this here Outpost do company and replace it with
the name of the authentic Outpost container running on the same Doos server so in my case this is server test one authentic Outpost remember that's why I said it is important to change the
server template name so that you definitely have always the same name that you can add in the middleware I think there's just one thing left to do
we have enabled the dashboard we have created the middleware now in the label files we have to tell the traffic reverse proxy to use this metalware so
we have to add a new label that is called HTTP routers trffic do middlewares and we have to set this to
the name of the middleware in my case I'm just using the name authentic so whatever you have added here as a name you should refer to here
and it's important to add an add file so to tell the traffic reverse per you note this middleware configuration you have to load from the middleware configuration okay good so I think that
is everything we have to do so now I can uh recreate the darker containers so I'm just going to take the project down and I'm going to take it up again with a d
the container is started and now if we start making a request to the traffic reverse proxy
which would be forwarded to authentic so let's try to open it by using traffic do server test one. home.
crave. and yep you can see we are redirected now to authenticate so we have to authenticate and lock in with a secure key or username and password so
that's it let's click on continue and now uh because we have uh choose the explicit consent it will tell us again you're about to sign into traffic test one information let's click on continue
and this will take us to the traffic dashboard again this is just a demonstration right so you could add any other service in here add a different compos file like an engine X web server
use these labels here use the middleware and create an create a provider and an application don't forget to move this application to the authentic Outpost so when you add
another application on the docker server you have to go back in here go to Outpost pick the Outpost where the application is deployed move the application from the list here in the
authentic Outpost for selected application to make this work and then you can protect any other application that you expose via traffic with a secq loog and this is really cool so I know
this is a lot you have to follow it can be complicated because there are a few separate things involved like the docker engine TLS authentication there is the authentic uh instance you should have
running somewhere you have to have the traffic reverse proxy running you have to create the middleware and The Outpost I know this might be a complicated tutorial to follow but if you follow all
the steps that I have explained in the first tutorial and in this one it should work for your environment and if you still have problems well you can just check out my boiler plates repository on
GitHub so this is a repository where I'm collecting all the templates for example if you go to darker compose and go to traffic you can see how many deployments I have collected here this nice you see
a template for creating a traffic reverse proxy in the config directory I've also added um examples for the authentic middleware you can see what
you have to configure there is the traffic configuration file with all of the settings that I'm using so definitely check out this repository this is always going to be helpful if you want to follow the templates I'm
using in this tutorial Link in the description of course down below and uh yeah before I finish this video I think it's already pretty long but I just wanted to show you how the kubernetes integration Works don't worry the
kubernetes integration is surprisingly much easier than the docker integration because the only thing that you have to do if you want to create an authentic Outpost for kubernetes you have to go
into a system Outpost Integrations create a new integration select kubernetes service config and what you have to do is here add the cube config file of your kubernetes cluster so this
is super simple by the way why not just uh let's do it together I have a kuet is cluster up and running for testing so if I just select Cube test
one here you can see I think I do I have deployed the traffic reverse proxy here oh yeah I have right so I could set up this here if I want uh so I think this
is located on server test three so this is the kubernetes cluster where it's running here is the configuration file so this is a cube file that we have uh
let's just copy this so one thing that is important of course this is using the um local IP address of course you have to configure it with the external IP address I'm using the htbs cube test
one. homec creator. I think that will
one. homec creator. I think that will work um of course this is not a local integration Cube test one this is external so let's click on finish this
should show you the version of the kubernetes uh noes so that's working and now we can create a new authentic Outpost for this integration as well so
what we have to do again we have to create a new provider I'm just going to call it traffic test too I think that will be fine explicit consent forward
off and um the fqdn will be traffic. Cube test 1. home. c.de course
traffic. Cube test 1. home. c.de course
https fine and we have to create a new application for it as well traffic Test
2 provider is um this one here the corresponding provider that we've generated and yeah so let's generate a
new Outpost I will just call it Cub one authentic Outpost proxy integration of course and the integration will be Cube test one and the traffic test to reverse
Pro I want to expose and before we create this of course we need to change the configuration settings again so we don't need lock settings we don't need the docker Network because this is a
kubernetes integration what we need is kubernetes replicas kubernetes namespace to make sure this is uh created in the authentic name space and we might want
to change uh the the naming template and set it uh to this name the service type will be cluster IP I think this is fine and uh the only thing that I want to
change here is usually authentic is also creating or generating an Ingress for this authentic Outpost and I don't want this I only want the connection to be
inside the kubernetes cluster's local network and not coming from outside using an Ingress route so what I will
add here is a kubernetes disabled component setting and this will be Ingress now we can generate The Outpost
now we have the Outpost of course we have to change the traffic dashboard to be enabled here I'm just going to copy one of my templates here um you can see this is
basically the same stuff that we've done in Docker I am just with a kubernetes manifest using traffic web UI middleware name and here in the address we of
course have to change this to the name of the deployment cubed t one authentic Outpost so we have to refer to this address here here dot the name space
where the deployment is located and then SVC do cluster. looc so this will be automatically resolved by the kubernetes uh core DNS internal DNS server to the
internal IP address of the deployment pot and then the middleware will forward the authentication to The Outpost here all right so that should work uh we just
need to apply this uh setting and then in the helm values we need to change this setting and then we just refer to the name uh traffic web UI middleware so
the same name as the object has that we have deployed and then we just need to redeploy the helm uh deployment of traffic so hopefully everything is
correct um yep so has been deployed successfully on that namespace here I think that also has updated to the latest traffic version and now we can
try to see what happens when we open a new uh connections and yes you can see it redirects us to the authentic loog and because I am already logged in with
this session to authentic it just gives me the consent to redirect me to the traffic test to dashboard and yeah so here we are at the dashboard of my traffic Ingress controller deployed on
the testing kubernetes cluster so now we have connected one Docker host and one kubernetes cluster to the authentic main platform using the Outpost I think this
is really amazing and if if you now want to use that to protect any application deployed on your servers or clusters you can basically follow the same procedure you have to deploy the authentic outpost
on each environment where your services and applications are running you have to integrate the traffic reverse proxy using a middleware that forwards the authentication and authorization requests to The Outpost and then at the
authentic main platform you have to create the application and the provider with the correct settings of the servers you want to protect I know it's a bit complicated but if you want got the process you have to follow in your hat
it's actually always the same I hope this was helpful to anybody who's using authentic and traffic reverse proxies and you now got a better understanding of how authentic Outpost work make sure
to hit the like button and subscribe to the channel thanks everyone for watching especially all the supporters of my channel and I'm going to catch you in the next video take care bye-bye
Loading video analysis...