Ederson Brilhante: Building Secure and Flexible Multi-Cloud Images with Multi-Boot Mode

In this presentation, Edison Brilliante, a Senior Tech Lead at Cisco, discusses the creation of secure and flexible multicloud images using a comprehensive CI/CD approach. He begins with an overview of continuous integration and delivery, explaining how these principles apply to building and deploying various cloud images. Edison emphasizes the importance of security, transparency, and reliability in the process, detailing Cisco's resource connector product, which supports multiple cloud environments. He describes the use of GitHub Actions, Packer scripts, and Terraform to automate the image building and deployment processes, ensuring consistent results across different clouds and boot modes. The talk also highlights the significance of versioning and thorough testing procedures to maintain product integrity and compliance with security regulations.

[Music] hello everyone and welcome back to the security hall I'm really excited about this next presentation that we have and we have the wonderful Edison brilliante with us who's going to be diving through uh his presentation of building secure and flexible multicloud images with multi- boot mode a comprehensive cic CD approach so Edison is an accomplished Sr te Tech lead at Cisco he's coming to us from

the wonderful city of cracow one of my favorite cities but I believe that is not originally where he is from but to give you a full rundown of himself no one is better than Edison so Edison I'm going to leave it over to you to take it away and just before you do a friendly reminder to all of our uh attendees here to please ask questions if

you have them you can do it in the chat or at the top of your page there's a Q&A button we will be monitoring them so this is your opportunity to ask ask Edison questions directly we'll cover them at the end so you thank you so um let's start pres myself so I know I live in Poland I am original from Brazil I have 70 years of

it and my main experience is being a develop specialist with Fus on infra and Cloud automation uh in this session I will we will see uh about our approach on building um different image for different uh clouds uh in know in environment that we need to have security and different stage of building uh to start at this presentation I'd like to give you a overview of cicd

uh in general so we can go later to our approach so CI stands by continuous integration is a place or a system that you wants to have automated builds automated testing or detections code quality uh so this is where you wants to have this kind of system and for CD um can be continuous delivery or con deployment depends which kind of product you have if you have

a API uh system that need to run 247 you goes with CI CD you could go to with deployment so you commit you push and you generate a build then you deploy uh immediately so that's how you you can have in our case the product I support is not a system but ECT file or a binary that is goes to the customer so then we apply continuous

delivery we have we build we test and we make available to be deployed by the customer uh so cicd uh is good for reability you expect freaking frequen upates uh you wants to find fast Buds and fix uh you want a cant user experience privacy and security uh have transparency so you wants to see what is happening the log uh and you want to be available so

you need the the system to be available anytime you want to to have uh your product uh with inion now context uh we have a product that inside of Cisco so is a resarch connector so resarch connector is a product inside a product so Cisco has secured um uh secur access Suite that allows the customer to have the whole network secured and make the his own uh

client to access his own uh uh private app in the way that's secure so in our case uh we have this resource connector deploy the same data center as the private app and between the the his own user and the private app we have the secured access with and the resarch connector that's uh a plugable um product between the private app and the SEC network so that's

why we need to support with called because we need to be where the customer is so if the customer has the Deo in on BR we must have and support on PR if the customer is in or another Cloud same thing need to support the VM that's can to be deployed in that environment uh M mode because uh we want to secure G type of boot modes

like secured boot mode with have TPM the future and local builds we need to have disable those options for Turbo shooting and the bugging and we need to use uh M stage build strategy uh our requirements and regulations and government regulations demands that we need to harden image and we also have internal uh way of doing so we have a Harden where we install and configure necessary

to have a healthy uh image used for product and for internal uh builds for example our runners use the Harden image after the the image is hardened we create the Baseline product so we install parti partition we installp grades and other configuration that made the base product available for different B modes and then we have also a Cod overlap in maintains so some parts of the code

are individually by the cloud or by the uh boot mode but a big part portion of the code is has overlap so we share the same across different type of Mage this is one way is good because it's less copy paste another way is bad not bad is a challenge I say because if you change one line it can po break everything because then you need to

to test everything so that's our context and that's how U we using this context we came with our approach so our approach um because we are using a GitHub to host our code we uh decide to use GitHub actions so GitHub actions cicd uh that support not by GitHub instead to use frin or Jenkins or this stuff uh in our team we use GitHub action uh and

as I told you we have different um build station so we have Harden Bas image and and the and final product in our case so and we use Packer scripts so Packer script is a es INF code solution uh that is uh made by hashcart company same thefor the for we use to the deploy our image the result of the pipeline in environment test so we deploy

if everything that's necessary to support that uh that image and we run a bunch of tests using inable files the same uh the same in not the same files but the same uh stack we use to build and test so we have bunch of inable roles that uh describe how build the the image what should be installed how and how should be tested and we need agression

test as I told you one line in any part of this INF cod in GitHub actions in the parer uh in the terraform in the anything or even in the software that we are building can change thep grades the software that Cisco creates to make the product can be changed so that's test every time you change anything and we test against everything because we have a uh

good portion shared across different uh image uh the structure that we use was to separate in different reps instead of have one mon rep with everything we thought it was a good idea to have one repo with Harden image that can be used for the product but to other other things so other products that we need or other deployments or the uh GB runners where you run

the the bus so everything is using this hard then we have the product base image that is not the fire image but the the image where we run uhp grades we create partition and other parts that make a baseline to create a product uh the resource connector product then we have the final image uh product that is only receiving a pin version so where we have the

image version pet with the Cisco s Cisco software pet and connect and another software that makes part of the connect is pet so we can reproduce the same build over and over because if you're not changing the a code and we are changing the uh the versions it always generate the same build over and over and we need that for AI reasons so we need to guarantee

and if a person came on a regulation or some recent case say what's inside of this image how you can prove that this is a software that you have inside this binary that's how we prove because it always generate the same uh binary over and over and then we have the tester Suite this is the reper we have lot of tests integration test sunity test performan test

soing test lity test and many other tests that guarantee in different states that our prodct healthy is safe and also has no performance degradation between uh uh upgrade versions for the product the Builder Suite structure that in our case we have three repos they share a stimul structure so it's easier to the developer main 10 so we are trying to keep the same uh format it's not

the same code but the same format structure so the developer reads or the reads is e okay the same contract has the same GitHub uh idea of GitHub workflows GitHub composite actions I'm not going to details what exactly is uh GitHub uh because we don't have much time to go deeper on that uh but reusable workflows are the way how you can reuse uh a por of

code that run your job so you have a job that does something build and this jobs inside the workflow and you can when you call uh to different uh reason when you create a PR on another job he wants to reuse this so this is how you can use reusable workflows and composite actions I can call as a basically a function because it has an input output

may have input and output and internally what does is not concerned outside uh of the world is can be selfcontain and each rep has a common in file so for build the product base it has the same files that we build for um VMware aure and so and other clouds that we support today and we may support in the future same for the Harden same for the

the final product and we have the parer scripts that give us the ability you create image different clouds because and uh possibility to different bu uh uh modes and because the in code we can uh know when something change and we can uh track back uh and have a a version in code that we can compare why the build start to fail and each reple has a

file depend version so the final version the final image we have a file that describe what's the base image what's the ciso version so version soft software a version one Z software B one2 softare three uh softare C uh 20 and so on and so on so we describe what's the dependency per different boot mode and for a different uh uh cloud provider so of course with

hard and and and the base image in the base image we don't have SAR so we just describe and other soft that we decide to pin same for the CD image or the hard that we have and the test swier uh we GS RA workflows in this case we don't use pocket we use form because we don't want to build but we wants to deploy one environment

we want to set up environment run a bunch of t regard to this pass and later we tear down this this environment so we have a FAL deployments for each test for each image and and cloud provider and we test using inable files so we have a lot of in roles and each Ro has a lot of um inable test where describe something to check inside in

the DM that was booted using the the the image that we built so just a simple case here um for example uh the product needs to create a file and file needs contains one specific format inside this file so and we need to guarantee that is happening that guarantees that the software is working because as a a configuration file is important to the to the to the

software so one one task would be to make as sa the machine check the file exist read the file and compare uh the format uh this the the the if the the the file has the proper format and the proper context it's F it's passing otherwise it's fail if you fail it fail the test and get says okay that image is not with the proper bu and

not going to the next stage that will be a g keep keeper so the developer or the needs to fix what is breaking the build not the bu but breaking the the product pass to to a stage and why this is Step uh as I told you uh I am using uh GitHub because we start our code in and we the native way of using GitHub is

GitHub action so we don't use use uh jings or whatever other thing in our team uh we thought this is good because is empowers the developers has efficient cicd Pipelines of course has the pros and cons if you compare with Jenkins and other cicd so every system has his goods and bad and you have to make bypass when you find something that is not good as you

like or create uh issue or request for uh improvements to the uh GitHub so GitHub is made in using EO files and is that you can create your own uh workflows or even your own actions that can be shared with other other developers other companies if you want to to go to open source you can create your own action and other other folks around the world can

use your action has simil integration with GitHub and can be used for everything mostly you can mute you can test you can deploy everything in one place you don't need to have one building one system another testing another system everything can be done in one way because it's easily to be integrated you can use exteral plugins you can so very nice to use and easier to maintain

um as I told you easy to to customize so you can create your own ex station so in our case we use to create uh stations for building testing and deployment in in the lab and covers if not everything uh almost all aspects of the um uh SD uh LG sorry um software development life cycle um and we use theform the form is a INF as a

code as I told you is uh created by hash C there was a fork now we there the hash copy version and the Open Source by the Linux Foundation but anyway the the terraform the IDE is to have infas code uh that defines the the infra and has St so you can deploy the same infra over and over so you can guarantee that the same uh deployment

is uring uh over the time so we need to guarantee the same uh um variable this over different U builds we need to support G with cl told you uh because our product must be deployed where the customer is so the customer has the data center whatever is and they have the they app and they need to have the resar connector deployed in the data center orul

is the environment and that's how that's why you need to have a a a pluging or in this case that form that allows us to deploy in our place that we need to be we have have a order so we need to deploy the machine we need to deploy the the the INF theet then the VM then we need to register the VM to the proper API

we need to uh run the the test so has order so theform guarantees this order and this is how you can guarantee that something will not be created before and mass your test has modularity so you can reuse components in other components uh so in case for example we need to Reg API we don't need to create a API for each uh each environment we have a

modular that has API and we just call when we want to deploy blast when was call Azure or another other Cloud when deploying you have a state um management so when you run the T form it will create a state file where locally you you can um placeing in the bucket for example and then uh when is is deploy it will save the state step so if

it fails it you will save what was created and what was not created will not be saved it keep it safe so if you run again you try to continue what why startle uh if he was to destroy if it was 100% completed or partially completed will destroy what was deployed so is is easier to make a clean up so you don't need to care about what

okay I need to make a gas but was clean CLE up make a lot of GS in the using for examp CLI you don't need to do that ter form will do that for you and because has a large community system integrates with and different Cloud providers uh same factor but but Packer is good to create image with paration and has other plugins for example if he

wants to build a c image has a c pluging uh if he wants to other type of builds has a lot of parer plugins to build so we use to build and have quickly builds support different builds and be able to integrate with other uh toolings so we use paret build and we call the to uh to make the configuration inside the the image that's being built

uh for security we can we can use th has a community so active Community many plugins you can even create your own cling same with if there someing that is not available is made in go uh and same as platform is multile so can create consistent image so uh if then nothing Chang in the uh in the s or in the code it will create the same

uh result over and over so give us consistence and and is important for Al in our case and in because it's agentless so it's not necessary to install anything inside of the the machine we don't want that so we just need to book the machine and then we is this happen when you try to build then it's available this stage then you uh run your playbooks as

a um B commands and this is this decare as files so it's human REO is easier to read maintain add has a lot of plugins so you can even use for example AWS you may use a c but instead to use a c you could use the plugin fors same for Azure and other other CL providers so this is not way of using a is extendable so

you can use uh plugins for other Developers for other companies or you can you on create your own plugin and you can use locally or you can even put in a uh open source SC store that's SC galaxy has a larger community in this in this uh community and as fcker has integration so can be EAS integrated with other to LS uh I explain now about our

ORF flows so this is our orlow we have a Harden image then the Harden image will produce uh um a base image using as hard as as a base image as input and then with the product based image we can create different boot modes as we want so bio security boot with u TPM whatever the the type of boot mode we want if the cloud provide supports

is available so is we can have different boot modes for different uh Cloud providers uh as we want or as we need here we can see how it looks like when we extend to G so single Cloud providers we have a a Harden image so for last we have my hard image for Azure we have image in Azure Cloud so and so on and so on for

other Cloud for them the hard image we create the basic product in that cloud provider so we have Mi for for the base same for Azure and so on and so on and as I told you so it will create its own um image in that uh provided for we are not sharing the same image across our our call providers although we could do it for example

we could build some um some vmdk file and then import to a but this when you import vmdk is insert insert some things that you don't want so this guarantee that we are using the cloud T way so this is the recommend way by the cloud um the the cloud provider so we are using that comination from the cloud provider so build have in the way that

the cloud uh saying and for testing pipeline uh we are using the same flow uh regardless the boot mode and the cloud we deploy the infra and the VM based in requirements on that environment in that cloud we run bunch of uh tests that curreny the the again is healthy it's passing with everything uh the file there the software everything's running as supposed to do it then

if it fails we fail but if if pass it and after that it um tears down if it fails be a gatekeeper and not allowed to go to the next stage that's more testing or uh allowing to to uh run uh to go to the customer uh uh deployment here a full pipeline um how it looks like when we have a job that triggers the hard that

triggers the base that triggers the uh the product and run the test and so on so on so individual builds uh they are uh they don't have they can run in parallel so we are not making one gatekeeper on other in the testing in the build uh so this give us um very uh freedom to increase more provide more modes without increasing that of the build so

it takes for example one hour to build everything increasing another uh provider if the build time is similar it's still 1 hour to build it not be two hours because we have something new uh I give example how we use for regression test as I told you uh we have a bunch of portion of the code that is shared across different uh views and here when when

when uh user chains a shared inable test uh and creates a PR that wants to change but this change can break because you are changing one task that bus image so you may not you want to change something that you are thinking AWS and indirectly you may break something for VMR but how do you know if you're not testing everything uh uh and we have different stage

builds and so everything can breaks in any part of the building or testing so we need to guarantee that every new change is not creating any any problem to to testing or to the to the to the product itself so in this case we build uh temporary image for the Harden with this temporary image we uh create a build image for um base image using as input

the stamp uh C image then we create the the final image same with temporary uh base image then we deploy we run test and we CH down so if everything is passing in that put mode in that cloud provider that means that change is health and safe for that that change to that uh uh that image and we do the same for every single Cloud providers and

mode that we support guaranteeing that okay that change is not affecting so when everything's passing we allow the merge merge then um soorry then we uh create the promotion pipeline uh we use the promotion pipeline uh uh job so here is example not from this Harden but for from the the base from the product final image sorry so we have um file files we have the base

image with the software that Cisco creates Theon and other soft that's propietary and we um create a PR and a job we understand okay are changing only for a l anything else be supposed to be the same so we make a GF and say okay I only have to build for a I only have to test for a the other things are not are not changing it's

the same uh so you you create a real imation this PR promotion to deploy machines we run and tear down if everything passing what was changing this PR you allow the merch run the so test scans and so on so on many of the other steps until you have uh ready for for the ga to to allow to the the customer to use if everything in this

promotion uh pipeline fails is block you're not allowing to go uh to the next and further process so we back to the development we have to fix and go again and again to the to the process until we have everything uh sort out and redit should be used in production in the for the customer uh so this is the final image for the seed and the base

image we have similar uh in the product we in the final we have a specifities that we need to use pet versions that we can uh if we change the is spin if we change uh the base image is spin if we change any so we have a version file with everything so if you run again and again is always gives the same image over and over

for the for the image the base install partitions and we install software prades that make change so the INF are called can be the same but if you run today or run tomorrow it may change the uh the resulta image because uh that maybe there was a Upstream update in some software Linux package or something happen a CV was fixed and then so the base image uh

will create a different uh result over and over but we create a new Bas image version that we be using in the final image so that's how we can okay new new CV fix set new base Image new PR to the final image so the death builds we have death builds VM thebug and all manual test to to allow developers to deploy uh without taking much effort

in deploying and test so we have case that developers is changing some Cisco propriatary codee and he wants to see how it's look like in the the final image so it can creates a a customized um that view it can pass what's the seed what's the base and what's the customer version software that that builds are even products that's uh uh that's been stage or in testing

yet so can be created and use it for manual deployments or any other development use case so give us the freedom and help Developers to have a f feedback on the software we also allow manual test so because we need to support different B modes different environments could be a toil is a toil to developers to know our invironments to know how to deploy how to to

test so we the developer just have to say I wants to deploy in this environment In This Cloud and using this version Trier for me deployment give me access so it will deploy give us AAL VM access vsh and the developer uh change the Playbook and so it's let's say adding new use case tests uh using the pipeline could be done you know can be commit and

push commit and push but the feedback is too much time so every time you're fixing you take a few hours because you have to wait everything to to pass so uh for a fast feedback in development it's easier to have one machine you run locally so if you wants to to see what is happening you you run again and again and you can have a fast to

the back and this Emeral takes you the developers decide how much time you need so one hour one day uh one week and the Machine will be run after that we steer down uh and delet and remove our environment automatically I have some code uh samples so here is how our GitHub action is structure we have a DOT GitHub this is how you create uh workflows and

actions in GitHub that repl the workflows and the actions uh we have a folder witho we have a folder with Packer and inside of folder Packer we have the examples here I gave just three uh Azure and um VMware and a boot mode file and or is not necessary to have for example in VMR I just I just place at one to give example that is support

G different and is not necessary to be the same over different uh uh clouds and we have the versions yo file so similar in the second column is for the tester we have also GitHub action uh we have the workflows and we have also folders that describe the uh how supposed to do it in each Cloud so for a for Azure for Vare how to boot for

VMware how to Bo frasure steer down and how to run the the test because although the code we are trying to use overlapping there are some specific on each environment so for a l you need to get the ation for Azure we need to do the same get the resource Group name and other stuff that we place in in uh in Secrets or environment variabl so we

need to get this this uh data uh inside of this this action and then we call uh the test so we need to so this is self contain all dependencies for each environment or each cloud is self contain so it's the same contract so it has the same input same output as a function a signature is the same but what does inside it does concern so the

developer okay I want to deploy AWS VM uh okay just pass the image pass the uh the platform whatever is the the the similar inputs and it will do it and as as in in the build we also haveo playbooks Where have have the the BS to to run the test and we have a a call back PL that we check the result and if there any

ignore any anything that is not passing it will fail the job and not allow it to go to the next stage in the pipeline that I showed before the composite action um as I told you I understand as a function you can uh understand as a function because has a signature with inputs and outputs and does something internally and what does internally this can be anything so

you can install you can configure it you can call it apis whatever is inside so can be called as a function uh in this case here this is a um plugin uh not action to build a base image for a so pass what the version image that we want to create for that what's the seed or the hard um and what's the output the image that we

are build returning from this build has a bunch of steps and getting the permissions get stalling any plugins that's necessary to build this image then we run the pocker so you can see so we pass variables and we call pocket and P to to uh initialize the parer the validate and build and this will create the build this will boot the machine in a then the build

will internally call the in to install and configure the machine then after uh uh run everything that you should pet will automatically tear down the VM and create a snapshot and then from the snapshot you create M so s happens with other Cloud providers it's not the same API it's not the same way this is how does but this the signatur is the same so we have

a pocket in it and some file that does something internally so this is the the signatures that we have and reusable uh similar withs also can be end as a a function where you have inputs and outputs you pass the inputs that be internally use it and instead to be just steps this job so you have and each job is executed in a different uh runner is

a different machine so you can have a builder you can have a test in the same work F and the build runs first and after the build is on you can say okay wait the build and run the test so you have also internally um what do what what you need in this case we call uh the the pipeline that's iOS we pass the uh the version

the platform and then with the platform we call the proper um action as you can see in the last block in the second column where we call the proper uh action um to the that that platform and we pass okay image and the hard or the C image for reusing workflows uh I told you that based in what you changing the version files we have a we

describe we create we we build exactly what was changing so if you're changing only for one boot mode or one called provider is don't make sense to create a new product because same image from the last build is the same we are creating that's why we are using verion So based in the discovery of this s we make a matrix and with the Matrix we trigger views

here is the the jobs after the Matrix uh that we created GitHub GitHub has a matrix strategy so you can use um option name and Matrix but with uh use workflows where you can have a job then with eror with another job and so on and so on so we have a long workflows is not very helpful in the interface it will make one Unity block can

put one job above another so you don't have in the interface uh the the arrows so far so far uh uh building uh different uh uh clouds in a long pipeline we needs to have a a an interface that allows the developer that's to identify the the issue easily so why is hard coded uh the pipeline to support but we use this conditional if so if it

was generated by The Matrix uh that means should be triggered if not you be and skip it uh so here you can see here's how you're using in our approach but if you're using the Matrix uh that's is how GitHub today's support is only one block you see instead this beautiful arrows just one Java above another and you don't know exactly what's the builds uh what's the

build what's the the testing because it's only one thing so there are issue that's people are waiting for this to be improved but until it's not Improvement we we choose to use this approach so here with the bug uh so the tier down uh has so we we deploy the machine one in this case the developer ask for one hour so run one hour gave it the

access vsh and here down after 1 hour automatically so we have a cleaning environment the user or the developer don't need to have access to all cloud provider Labs everything only access to the to the machine vs and on reduce access to environments access to clouds anything that uh reducing the risk to to anyway to to create message from developer or creating things that should be created

in that lab uh some crucial takeaways um as I told you so developers don't need to Dey the the infra access to a specific they just need to say I want some to deploy this this VM in that environment please do it for me and done it will be done can us it in uh the P can use it for troubleshooting in worst case scenario that we

saw our stage and builds takes about three hours uh to be test build and drive to the next stage that is per performance test Lo test so but this take time but the build like we have that's image boot B and working is about three hours and so if you have any CV fix set that we need to fix urgently we do it in three hours have

a image that can be fixed if is a need like a hot fix we can do it and go we are fixing something we can easily to add more Cloud providers is not affecting um the time so we don't need to hire more people to support the the infra higher more developers uh to more uh to test and and put uh Bea I don't know a full

uh uh key uh key8 because the pipeline serves as this purpose so uh we just need to add more providers as much uh the product needs to support we are using newa Code principle along with final verion so this allows us to find bugs faster so if we introduce bugs we know because it start to break if something start to break could be not because of verion

but for something in the uh OS package grade so we can okay we can determine where start to have a problem and try to fix and as much as possible and the pipeline is very modular so has different Cloud providers but is is not a problem because our dependencies our logic is selfcontained in action in a workflow so this give us um uh freedom to to extend

and add more more providers easily without any problem or breaking anything uh that working I have some links here so if you want to learn about this St that you know yet so here can a um I started so about ra workflows actions how to trigger workflows about GitHub about parer and and and here is my um so if you wants to send me a DM in

the linking to get more information about the P planine because this was very short me uh talk so if you wants to to see you can access my linking and my um my GitHub and the idea that we are trying to open source this code as soon as fast we are going to a process to so uh you're not seeing the product but the the workflows the

structure the architecture will be we want open source so we in a process proper source and you can see um vanilla version how to do do the same regardless your product so if you have to apply something similar with different stage or just one boot doesn't matter you can you could use the same architecture uh that we use so now uh we are open to uh question

and answers awesome thank you uh so much uh Edison so uh to the uh people online please add any questions that you have into the chat or into the Q&A tab we'll be monitoring that we are a little bit over time so we will try to to be brief but uh it isn't I I'll kick things off I have I have a question here um it's that

was a incredibly insightful presentation one I'm gon I'm gonna have to admit I'm G to have to go back through some of the materials that you shared to to to fully wrap my head head around everything but I was curious are there um are there any kind of common mistakes you see people making with their CD pipelines and building their images in in areas where uh that

that create security holes that can can easily kind of be fixed based on on what you sheared uh yes so um we our approach is to fix and reduce the toil to have a product because we we need to support clouds uh boot modes and we share the code with different things so uh we try to pin the versions of the pin in the versions is crucial

to our case because we need to guarantee that okay we are using a new uh any connect version with alongside with other softwares that Cisco creates to make this product so we we need guarantee that software that we created ourselves not creating any security issues to the customer because this is be def the customer so when we have this final version and we test against G different

uh um uh s tester vulnerability scans this allow us to to fix this uh or when say we are updating the OS the OS package this is not our part this is from the the suppier from the the Linux uh uh package that that we don't have management but we need to guarantee that we are not creating any problem because uh we are using something for open

source can be included no I don't know let's say a new version that inject something that's some durability some access to to the machine to the the customer so we need to guarantee that anything that we inject from our part or from the uh the the the supplier we need to guarantee testing that will not break like the software we work has no performance degradation but also

internally a scans so we use internally scans scan the VM we scan the the uh the image that everything's fine so that's how we can that not only beakes by the developer but from the the Linux community that we well yeah does is there a question or yeah ABS absolutely um I think we have to uh unfortunately wrap up here but if you have questions for I'm

sure that you uh can reach out to him I hope so anyway his details are on the screen to follow him on GitHub to follow him on LinkedIn um would be great uh Edison I just want to to say thank you so much for sharing your knowledge here sharing the great work that you're doing at Cisco and wishing uh wishing you all the best and I hope

you enjoy the the rest of the conference that you have with us thank you yeah byebye for