LongCut logo

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...

Loading video analysis...