Florian Rappl: Micro Frontends and Security

This talk discusses micro frontends and their associated security challenges, led by Dr. Floren Rapel, a solutions architect based in Munich. He starts by explaining his expertise in creating scalable web applications, particularly within the IoT space, and introduces his upcoming book's second edition that will include a specific chapter on security in micro frontends. The speaker emphasizes that while micro frontends are still web applications and face similar security risks listed in the OWASP Top 10, they also introduce unique vulnerabilities due to their distributed nature. Key topics include authentication flaws, injection attacks, and security misconfigurations, along with strategies for mitigating these risks, such as using session cookies instead of tokens, implementing Content Security Policy, and employing subresource integrity for script verification.

[Music] hello everyone and welcome to the security World stage of the cyberwise con thrilled to be here as your host today uh you'll be joining me for the first half of uh today as I get to introduce and uh listen to and participate with some of our wonderful speakers speaking of wonderful speakers we have a fantastic uh first Speaker lined up today I'm joined here by Floren

rapel Dr Floren rapel is a Solutions architect from Germany he's joining us from Munich uh welcome Floren it's fantastic to to have you here this morning with us thanks thanks for the kind words well Florian's going to be talking about micr front ends and security so without further Ado Florian I'm going to get off this stage and uh because really no one's here to to listen to

me today but I'm going to hand it over to you I wish you all the best and please just a reminder to the audience to ask questions in the chat um I'll be hosting a question session at the end with with Florian so here's your opportunity to ask uh Dr floran any of your burning questions so floran I'll leave it over to you thanks a lot so

welcome everyone um and uh I wish you all a very nice conference I'm here to kick it off uh just a few more words about my person uh as already said my name is TR rle I'm working as a solution architect for a smaller company in the Munich area called snapiot uh as the name might already ring there's three letters in there iot and there are maybe

other combinations in there that might seem familiar like API we are doing mostly um scalable API development in the iot space but I myself I'm specialized in the creation of well scalable web applications uh mostly in a distributed way uh hence microfon in so that explains already one part of the of the title um we're also doing consulting in other areas so some of these areas are

shown here if anything in there sounds interesting to you always feel free to get in touch with me for instance via LinkedIn but enough about me so let's just dive right into the topic and the first thing I want to note is that uh I've written a book about microfrance and even though security wasn't let's say a chapter of this book right now I'm writing the second

edition and there will be a dedicated uh chapter even on uh microphones and security so essentially what we are talking about today but even if you just have the first edition you will already know that uh some parts in there they they're not let's say without security it's already let's say sparkled all over the place just with the new edition that will be also condensed in a

in a dedicated chapter and this new edition will be out let's say in two to three months uh how the technical and the bureaucratic processes now go but writing is finished and now we are giving it the final touch and so second edition will be out soon soon now you might say uh okay uh security microphones is that different from security in general of web applications and

of course the answer would be no I mean microphone is still a web application so if you have your OAS top 10 open somewhere and you look at this list this is a list of threads that also will of course appear uh or should be mitigated in a microphone and solution right so that it's no different in that aspect however of course certain problems will occur more

often in the microfrance space and uh we are here to look specifically at those problems so the list here overas top 10 was taken 2021 I think they're releasing a new list about every four or five years so new one will will come out soon I guess but uh make no mistake I mean uh independent how old these lists are you could also look at an older

version of it uh most of these problems are still relevant and you should always account it now I've already asked the question why talk about microphone specifically let's look at uh let's say the the starting diagram of microfrance and this is the diagram taken from Martin Fowler's uh entry I think in 2017 uh where I think also the the the name of microphon and have been coined

so um what do we see and what do we recognize here so micronance is all about having distributed code getting essentially put together in a composition at runtime so this is what is marked here as production this means at run time now this simple diagram of course doesn't tell you anything about is is composed on the client so meaning in the web browser maybe on the server

is it on a single server is it via multiple servers all these technical aspects they're not there and that's of course for reason because like microservices it doesn't put you into any constraints what the technical aspects of it are at its core microfrance is an organizational pattern which means that it's all about having the ability in different teams to work together even though you all have separate

let's say technical repositories and all that completely isolated team they run their own pipelines they decide on their own when to publish and then it just goes into some artifact which is marked here in the production colum and later on at some stage again may be uh at the client at the server may even be an additional build step so already let's say a build time composed

solution these different fragments come together and they form one page or let's say uh your your solution your web application out there but if you look already it it's quite unique from the point of view that you have certain things like for instance distributed code meaning you have now Parts in your application that you can't control right because you might be now this team Orange um but

you don't control what team green and team purple here is doing right so you can't tell them um how they should let's say scan their code statically or how they should build or test the code uh of course in some in-house microphone and solutions which are the most things we are Consulting it you quite often you have some leverage there and you can make some guidelines and

even enforce these guidelines so there is some leverage here but make no mistake in general you will be in the position that you can't control what's entering there and that puts you of course already at risk and the risk only gets of course larger if you look how it then comes together together because for instance if you take as an example a composition in the browser you

will now add scripts of themes that you may know but you don't control the code into your code base there might be anything happening to the scripts along the way you just trust that these scripts now give you something and uh you might now say hey wait a minute I'm using I don't know some tool let's say I'm using weback modif iteration so I don't insert in

scripts but I mean this is exactly what this tool is doing under the hood so even though you're not doing it by hand the tool is now doing it for you and it is still doing the same thing it's entering now from some remote URL uh a script source and it just embeds it there and this means you are in in trouble essentially because after all when

the script is inserted uh code is executed and that's now executed in this uh composition layer which is again my in the browser but it might also be on the server which puts you even at even more risk because of course in the browser it's not nice uh if the script goes wrog it might install a key logo or something or maybe even get some some tokens

uh whatever your your architecture looks like but on the server it could get uh all kinds of access right for instance to your database or other systems that you don't want of course to be compromised and therefore this presents a quite a huge attack vector and you need at all costs to guard that right so looking back at the O top 10 which are the ones where

of course with microfrance you open them up explicitly potentially and you need to have extra care uh the number one is in my opinion injections in general because now you want to have injection after all that's what micronance is about but of course you don't want to inject something you you you you don't want to have in there you only want to inject the code that uh

you you think is is trustable right um of course insecure design uh is something that strikes also micronance especially with the injection vulnerability that we've seen beforehand and that we talked about so insecure design you need to mitigate from the beginning you really need to make sure that your design is under all conditions just just rock solid as good as it can be then we also have

security misconfigurations um we will also talk about this uh a bit and um make no mistake I mean uh security is always um I would say very hard to get right because the thing is you always think it is secure unless someone comes and says it's not because I can construct the following thing and then of course it's up to you again to to evaluate that and

say hey how like is it to happen and if it happens what can be then the worst outcome so you need to rate that at the end and quite often of course companies at least that we are Consulting they're getting external help for that external penetration tests Etc and then such misconfigurations can be let's say reported and properly fixed but fixing it and and and seeing it

yourself is always very difficult because you are already in the forest and uh you just see trees there for you it's very hard to get the big picture after you all you designed the system so yeah um little bit of a chicken egg problem here and finally uh identification authentication flaws this is something I always point out because there are multiple ways how you can handle let's

say authentication your microfrance and um I mean there's of course just from the ground up there is no really wrong way but in my opinion there are ways which are given the resources more secure and maybe even more convenient to deal with and we'll look at what we can do here to actually well um improve the situation all right so with that in mind let's start with

the authentication flaws here because yeah it's uh uh an easy easy uh thing to crack in the beginning um so what we want to look at is an attch Vector where we say Okay um you start with the assumption that uh we use a JWT for instance and as a bar token and each microphone that wants to communicate with um corresponding Services uses this uh authentication token

here right and um we need to send it of course with a request now you might say what what could go wrong here I mean come on it's a token but still I mean now you give this token uh away to the scripts of course that form the micro frontends and um these scripts they might not behave so nicely so even if they behave nicely they could

uh be flawed for instance a script could instead of sending it to your back end have a typo in there and sending it somewhere else now since you just have a header um it will happily send it and uh essentially the following is happening you have now the composition as remarked from the diagram earlier your orange microf frontend wants to communicate maybe its own micro uh service

it sends the token gets the response all fine the same goes for the green team they send it to the backend API all fine and then for some reason it might be that I don't know there was a misconfiguration might also be a tyo that I don't know when I'm tested in this specific area the token can now be sent from the purple microphone to not the

back end that it should be sent but maybe to a malicious side could also be other reasons of course code could have been hijacked we come to mitigations of that later but the rest assured we're just sending that token and uh that token is a powerful thing um until it expires um well it does everything on behalf of that user not very nice so what could we

do here um well instead the simplest way would be to not use any token uh with that we are not let's say in in any danger to to u to do something wrong now of course the question is how can we now uh really claim that this is a certain user sending the request well we we fall back to the mechanism of the browser use session cookies

there are SE several advantages the browser keeps track of them so in a Secure Storage most hopefully and uh therefore there is ially well not easy to grab uh and um we can make an HTTP only meaning that sure uh you can't even read them out from JavaScript so even if scripts go Rogue no no chance to to get access to them and we can make them

secure only so even if there is some um Tech Vector where the uh TLS Channel or something uh would be circumvented well we wouldn't use or or send the cookie right and the browser takes care of all of that and we can even then restrict it to for instance just our top level domain and not worry about anything regarding sending it from another domain or something so

uh with the domain policies same side for instance we are always and on the safe side here and that would be quite nice um to just well leave it all to the browser there are other convenience points in my opinion that make this appealing so for instance since you don't have a token any more you don't need to worry about the token's lifetime sure you might say

now I need to worry about the session cookies lifetime but that you could expand much further and you could control much further uh and so there is one problem out of your way still you might want to have access tokens just not in your browser so what you could do as an example is um you could communicate now with a Central Gateway anyway makes sense uh and

since this Gateway sits maybe on the same domain or at least on a subdomain but within a space that you say within the cookies I can control it that it's still sens there um the cookie would be sent from the browser implicitly to this Gateway and then from the Gateway the actual request is dispatched and the Gateway just exchanges the cookie to the Token if a token

is available the Gateway also therefore makes sure that I don't know tokens are refreshed Etc so it wouldn't use something like the implicit flow there um you could use something else uh and uh therefore I mean it would also have access to a refresh token in the Gateway um but nevertheless however you implement it in my opinion it makes sense that the apis themselves they use um

a token because this way they're rather auton uh independently working right so um they they clearly uh they just need a public key for instance and they can verify that this is indeed uh a valid authentication mechanism a valid token and um they don't need to worry about the rest of the system they don't need an off service or a session service where they go to and

then grab the information about the cookie or I don't know um so that makes sense um and then again if we now have this case that we described before and that we go to a wrong URL I mean the browser wouldn't send the cookie so it only sends it if it matches so the malicious site now gets no additional information and uh we are good we mitigated

this and uh we are here now just to put it also a little bit into code um originally let's say we had a request like this uh maybe even with a full URL um and uh we sent the Bara token um token that we of course verified to to be uh still up to date otherwise we refreshed it beforehand and now we transform this call and we

say okay let's just go to I don't know/ API that's gets automatically dispatched um to our Gateway and then the first segment here after API that points where it should then redirect to internally and then we just have uh by uh for instance um some convention the uh actual Endo um but if we put a put or I don't know post Etc that that just gets proxy

and we we use this kind of proxy there the the Gateway um to actually dispatch that accordingly so quite nice and as said in my opinion also quite convenient because also now local development I I also just need to always call SL API and then my local horse can actually either forward it to some environment that I want to use as a backend environment for local development

or maybe already handle it locally and really mock the data uh really then stressing out that local development should be as fast and maybe offline possible as possible right um and uh this is this is uh in my opinion therefore a win on multiple sides so the only loss here is that now our infrastructure gets more complicated um but in my opinion only slightly and you the

advantage of more convenience and especially more security coming to the next thing uh in secq design what a tech Vector could we uh construct here so as an example um and I mean most of these are of course targeted in this Direction Let's suppose we have a man in the middle attack here such that uh we introduce um additional code into a script right so I said

already we are injecting scripts and in the front end there's not much we can do because we want to inject these scripts um but still of course there are certain things we can do to control what these scripts can do and especially of course how we verify that these scripts may not be tempted after all right so now uh let's say uh we have this man in

middl Tech and it manipulates the source code of the script that needs to be injected and it could for instance therefore put in a key lock or something else in there so quite bad uh and what can we do how how does the situation look like so we grab the scripts and instead of our standard Json that uh sorry our standard JavaScript that enters in the orange

and green microphone then we are now for this script of the purple one we are entering a modified script now in my opinion there are there multiple ways to solve it the most complex one is a certain kind of code signing and we would need to evaluate uh using a special loader you could use system CH for on the front and and really make sure that there

is some some public key being satisfied here so that you know a private key was used and sign the um the code but I mean after all the only thing we are after is um that we uh we really uh verify that it wasn't let's say altered from when the team let's say the purple team in this example published the microphone or the script specifically to when

we want to include it right and for this uh it's enough to use a simple Integrity check and the beauty of it is that this is already fully embedded into the browser now um how does this look then in practice what what can we do here um one example is that if we use the sub resource integrity and we want to use this Integrity check we use

a central service which anyway makes sense for micronance in my opinion uh in general so this should be the service where the microphones are published uh this is quite often known as a microphone Discovery service we quite often call it a feed service independent how you call it it's the one service where your teams publish their microphone and to it would put them the assets on a

CDN and whatnot and now this service of course can make certain computations so for instance around the uh script it can compute the Integrity of it right and uh now if we ask the mic micophone Discovery service hey give me all the available microphone lens it would respond with something that looks um I have it here so sorry I need to swap those it would respond with

something like this so it says Hey There is a a microphon in there let's name it my microphon it it's currently published in version one and um this is the link for it right so it's the URL where the script sits and now it also gives you this Integrity property this property we can now use on a script T so like this here right such that nice

um now the browser knows the integrity and if the script from this Source loads and doesn't fulfill the Integrity which here is computed with a sh 384 then um well it it won't allow running it at all so before even evaluating the script after it was downloaded the Integrity is computed and is verified against this attribute U this subresource Integrity it works not only for scripts it

can also be used um for other things like uh sty sheets and um in my opinion it is a huge benefit because this is one way how you can make sure that your assets have not been tempted but of course again uh you shouldn't let's say before you request that resource from there computed it should be already statically placed so once you publish it you place it

there in your database you write the integrity and now of course you give it to the front end to verify that um so it's important that these two time positions are different because again if someone gains access to for instance the CDN or the blob storage behind it and is able to modify the script I mean if you would compute it on the Fly you would get

the same answer and it wouldn't protect you of course that it wasn't uh let's say from the time point in time where it was published to now so this is what you really want to guarantee and therefore you should computed when it was published you should then therefore of course provide this value now uh also looking at the at the diagram how does it now behave so

before we even start loading this javascripts we go to our microfon and Discovery uh service we get back the available micronance and the Integrity attributes and now uh we load them via their integrities and so the purple uh microphone it would be blocked by the browser it wouldn't even be there because the browser sees it doesn't match what was given and uh that's the end of that

story right so my opinion quite an easy fix but it always involves of course that you don't directly put it in there so if you use I don't know I again use as a reference web mod Federation this doesn't work with this because it directly you out of the Box uh if you use it like the simple example suggest you would not be able to put an

Integrity because you don't know you just specify URLs there so what you would need to do with meic modif iteration you would need to first go to uh Discovery service and then of course uh request your scripts but request them with the Integrity flag but then it would just work as it should all right um next point is injection and as already said uh injection is one

of these fundamental aspects of a microphone in solution because after all what you want to do is you want to inject certain things right so uh you want that R time to compose it now in the browser besides the things that we already covered there isn't much you can do because I mean the browser it just opens you one JavaScript runtime if you want to open another

one you have just a few options you can use an iPhone frame but then I mean everything happens on the iframe rendering and everything and that has other advantages and disadvantages in general you don't want that for a solution that really nicely composes on the screen and the other option that you have is that you use something like a a web worker so not a service worker

that's another kind of a worker but uh so a web worker which gives you another threat and another execution context for JavaScript however that doesn't have access to the full document object model either and so therefore rendering will be kind of a problem uh and this of course is not an ideal solution there are well let's say Solutions on the way in form of the realm specification

but it's I mean I don't want to say I've given up hope but uh it's been now I think six years since we're talking about it and it hasn't moved on yeah let's say visibly it moved on a bit but it is I mean far away from being implemented in some browser but I'm always uh let's say optimistic that at some point Suddenly It's in in Chrome

and then of course other browsers will follow uh nevertheless um injection when I talk here about what is our number one point it's server site um so let's say we are running a a server site composition from a no shars application and of course we bring in the microphon directly now on the server site and they will render and they will spit out and we are all

fine but now of course we have a problem because now we have an injection in the browser in in noest and unlike in the browser there are not so many nice checks like Integrity sure we can Implement them ourselves when we fetch the remote sources we also make sure that we use some Integrity flexs but even though that that say safeguards a little bit it doesn't safeguard

that the script we injecting has has been malicious already from the point of publishing maybe there's been a vulnerability in in the npm packages that have been used to create that script right you don't know I mean again you don't own these other repositories now that might have access to anything like database uh connections or any kind of environment variables and that's bad so what can we

do well we can just not evaluate the module and evaluate it via for instance new function or uh require just uh what we want to do is we want to sendbox that and for there's a really nice thing in noch it's called the VM module so viral machine and uh essentially it allows us to restrict the access to the provided Global so essentially all the runtime context

now an example I think is better than a thousand words here so let's see what how this looks like so this is some some code that you might want to use in Altered form so what we need definitely from VM is create context and uh running context create context creates a new evaluation context and running context then runs some source code here given in form of content

whatever is in there uh and uh evaluates that right and we can even specify certain things like a file name you want to give that is very useful for for error messages or even a timeout which is quite nice because we to let some script that we just got uh let's say drain the server resources and run for I don't know 40 seconds or longer than a

request takes so therefore we really want to constrain this and maybe even more than than what we see here two seconds is already quite some time but there might be some asynchronous processes in there so yeah let's just give it two seconds um but you want to constrain that for sure now um what we give here is on the first part we give it some context information

like for instance standard uh Global model module Global variables like find name de name you would give it maybe it uses that well then it has it and then you might also want to Define how process looks like and uh you might not want to give it to full environment variables like is given here so EnV column process in you might not want to do because this

might contain sensitive information you might want to give it over if you removed all the sensitive information that you could do of course um and this is fully up to you now uh the next thing you want to give in is of course some kind of available API most not notably some globals that are always there buffer Json these things that are expected to be there and

working from the JavaScript runtime you want to pass in um depending on what it is you might want to modify it and then finally uh you want might want to give it a require function now you could give it the original require but then the whole sandbox model would be broken a bit because I mean now you got access to yeah anything right so you can require

uh process so child process and run any any kind of process including reading out the original environment variables uh you could require fs and and read from the file system so this is something you may not want to do instead that's why I denoted here custom require you might want to run it with something where you Safeguard it so certain things might still be allowed I mean

depending on what is the name of the module uh especially internal modules maybe coming from the same microfone and you should just read them out and it's all good but then again in general uh you might not want to give it access to anything so FS or any kind of third party dependency that you have installed you shouldn't give access to here and finally we just put

in there the module uh exporting module in there um to get rid of that all right so there are two more things I want to discuss but I will only touch them very briefly because they're web standards and I just want to highlight how important it is that you actually respect them and have them really correctly used so the first one how are you uh let's say

again treating third party script injections especially with ones like kog we have already seen how we can safeguard against modification our own code but the mitigation that you definitely want to use still is a in the browser is a is a really good content security policy definition so uh this is done be some headers and it will limit what scripts can do from what sources they can

come and if I don't know they can be extended by themselves for instance we inline evaluations and things like that right and at the end of the day this will limit arbitrary code but also other re resources on the client num piness is very important how it looks in general is that uh your users enter via the web browser your web page and it sends back on

the index HTML and the metadata but usually in the headers uh CSP rule right and this rule that contains now what sources what Origins are allowed and I don't know inline scripts and what not how what kind of scripts are allowed in general U but also other assets images Etc now um there is the possibility and that my opinion you should really do that to also report

violations of the policy quite often that violation is not let's say a really attack or or something like that it's really just you didn't think of something right you're using I don't know a third party dependency and that also needs to load resources from another server and now it's up to you to evaluate do I want to keep the dependency can I maybe modify this URL or

do I really want to allow this URL but then again you might not see this directly and therefore having such a CSP reporting uh URL is quite cool how you do it is like this so you you find the header you give it a default Source this will be used now for all the assets if you don't let's say override it images in this example You' say

whatever take it from anywhere same as media audio video right but then scripts you might want to say my scripts are all coming from userscripts example.com like microphone and assets example.com and then only this source is allowed but there's no inline scripts allowed so no eval use or function or a script that has just text content in there is not allowed here right and this crucial and

again test your rules before you go there is a special header called content security policy report only set to policy and then you can have a reporting endpoint and therefore it will not um uh put any any any errors it will not plock it will just report these as warnings and report it to the to the endpoint uh Additionally the reporting endpoint is optional in my opinion

really good if you want to First roll it out let's say for a month to your end users and then see yeah what what kind of violations came back and then you can uh refine and and uh iterate your rules all right finally uh finally Tech Vector um in the misconfiguration space um yeah you could send some authentication data um to yeah from unwanted SES essentially and

therefore really open open your uh Services more than they should be and it's quite it's a backend vulnerability but you can also solve it in the back by sending a certain set of headers known as cross origin resource sharing or course and this essentially will avoid all kinds of things essentially also avoiding sending authentication data or other sensitive information um unwanted headers uh if the site that's

using it is from foreign domain now from a cookie perspective that might anyway already be established if you use the same site policy might be not depending on how your cookie is constructed but then again um what you want to achieve is a behavior like this where say okay uh I'm now uh requesting from my from another server an image that should be just fine and uh

I allow that um and we're good but then again uh if uh request is made to some of my apis you don't want to allow that so you're sending that a different set of of uh course headers on the pre-flight request which which is uh the option request that's sent from the browser always when there is a cross origin request incoming meaning from a different um origin

you're sending a a request and so with this in mind um and now I wanted to leave some room for questions that's why I hurried up a bit and I hope we got some thanks everyone for the attention and uh let's hear it for for some questions thank you uh so much for that uh floring it was really really insightful session um I want to kick off

the questions with a question that I have uh just on my own here I was Wonder you've gone through a lot of different attack factors uh from here on the micro frontends I was wondering um is there a common security mistake that you see in lots of front ends or is there something that is perhaps more predominant than the others in in some of the subjects that

youve covered I mean uh I still would say I mean of course this list wasn't taken out of of nowhere uh this this I think covers it pretty much but um the number one is definitely the use of authentication tokens right I mean sure that they're very helpful and and I'm also for for simple web applications using them but there is always a massive threat behind it

and I mean uh luckily I wasn't let's say at least always in the room when when problems were happening but what I can tell you when when hit the fan really I mean really literally even it uh the thing was in in let's say 95% of the cases that a token was used and the token was sent somewhere else and then suddenly I mean fortunately it was

always where the toen went essentially I mean no one profited from that but I mean if someone would have wanted to profit then really real user data could have been exposed and and and a lot of worse things could have happened so this is this is a very sensitive topic these tokens are super powerful and uh I would always try everything to to guard around them because

uh if they go in the wrong hands I mean you're you're dead and I mean we we are quite often also as web developers right we are quite often just pasting these tokens somewhere in right so of course these are usually quite nice Pages like JWT Ms or you know doio whatever then to to just see our token be composed but I mean this is already all

already also not very nice from a security perspective so I would always say these tokens they are so powerful and mighty you might want to be very cautious about them um so this is the number one thing that I see um being misused quite often yeah yeah definitely and I it's it's great we say that because so often in security we we talk about very complex uh

attack systems we talk about very complex and sophisticated you know supply chain attacks from State actors and all of that and then when you look at the the the breaches that happened you know half of them are they've bought a token from someone or they' fished and they've got an excess credentials you know so we're still we're still suffering from um security you security basic so I

really relate to that social engineering is the number one attack Vector still right so gu some some responsible guy for security of a large company was was asked what does it make uh lose your sleep at night night and uh we responded well uh it's uh people they click on everything in their emails like everything and I mean the especially when they when they are targeted towards

corporate users they quite often really well done in my opinion they're not like you know as a private user you often get these fishing emails where you can immediately say I I don't know it's broken English it's it's not even the real company's logo or you always notice it right usually but the company ones they usually really well done because I mean companies can actually send you

these emails also last notification you need to really log in now and so and they and they even make these these trainings then where they say well if we send a very important message that's properly spam but then they they even they still do it themselves so it's really hard as as a corporate let's say user or an employee there to to distinguish one on the other

they're really well made these fishing emers there and so this is of course still the number one vector they could just grab it of course there must be still something else open but yeah it's yeah social engineering always work yeah definitely and and developers are of targets of that um we don't have any questions from the audience coming through at the moment so uh if you do

have any questions be quick to get them in here otherwise we are going to release uh floran uh black to the Glorious town of Munich um but I think we're I think we're finished here so stay tuned in the security Channel we have another awesome talk coming up right after which is going to be on building secure and flexible multicloud imag with multi boot mode so Florian

I just want to give one final thanks for being here and sharing uh your knowledge with us and uh and and finally I see your LinkedIn down there is that the best place for the audience to connect with you if they want to perhaps follow more so the LinkedIn link for Florian is down there I'm sure if you just search his name he will pop up so

Florian thanks again for coming here and wishing you all the best for the rest of the day you do bye for