 So hello everyone. So yes, I discovered AWS before OpenBSD. I'm very new to OpenBSD and this is gonna be part of the talk I'm gonna give today. So first of all, a very quick introduction. So my name is Laurent Bernal and I work at a small consulting company called D2SI. I've got mostly a Linux background and I'm just getting to know OpenBSD. I've been working on cloud projects for the last five years or something and I really like it. And I really love discovering, building and breaking new things and I really enjoyed discovering OpenBSD. So what you can expect from this talk is on this slide. So the first thing I'm gonna talk about is how OpenBSD came to be on AWS and how it's integrated with it. And then we'll talk about, we do a demo which hopefully is gonna work, but it's a demo so we'll see. And how we can use OpenBSD to do microservices and I'll give you an example of how we can build dynamic VPNs using a tool like console and all this on OpenBSD. And finally, throughout the talk, I'm gonna give you my feeling with OpenBSD and I can already tell you that it's been very good and I've been very impressed by this operating system. So first is, well, how OpenBSD came to be on AWS. So it's all started when, okay. Sorry. Do you want me to talk louder? I can talk louder. Okay, so the whole story, so the whole story of OpenBSD and AWS started in 2015 when Antoine Jacouto, who most of you know, I assume, started working at D2SI with us. And at that moment we're already working a lot on AWS and Antoine didn't know AWS very well at the time and it checked if OpenBSD was working on AWS and it wasn't. So most Linux distribution were already available on AWS and FreeBSD was also available, but OpenBSD was not there. So it took up the challenge to create an image for OpenBSD on AWS and it proved to be quite a challenge because, well, it was, it made an image quite fast at the beginning, but then discovered that due to lack of Zend supports, many things were not working. So the instance was booting, but there was no network support at the beginning. So thanks to a lot of work by Mike at Sdenera, all this Zend support has been progressing over time. And so basically like beginning of 2016, there was the first OpenBSD image working on AWS. If you're interested in all this story, you can have a look at all this link I put on the slides. So the first one is like an introduction of how the first image was built. The second one is the GitHub repository where you have the code on how to build the actual image on AWS. And the last one is by Mike and it's explaining how it worked on Zend support for OpenBSD. So yes, so the first image worked when the network was fixed and the second issue was disk. So at the beginning, OpenBSD was using IDE fallback for disk support. So it was okay for the root disk, but if we're adding additional disk on AWS, it was not working. So like mid 2016, this was okay. It was fixed. What a big surprise at the end of 2016 when suddenly some OpenBSD machines were not starting. So when we're starting an instance on AWS with the same image, in some cases, it was not working. So it was like very surprising. And what was happening is actually, AWS did a challenge in the hypervisor and some primitive from Xen were not supported. So this was fixed in probably January 2017. And so it was on this fix available since 6.1. And so the picture I put there on the right is at the time of the first patch for this issue, we're actually working for a customer in Monaco with Antoine and he received an email from Mike telling him like, I have a patch available. Can you test it? And we're at the bar, so we're drinking. And so we're discussing and suddenly like Antoine like couldn't take it anymore. He took up his laptop, patch it, applied the patch and tested it live in this bar. So this is what this picture is. And you can see like traces of pizza on the table. So all the demo I'm gonna show you is gonna be based on 6.1. And you can expect many more performance improvements in 6.2, so very soon. So let's have a look. So I'm gonna start an OpenBSD machine on AWS. So it's gonna be hard typing with the mic. I'm gonna do my best. So I don't know if most of you have already seen the AWS console, so this is like the console where you get to in AWS where you want to create instances. And so what I'm gonna do now is I'm going to create an OpenBSD instance. So I'm just gonna look for OpenBSD. Okay, now I'm gonna get the latest image here. And I'm gonna start it. So I won't touch most of the options. I'm just going to give it a tag. So we know what it is. Okay. Then I need to be able to access the machine. So what I'm gonna do is I'm going to create a security group which is for people not familiar with AWS, a firewall in the hypervase of AWS to filter traffic. So let's call it SSH demo. Okay, typing with one hand is definitely gonna be tricky. And what I can do is I can even say, okay, only my IP, so it's, people won't be able to connect to it. And so now it's starting. So what's important, and we're gonna deep dive into this just later is, it's asking me for a key pair. So a public key that's gonna be put in the authorized key file on the machine so I can connect to it. So the machine is starting. It's gonna take about probably like one minute. So you can see here my machine is starting. Okay. And we will be able to connect to it in about a minute. So as you can see, like we have several information on the machine. Like it's been given a public IP address I can connect to. It also has a private IP address because what AWS does is all machines only have private IPs. But if machines are in public subnet, they have one-to-one net mapping with a public IP address. So we will be able to connect using this address. And then you have all the things like instance type. So I chose a very small one. We don't need any more anymore. And you also have like security group, which is the one I just created to allow only connection from the wifi IP address on port 22. So let's try and connect to it. Okay, so here I'm connected with the user called EC2 user, which is standard on AWS. And I'm gonna explain to you afterwards how it's worked. So as you can see, I'm just connected to the OpenBSI machine on 6.1. And that's it. So we have an OpenBSI machine inside AWS. So it's not very interesting, but we're gonna dive into a few more things. So the first thing is, you saw that I put my public IP address when I created the machine. And the question is, how can I connect to it? So of course I have my private key on my laptop. So that's why I was able to SSH. But how was the key downloaded to AWS? So the way this works is, AWS exposes a metadata web server at this address there. And there are a lot of information. And we're gonna go through a few ones afterwards. But the one we're interested in now is public key, which is like a directory where you can get the public key that you gave to the machine. So we're just gonna check that. Okay, so as you can see, when I connected to this and with the same address I gave you, I can see this and now I'm gonna get the public key itself. Okay, so this is actually my public key. Okay, so it's available on the metadata server. And as you can see, if I look into my authorized key file, I have exactly the same keys there. So this is how it's, this is the same key. So now the question is how did the key get there? So this question is how did it get configured and how my candidate up there is actually interesting is to do this, most Linux distribution rely on a tool called CloudInit. So I gave you the link there. And basically this tool is as its origin in Ubuntu Cloud. So they wrote it to configure machine when they were booting. And it became like a standard for most Linux distributions. So they almost, I mean, the other one I know, now use this CloudInit. So CloudInit does a lot of things, but it's a very big piece of software in Python and it's very Linux specific. So in order to have like a minimal CloudInit implementation, Antoine wrote EC2 init there and you can access also the repository here. And this tool is actually run when the machine is starting and it's very early in the boot process because it started when the interface comes up. Okay, so we can have a quick look at this file. Okay, so you can tell it's when the interface comes up, it's configured using DHCP, which is the normal way to do things in AWS. And then it's executing this script here, the one I was just talking about. Okay, so this script is not that long, but I won't go through it. I'm just gonna give you a quick idea of what it does. Okay, so this is like all these other functions called by the script. And I'm gonna go through it quite quickly. So the first thing is, since this script is run very early in the boot process, PF is not open. So the first thing the script does is it opens PF so we can connect to the metadata server. The third thing is, this script is run every time the machine is started and we only want to configure it once at the first boot, basically when the instance is created. So the way this is achieved is it's getting a metadata information, which instance ID, which is like the unique identifier of the machine inside AWS. And it's comparing it to a file there, so VARDB EC2 init. And if it's different, it's means like it's a new machine, okay? And if it's a new machine, we need to configure it. So the first thing it does, then it's actually creating the VARDB EC2 init file. So it puts the instance ID there. So when we reboot, the script is gonna fail, it's gonna stop at the first if. And then it's getting the public key. So this is how my public key got in there and how I connected to the machine. It's configuring the hostname of the machine based on AWS metadata, because when you create a machine in AWS, AWS gives it a default hostname. So this way it's gonna match. This function here is executing user data, which is another metadata information that AWS gives. And we're gonna focus on that a little later. This last two, I'm gonna first talk about this one. So this one is easier to understand. So this screen is going to clean up the instance. So if you create an image from an existing OpenBS installation, what's gonna happen is you're gonna have SSH key logs and DHCP leads, for instance. And this script is going to remove all that. So we start with a brand new machine. Okay, so then when this is done, the machine is gonna boot. Since there is no SSH key, it's gonna generate one. And what this script does here is gonna write to RC first time of very small scripts to display the fingerprints of the SSH key, because once again, it's a standard behavior for most AWS images where at the end of the boot, you've got the fingerprints of the SSH key that have been generated for the machine. Another thing is you remember when I connected, I used the EC2 user to connect to the machine. So this is like standard behavior on AWS. Well, basically you never connect as root. So you use, there's no SSH key for root. And Amazon Linux is using EC2 user from the beginning, and most Linux distribution went the same way. So Red Hat, Federal, CentOS, and FreeBSD made the same choice. Debian and Ubuntu made different ones. So as you can see, the Debian default user is admin and Ubuntu is Ubuntu. They never do anything like the others. And so, and when I connected to the machine, this EC2 user has unlimited do as access. So if we look at the configuration of do as, we can see that we have all the missions. Okay, so you can see that I can do anything with EC2 user and I don't need to enter a password. So for instance, I can do, and so you see when I de-played the image, I can see all the fingerprints from the machine, from when it booted. So the one created by the script I showed you earlier. Okay, so now that we have an instance, we're gonna try and do a few things with it. So the first thing we're just gonna do is we're going to install a tool called Terraform. And then we're gonna clone a repository and do a few things with Terraform. So for those of you who do not know Terraform, it's a tool to describe cloud infrastructure components and build them in a reputable way. So you can think of it as puppet, but for, instead of configuring several services inside server, it's going to configure infrastructure. So you have alternative like cloud formation, which is AWS specific and hit that was developed for OpenStack. But Terraform is getting to be like the standard for all these kinds of things. It's supported also by GCP, by Azure, and by OpenStack now. So let's do this. Okay, so first I'm installing console and now I'm gonna install Git. Okay, and then I'm gonna clone a repository where all the demo is. And everything is on GitHub, so you can have a look at it afterwards if you want. Okay, so in this repository we have several things. And the first thing I'm gonna do is I'm gonna build a VPC inside AWS and I'm gonna show you what it is. Since it's gonna take about a minute, I'm gonna start it. So, okay, I didn't install Terraform, sorry. Thanks. Okay, I went too fast. I already installed console on this machine where I don't need it. So that's gonna work a lot better now. It's very hard to type with a mic. Okay, I need something else. So this is interesting. So what's happening is I'm telling Terraform to do things and I have no permission inside AWS to do it. So what I forgot to do is to update my credentials so I'm to upload my credentials there. So I'm gonna do it right now. Inside my AWS credentials file so I'm telling the one I'm using. Okay, okay. That should have worked a lot better. Okay, what happens? I'm going to create the database directory. So basically what I did is okay, thanks. It's called credentials. So now I need to move it. That should work better. Okay, we're there. Sorry for this. Well, and actually this is not the real demo part because afterwards things might break. This is something that should have worked like from the beginning. Okay, so I just did Terraform plan which is like telling me what Terraform is gonna do. So it's telling me that it's going to create a whole bunch of resources and I'm gonna show what just afterwards. Okay, so I don't know if most of you have heard of Terraform so I'm just going to give you a very quick introduction to what it looks like. So basically in the, on the black box is here you have description of resources inside AWS. So on the top, for instance, you have the description of the DPC, sorry, which is basically like a private subnet inside AWS, a dedicated subnet, a whole bunch of subnets. And inside this isolated network you can create different resources such as subnet, for instance. And this snippet here is creating a public subnet. So what's interesting is this resource is a subnet and I call it public. And what's important here is I can give it a reference to another object that I've created before. So this VPC ID there is actually pointing to the VPCs that I've created before. So I can like dynamically get the idea of the object that was created and Terraform is gonna do a whole dependency graph so all the resources are created in order. And in addition to like networking things, I am also creating a machine. So a bastion host where I'm going to Ssh to connect to different machines. And like you have like different parameters for machine like the instance type T2 micro, which is the same one than the machine I'm using right now. The AMI which is the image I'm using and here it's so the open BSD AMI and in which subnet I'm gonna create it and so on. So if we're lucky Terraform is going to have worked, let's have a look at it. Okay, so it's still creating but I can start showing you things. So I'm going to the VPC parts of AWS. So I'm gonna show you the VPC I'm creating. So let's filter on the new one. So it's this one called demo, EuroBSDcon. So this is this VPC with this address range. And I have like several subnets like three public and three private subnets. Okay, and so everything is like is being configured right now. And so if you remember just before I showed you an example with only four subnets because it was easier to fit on the slides. But what I'm gonna do now is I'm gonna show you what we're actually building. So this is what we're currently building now. So everything is almost ready. The only thing that's missing is the NAT gateway here. So you have two different kinds of subnets in AWS public ones which are machine we have which have a public IP address so you can directly connect to them. And private subnets which are subnets for machine only have private IP addresses. So if these machines want to connect to the internet they need to be added and there's a service inside AWS to provide this NAT. So basically any machine here would connect to the internet using this NAT gateway. And this is a little long to create but it should be okay now. About a meter is generated in the description. Yes, exactly with the description I gave you and the examples is what's in the code there actually. Okay, which is like different thing because it's not the same kind of exactly the same thing because it's different subnets but it's exactly the idea. So it's a language that describe what you want inside AWS and then it's going to create them inside AWS. Oh, it's similar like what we... Yeah, exactly. Okay, so everything is done. So this is all the objects that were created. Okay. And they can connect to this new Bastion machine here and here we go. Okay, I'm connected on the new machine. So this is the first machine here. So I can show you its IP address. So the one from which I'm running Terraform. Okay, and this is the new one. Okay, so this one is in the address that I just showed you on the slides. Okay, so now what we're gonna do is we're going to start creating more interesting things. Okay, so we had like the basics, so all the network basics. And what we're gonna do now is we're going to build a console cluster. So a console is a tool developed by HitchiCorp. So the people who do Vagrant, Packer and Terraform. And it's used for service discovery and it's a distributed key value store. So in our case, this cluster is going to be made of three machines there, which are console servers. So servers that participate in the rafts distributing consensus and that store data. And this one is just a client of the console cluster. So it's part of the cluster, but it's gonna store any actual data and not participate in any master election. And I'm just using it to connect to the UI so I can give you like a graphical version of what's happening and let's do that. Okay, so now I'm using another Terraform script. It's similar to the one before, but instead of creating network resources, it's going to create machines like the four machines I just showed you to build the console cluster. So it's gonna take probably like a minute. Okay, so this is a slide, but I already told all this. What's important with console is it's used a lot in microservices because it allows service discovery. So basically machines or containers can register as themselves as providing a service. And then you can use console as a DNS to connect to these machines. It also provides a key value store. So you can store configuration and you can have your application get the data from console and get configuration from there. What's important is it's very resilient. It's been tested a lot for resiliency. That's why there's this rough implementation for to make sure that there's always consistent. There's always a master and if one node were to go down, everything would still be okay. So let's see if it's up now. Okay, so as you can see there, it's up. Okay, we're gonna have a quick look at it. I'm going to, as you remember, there's all these machines have only private IP addresses. So I need to connect to this one through this one. So I'm just gonna do that. So this is a console UI. So the cluster has been built. And as you can see console has identified four nodes. So three console nodes where there's one service which is the console service itself. And one console agent where there's no service. It's only a client on the cluster. And so this is the view we have the UI from console, but we can also check it from the machine itself. So I'm going to connect to one of the console servers and show you that. Console is not AWS specific, it could run anywhere. And Terraform can drive AWS, GCP, Azure, OpenStack, and many more. No, no. I mean, the AWS support is very important because it's how they started. But there's a big, there's a very big community and many people like working on it. I can see here exactly the same information we had on the UI. Okay, so on this server we have console installed and the agent. So now I mean, you remember I told you like, I started standard open VAT machine and I have console installed. So how did that happen? Did we did? So you see that all these machines are configured and we have a console cluster. But with the AMI, so the image I used when I started the cluster is a standard open VAT machine with nothing installed in there. So of course console is not installed there. So the way this works is with the user data I mentioned before. So it's a script that you can provide when you create an AWS machine that's going to be available on the metadata server and that is going to be run by cloud init or in our case, EC2 init. And it provides you a way to bootstrap the machine and solve a whole bunch of stuff and do configuration if you want. Yeah, you could, you could. And actually one of the reasons cloud init is so big is because you can have direct puppet primitive in there for instance. So you could do a puppet run here for instance. In my case what I want to do is very simple. So I don't need puppet but you could definitely do it with puppet if you want. So what I do is basically I install console and then I do the console configuration. So I'm not going to go into too much detail but basically this part here is telling console is telling console that this is a server. Okay, so remember there's two distinct nodes in console, servers and clients. And so this one is a server and this one the bootstrap expect is telling like don't bootstrap any cluster while you don't have at least three members, okay? So because if you don't have anything like this in there when the server is going to start it's going to start in standalone mode and you wouldn't have any resiliency. In our case we want some. So we would tell console like start with three nodes at least. Sorry? Yes, exactly. But I think like if console server is by itself it's going to establish current for one, okay? So that's why it's I'm telling it well don't start anything before you at least three. And the thing is like it need to discover the host, okay? Because the first all the three console servers are going to install console and start with this configuration. But the thing is they need to find the other ones to build the cluster and build the current. And the way it's done is you have different discovery mechanism. And the one I use here is integration they did with AWS which is it's trying to discover other members from the cluster by using AWS API. So what what console is going to do is going to describe all instances and it's going to have all instances is going to try to connect to all instances with this specific tag here, okay? So a tag called console cluster with value console and I'm going to show you the AWS console how it looks afterwards. And then we need to enable the console service. So if we reboot the machine, console is going to start. And then there's a small workaround I had to do to get console to start at first boot is since I enabled console very early in the boot process it's done by when the interface is coming up. So it's enabled. So it's going to be written. This is going to be written to rc.com.local. But the thing is this file is sparse earlier and only once in the boot process. So basically console is going to be appended to PKJ scripts to be to be started. But since it's not going to be reread afterwards console would not start, okay? So to have it start what I did is I write to rc first time start console, okay? So this way it's going to start that afterwards. Here on the console, the few things I told you. So we have now we have much many more instances than before because we have the new, the four new ones, the console ones. And if I click on this here I can show you that there's a tag and this is how all the console servers are finding each other. And also, so I won't dive deep into it, but the machines needs to have permissions to call the AWS API. So the machine have a role which allows them to do a describe instance. So they at least all the instance with a given tag. Okay, and if you have a question about this you can discuss this afterwards. So now that we have this console closed, so well what are we going to do with it? So there are many things you can do with console I was saying before, but in our case we're going to use something that's pretty simple. We're going to use a companion tool to console that's called console template. And what console template does is it connects to console and watch for keys in console and when they change it can generate a template it can generate a file from a template and it can execute a script like a reload of configuration for instance. So what we're going to do with this is we're going to build a dynamic VPN gateway. So what we want to do, what we want to achieve is to have a generic VPN machine without any configuration. And what we could do is put the configuration we need like end point, appreciate key and all this inside console. And then it's going to build the configuration and start the VPN. Okay, so let's do that. So this is where we were before and I'm building this new machine here. Okay, and this new machine is going to be the machine which we are going to use to be at the VPN. So it's going to be ready in a few seconds and we can have a look at it. So what we're going to do just afterwards is we're actually going to connect, sorry I'll go back to that afterwards. It's just to win some time. So what we're going to do is it's going to be this. So I'm going to start a machine inside another AWS region, the US. This is the one called demo there. And I'm going to build a VPN towards this machine and I'm going to be between this machine here and the region in the regional region of AWS. I'm not going to build a VPN between my OpenBSD machine inside Ireland and another OpenBSD machine inside Virginia. What I'm going to do is I'm going to use the native AWS VPN service which is called virtual gateway in AWS. So basically AWS has a VPN service and what I'm going to do is I'm going to connect my machine to this VPN service and then I'm going to try and ping the demo server inside this VPC in Ireland. So let's just go back to the machine and see where it is. Okay, here we go. And we can check that IPsec has been enabled. There's no IPsec.conf configuration yet because I haven't done anything with the machine. Okay, so there's no flow, there's nothing. I mean IPsec is enabled but there's nothing in there. And the thing is you remember before we did, we installed console using user data and this time we did a few more things. So let's have a look at this. Okay, so this VPN server what we did is we enabled IPsec, which is what I just showed you. Okay, here. And then we installed console and we installed this, not what I was telling you about which is console template which is going to connect to console and get data from there. So we're installing the console template package and we configure it. Okay, so we're telling you to connect to the local console agent. Okay, so we installed console agent on the VPN machine. And then there's this template configuration which is basically, well, I have an IPsec template file. Okay, you're going to use this template and when you have keys inside console that matches this template, you're going to generate this IPsec.conf file. Okay, and when the file change, what you're gonna do is you're gonna run this command which is gonna reload the IPsec configuration. And here is the template here. So I want, so the way the template works, it's basically I'm gonna create keys inside console that are gonna look this way. Okay, so I'm gonna have a root key called VPN and then like a description for the VPN endpoints I wanna connect to. And then I have three subkeys which have all the configuration I need to build the IPsec configuration. And so that's basically the network I wanna connect to, the endpoint which is the IP address of the machine I want to go to and the project key I wanna use. So basically from this in console, we're gonna try and generate this configuration in IPsec.conf. And the way this is done with console template is with this, I mean frankly awful template language which is derived from Go template. And what it does is it's going to iterate over all subkeys inside VPN. So this is the first line. It's gonna check if these variables are not empty because I wouldn't want to create an invalid IPsec configuration. So it's like basic sanitation. I don't want this variable to be empty. And then it's gonna generate this code inside the IPsec.conf file. Okay, so let's go back to the machine. We can check that console and console template are started. What I'm gonna do now is I'm gonna create the machine inside the other region so we can check that we can actually build the VPN. So I'm gonna go to Virginia here and I'm gonna create a new machine. So it's also gonna be an open BLD machine. Let's do that. That's not gonna work. Okay, so this one is a copy of the latest machine. Let's start it. Okay. Now there's, okay, so let's call it. Let's give it a name. Is it okay? So that should work, okay. So the instance is starting. So this is a new machine that's this one is in the US. And what I was telling you before is we're gonna build a VPN which is connected to the AWS service inside, for VPN service side of the US. So it's configured here. Okay, so this is like the VPN gateway from AWS. It has been created. And the reason I created it before for the demo is building this service and configure it is taking like at least five to 10 minutes. So for a demo it's kind of long. And so this endpoint here is the public IP address of my machine, so my VPN machine. And the way I did that to make sure that this address is not gonna change and that my VPN is gonna come up is I use a concept called an elastic IP inside AWS. So basically when I started the VPN machine instead of letting AWS pick a random public IP I told him like use this one that I've reserved already. And then there's this VPN connection. Okay, so this is a VPN connection. And if we look at the details, well there are two endpoints inside AWS which both with these two IP addresses and the tunnel is done of course, because I mean there's nothing configured on my side. Okay, so what I'm gonna do is I'm gonna get the configuration and I'm going to input it inside console. So let's go there. Okay, so this is the configuration for the VPN. So you have like configuration for different equipment but I'm just interested in the appreciate key, the IP of the endpoint and I already know the network. Okay, so I mean you remember when I go to the machine there's no thing in ipsec.conf we can go and remember. There's nothing in there and what I'm gonna do now is I'm gonna put the necessary information in console to get this generated. So I'm gonna mirror the organization I showed you before. Okay, so I've put all the necessary information inside console and if now I look, thanks. Right, thank you. Okay, so this is the part of the demo that where it may not work, let's see. So I'm taking the IP address of the machine that has been created. So it's really private IP address inside of AWS and I'm gonna try and ping it. Okay, cool, that worked. Okay, that was lucky. Yeah, I mean of course like all the time when you repeat it works but when you do demo it kind of think like you have so many things that's so many moving parts. And so if I look at the IPsec flows, so IPsec CTL. Okay, you can see that my two, I mean all the flows have been created with AWS. So we're done for the demo part. Let's go back there. So this we did. Okay, and so we're done. Like I'm a little late, so just like at the conclusion what I wanted to do a few things. I mean, one of the reason I think OpenBSD is very interesting for this kind of service. It's like it's basic infrastructure service that's gonna be core in your infrastructure when you start using it. So using a simple and very secure operating system is very important. So I think OpenBSD is a very good choice for this kind of use case. And in my demo there are many things that could be improved in terms of security. I mean, I did it in a very simple way. So it's, I mean, it's already a little long. So in console you can enable SSL. In my case there's no SSL communication. You can also have ACL. So you can limit, you can give tokens to people for certain set of keys and limit access to certain keys because you wouldn't want anyone with access to console to be able to reconfigure your VPN. And also you saw that I put the pressure key inside console. Since it's a secret, it may be better if it was encrypted even at rest. And so there are all the tools you could use for encryption and there's actually a tool also built by the people that do Terraform and console which is called Vault, which can be used to store like secrets. And Vault also works on OpenBSD by the way. So my use of OpenBSD is very recent but I've used it in several use cases like VPN gateways, I've just showed you. DNS proxies or DNS resolvers in our console. Of course there are many more use cases. What I found interesting, and this is also a discussion I had with Antoine when he told me to propose a talk for here was like it's interesting to see OpenBSD used for microservices kind of workloads because we can see that it can be used for this things for today. All the code for the demo is available in GitHub. If you have any question afterwards you can ping me on Twitter in the problem. And if you have a question now, I mean we have a few minutes for it. Thanks very much for this presentation. So that's a lot of automation in there already but there are some parts missing a clue like you have to Terraform stuff building everything automatically and then you have to create the VPC manually in your case and looking up the IP address from the Elastic IP add that to console manually again. Question is did you try to have something like Ansible modules creating the VPC they are available but then retrieving the IP information and putting it into console via Ansible or whatever or Puppet or... So the Terraform party, I mean actually Terraform is, you can compare it to Terraform and Ansible can be compared. I mean Ansible is mostly focused for what's happening inside servers even if it now has modules to be able to manage AWS. I think that for managing cloud objects Terraform is better than Ansible. One of the main reason for this is Terraform maintains a state of all the resources it creates. So if you remove something from your Terraform file it's gonna be destroyed. More as for Ansible, it's easy to deploy but when you want to remove things you need to have new playbooks. So it's actually very... You can use Terraform for the whole infrastructure part like VPCs and all these things and you could use the Ansible to configure the machine themselves. And it's like the build of the VPC was actually automated. It's the first Terraform run I did. I built the VPC automatically with Terraform. More questions? Was it the same question several times here? I saw more hands previously. The slides, yeah, sure. Yes. Ah, where? I don't know. I don't know if there's something that's already prepared by the conference otherwise I'd put them on Slideshare. No problem. So just get the fake LinkedIn account and you can go to Slideshare afterwards. Yeah, and the repo is there for the code but there's no sliders. What I'll do is I'll put a link to the slides on the repo. Next question? What's the state of Amazon supporting OpenBSD officially? Well, today there's no official AMI. I know it's a trick question. Maybe Antoine, you're a better place to emphasis. AWS is interested in having official supports but it's not done yet. But the AMI there is working very perfectly. Any other questions? Let's thank.