 So I'm going to talk about why do you want creating a safe access into your app when you are a SaaS provider and how you can do it with a Chicago port. So I'm Tomas and I'm working for the 2D POPNLM project, which is basically an application to help you build software and manage your project, project management stuff. It's an open source software and I'm also, I'm also like, I like Alpaca, but I think it's mostly available for today. So a bit of context. We are a SaaS provider, we are providing Tulip as a service for easy use for all our customers and we are also the main contributor of the product. So we have ways to build stuff for the product easily for just this usage. It's a web-based application. So we got REST API in PHP and we proposed something with its single tenant SaaS. So each customer got its own application and can do almost everything with it and we do not have interaction between clients. So each instance is really independent and we also provide support. So we get emails sometimes that just tell us that thing does not work and we need to fix it but we don't have any more details. So sometimes we we need to access the customer instance to see by no sell what's going on and to help the customer fix the issue. So creating an access in your customer instance is a bit hard because you need to really do as much as possible to protect it. You do not want to leak information, to leak potential access to other people because all your customer data are really, you are putting to your customer data. So you do not want to maintain unnecessary or permanent access into the application. When you don't need it, you don't need to have access to the customer instance. You want to restrict as much as possible when your team is capable to access the customer instance and of course something sometimes goes bad and you need a solution to you need to have a content agency plans to be sure you can do as much as possible to protect your customer data. So basically you want to know who accesses your customer data, your customer instance, when and how it's it. You need also to keep seeing really usable because when you do security sometimes you really do, you really do things that really great on paper but when you use it every day it's really hard to do, to use it so people are getting a bit angry with it and you need to find a way to ease the process. So basically we have no source product. We are relying on Ashikov Vault to do all the secret management. So Ashikov Vault is a really nice thing that allows you to generate and store secrets and comes with a lot of things like audit capabilities. Every operation you do on Vault is logged and you have the possibilities to do really strict access control. It's integrated really easily with all your infrastructure. So basically if you are an LDAP server, you can authenticate your user, your team member with your LDAP server or you can use GitHub or I don't know, there is a lot of things. You can also authenticate things like a pod in Kubernetes so you can identify people or things in more general matter. The audit capabilities of Vault is really nice because every action is really logged and you can choose where the information goes so you can just store it in a basic file or you can push into syslog or whatever circuit you have so you can, for example, push directly into LogStatch to be able to do some verification and some analysis on what's going on. And from the secret part Ashikov Vault has already a lot of things that are already built in. And it has nice, for some backends, nice things that Ashikov Vault will create for you, also create the user into, for example, your database. So when you need to access the database, you don't need really to have a credential or code it into your application but you can ask Vault to create a specific user for a certain time and just retrieve it directly so you don't store any more the credential of the application to access your database and you can just request it when you need it. It's really nice because even if the credential is like, you can still revoke it and the application will get another credential to use. So that's really nice and that's basically what we want to do in our application. But in fact, we are not in the real team circuit because we have a specific application so Ashikov Vault let you build your own, your own plugin in your own circuit backends to do that. Vault has a support for plugins and basically you just need basic knowledge of Go to do it. The last version of Vault even exposes a GIPC interface so you can probably use it with your favorite language as well. So it's only used to create your specific, your specific backend to your application. So in our case, you just want to create new user into your application for a quick time and even when you do that, you just, you also get all the nice vault feature with so you still have the audit capabilities, the control access and whatever vault come with. The only thing you need to do with the Vault plugin, you also need a bit of support in your own application. So if your software does not, does not waste to create an on-demand user, you will just need to extend that to be able to do it. And you will also need a way to authenticate requests coming from Vault. So basically for your case, to authenticate requests coming from Vault, we have a choice to rely on public key cryptography. So basically we create, we generate the private key directly into Vault. So the private key cannot be extracted from Vault. It's directly used from Vault and only Vault knows the private key. And on all instances of no customer, we just deploy the public key part. Then when we communicate with Vault, we want to communicate with our application to push a new user. We just, it just signs the request and the request can be verified from the application. This is something that is really quite easy to do now with Lab Sodom library, which is a modern cryptography, which provides you a way to deal with high-level cryptography permative. So you can just sign or encrypt data. Really, it's really hard to get wrong with LibSodium. There is bindings in almost every language. Go as it. So it's nice for the world plugin. And in your case, PHP has it in the standard libraries in the last version. And there is support in the old version with either an extension or a polish file, polish field to do it. So we almost have all new, all new, all new. We have all the things we need to build it. So how does it work in practice? Basically, when a team member wants to access a customer instance to do, for example, super stuff, you just need to authenticate against Vault, so potentially Vault will use this authentication backend to do it against your LDAP server. You will get a notification token and from that you will be able to request an account from Vault. So we will just call Vault with the token and the free condition domain name of the platform we want to access. Vault will then just request the creation of the account on your application. And so we will pass the user name, the password and an expiration date. So even if the communication is broken between Vault and the instances, the account has not been defined. It has a limited lifetime. And it will of course sign the wall request so your app will be able to verify if the request is already coming from Vault and accept or not the account creation. Once it's done, Vault will retrieve and will give you the user name and password and your team member will be able to authenticate against your customer instance. So this is quite nice because now we have a way to access to customer instances on-demand. You don't have permanent access to it but you can request it and you can also revoke if I don't know if you leak user name and password that has been generated or if your team member leak it's token or I don't know. The team member is completely compromised. You can just revoke all the existing accounts as it asks for the different customer instances immediately. So it's quite nice. It's quite centralized. And if things really, really go wrong, you can still revoke all the instances you have given to your user and just seal the Vault. It's a secure Vault so basically Vault will shut down and will stop any operation it's doing. So it will give you sometimes to audit the logs and to just see how much the merge is that has been with Intrusion. So basically a secure Vault is really nice because you can integrate it with existing infrastructure really easily and it gives you highly flexible secrets management so you can either use what's built-in but you can also use what you need. And there is all the audit capabilities and control access that are already built-in and really easy to use. The downside of this approach is basically you have one more sensitive endpoint to your software. You have all the verification of the request. If you do something wrong here potentially the whole thing is completely broken and so you need to really be careful when you do use implementation. However it's still better than just an accurate account into your customer instances so that bad but still better. In terms of usability, it's only a CLI. We only use the whole CLI to request the account so depending on how your team member is liking or not the CLI it can be a bit hard to use but there is still a still nice fine you can still use web interface if you have time to build it to make really thing easier for your team for your teams. That's all. Maybe I've been a bit short I don't know. You have 10 minutes for question? Yeah I have 10 minutes for question. Perfect. So the slide you've had where Vault was creating a secret on your own back end. Is that a custom secret thing you built in or is that one of the box? No no it's not out of the box. The whole thing is you Vault does not have a thing for creating it has thing to creating a PKI and just to creating certificates but it doesn't really have a thing to create the public key and just request a request to the application so it's custom built yes yes yes sorry if that sector must code no not way it's it's really easy to do with Vault basically it's just a plug a thing into you just tell Vault to the okay so I want to have a post interface so okay just push out and do it it's really easy it's it's I think it's 110 line of code or something like that so not not that much yes how we did the secret introduction into new customer okay so basically we we don't care we don't catch it's just a public key so even if the public key leaks we can okay but it's a public key so we can just even display it on the internet we don't care because with the public key you can't sign the request like if it were coming from Vault so basically even if the public key leaks we don't care hello where is the private key yes the private key is generated directly in into Vault so in Star by Vault it's generated by Vault and Star by Vault so basically the private key never never keeps our vaults and we does not even know the previous the private key yes okay if do we use Vault for anything else yes in fact we already have Vaults before doing this this we use it for all not say all all the secret management so we use it for the databases for anything that has password or so we already have we already have Vault into no infrastructure yes yes okay how would we link the account that has been created onto into with with basically the team member and to check it as a right to do it yes so basically it's we're right on Vault to do with that since Vault is the only thing that has the private key it's the only thing that can emit a request to create an account and you here you can basically adjust with the Vault control access you can just tell okay I won't tell I want I want those people to have the possibility to use this this API so only the people will be able to to call it but of course if after team members just give the username and password that has been generated to another team members you can't really can't really do something about that the only thing you can do it's to create a really short account on you on your app so basically we create our valid account so even if the username and password is given to another team member that does not have authorization the exposure time will be short yes yeah okay yeah hello is vault has support for material material encryption basically there is there is a way to use the HTCM with vault I think with the vault enterprise version we do not use it there is I don't think there is support for things like HGX or I don't know stuff like that but I don't think there is a really a lot of support basically what I should recommend when you when you use vault is to use a BME tell server and you it's the only thing that should run on it basically it's since it contains all your secrets in your infrastructure basically just isolate it as much as possible and do not run something out with it and it's basically the best way to help reducing the potential exposure and the potential issue with that yes do we use only do we use enterprise or the only the open source version we only rely on the open source version for now because we are fine with just not having support if things like okay the same banks and we know it and we will deal with it but for now we do not use the enterprise version you basically can do all the all what I've described today with with only the open source version anything else okay perfect