 All right folks, I guess we're gonna go ahead and get started then Thank you very much for coming out to our presentation this morning extending barbican managing secrets in a venture way Let's go ahead and start off with Kind of an introduction of our presenters today starting with My name is Audi Lee My name is Audi Lee, I'm the project lead for the dog tag certificate system, which is the upstream version of the Red Hat certificate system Dog tag has the ability to store secrets and issue certificates, which is exactly what barbican does Us working together. It was a perfect perfect fit I've been working with the barbican group for about a year or so now one of the barbican course and working mostly with working with the upgrade with the Plug-in framework, which we're going to talk about today And the certificate flows Right. I'm Nate Reller Yeah, I'm Nate Reller. I'm not Joe. Joe's here somewhere So I'm Nate Reller. I'm from APL. That's the Johns Hopkins University applied physics laboratory If you're not into that whole brevity thing So APL is a research organization We're what's called the University Affiliated Research Center. We have research in many different areas We have two spacecrafts that are mapping out the Sun. We have another on the way to Pluto a little closer to home We have Prosthetic limb research as well as cyber security and that's my group In particular my team is working on OpenStack and our goal is simple We just want to improve the security of OpenStack So we've been involved with OpenStack for over two years now a couple of features You might be familiar with are the cinder volume encryption We added that in Havana as well as the ephemeral encryption And of course if you have encryption you need secure key management. So that's what brought us together With Barbara Kim All right, so I'm Paul Kerr and I do a cryptography work for rex space and I'm actually operating on about One hour of sleep in the last 27 so I'm going to be mostly watching from the audience But I worked a lot on the pkcs11 plug-in that they'll be talking about here and in general I've been done a lot of work on the plug-in infrastructure So if you want to hear me ramble incoherently after the talk you're welcome to come and ask me questions Thank you Paul. Yeah, I'll do my best to go through his slides, but if I say anything wrong He can bump me over the head So my name is John Wood. I'm also with rex space and So my history on the project is I was the first I guess Developer on the project After after Jarrett so Jarrett rain had this idea and I'm you know, maybe a year or two before I started on the project And once he finally was able to form a team with Andrew Hartnett They they brought me on to try to set up the project get it off the ground And the idea was to try to get something ready in front of the Portland conference So we're talking, you know, almost two years ago next year And try to get something more people could evaluate the API and all that on there on their local machines And then I would say, you know probably around that time is when Douglas Mendeza ball came on board the PTL of Barbican And so it's been growing ever since so if they're if you don't like the structure of the project Please see me for complaints, you know Otherwise, I'd say let's go ahead and start on our presentation today So what is Barbican? Beyond a medieval fortification and defense in front of a castle. It is also an open-stack compliant secrets management service I'm gonna try this this cool thing out here. There is some Integration underway. This is just some of the integration work that's going on We also have scheduled tomorrow a design summit session Where we invite people that are interested to integrate with Barbican to come I'll show a slide at the very end of the presentation with all the schedule for those presentations And finally, there's a plug-in approach that we use to extend features of Barbican Which is obviously going to be the focus of the presentation this morning So big picture view just to give people an idea of what we're talking about here We have clients that wish to use Barbican Those could be other open-stack projects or just clients in general wishing to store and retrieve secrets out of Barbican We have Keystone for for authentication and authorization And then Barbican core will be referring all throughout the presentation to Barbican core and that's that's the API front end of Barbican, that's the the business logic of Barbican if you will Everything that's not plug-ins and so there's a certain amount of feature set then that we we want the plug-ins to deliver And so Barbican core will work with those plug-ins through a contract, which we'll be describing To to make those things happen And so then you have your basic plug-in you have a variety of implementations that are available once you have a plug-in contract in place And once you have that that interaction going Then you can start to use Barbican in your system so you can have clients working with Keystone to get their tokens Then they can make their arrest calls to Barbican Barbican core will then Work with Keystone to verify that token and collect the the role information applied against the policy and if all that Passes the Barbican can work with that plug-in to do its thing plug-in can do whatever is required behind that interface It responds with with its result and Barbican can respond back to the client And so once you have that interaction in place what you have that contract to find well Then you can start making other plug-ins that fit into that same contract so more plug-ins more better that's kind of the approach and so if you start looking at a contract is basically just a an abstract method or abstract class that is with abstract methods that Plug-in implementations would extend And so configuration we're using Steve door to to to pull those plugins in and use them and You can see a basic configuration would have namespace and a actual implementation class defined And that's how these things are looked up within the code So when you have a plug-in installed and you and you're ready to use it you can configure its behavior by Presenting in the Barbican config file a group of configuration Specific for that plug-in so every plug-in can have its own group of Configuration items within that config file and the idea being you can use chef or some other configuration management to To actually supply things like passwords out of encrypted data bags and so forth And so this is kind of the the landscape of the plug-ins so far for for for Barbican and So just briefly on the left hand side. We have the secret store interface, which is our basic secret storage and retrieval mechanism within Barbican Within that a subset of that secret store is HSM style plug-ins or crypto plug-ins we call them in the code base and these are Plug-ins that specialize in encryption and decryption of secrets, but they don't they don't themselves store those secrets So Barbican core stores the encrypted secret on on those those plug-ins behalf Then we have what we call certificate or see you know certificate plug-ins that work with CAs typically they don't have to but the idea there is Barbican core and those plug-ins work together to to so drive certificate generation workflows and finally we'll touch on the eventing plug-in structure that we're trying to get Working within Barbican. There's some early work on that So with that I'll hand this over to Nate to talk about the secret store plug-ins Cool. All right, so I'm gonna talk about the secret store plug-ins within Barbican What's cool about the secret store plug-in is this is what you can use to configure how you want your secrets to be managed by Barbican So for example, some of you may have requirements for how your secrets need to be stored So for example Some people have requirements that their encryption keys need to be created and stored on a FIPS compliant device That's tamper proof and has some auditing capabilities So if that's the case and your device is came up compliant You can configure Barbican to talk to that device using the came up secret store If it's not came up compliant We have a couple other secret stores that may work for you and if those don't work you can always write your own and I have a couple slides at the end that show how easy it is to do that So now I'm gonna give you a little bit more context for the secret stores show how they fit in with Barbican itself and then within Open stack in general So as John mentioned earlier, there's Barbican core What that provides is the restful API in the access control for all your secrets and the API for Barbican core has the basic methods for secrets So creating reading updating and deleting secrets and if you look at the interface for the secret store It's very similar has create read update and delete methods for secrets The big difference is the Barbican core Takes in the keystone token and and it needs that for the access control So the basic relationship here is Barbican core receives it does the access control and then delegates that method off to some secret store So we'll go ahead and look at an example to show the sequence of events for how this would work So we'll use the center volume encryption feature for that So we'll start off on the top left up there with Nova. That's the client so with the center volume encryption What Nova needs to do is it needs to get the encryption key for the center volume? so what it does is it talks to the key manager interface that's an interface that's within Nova and We have a patch out there for a Barbican Implementation of that key manager interface So if you like that patch, please give us a plus one But hopefully that should be in soon and what will happen is Nova will make a request to Barbican and say please give me this particular key so I can do the encryption At that point Barbican core receives that request. It does the access control checks Using keystone if everything goes goes well, and it's authorized to use that key It then calls a secret store and so secret store. Please give me this key At that point the secret store then does whatever it needs to do to retrieve that key in the case of the came Up secret store what it does is it actually makes a call out to an external came up server That came up server will return the key to the secret store secret store passes it back up to came up core Came our sorry Barbican core and then Barbican core passes it back to Nova at that point Nova has the key and then they can set up DM crypt and set up the encrypted center volume So we created the secret store interface in the Juno release and we also created some implementations of it So there's the hardware security module. This is the Barbican HSM secret store So John is going to talk about this one next. So I'm not going to go into too much there There is the came up secret store, which is the key management interoperability protocol That's an OASIS standard for talking to key management devices And the third one that we have is the dog tag secret stores So this is the one that a day developed and this talks to a dog tag server So this slide here just this lists the methods that are required for a secret store implementation So I'll go over these real quick just to give you an idea of what needs to be there There are two supports methods So what happens when Barbican core receives a request the first thing it needs to do is make sure that the Secret store can satisfy that request. So there are a couple supports methods there for that So it just basically checks. Hey, can you generate a AES-256 key for me or can you generate asymmetric keys for me? So it does that check first just to make sure that it can satisfy the request There's store secret. So if you have an existing key that you want to store it would call this There's get secret then we have a couple of generate methods. So generate symmetric key and generate asymmetric key So sometimes the user just wants you to create that key for them. That's what these methods are for and Then we also have get transport key This one I'm not going to go into too much detail. I think Audi may touch on it briefly But essentially what this does is this allows the client in our previous example That was Nova you can wrap the key between the client and the external server if you like This way Barbican cannot see that your secret while it's in transit through it So now I'm going to have two slides on secret stores and actually how you would go about implementing a secret store if you would like So I envision most secret stores Are going to be Adapters so they're going to call out to some external piece of hardware for the storage of their keys So this is how the came up and the dog tags secret stores actually work so essentially all you're doing is Wrapping the interface that is provided by your back-end device to what is provided by the the secret store interface So if we take a look at the table here, this shows the secret store method and the corresponding came up method So you can see how they map nicely together. So generate symmetric key calls create in the came up method Similar for asymmetric key and create key pair and so on and so forth so if you look through the code for They came up and the dog tag secret store All as you do is you get the request you have the Barbican objects You then translate those to your back-end device objects You open a socket send the message request across and then you wait for the result so the result the result is The only part that may be a little unexpected So if you notice for each time each of the methods that generates a new key This will be like generate symmetric generate asymmetric and store key the return value of that is what we call a secret metadata and This is just a dictionary. It can contain whatever you like in most cases What it will be is it will actually contain the ID that is from the External device that's storing your keys So essentially what you're doing is you're creating a mapping from the Barbican ID to your back-end appliance ID And then that metadata is then passed to subsequent calls to Retrieve update or delete that key So here you can see this is actually the return value for the came up secret store when you generate a symmetric key And then when you call get key for example or delete key, this is passed in You look through the dictionary make sure the UU ID is there and that's what the the UU ID you would pass to the came up device So that's all I have for the secret store, so I'll hand it over Thank you Nate So the next Next plug-in that we were gonna focus on was the HSM style and again I'm speaking on behalf of Paul who has very little sleep in the last day or so So like I said, if I if I say something wrong Feel free to throw something at me rotten tomatoes or whatever. I know you have some in that back back there, so Let's see so an overview So as I mentioned before the HSM plug-in Performs encryption decryption. It can also generate secrets, but it doesn't actually store the secret information So it uses a key encryption keys or keks that we'll call You know that we'll use that acronym all throughout the rest of the presentation Uses those keks to actually encrypt those secrets and so Barbican stores that information in its own database And then as as Nate mentioned there is a adapter plug-in to adapt the secret store plug-ins to the HSM style plug-ins And the actual implementation we have available now with the code base is a pkcs 11 based interface using that protocol and it's talking to a safe net HSM, but You know you could be wouldn't take much trouble to get a pkcs 11 based HSM to work with that I Will note that throughout the rest of the presentation as well. We're using p11 is the shorthand for that In fact, if you look at the code base will see p11 Referring to that There is a team also working on our HP etolic HSM interface So the contract for HSM plug-ins then starts with the crypto plug-in base abstract class and There's the familiar supports method to determine which plug-in to actually use There's a bind kek metadata method that we'll go into on the next slide more detail But the idea is that each project has its own key encryption key And this is an opportunity for the plug-in to establish that key and whatever mechanism that it needs to do And we'll show the p11 example in a second Encrypt and decrypt, you know your basic operations for HSM You would expect those to be on there and then to generate methods one for symmetric one for asymmetric keys Very similar to the secret store So if we look at what the p11 plug-in then is doing currently It establishes a master encryption key within the HSM and the idea is that's going to be used to wrap project key encryption keys and And so the idea is these these project project keys are actually going to be doing the the encryption process and So we also have an HMAC that's being established and that's being used to verify that encrypted project kek so As it turns out both those those pieces of information can be stored in Barbican But the MEC and HMAC itself will be established on the HSM and never leave the HSM So if you look at the process then We have Barbican core on the left-hand side and it's the Barbican database And then we have our plug-in in the center there p11 plug-in and then the HSM that it's interfacing with and So as I mentioned the MEC and the HMAC are established in that H in that HSM and So when Barbican core is ready to call that buying process and again that buying process will be called every time a secret Process is encountered for a project ID that hasn't been seen yet. So once that project ID is established it won't do this again And so the p11 plug-in orchestrates with the HSM to create that kek The master encryption key then is used to wrap that kek and an HMAC process is run To to aid in verifying that project kek later And so that produces your wrapped kek and HMAC result both those pieces of information are passed back to Barbican core and stored in its database So that but like I said that that's going to be once that's established that will be reused for all operations with that project from now on and so as a It's kind of a anecdote I would also mention you have to be this is this is going to kind of lead into a conversation We'll have a little bit later about plug-in versioning. Okay, so We what we ended up doing originally we were putting these project level keks right in the HSM And the problem there is for the HSM's we're using at rack space anyway There wasn't going to be enough space to store all the projects that we were going to support it be supporting secret storage for So Paul ended up changing his original design to use the master key encryption approach So that was the wrapped kek approach that we just discussed And so the good news is the contract didn't need to change Barbican the bind the bind kek results are stored into Barbican's kek database and Everything's fine. You know, I mean that's that's how it works so the plug-in determines what that that That metadata looks like and Barbican stores it on the behalf of that that plug-in and hands it back to the plug-in So that was good, but the problem is the semantics changed right so Now we were putting wrapped kek information that increased the kek information for the projects into that metadata When before we weren't and so that means when we tried to retrieve secrets using that old style Well, obviously that data was missing and we effectively broke retrieving those old secrets So even though we were using the same plug-in by name and that information is recorded on the metadata The information put into that metadata changed and that was enough to wreck things. So as I mentioned there's going to be a design summit to kind of dive into that and Try to standardize ways to control that probably through versioning So if we move on to encryption then as I mentioned before we have our project kek Wrapped in the Barbican database and we have our Mac and H Mac And so this is the starting point for for your your operations And so the seat the secret is provided by the client through the API and So Barbican core with retrieves the project kek for that sends that over to the P11 Who then orchestrates with the HSM to place that information into the HSM So the wrapped kek shows up there The H Mac then is used to verify it based on the H Mac Results that were stored when the kek was created in the first place and then that's unwrapped by the mech And then that unwrapped kek is used to encrypt the secret And so that's passed back out and then stored into the Barbican database So this is an essence where your encrypted data encrypted secrets come from in this process So if we move on a decrypt well, you know, it's as you might imagine. It's the reverse process So when you're ready to encrypt a particular secret You you pull those pieces of information the project the wrapped project kek and the encrypted secret pass that along back to the HSM same sort of H Mac verification and unwrapping process goes on and then unwrapped kek Then is used to decrypt that secret which is passed back out to Barbican core and is returned back to the client So generation. I'm not going to go into too many details on generation. It's it's a fairly simple process As you can imagine the wrapped kek and H Mac are always the inputs to these processes You know once that's established that's kind of a familiar familiar pattern But then for generation you have to provide the client would have to provide through the ordering process What the actual secret that they want to to generate is bit link algorithm, etc. So that information is provided and Then the HSM will actually generate the random bits for for symmetric It's it's relatively easy to do that and then the encrypt process that we just talked about is is run on top of that So just a configuration example then You can see we have you know the things you would expect out there a login password You can also see the MCAC label and H Mac label the labels are how Barbican refers to the information that's in those HSM they The H Mac and the Mac that never leave the HSM are still referred to via these labels So so Barbican core and the plugins can access those And so again, this would be Something that your configuration management would override those values as needed for your environments And with that Pass Okay, so certificate plugins So of course certificate plugin is just basically the plug-in that interacts with the certificate authorities To do certificates for x5 or not for x5 or nine certificates for pki Currently for Juno, there were two plugins that were written about tag and semantic of kilo. There's a digital digital plug-in That's being currently production The current planned use of an open stack is the load balance as a service for neutron Adam Harwell and and his guys have been working pretty hard on on getting Bob again in there but of course there are lots of possible future use cases any open-stack service that needs SSL server suits or needs User suits potentially signing suits like keystone tokens or something like that for pki. Those are all possible play things that could be done So the contract is pretty straightforward of the for the certificate plug-in you have Some support. Yeah, basically the same kind of methods So you're gonna see the same kind of supports methods that you've seen in the other plugins as well, too So this would be for example where you'd say whether or not your CA a supports generating an ecc Certificate or certificate with a certain key size or whatever the case may be your extensions or whatever Issue certificate request is going to be the call that you're going to use to Talk to your particular CA and start the enrollment process for getting a certificate coming out of it And that could ultimately return either a certificate automatically if it's automatically approved or It could return a status that says, you know, basically we're waiting for the approval on the CA side And so if you if you don't have a certificate that's already approved there You can of course always either modify or cancel the certificate request And then ultimately you're gonna want to check the status of that certificate request To make sure that you know when you get a suit when you get a suit It's gonna be returned and then it'll be returned back to my while we can core So then these are the methods that would be need to be implemented by a plug-in So they're pretty straightforward They all take three three parameters because the certificate plug-in comes in through the order Interface in the barbican API and then you're gonna have you can have an order Essentially associated with it. So it's an order ID the order metadata is gonna contain all the things that you need to specify what kind of certificate you want so things like the CSR or the The requester ID or something like that the plug-in meta has the same sort of role as Nick mentioned in the secret store it's basically a Dictionary that's used by the plug-in to store any data that it needs in order to keep track of the state of the certificate request So obviously for issue specific request one thing you're gonna Watch is the ID of that request on your on your CA so that when you check the status at a later point in time You have that ID ready to to go ahead and check It's gonna return a result objects will result DTO dotted data transfer objects Which essentially is gonna have the status the certificate any intermediate certificates retry parameters that kind of thing So just to kind of see how this this would work Some client is gonna make a post to order so that's new to on over there Load balance is gonna make a post to slash orders It's gonna the body of that request is gonna include all of the relevant parameters that you're gonna need To make the request So the CSR and so on all of those are going to be stored in the order metadata And an order ID is going to be returned to the client that that points a certificate task is going to be queued and once it is executed a CA plug-in is going to be selected by going through all of the plug-ins and and you know going through and specifying the Sports methods and so on Loaded by stevedore and then we're gonna call issue certificate request on that plug-in Which is going to make translate that into a CA specific API call To generate your certificate request on that certificate authority now at that point Certificate authority is gonna return a status It could be pending it couldn't have the suit itself That is going to be a CA specific type of Output which will then be translated by the CA plug-in into result objects which goes back to Bob again core and gets stored The orders updated so it's a sword and someone so it turns out that we store the suits Using the secret store interface, so they're actually stored When you when you get them back you're actually getting back something that'll be a reference to a secret Eventually we're going to get the order We're going to retrieve the order and the certificates and we're all going to send that back Now it's a little more complicated and not on on the get side of things over there because As I mentioned we actually store the suits as as secrets and we aggregate those into some sort of container So the order will contain a reference to a container Which will then contain references to secrets and then you get the secrets and then you just But it's just a series of gets So Just to give you some idea as to some of the state the machine that's going on here You could have a post to orders That ultimately will call issue certificate request on the plug-in At that point it may come back as as pending And so we have a queue in which retry tasks or which tasks are are are stored or queued up So they'll run periodically and you'll get checks to get a check certificate status checking it It'll check it periodically and then once you actually have a certificates or you have an error It'll come out of that Store the certificate and then ultimately later when the client goes to get the order and ultimately goes to get the secret You're gonna get your certificate. So there's a there's a State machine that's in there. That's within Bob it can core that manages this whole operation So just a little bit about dog tags. I'm gonna talk a little bit about the dog tag certificate plug-in in particular Dog tag in case you don't know is the is the upstream version of the red certificate server It's been used in some of the largest deployments In the world millions of keys millions of suits it's been around for 10 12 13 years, I guess it is It does interact with a bunch of HSMs through pkcs 11 It's common criteria certified which if you've been through common criteria certification means you've been through a long and painful process of Certifying that you have all the required or authentication authorization Auditing that kind of thing signed audits so that the audit audit log is tamper proof and so on as well as making sure that Secrets for example that go through are never in the clear even in memory So Nick mentioned the wrapping thing So this in in the case of dog tag you have a transport key Which is a public key which is used to wrap the secret on the client side and therefore It cannot be decrypted until it eventually gets into the HSM Where your dog tag system resides and then it automatically immediately gets re-encrypted and stored So that it's never out in the clear in memory anywhere. It's only in the HSM so There's two components of the dog tag system that that are important for our case here There's the certificate authority which is issues the certificates and the key recovery authority Which is used to be the component that just stored private keys, but we've extended it to extort just about anything You know any kind of secret private keys Symmetric keys and so on And there are many for the dog tag plug-in. There are many different types of certificates that are available The server suit user suit based on what certificate profile you have the profile Within dog tag talk is basically a thing that maps towards a type of certificate So it will specify the types of inputs that you need on the certificate will specify how to create the subject DN Any kinds of extensions that are available in that and that kind of thing and of course It comes automatically with a bunch of different profiles, but you can specify Custom profiles to get whatever you want in your certificate and The dog tag plugins are set up to interact directly from Bob a can to the CA in the KRA With a trusted user so that you automatically can get your certificate approved. So you don't have to wait So just as an example of how this will work You would do a post to Bob a can to the orders interface And the body of that is going to be it's going to be a type of certificates The green parts over there are the parameters that are going to be passed in And I mentioned those in particular profile ID and that suit request and so on those are specific dog tag Parameters are there and the reason that there's specific dog tag parameters It's that in Juneau these parameters are just passed directly to the plug-in and those are passed directly to the CA And so dog tag knows what to do about that And so you have if you happen to know that you have a dog tag CA at the back end you can do everything That you would ordinarily be able to do with dog tag Bob a can essentially proxies it through does the authentication with keystone and then proxies it through for you In Kilo We're going to add an API to allow you to generate any to not even know what CA is behind there So you can get certain simple kinds of certificates and so on by specifying these these the parameters Which will then have to be translated by the plugins to whatever the appropriate plug-in interfaces Okay, and there's a design session that will be coming up later this week on on that specific thing So if you're interested in that, please, please attend and Once you do that you get your order order again contains a container reference at the bottom at the bottom over there get your container and Then you have you can see you have a series of secret references over here get those secrets One of them is going to be your your certificate you get that secret and there it is So Talk briefly about the notification plugins that we're using within Barbican And so the idea that we're taking right now is to have kind of domain specific You know specific to workflows within Barbican an interface that has you know natural methods on it That makes sense for that workflow And then leave to the implementation Exactly how to create tasks and in QM or whatever it needs to do as far as the implementation is concerned So you can see in this example we have a notify certificate is ready So we would use that as far part of our certificate workflow to surface those sort of events And so your choices right now, you know, we're thinking Oslo messaging notifier is used in projects like Nova and so that would be a natural plugin to implement and use We could also, you know, folks can make their own plug-in to adapt to whatever corporate system that they have corporate ticketing or whatnot Customized system law system is logged system logs We might use that for example in Barbican to surface events that associate a knowledge article with with an exception perhaps and And allow admins to have an easier way of maintaining and troubleshooting Barbican and Multiple of these events could be installed at a time So I could say notify certificate event and if there's three plugins three certificate event plugins installed It would fire up all three of those and So let's get into the challenges then for for kilo then Multiple plugins versus one the minute you have multiple plugins installed You need some means for for selecting which one to use and so we've already talked about the supports method as one option for that Migration between back-ends. Let's say you have a bunch of secret stores stored with an HSM And you want to convert over to came up or dog tag Well, what do you do with those old secrets? Do you migrate them in mass? Do you maintain the HS at both both plugins effectively and only for new secrets to use the came up those sort of things? with we need to discuss and I mentioned through my anecdote about the HSM plug-in, you know versioning within a plug-in is something we'll have to definitely contend with and Then as adi mentioned on the certificate plug-ins If you have multiple plugins that are working with multiple CAs you need some way for clients to discover which of those plugins they want to use and And so that's something that we want to discuss as well As well as common parameters across those CAs identifying those and standardizing those if possible and So Tuesday is going to be a big day for for the barbequan project Starting with a a wonderful workshop hour and a half workshop Barbequan securing your secrets if you want to really get your hands ready with the API, please. Please attend that There's also going to be a tech talk given by Joel securing data at rest and Then we have four design sessions Any great Barbo came with other open stack projects as I mentioned if you if you have an integration use case with Barbequan, please please come to this Comment certificate issuance. This is all about CAs and trying to come up with that that search discovery API for example Driver lifetime management that gets into all the verging issues that we were talking about is as well as you know Any other issues related to managing plug-ins and Finally a per user entity level RBAC So trying to find trying to make a more fine-grained access control for our back for Our back in Barbequan. So maybe a per secret our back would be better than just using trust at a project level for example And so we do have an ether pad Please go out there and view you know what feel free to view what we what we've identified as issues for Barbequan so far We're gonna have a table if you have questions, please come on by and finally this these are the the folks that Made things happen today for the presentation Feel free to contact us with any of these mechanisms or talk to us after the after the conference Thank you very much. Appreciate it guys