 So first hello everyone. So welcome to our presentation bringing in compliance for public clouds Presentation could have been named be careful when selecting your cloud partner for compliant environments. I Hope this topic is not surprised for you If you didn't want to hear about security or compliance you're probably in the wrong talk But if you're interested in secrets for your information, there is also another talk At the same time talking about hashCop fault so Here what we hope is that after this presentation You will know how to build your cloud or select your cloud vendor Based on your compliance requirements so let's talk about Compliance and security while just in time Can you go to the next slide? Yeah, sure Before we start you might point you might wonder why are the two of us talking about? About compliance. Well, this is related to the to the company we work for And here comes the first surprise You might have heard about city network before and we recently evolved our brand from city network to clear so clear is a company with open source at heart and We we truly believe that collaboration across organizations and borders leads to great solutions Clera offers amongst others a public cloud a compliant cloud private cloud and managed services Clera engage heavily in open source and we have more than a decade of experience in building and Globally scaling our cloud infrastructure solutions. We're committed to a data sovereign Europe Where a business accelerate and sustainable open source based and regulatory compliant cloud services? What you need to remember of that is that we focus on open source and have a strong focus on security and regulatory compliance. I was saying earlier in this presentation that This presentation will help you figure out how to build your cloud or Select your cloud vendor based on your compliance requirements This presentation comes from the question that we see from our customers asking Can your cloud tick all those security team all my security teams boxes for encryption? while following regulatory compliance and After your presentation, you will be able to answer this question for your case, and I'm insisting Your case as I think it's very important a company is not the other a business is not the other Your compliance doesn't mean compliance for another company in other words as A cloud vendor you can take decision for how you design your service and as a cloud user You can take this decision on which cloud vendor meets your needs So can a cloud take all of the security teams boxes for encryption at rest or in transit while following regulatory compliance Big surprise it depends It depends on the cloud design. It depends on what you need. There is no perfect solution I really want to highlight that there is no perfect solution every design at its trade-offs and Your experts should know That the design matters It's not as simple as I'll provide you an API endpoint. You're gonna you're gonna put your cigarettes there and it's done So you might want also to wonder what basically Compliance and what do we mean under compliance and why everybody today talks about it So as simple example, we are taking General data protection regulations known as GDPR as just simple example. So you might know that All service providers may obey it especially in Europe if they want to store customized data So in case of any data leak or violating GDPR your company might get real huge finds that may take it basically down and It's not only about Europe's results. So CCPA for US or LGPD for Brazil So basically wherever you are in the world you need to care about customers data and If you want to accept payments for example, then you also have PCI security standards which regulate Payment account data security So while with GDPR you Basically don't have any strict requirements of what needs to be said PCI there says brings it and Yeah, you will have minimal requirements of how data should be encrypted what's in first used and so on and On top of that there is also ISO 27,000 certifications We describe security standards and they also require data encryption and rest so if you want to provide in Europe Services for high-legatory businesses. You also likely should be certified with these standards And likely include we have this In other words data encryption is quite basic thing to have for these days for any Service provider if they care about customers and their data But you are missing slide, no, it's okay. Yeah So We need to also Select back ends. We will not Come straightly to the barbicons that we implemented At first we will we were considering using Hashi cope volt because it's quite popular and everybody loves it for basically key storage and Yeah, it looked like a perfect candidate for us to get it at the first place It's API is highly adopted and used In many places and the open stack is not an exception. It also has integration with vault. So It's it sounded like pretty easy Johnny But and back then we were considering barbicons just a plan B case which we can yeah use if it won't work out of his vault and Yeah So, yeah, I'll I realize maybe it's I should I should spend more time on explaining the architecture. So How do you I mentioned how do you deliver a cloud that take all the security teams boxes while following regulatory compliance and I realized we forgot to talk about the secure supply chain right for the delivery and That includes your software that includes the configuration It's it's it's a very broad topic and will not solve this in this session Just to talk about the supply chain alone You would know probably ever talk and so a bill of material All of this requires time and effort. What's important here is that when you have handled These parts of this of the supply chain the software bill of materials Then you can only focus on the software itself and its configuration So you need to take the right design decision and add up to your configuration for it So as you can guess we're using open stack and we're using a deployment system that allows us to easily control the software That we deployed the import. This is important for a secure software deployment to Handle the holder chain what you need to keep in mind is Open stack is very flexible and it can adapt to your needs Because on stack is very mature and very flexible yet surprisingly this flexibility comes at the expense of compliance So let's go through those Yeah, the slides are maybe nothing other. Yeah. Yeah So what do we do in in clearer? What do we wanted when we build our clouds? Yeah, so when we were driving Right in design We said some kind of expectations and some bullet points we want to cross so and first and quite important is tenant isolation And kind of proper one because stored secrets in storage Must be separated per users and in case one customer is compromised. It shouldn't affect any other customers And of course we wanted to provide the API for customers so they can store random data pretty security so and to store data securely we also need to leverage hardware security modules and basically why we organized all that is a block storage encryption and Obviously object storage encryption And on top of that we had kind of requirement for load balancers to terminate TLS as otherwise In order to do basically TLS termination you need to stores SSL's private keys somewhere in a pretty secure place and that is yet another thing that we can now achieve with secrets as a service And you could also mention that We still have some gauge not filled so we can add more expectations And this is images encryption and slow operational costs. Why not, right? and we Finally got a tool for that and this tool is Babicon But our slides are not in order again So why we're talking about castellan because basically all services reach Babicon through castellan castellan is Basically a Python interface that projects like Tinder or Nova or even Octavia can use to get to the back ends So basically, yeah It's like that But eventually as I told volt is pretty much popular. So you can Configure it as a Babicon back end as well So you go through castellan to Babicon and then store secrets basically involved But let's probably compare this mentioned options now and why Some are better some are worse As I said before We were first of all we were considering using just wall back end and you can do simply that through castellan so basically Octavia through castellan just reaches wall back end and each service Use its can use its own key volume key value storage inside vault but there are some pros and cons with that first of all About cons there is no tenant isolation So all secrets are for all users are stored inside key one key value Storage so basically if it's got compromised you got all customers data leaked kind of and on top of that You know to integrate with HSM you need enterprise Version while it also bring multi tenancy involved There is no implementation on castellan site for multi tenancy So you will still have user the single user regardless of vault version So now we going on and we decided that We can out Babicon right because it also can store in vault And on paper it looked pretty nice because we speak it says 11 Crypto driver you can encrypt storages or you can You can use HSM and leverage is HSM for encryption and at the same time on paper You could store secrets in vault and kind of Babicon provides tenant isolation and everything good, but There is huge but that you can't use Vault storage plug-in and the piki says 11 encryption So you still don't have a tenant isolation and now you have two services that you need to maintain and you still kind of need enterprise for HSM and Yeah, you just increasing your operating cost and complexity and Basically known of these two tools provide what you need and on top of that Vault storage plug-in was broken Until Xena release and yeah now it's fixed, but yeah still it's not Best solution and what we kind of needed so at the end we kind of dropped vault and as a DA because it's with it. It's basically no tenant isolation and Probably I should explain how since work with Babicon because it's Kind of interesting and a bit complex So in HSM, we store only two things it master encryption key and hash-based notification code HMAC So HMAC is used to ensure that data is encrypted and it's correct at the aesthetic and the master encryption key used to encrypt project keys so for each project a Unique project key is generated When the user first time creates a secret and basically this project key is encrypted with master key and Then when you store a regular secret it's got also encrypted it got encrypted with project key so basically In other words if you leaked a secret from database to decrypt it you need project key and to decrypt project key you need master key and Which is stored in HSM. So basically when you ask for any secret you go through HSM and there is also HMAC involved to Verify that hash is valid and it wasn't substituted on its way And concepts that are quite fair because HSM is basically Hardware modules produced by a certain party company. So drivers are appropriated Proprietary Which is yeah both believe in and It might be tricky to set up H8 for HSM devices, but let's not Yeah, go deep dive into hardware now Let's limit It's what we already have And we basically spent quite a lot of time understanding how Piki says 11 Crypto plug-in works with a storage plug-in We push some documentation changes. So now it's I believe can be more clear if you read through it. It's In better shape Yes, and now that you know more about the architecture How do you secure it securely deploy this for those interesting into building the cloud yourself in a compliant way? Well deployment was easy Anyone can deploy a cloud like we did at clear here is the recipe As I said, we're using a deployment system and this one for cases open stack Ansible and Well, the first step is to have the host In your inventory You define this little blob of YAML The to defines the valuable that applies to your inventory You run these three playbooks to because we were running with System containers the Lexi containers that you can see we added to them to the load balancer with h-approxie and Then we run Barbican and we deploy Barbican that is secure So if I recap so far, we have an architecture for cloud that architecture seems secure can take the securities team boxes But as I told you before opens stack is full of surprises Yes, so one of the surprises for when we try to include object storage server site, of course because we're not talking about client site. It's problem of clients kind of so According to a three specification, there are several ways to get server-side encryption First option is secc Basically, it's customer creates and stores secret wherever it won't and we have an API now for that Where can he can do that securely? But it's not actually Handy because you need to provide a secret with you with each API request and Yeah, then you need to somehow store secret and on top of that notice three tools Have this part working it's either it can be either absent or broken or implemented super recently As an eyesight though that you don't need much a configuration on storage site you just need to ensure that Connection is encrypted with SSL all the way from API to Backends, but other than that you don't need more But another option is secc CMS So basically you're I mean, I forgot to mention that we are using SAF and rather gateway So with SEC CMS rather gateway can be integrated with Barbican Which is my side, but There are some issues with implementation of that because so in order to integrate with Barbican You so basically when you when you create secret So basically user still needs to create secret manually and after that share It with ACL rules with Rados gateway admin user So basically we are in situation when one user in Keystone can read all secrets and Basically decrypt all objects in the object storage, which is not acceptable for us another issue is that When you upload in a pretty I mean big file you leverage a multi-part upload So each object is split by chunks and with that for example, you have two gigabytes file and It's split in like eight megabyte chunk So you have like 256 around parts and the problem with implementation that Rados gateway tries to Encrypt or decrypt each chunk independently. So basically you can repeat this process 256 times for single file upload So it means that you get that amount of requests to Keystone to Barbican to Rados to to Keystone to Barbican and to basically to HSM and HSM's are usually rate limiting say they are not designed to So huge load So basically when you are going at some scale of file uploads, it's not I mean you are just starting to endorse in yourself kind of and We also should mention about Octavia And how it handles SSL certificates that are stored in Barbican Basically club flow is quite common Certificates are stored as regular secrets in Barbican They are owned by a user that creates them It's nothing pretty specific So when your application asks to create a load balancer that will terminate TLS Octavia will reach Barbican should reach Barbican with user privileges But for better auditing purposes, it's not using original tokens and provided in request it creates another token From already existing one then Keystone Generates it returns to Octavia and with that new token Barbican is asked But why we are kind of talking about like application credentials because this flow is broken and is broken quite early so basically Keystone Rejects to create new token if original one was created from application credentials Its issue hasn't been solved as of today There are like some workarounds in code that can help but basically if you want your application to Interact in this way you should just use password authentication because it smokes quite nicely so So if you want to help us fixing that bug that would be great Yeah, and so operations, I'll just make it a one-minute thing seems like by now We have a design and an implementation. Does that mean that we can launch the product and production? Well Operations not that simple Pouring up and pouring on and migrating a VM now you need on-demand sharing of the secrets via ACL For to do your operations planning to reboot your hyper visors ask your users to shelve or unshelved the VM or share the share the share the access to the secrets What about your hypervisor that fails? No surprise You need to know that you need to have access to the secret again to have to be able to evacuate the VM So if you have smooth operations and live migrations, it's probably means that a secret is shared somewhere So as you might guess We're still missing some things implemented from the design we draw first is the image encryption Image verification. I'll I mean I'm realizing that we were short on that we were short on time so I'll skip that for now and The FIPS mode and the simple operations Sadly operations are not simple when you're implementing Barbican this way So I hope that we didn't scare you too much The cloud is no different than other software You need to take design decisions and those have trade-offs No design is perfect So when you are a cloud vendor you need to be aware of what your users want and Compare that with your security requirements Sometimes they are not aligned and this is the start of a wonderful journey for which you will explain to your users What they risk if you get access to their secrets basically and this is what generally Vendors do for convenience. Basically they grant themselves access to secrets And if you're a cloud user you need to be aware of what your cloud sells you Because their operations might have access to your secrets So should we then consider those as secrets? Some vendors don't hesitate to make those trade-off for operational ease and I completely understand them, right? It's just that I clear I would have we have taken a decision and we don't do this If you have any questions I'll be just outside. Yeah, as we're short on time Should you go outside