As an artist, I'm interested in how we relate to public space. In Australia, I found how the song lines help the aboriginals to describe their landscape, their nature, which for them is public space in music. I then started to make music from buildings, inviting skateboarders or a dancer to translate their architectures according to their own local culture into music. From their thumbs and their slides, I create music to which they can perform in a second act. This Korean dancer takes on the role of a shaman working on the theme of the trauma of the bloody student riots that took place on May 8th, 1980 in Gwangju, South Korea. Now this space in its entirety becomes an instrument that the audience can play whilst plucking the 250 strings that are connected to contact microphones that trigger echoes and delays in a computer. Or cellists can play them, or dancers can dance this space. And finally this music, these song lines are cut into vinyl that are given away to DJs for free, which can use them as samples to create new music, and therefore distribute and share these spaces that we can finally take home in the shape of a song. Thank you very much.


YouTube, what's up, man? WAH! WAH! WAH! And we're back with some scary TikToks. It's been a while. It's been a long time, bro. It's been like two months almost. Oh, something like that. But we're finally back. Maybe I missed it. I'm pretty sure Mike missed it. Everybody's missed it, man. So, uh... My mom too, she told me. His mom even missed it herself. All right, so you guys ready? We're ready. And let's begin. Ready. Let's start off with lights are off. You're not here. The lights are off, bro. I like some perverse house or something, bro. We got cameras everywhere. Bro, I got the same floor in my house, bro. Oh, my God. I'm not a pervert.  Look at all those cameras, bro. It's like a... Is this like a Black Mirror episode or something? It was like the apartments that you get on the app and you go over there to stay. It's like a hotel. Airbnb. Airbnb.  There's a dark side of Airbnb's.  Stop clowning around, bro. Hey, he had nice teeth, though. Is this how much of the scene is there? Is this Huggie Wuggie? There's a copy of Playtime. I don't know why it's that late with me. Is that a Furby? It looks like a Furby. Yeah, that is a Furby. What the heck? All right. All right. It's going to be the next turn of 2010. No. Double comic seven, eight, and all. I think it's called train. Brother has to be New York, bro. New York. Manson from the regular show. Who is this? Kirby in the back rooms? Yeah. I forgot the name of that one. Oh, so I love him. Oh, that's not good. He's going to turn evil. Oh, he died. Oh, it's a new Sonic movie, huh? I guess so. Oh, Robotnik. Oh, that's a cool Robotnik outfit. What are you doing to Tails? Tails. I hardly know her. What? Sonic, help me. Miles. Oh, it was Super Saiyan. You are like my balls. He turned him to an egg. Knuckles? What's this? Oh, he's the ultimate lucky artist, dude. I found him.  And you like to know. Wait, why is Patrick Lyric's not Bob? No reason. Except you gave it largely. He said he gave him the ugly. Oh, Adventure Time. I still love this cartoon, man. Cool.  What's happening here? Wait, what did you do these? Rigby? Oh, we were playing. Oh, is that a Spanish? That pops, yeah. Don't you want to play? Oh, that's the one you were talking about, huh? Bro, what the heck is this? What kind of cartoons are you downloading, bro? Bro, I downloaded this from the dark web. What do you have in your hands, Benzorn? What do you have in your hands, Benzorn? Oh, bro, what did you do? What did you do? I think he framed them, bro. Oh, that looks dark right there. I don't know what happened, but I'm scared. Oh, his face. Basically, Brandon is what you got. Oh, this supposed to be like a super creepy video, bro. It's cursed. It's like an act of body. Yeah. Bro, it's like Rodney. Bro, she's dead, bro. I gave her seven, but after that, she's like a zero. She actually went after me. Nah, I think I remember why we started watching these. Who's this? Basically, Brandon again. So what's his eyes, bro? A baby? Yeah, it's a baby. He's just born. Oh, look, then they grew up to being those ugly freaks in the back. Yeah. Oh, he's so happy and cute. He has like a deeper meaning, bro. Bro, I know what this means. He teeth on home. He's gonna pick his nose. Oh, it's part two. I guess so. Is the kid playing music? What the heck? Dude, once you turn 50, this is what life is like. That's me right now, bro. How disturbing. You see, it's...  You're born into life, you're happy.  He got rhythm, though. He does, too.   Stinks. That was so weird. I know, dude. He's such a long video, too. When does it end? Thank you. Thank God. I thought I was gonna keep going out forever. Don't get on here rapping. Do not get on here rapping. Who pierced his bubblegum? Don't get on here rapping. I'm stacking, making it happen. Hold on. Let me keep going. Look. Stacking and flipping and getting it. Hey, Jake got the bar. Great fit. Yeah, it's fit. Dude, they got 100,000 people watching, bro. And I'm rapping here. Head shake like a deer. Kill him. That was so weird. You love God. Speed. A little free action. And then... Oh, wow. That was it. I found the shortest one ever. You love God. Part two. Oh, part three? Probably not. Where is that in canton? Yeah, yeah, yeah.  Problem solved. Wow. Just that easy. You could have done that the whole time. What is this? Is that Kirby? It's so random. Mario T 209 films. Knuckles, come on, bro. It's so heavy to be up there in real big hands. How many people are in the scene? I have no idea. Oh, what? It's funny because it's both of them. Chris Tucker, they're both actors. Yeah. That's pretty genius. I'm going to. That was pretty genius, man. We made a better Sonic the hedgehog trailer. Two years ago. It's part three. Somebody murdered Tails. Not Tails. I'm finally going to get my revenge. This must be ugly Sonic. I think I got the wrong address.   Wow. We reached the end, thankfully, safely. Kind of. Kind of. I was kind of dying at that weird video with the old little freaky guy. Whatever that was, dude, it weirded the heck out of me. All right, you guys, well, anything you want to say, Mike? Make sure you guys go and subscribe, comment, and hit the notification bell, too. That's the big one because you took the hate on us. We onto YouTube and you onto us. It's like we're at war right now. It's a little sudden war. All right, you guys, thank you guys for watching. Thank you all for the base support. I was truly appreciated and we will see you guys in the next one.


From the CUBE Studios in Palo Alto in Boston, connecting with thought leaders all around the world, this is a CUBE Conversation. Hello, and welcome to today's session of the 2021 AWS Global Public Sector Partner Awards. I'm your host, Natalie Erlich. Today we'll discuss the award for the most customer-obsessed mission-based win for state and local government. I'm pleased to introduce our guests for today's session, Todd Carey, Global Head AWS Business Group, Cognizant, and David Sullivan, Chief Executive Officer of Elizabeth River Crossings. Thank you gentlemen for joining the program. Thanks, Natalie. Thanks. Perfect. Well, Todd, I'd love to start with you. How are companies thinking about Cloud today in their businesses? Well, there's some really exciting developments, but at the heart of it, Cloud is changing the way companies interact with their customers, their suppliers, and the way they think about business. And at Cognizant, it is really a customer-first, customer-centric approach. And then we work our way back to a solution. But most of the time, Cloud decisions are not really made from a cost optimization or cost takeout point of view. They're made from a customer experience or a business driver point of view. And how do we make businesses better, more scalable, more agile, more flexible? And we've really built some really great solutions that are industry-specific. And we've loved working with ERC in this capacity. How about you? I'd love to get your insight as well, David. What do you see as the main challenges and also how next-gen technologies like 5G can help alleviate in those issues? Yes, Natalie. First, like Todd said, the customer has an expectation. And that expectation is raised every day by what they experience in every other channel they work in and shop in and whatever they're doing. So expectations are always increasing from the customer side. Responsiveness, personalization, they want to see all of that in everything they do, including paying their toll bill. And so I think as technology has changed, tolling has kind of come from technology that is really 20, 30 years old or older to more of a modern influence. And today we use RFID tags that are embedded in things like EasyPass. But in the future, it'll be your mobile device or your automobile itself that triggers a toll transaction and helps us process it and make it in a way that is fast, convenient, and most importantly, accurate. Yeah, well, saying with you, David, I'd love to hear how working with AWS helped modernize your systems. And as well as if you could give us some insight on your tracking systems. Yes, so with AWS, we have been working with Cognizant. Cognizant is our tolling subcontractor. So they're responsible for providing our tolling system.  We had two data centers, both of them located pretty close together, a primary and a redundant data center and both of them very close to flood prone areas. And in our location in the Southeast corner of Virginia, we're very vulnerable to tropical storms and tidal flooding. So part of our concern was, we're exposed. All our infrastructure, all our tolling infrastructure is exposed. So as we began to pursue a cloud strategy, the first idea was just to lift everything out of our environment and move it to AWS. And Cognizant pulled that off in about three months, which is really pretty incredible. And we never missed a beat. You know, we did it over a three-day holiday weekend, but from a business transaction standpoint, it all flowed. Once in the cloud, we began to rethink now that we're out of these legacy hardware environments, how do we get out of the legacy application environment and embrace what the cloud enables and working closely with Cognizant who had a great vision for how this could be achieved, we were able to systematically move through and migrate to a cloud-first, cloud-oriented system. And it's given us lower cost, increased availability. And most importantly, for our customer service agents that deal with customers or customers that deal with the web, it's given them a better experience. Shorter call times, better information and frankly, better customer satisfaction. Terrific. Well, thank you for that. Todd, let's shift to you. What do you see as the next phase of this digital transformation process? Well, as David hit on, I think it's an important theme of cloud-first. I mean, most companies and our clients start with that cloud-first, cloud-native mentality, but for Cognizant, our cloud approach is really customer-first and being able to start with the client in mind and then work our way back into a technology stack or into a scalable solution. But specifically for the toll industry, there's a lot of things that are needed around revenue predictability and looking at potential leakages. But as we hit on already, making sure that we're really delivering a great customer experience. And so with our solution, as we expect our tolling solution to really grow, we're keeping it cloud-native, we're keeping it modular in nature and integration ready. So if, for example, our toll customers can use their own roadside solutions or handpick some of the small back-office modules that they want to use, it's always going to be purpose-built and aligned to our customer. And we see nothing but growth in this segment. It's very exciting. Yeah, terrific. Well, David, now that you've actually implemented this, what do you see as the next phase? What is your vision for the future for your business in 2021? Well, I think for us moving forward, we've been in this, as Todd said, kind of a modular approach, which is great because you can make the changes and really manage your risk while you're making them. So you're moving small things, whereas traditionally, new systems meant massive investments, long-time implementation times, and all-end cutovers, all of which are packed with risk. So we want to reduce our risk and the solution that we have being cloud-native allows us to really incrementally and quickly just continually to improve the system. So on our forecast, we would like to have a better insight into our customers and support a direct app, an ERC app that would allow our customers to interact with us and give us a better view of the customer and a better experience for the customer overall. But our goal is to build that total transaction accurately, fairly, and then if the customer has an issue to be able to treat them in a way that they feel respected and valued as a customer, because we do look at it that way. Yeah, terrific. Obviously, engagement is such an important issue in this area. Now, I'd like to shift gears and hear a little bit more about, what are some of the other applications that Cognizant could provide beyond tolling? And let's shift this to Todd. Well, David, you know, a little bit. There's a lot of, when we start to focus on the customer, there's a lot of opportunity there on the front side. So, mobile apps, websites, synchronization of data, but then also the way that we support that customer interacting with that data, things like IVR or automating call centers, being able to support that customer through the entire chain of custody. There's some new and exciting applications now that would come out, and David touched on a little bit too, in terms of vehicles. So, the vehicles to everything type motion, that's an exciting development in this segment as well. To be able to continually integrate everything that's in the customer ecosystem. So, whether that's the need to pay a bill, or be able to drive a car through a gate and be able to simply not touch anything, but be able to have that payment processed all the way through, and then have clear visibility into usage and insights, and then also be able to turn all that data over to a company like ERC to make good decisions based on what they see in terms of buying patterns, consumption, et cetera. There's a lot of expansion going on in this, and the greatest part about this is it's built on the AWS platform. So, when we architect something in a cloud native way, we can rapidly expand it, and we can really streamline the investment required to jumpstart any kind of innovation. And best of all, our customers in keeping with the AWS model, really only pay for the actual traffic that they use, so we can keep those long-term costs down. Yeah, well, excellent point. Thank you both gentlemen for joining our program. Really loved having you, and that was Todd Carey and David Sullivan, excuse me, and I'm your host, Natalie Orlick. Thank you for watching.


So, next talk is from Milan Broz. Milan is a software engineer at Red Hat and he's also a PhD candidate at the local university here at Pro. He's going to talk us about the story and the encryption and the question of data integrity. Thank you. I hope you hear me. Thank you for coming. Afternoon is quite late, but I will today talk about something that maybe follows the talk from last year about Clux 2. I'm now going to talk about storage data integrity detection, maybe correction in full disk encryption. So, thank you for your introduction. I will just add that this work is partially part of my academic work and part of the software engineering. I'm trying to do something useful. We will see if it really works. So, let's start. What I would like to talk here can be split into two parts. First part is a little bit description of some terminology and maybe description of what is the checksum and what is the authentication pack just to understand what is authenticated encryption because we will play with the data. And the second part is real demonstration what we actually developed and what hopefully will be some day in distribution. Maybe, maybe not. I will mention the problems. So, let's start with that. First, why we should care about data integrity at all. The major problem here is data corruption. Data corruption is something, some change in data. I'm talking about the storage devices, so data at rest devices. Data corruption is something that basically changes the data without intention and the most importantly without detection. So, it lives somewhere and sometimes later it will come and do some damage. What is important? I need to split this into two separate areas. The problem is the same but the solution is different. First is silent data corruption. Usually, if you talk to storage people and there is a lot of such people there, you are talking about silent data corruption. So, something what happens if bit flips in memory happens and it's stored to this. Something if you have flaky cables, data misalignment but something that is random. It's not intentional change. So, if we can detect it or we can fix it, okay, that's correct. The second part usually is not so focused by storage people is some not authorized change of data. It's intentional change of data by usually some attacker trying to play with storage device and later it can do some damage. The solution for two problems are different. We will focus on the second one because I am trying to combine integrity checking with full disk encryption but this split is quite important to understand why some subsystems cannot provide real integrity prevention or integrity protection. So, what is data integrity? As I already said, it's the way how to provide data consistency and it should at least detect that something is wrong during the whole life cycle. Because we are talking about the data at rest, so not in password but in normal speak about the disk or SSDs. It can be even years. It can be a very long period, so you need to store some checksums or something like that. So, the solution for the first problem, random data corruption or silent data corruption is basically just a simple checksum. You probably met it in several programs, several tools. For not authorized change, you need something more. You need a little bit of cryptography there. And then we usually talk about message authentication codes or if I will be talking about authenticative encryption usually about the authentication tech. It is almost the same but it is something that can be calculated only by authorized person. I will talk about it later. So, if we are talking about encryption, we usually want authenticated encryption. I will show why looks in that current version cannot provide any authenticated encryption because we don't have space to store that. So, integrity protection. As I said, you need some additional space. You have the data. You will encrypt that, decrypt that. But if you have link present encryption, you don't have any additional space there. Imagine for example some network protocol. There is no problem with that. You just can encrypt the data and add some additional data. This also packets slightly increase in size, but it's okay. In disk, it's not so easy because the sector is fixed. We need some additional data. Additional data can be used for. Simple checksum, authentication tech, but also it can be used to store some additional data like forward error correction. So, we can detect the corruption and we can basically repair it if it's possible. For the error correction usually there are some algorithms like read salamone codes, something working with Heming codes. But I don't want to explain it more here. Just the problem is the same. You need more additional data for the redundancy. And we can somehow combine it with encryption as well. But that's something I mentioned like a possible extension. I will shortly mention it in the example for DM Verity, what you have probably on your Android devices. So, that's the beginning. And question usually people ask there why I should care about it here because it's already in hardware. Well, maybe it is, maybe it isn't. If you buy some very big proprietary solution, you will probably have something that tells about that integrity there. Some SSDs probably calculate something inside the drive, but you cannot prove that. But there are definitely disk that just don't do any error checking at all if it's retinal data. It's okay. But definitely you cannot prevent that not authorized use of the device. If someone will just temporary the device, you have no way out to detect that. So that's the reason why I would like to look. And just one mention more. It was question if we can implement everything, if we can prevent so-called reply attacks. Reply attacks is something you take the snapshot of the device, order snapshot, and you will place it back. So we will basically revert the, either the whole disk or part of that. If I am talking about just common of the shell of disk, so just normal disk, we cannot solve this situation because for prevention of reply attacks, you always need some external trusted store to store something more. Counter, last date of modification, something like that. So this combination with, for example, a trusted platform module, maybe it can be done. But if I have just only disk that provides me sector space or something like that, nobody will stop me, take the snapshots and return it back. So that's one of the problem I cannot easily solve here. Otherwise, we will see how it works. So I already mentioned there are some algorithms for checks, so you probably know secret currency codes. I just want to mention here, never use that for any cryptography. The problem is that you can very easily find another message or another data that will have the same checksum. There are a lot of examples in cryptography where someone tried to use that and it failed later. One of that example is one of the old through-crypt system and they used CRC32 for initialization vector generator and the problem was exactly that they used something used, should be used just for random data detection, not for intentional data, intentional data corruption. So that's enough. If you are a trust model, just detect the random changes, okay, that's fine. If you need something more, you need to use cryptographic hash. I mentioned here because you can calculate even for the random data corruption, you can calculate checksum using cryptographic hash. Still, attacker can recalculate that, but now you have at least the guarantee that attacker will not find another file with the same checksum. You can later sign off these checksums and you will have something, for example, what is used for ISO images signing or something like that. But this is just if you need checksums. So that's for non-authenticated integrity protection. What I need is authenticated integrity protection. What it means? It means that the checksum, and I intentionally will not use checksum again in this context, it should be authentication tag. You need some key or something that allows you to calculate or verify the checksum. So you can use hash, but you need to use something key. So usually there is HMAC algorithm hash message authentication code. You can, in combination with encryption, you can use authenticated encryption, and usually there is specific modes designed that it does both encryption and integrity protection. So calculate authentication tag, for example, as GCM. I don't like the GCM mode here, but it's implemented everywhere. So I am using it for testing. But what I would like to know, there is ongoing crypto competition named Cesar that is trying to find better algorithms for authenticated encryption. And we will probably in future use something better. But for now, I am trying to use what's its kernel. We will see that the whole solution is basically algorithm agnostic. So what's possible we can use? We are not bound to any explicit algorithm. Another abbreviation I would like to mention here is authenticated encryption with additional data. It's basically the same. Just you are authenticating something more, just only data. It's metadata usually. It can be probably, it can, there are usually public. Imagine some date of creation or in our case sector number. It's something public. But I would like to add it to authentication. So if I'm reading the sector from the wrong place, authentication should fail. So that's the additional data. So you will usually see somewhere A, E, A, D. That's authenticated encryption with additional data. That was the beginning, just interaction of the basic terms. I don't have much time to go into details about the existing solution, but just a few of them from the open source world. I am not talking about proprietary drivers, but from the open source, there is on the block level, there is very interesting DM verity. DM verity does just the integrity protection. It doesn't encrypt the data. And you are probably using it if you have Android phone or Chromebook, because it is the device map or target that provides integrity checking, cryptographical integrity checking for the block device. Basically for the system partition. The problem here is that it works not directly by checking the sectors, but you have hashes of the sectors. In the tree structure, in cryptography, it's called mercury. And the root hash is stored in firmware and side bind firmware key. So we should want to upgrade the whole partition unit, that key, just basically flash the whole device and recalculate what's in firmware. It perfectly works for system partition on Android, but if you have some data that needs to be written there, it's read-only partition. So it's a nice idea. It requires a little bit additional storage space, but it's unusable for read-write partition. For file systems, but there is doing some checksums. It doesn't do authenticated encryption. ZFS uses GSM in some mode, but with ZFS, it's problematic. It's out of the tree. And the only file system I know about that is trying to implement real authenticated encryption is currently B-Cache FS. It's file system based on the B-Cache in kernel, but it's developed outside of the tree. But it really uses the authenticated encryption based on Cha-Cha 20 and Polis 1308 Authenticator, but it's fixed there. If you are interested, just Google it. You will find some discussion about that. I am not talking here about integrity on application level, because the data integrity, for example, in database world means something slightly different. In relation to database, it would be probably meaning consistency of the references and so on. That's not what we are talking here. We are talking about storage. So the second part, I will talk about something that we already implemented. First introduction, then I will show the demo. So we have full disk encryption. We have looks. Basically, it's generic for disk encryption. And the problem there, if we want to provide integrity, is that it's so-called length-presentary encryption. The same size of the input, imagine the sector size, is on the input. So plain text is the same size as the ciphertext. If you want to add integrity, you need to add something to that. I basically cannot just create bigger sector on the device. So that's the problem. I usually, in literature, it's said without extending sector of some data. It's not solvable. So the full disk encryption provides confidentiality only. Confidentiality means that user can access the data only if it's authorized. So it can provide a key. Nobody can decrypt the data if you don't have key. But it absolutely cannot provide integrity. The only way how to detect integrity in current full disk encryption, and this applies for all operating systems like big locker for windows or service encryption if you can modify the sector directly there. Only way you can detect some violation there is that the decryption can produce garbage. Someone is tampering with the ciphertext after decryption you have garbage. How do you know it's garbage? Sometimes you can detect it. It's so-called pullman authentication. I think I mentioned in BitLocker definition by Niels Ferguson. I would say it's no authentication at all. It's just something you can in some context use. So there is no integrity protection. That's Many people just confuse that really if you try to modify something on Look's device, it will quietly decrypt that wrong ciphertext there, result will be garbage, but nobody will detect it until something bad happens on the application layer. If application will have integrity checking, okay, that's fine, but how many applications do that? So, okay, one side step I need to mention is change propagation or error propagation inside for this encryption. If you change one bit on disk, on memory and then save to disk, if you don't have encryption, only this bit changes, so you have some small corruption, but nothing else happens. But if this happened in encrypted disk and you flip one bit in sector, the damage will be at least cipher block size, so 16 bytes usually. In some, it depends on encryption mode, it can be amplified up to the sector size, so one bit can change the full sector is completely garbage. So that's error amplification inside full disk encryption, and that's why if something bad happens on encrypted disk, you are usually detecting it much more earlier than on other disk because the focus of that destruction is much, much bigger. It's the feature, it's not bug, it's intentional design, because if you are looking from the other side, if you change one bit in encrypting data, you would like to split it to whole sector, so attacker cannot detect where the change was. So it's feature, but unfortunately it has that bad problem if you are dealing with data corruption. Okay, that was, that was a slight sidestep, I know this looks. What I am doing here, what I am trying to present. First there was just pure academic idea during some PhD discussions at the faculty. Why we can try to run out the decadent encryption in disk encryption context. Nobody probably expected that I will try to do something more useful with that, so unfortunately I am engineer, I have to do something that is working, not just for some paper. So we implemented the way with MiClash, I hope sitting somewhere here, we implement it so it's usable, if it's usable in reality it depends on testing, but I will show you booting machine with the full disk encryption with authenticated, so it works, it's implemented, but it's the first stage here. So what we did, we split the problem to separate parts. First is non-cryptographic part, we need somehow provided additional space to the sector. This encryption runs with sectors, so we need additional space. So we invented or write new DM integrity module. I will explain how it works later on some high level point of view, but basically DM integrity provides only that additional space, nothing more. Then I added authenticated encryption to DM crypt, so we can now either encrypt in like preserving mode or with authenticated encryption and it needs some more logic there. I will talk about it later, but the whole talk can be about the problems, how to use correctly known or initialization vector, because it's not so easy to do that. So that's the architecture, a little bit more on DM integrity. It's new separate device mapper, by the way all patches I will show are on the kernel or Git tree in my tree in branch, the same for cribset up, it's in development branch. It's not yet in mainline kernel, but everything is public on the website. So DM integrity works that way, that it basically inspires by thrice from SCSI world, SCSI invented something like that 10 years maybe even more ago, providing separate data integrity field. So this can store up to 8 bytes and you will receive the data plus 8 bytes. It's not enough for our use, but the logic is inside kernel already. Kernel can provide kernel EO operation on bio structure can provide data plus the integrity metadata and we are just using that logic. So we are not requiring any changes in kernel, we are just emulating this way. So DM integrity basically emulates the disk with additional metadata and provides the info up to the next layer. It used by using interactive metadata sector, you will see that and what we need, we need to provide atomic updates of data and metadata. So that's what DM integrity does. What I like to mention, it works, it can work in two modes. First is, as I described, I will be showing it provides metadata for someone else, for DM crypt, but it can work also in standalone mode, it can calculate the checksum itself. We don't have yet user space for that, but it can be useful for other ways. I'm just mentioning I will not use the standalone mode here. So how it looks like, I said there are some interleaving sectors. So on the disk you have just normal sector, then you have the metadata sector where all the metadata starts and this repeats. The structure is here this way because it can allow us to resize the device in some steps but the device can be still resized. I put here a table from some paper where I calculated how many space it will take from your block device. Similarly if we are using Shah tool, we need 32 bytes, so for 512 bytes sector it's around 6% of the data needed for checksums. For 4 kilo sector it's quite better, but that's just for information, you will see the real numbers. The second part, DM crypt extension, as I said, it adds a possibility to add authenticated encryption. We are using interface to kernel cryptography API, so we can use whatever provides cryptography API there. As said here, it can provide combined modes and so on. I will better show it live, so that's just slides. Slightly more about cryptography, I will not go into detail, just I want to show that it's not so simple. So instead of encrypting data as previously, so you take data, you encrypt it and store on the disk. I create something like sector request and that sector request contains, these are the additional meta data, so sector in little end end encoding, so we are cross-platform initialization vector. So we will like to fail early on authentication if there is corruption not in the data but in the nonce or initialization vector and the output is encrypted sector and the authentication tag. Decryption is just reversed, you take the data authentication tag and authenticate additional data and it will either put the data or it will fail with authentication failed. The rest is the cryptography problems there. Just to mention, you can forget that, but that's what it's about. Then authenticating encryption some modes are very problematic if you use nonce, nonce is a number, use only one, so you never must use the nonce if you are encrypting the same data. You can do it easily in network communication, but if you are writing to the same sector area, you need to generate something more. So part of that problem we implemented random initialization vector, we can store it in the additional data, but there are more problems with that, but also it helps in other context. I mentioned here probably I will write something more about that, but it's probably not good idea to mention it in detail here. Just the real problem, the security of the whole solution is in that initialization vector here. Okay. So let's do something more interesting demo. I hope it will work. So I have two demonstrations here. First is I will boot just plain installation Fedora. It's not completely recent. I think I prepared it one month ago. But what I did, I took it just to switch the look, standard looks installation to the authenticated one and just replaced kernel with the patches and the Cripset up with the patches. So everything else is standard Fedora. I will just show you that it works and it's usable. A second one, we will play this command line. Just I will show you how to create that. I hope it's quite simple in the Cripset up context. So I will switch here, sorry for using VM there, but it's how I have to configure it for now. So here you can see just normal Fedora installation. I just switched some older kernel with the patches. So it's a basic Fedora just with added VM integrity and with patched VM Cript. So I will try to boot that. There should be some standard looks question and it should boot to some environments. So I need to remember password. And by the way, I'm using for I think six year old laptop with virtual machine. So even if I am running encryption, it takes some time. But you can see here that the speed is at least usable here. And if you don't believe me, I will just show you, okay, let's switch it to the full screen. Is it blocked? Okay, so standard block. So this should be standard block stack in device stack in Fedora. Just you can see that there is one device more here. That's the VM integrity device. And otherwise it's exactly the same like in Fedora. LVM overlux. I need to be a super user to show more. So we will, we can show device mapper table. It's quite unreadable, but if you can find the first lines are LVM, then there is Cript target is Vibe key. And you can see it's using SGCM with random initialization vector. So every right to the device will regenerate that initialization vector and store the metadata. And with new parameter here, integrity, 28 means we are using 28 bytes per sector, additional 28 bytes. Why 28 here? Because GCMOs are using 12 initialization vector, not 16, 16, but 12. And 16 bytes is reserved for the persistent nonce or initialization vector. So 12 plus 16 should be 28. And the second device is that new integrated target. So you can see integrity here, 28, that's the same number. J, it means that we have active journal. So we are providing that atomicity. And basically that's all. I can try to show you how looks device. I hope it was SDA2. So looks version 2. So that's maybe answer for what happened, but if it looks to I talk last year, we are still working on that, but I'm focusing on some other features. So I am still using that. And this is real usage of the encryption implemented there. What I would like to show here is the segment is encrypted as GCM random, integrity IID. So that's how it works. Just small note for the key slot where you have the real key. You cannot use authenticated encryption because the key for authentication is stored there. So it's using normal encryption, but later it's authenticated by key digest. So basically it's already there. So that's just short demo of booting the machine. Maybe I will, I can do something more intelligent, like open library office and open these slides. So you can see that there is no so big delay. The system is usable. I don't want to present the real performance checks because there are some problems on SSD still, but on the rotational drive we are quite good in performance and I think it's usable. Okay. So I will shut down this machine. I will show you. Ignore that. I will switch, I will switch to second demo. I have running some small development system. Actually it's my, it's my small Gen2 system where I am testing that Gen2 because it can be really small and I can avoid all system DMS with automatic activation and so on. So this system is quite recent. If you can, it should have some recent patched kernel and I will show you how to, how I created that encrypted system. So I have patched kernel, I have patched clip setup, rest is the same. So let's format some single, I will show you how the device text looks here. So I have several, several disk. I will use, for example, SDB for the looks to device. So just normal format, but we need to use looks to here and that's just normal format as if you want to format looks device, but now I want to use integrity. So this is new switch and for now we will use HMAC SHA2 to see something different and I will switch it to batch mode and to some, some quicker mode, just not waste time here with iterations in key slot. So enter some passphrase. Now it's doing benchmark for key slot, the standard looks tough and it should, it should be done. So let's try what's there. So I have looks to and we have the standard encryption more because I didn't specify another one. So let's use the default for full list, encryption XTS, but now we have HMAC as integrity. So I will activate it and show you what it's, what it's, it is already doing. So again, and let's name the device test and you can see that I have this DM integrity DM looks. So if I have, if I check the table, we have the integrity stuff, as I explained, we have DM crypt with IS XTS plane and there is the HMAC. In reality, Crypto API constructs the constructs these two together and creates authenticated mode like something like this. So we have authenticated encryption with the authenticator HMAC SHA2 with XTS mode. So internally it's using Crypto API interface. What happened here? I activated new device, but that new device, nobody formatted it, nobody calculates that integrity integrity checksums or integrity authentication tech. So every read on the device should fail because the, it authentication tech doesn't, doesn't match. And exactly that happened. There is a log from that, a log from that kernel. You can see that if you activate new device, Udev will scan it if there is some signature. Because the device is integrity checking and integrity wasn't there, nobody write it there. So integrity must fail. We can see that block ID just failed. I can repeat that very easily. It's turning block ID on that top level device. And it will, I guess that block ID apparently stops after the first error. So it doesn't continue with scanning. But that's the problem, new problem if you add in integrity checking inside block layer. So what I have to do, I should rewrite the whole device just to recalculate the integrity checksum. I should integrate it in a Cripset app, but for now I have some external tools. For now it's on my GitHub. Basically it's just DD, it's duplicate, running some more intelligently. So we will run format and the top level device. All this should be integrated. So for now it's very hacking the tools, but later all this should be in a Cripset app. So I will format it, and if I, for example, some file system, I can do block ID again. I see signature, I can see there is no more any integrity problems. So I think I have some test script that will inject data corruption just to test it works. If we can see what it does, basically it takes only some random data from the DeFiurandom and rewrite some random sectors inside the low level device to prevent reading the data from PageCache. I am just flushing the PageCache. So by running these scripts, I basically corrupt the device, know that this device is empty. There is no data there. They are doing integrity protection even for the unused sectors. Now if I run the check again, basically the check is just, integrity checks just read the device. It doesn't have any magic. There should be some failures. The same, it should be 16 sectors. I just rewrite. Just the offset is different because we are mapping it to be some offset. The kernel should comply in exactly the same. So we detected integrity failure. That's the reason why we are doing something happened with your device. And now it depends what we want to do with that. Currently I can just wipe this area. Later probably we can provide some special tool that can how to read data without checking the integrity and do some recovery. We will see how it should work. For now I have a very simple case here. It will try to read that and if there is error it will be wiped. So it works. It works this way. So that's one thing. Second is that DM integrity, standalone mode, I don't have demonstration for that because we don't have any user space for that yet. But so it will be very hard to play with DM tables. I don't want to show it here. The logic is that you can use DM integrity in standalone mode and you can basically add just some simple checksum with this target and you can use anything up to that layer. So I can imagine that it can be useful if you want to add integrity to something that is like black box. It can be some virtual machine and you can put that target below that. So you will quietly checking for any corruption there. Maybe it will work. So I will return to my slides actually just to the conclusion. So it was quite a heckery here but based on that academic idea I think we went to quite far and we have something working. We proved that authenticated encryption can be used in full disk encryption. With some device mapper help. It's quite easy to start. Once it's in kernel it's quite easy to start in. Basically instead of Anaconda creating the standard looks device it will just add one parameter and the rest is the same. Activation is exactly the same. The stacking of device that's all the handle by grip setup. The problem is of course price for the performance. We will work on that. I will provide some better testing but even now it's quite usable in some situations. If you are not doing any complicated device you will probably not notice it at all. I would like to merge it in upstream kernel but these discussions are just ongoing. We start this week so there are some changes needed yet but the logic there is based on looks too and that's the question looks to is still life and I hope in several weeks we will have some testing development released. There is a lot of other new things so we will need to discuss it but I will release some some bundle of that for testing. So for now if you want to test it you really need to patch everything and place that. The last what I would like to mention my intention was to show that we can do an integrity checking on this level. There are many situations where it's not proper place for data integrity but if you see last year's how many systems really implemented something. There is butterfs doing something but butterfs is not quite usable yet at least not for all these things and on application layer just try to modify randomly some documents if application detects that someone is playing with the data. I think there is not many such code doing integrity. So if we are doing it on the lowest level maybe it can help. Maybe not. I don't know. That depends on users on you actually. So that's all from me. Thank you for listening and we have probably some few minutes for questions. The question was if the same CRC check can be used in DM integrity as in butterfs. Yeah sure that's exactly that standalone mode. You can select whatever Cript API provides Cript API CRC32 so you can just define it that and it will do the same mechanism on allocating the sectors and calculating itself. So no more Cript setup over that DM integrity work this way. You can even use the hash actually you can even use an HMAC but that's more complicated you need to provide key. But CRC32 is exactly the situation I mentioned for standalone target. Sure you are storing more data but that's the question sorry the question was if the performance is in the IO or somewhere else. That's exactly why I don't want to present some performance graph because we surely don't know yet. We have some strange output. We have tools like brain mentions here we will analyze that but really this is the first step so it works quite well but maybe I forgot to say 10 years ago when look started we have the same performance problem in this encryption. It takes several years to stabilize it that it's today. This is completely new system so I think it will take few months at least so yeah. Question if there is some attacks like row hammer on storage. I am not sure exactly what type attacks you mean row hammer is that you are attacking different cells then you are accessing so you are playing with some bits in memory and some other bits change I am not sure how it's mapped to the storage probably inside SSD I don't know maybe maybe discuss it later but I am I don't know about such attacks probably in SSD maybe there are some but I don't know about that yeah that's the good question if it can support this card on SSD script setup or DM script supports SSD you can switch it on for that stuff it's problematic we can very easily switch it to support that but problem is that if you run the discard it will discard that checksum as well or that authentication tech and the problem is that you need to write there using direct to create it again it will work if we enable it problem is that in between application on this layer is page cache and page cache read the page so if you read one sector 512 bytes page cache will read 4 kilobytes and if you don't have calculated calculated checksum for the rest rest of the sectors it will fail the whole aisle so it's problematic currently we have disabled disabled the trim so it will not support him I can imagine if the page page is the of the same size as sector we can probably somehow enable it it's more question for me clash but maybe later sorry which calculates sorry how I created the table that with that numbers or I don't see I'm not sure if I understand the question calculation for for the page or yeah yeah yeah that day I it will fail okay the page on the Intel hit actually is for kill it's eight sectors we are calculating checksum for each sector if we are using that small sector so if you have the device and only first sector is used and have the proper checksum if I using direct you I'm I'm going around the page cache so I'm asking device just to the one sector it will decrypt it will verify authentication it it works if I'm going through page cache I have the just one sector this proper checksum and seven sector without proper authentication so the page cache will issue instead want that small operation it will issue I operation of the whole page for kilos and because there is no DMC it will see that one request it will try to decrypt it will decrypt the first part and under seven sector will fail and it can it cannot proper actually better than fail the whole IO so I cannot write there I need to skip it by direct you that's that's the limitation maybe something will be better but if we are using the page size and the sector size of the same size I think it can be solved but currently we don't support it that's that's going to be complicated and in the security context you are creating some side channel so yeah so sorry I didn't repeat that the question was and if we create some bitmap of something like that that depends yeah I will try it's a lot of local question there but I will try to repeat that the problems with this attacks here is that basically we are trying to fit some usable space so attacker can can replace the sectors and if there is file I create some destruction if not basically it means nothing and you are suggesting that instead of wiping we are replace it with backup or something like that well yes first is we are below the file level abstraction so the block device has no conceptual file it cannot know if the sector is used or not by file or whatever so I cannot play this file but I give you some example it's maybe like James bought example but how this can be used and why I want to integrity checking even for unused sectors imagine you have a laptop with encrypted disk and you are going through some airport checking something someone who can do forensic checking there and someone will replace the unused area with hidden disk the same like true keep to that so someone take the take the image place it there calls the the airport security that you have some confidential data there and say the password for that they will run forensic checking they have password and they will reveal that hidden disk with some confidential whatever imagine whatever that I I don't have any chance to checks myself that this unused area was tampered with I can do snapshot undo some diff but that's complicated but if I have if I have this this integrity checking I can just run that check command and I will fail I will see which sectors fail so there is some tampering if it's intentional or unintentional I don't know but I know this data are no data I've written there so maybe stupid example but that's something I am using to show that and you are of course right that if it's connected with backup it's of course much more simple just to take back up sectors and put it there to recover but that's integration summer okay the last question yeah a question was if for forward error correction we have some algorithms or we don't want in what I don't want to invent any crypto I don't want to invent any forward correction and we have already in kernel it's actually used with DM verity I didn't say that but the mv3 does not only verification but it has a space for forward correction classic rich Solomon codes it's in another DM verity targets I can use it there I just need to do some analysis if it's a cure and maybe if it's usable but definitely if we want to use forward error correction we will use the library or a representing kernel so okay and we are out of time thank you very much for questions and for coming okay thank you and for everybody there will be lightning talks in this room and the rooms downstairs so if you want to see the schedule it's only online app and on the website and we'll have five of them in this room so like a 10 minute short talks you can see them on the website


Let's see what's behind door number 17 today because we are still doing self tapes every day until Christmas because I want to keep practicing acting even when there's not that many auditions because it's December or bookings because it's December and I have conflicts. What I've been doing is doing a scene or monologue from a Christmas movie or TV show and today is day number 17. It's right here in the fireplace. Mary in Laws. Is this a famous movie? Because I didn't watch this movie. I just scrolled through it until I was like, oh, I'll do this scene. But I saw a lot of actors that are pretty well known, but this is a scene where she's getting proposed to and she's like, oh my gosh, wait, let's think about the logistics first. And then she's like, okay, fine, let's get my weed. I'm gonna set a 15 minute timer, prepare it a little bit, record the other lines because I don't have a reader. And what I've been doing when I don't have a reader, like today is I record the lines, chop them up and then I do the scene with the OG person from the film. Now that I recorded the lines, this scene is actually pretty short in the film. They do take a lot of pauses for visual things because it's a whole big engagement setup at their house. So this is actually shorter than I remembered.  It's a very classic thing for Christmas movies to be proposed to. Oh wow, yeah, this is like way quicker pace than what is seen in the movie and that's fine. So I definitely, I'm gonna say yes at the end, right? Cause that's in the lines. It's just like what happens in between. We need to think about the pro, you know what? I think I'm ready. Let's just do it. It's only been like five minutes, but let's give it a try. I'm gonna do it how I would play it with these lines and then maybe we'll try one just for fun, like a different one. That's okay, will you? Okay, let's do it one more time like that. I just really need to be very surprised at the beginning. Like confused of what, what, what is this? Like my brain is malfunctioning cause it does not comprehend that I'm getting engaged too. So it's trying to like understand like, wait, why does my boyfriend have a ring? Like this doesn't make any sense. What should we do for fun? Okay, how about I'm making excuses for like, for reasons to not to. And then at the end I'll reluctantly say, yes, of course I'll marry you, like nervous, like, okay, how am I gonna get out of this one later? Yes. Ooh, I would not want somebody making that face. I mean, not that I could see my face, but I would not want somebody making that face when they said yes to me. Let's see how those came out. I'm gonna show you the best one or the best two takes and I'll see you tomorrow. Peter, what is this? Oh, what? This is also sudden. We've never talked about this. It's just, this is out of nowhere. Let's keep it together for over a year. Just say yes or no if that's how you feel. Oh, no, no, no, no.  I mean, Peter, no, we just have to consider the pros and cons of legalizing our relationship. Like, what's this gonna do to our taxes or our benefits or not to mention, I would have to change all my legal identifications to your family name. Like, do I? There are no cons here, there's just one pro and that is me getting to spend the rest of my life with you and Max. I love you, Alex. So, what do you say? Will you marry me? Yes, of course I'll marry you. Peter, what is this? Is this yours? Alex Spencer, will you marry me? What? Peter, this is all so sudden. We've never talked about this. Just say yes or no if that's how you feel. No, no, no. I mean, yes, I just, Peter, we just need to consider the pros and cons of legalizing our relationship. Like, what's it gonna do to our taxes or our benefits or not to mention, I would have to change all of my legal identifications to your family name. There are no cons here, there's just one pro and that is me getting to spend the rest of my life with you and Max. I love you, Alex. So, what do you say? Will you marry me? Yes, I'll marry you.


Hi, and thanks for joining the CNCF webinar about Cubescape. I'm Craig Box, I'm the VP of open source and community at Armor, the original creators of Cubescape, and the company that contributed it to the CNCF. Today, I'm going to tell you a little bit about the Cubescape platform, what we at Armor who built on top of it, and what we're doing now, and in the next few months to make the product better for everybody. Let's start by asking the reasonable question of, why do we even care about security? This is the first of what I like to call the scary numbers section. IBM Research last year says the average cost of a ransomware attack was $4.54 million, and that doesn't even include the cost of the ransom. There's an entire industry predicated on providing scary numbers, this should be fun. 97% of organizations say they have concern about Kubernetes security. Looking at what risks people are most worried about, the highest number were people worried about misconfigurations or exposures in their environment, followed by vulnerabilities, and only then actual outside attacks. That tracks to what people have actually seen in the last 12 months. Red Hat Survey says that 53% of its respondents had detected a misconfiguration in their environment that caused a security flaw. 38% had a major vulnerability that they needed to remediate. Gartner, by some measure the king of scary numbers, say that 99% of breaches in 2025 are going to be traceable to customer mistakes. So some of you will have an inner monologue that's going, I am but a developer, I don't have to worry about any of this. I have an entire team of professionals whose job it is to make sure that I don't have to worry about any of this. Well, you should go and talk to them, because it turns out that they don't think that's why they're there at all. Cloud and Kubernetes have been great at moving responsibility around, so that developers have to do more things. Developers are shifting right, while security and the responsibility for it is quote unquote shifting left. So put simply, today developers and DevOps teams need to care about security. Some people call this DevSecOps, I'm just going to call it extra work. Half the people Red Hat surveyed said that security got in the way of them deploying at the speed that they wanted to work at. Citing some foundational research in the industry, the tag security white paper says that 85% of defects are introduced during coding with a cost of $41 to fix at that point, compared to a post release fixed cost of $26,542. Let's try and catch those vulnerabilities early, shall we? So hopefully I've scaring numbered you into thinking that you need to do something. How should we think about security for Kubernetes? Well, we turn to the documentation and it talks about four Cs we need to consider, code, container, cluster, and cloud or co-location provider or central IT team, if you like. These all build on top of each other in a very specific fashion. If your cloud is compromised, there's no amount of security you can add to your code to help protect you. Clouds have many more services and concerns than just the ones of a Kubernetes environment, so for now, we simply have to accept part of the shared responsibility model and say, we have trust in our vendor. But the cloud vendor doesn't know what you're running unless you install some sort of agent to tell it. And in general, they don't want to be responsible for what you are running or how you have configured it. Let's then look at code. There have been books written on how to write good code. There's a sea change happening in the industry at the moment, in terms of memory safe languages, which I will glibly summarize as rewrite it in Rust. But ultimately, you're going to have to do your own work to make sure your software is secure. What then is the software supply chain? Well, I like to think about it as the gaps between the boxes, specifically by what process is code taken and made into a container, or by what process our container is taken and instantiated to run on the cluster. And we'll look at that a little bit more later. So back to our four Cs. We are predominantly concerned about the container and the cluster. What we're going to run and how we're going to run it. What we're going to run is reasonably self-explanatory. Code has dependencies. Those dependencies have occasional vulnerabilities. Those are documented on the common vulnerabilities and exposures list, CVE, with coordinated disclosure being performed. How we're going to run it relates to the thing people are scared of. Kubernetes is basically its own operating system, with many different options to trip you up. The thing that makes Kubernetes different to a PaaS is the fact that you must, or at least can, make all the decisions yourself. What sort of storage, what network configuration, what permissions, etc, etc. You submit these in the manifest, synonymous with its data format, YAML, and then you hope you didn't make a mistake. Our first move needs to be to put in some guardrails to stop people making mistakes. This is a quote from the Tag Security Cloud Native white paper, saying it is vital to scan application manifests in the deployment pipeline to identify things that could potentially result in an insecure deployment posture. There are a number of tools that can do this, but ultimately it's not really helpful to say something is wrong. If I knew something was wrong, I would have written the manifest properly. What you really want to be told is something is wrong, here's why, and here's how to fix it. You can't just compare everything against the checklist and say I am secure or I am not, but that doesn't mean that such checklists aren't helpful. The good news is that there are a number of government agencies and nonprofits that have developed benchmarks or frameworks which you can measure yourself against. You can use these frameworks in a couple of different ways. As sets of tests, you might want to run against a cluster to check you have a good security posture, or to validate to some external compliance team that you are running your infrastructure in an acceptable way. None of them are law, but they're a good baseline. Take for example the Kubernetes Hardening Guidance developed by the United States NSA and CISA in 2021. It introduces a threat model, talking about three possible sources of compromise. Supply chain risks, malicious threat actors, and insider threats. It then spells out things that you should be doing as mitigations to those common threats. Some are configuration knobs that should be set in a certain way. Some are best practices for the configuration of workloads. And some are cluster settings that will allow you to limit attack surfaces and help diagnose the problem if you ever are attacked. Just after the release of the NSA guidance, Elmo released Cubescape. The first piece of the security landscape that Cubescape addressed was that NSA framework, but we've continually added support for new frameworks and more ways to provide a view of your Kubernetes security posture. We're creeping up on 200 controls or potential vulnerabilities to check across the three major Kubernetes security frameworks and their own Elmo best practices guidelines. Cubescape is an engine, a command line tool, a set of cluster components, and a SAS backend for defining and enforcing best practices, whether it be against one of those frameworks or something that your business wants to define itself. Identifying and preventing drift, continuously from deployment of applications through the lifecycle of an application and production, and continuously hardening and reducing the attack surface of your environment with remediation advice and contextual insights on things that you might want to change or improve about your environment. The first way that most people interact with Cubescape is through the command line tool of the same name that takes us and put the control library, which it will download and make sure is most up to date when it runs, and it can be run against YAML files, Helm charts, a running Kubernetes cluster, or a Git repository that contains manifests. Output can either be directly to the terminal in useful formats like XML or JSON locally, or submitted to a backend service like the HALMO platform. Installing Cubescape is as simple as this hypersecure curl pipe bash command, but you'll be pleased to know that you can also install Cubescape with Homebrew with the crew package manager, and we are currently implementing support for Deb and RPM installs. As long as I have Cube CTL set up with a context to connect to a cluster, then I can run Cubescape to scan that cluster. And in this case, let's use the NSA framework. There we go. That's as easy as that. You'll notice that there were some things that we were unable to scan here because we did not install the host scanner. There are some things we can't get from the Kubernetes API server. We actually need to run an agent on the host to query some of the state of the machines. So to install that, we simply run with dash dash enable host scan. The host scanner is a daemon set, which is run on each machine only for the period of time which Cubescape is scanning it. Once the scan is complete, the daemon set is uninstalled, and you don't have anything continuing to run. Previously, we had some vulnerabilities which would have been critical had they failed, and it wasn't able to check those. With the host scanner installed, it is able to say that everything's okay and those are no longer a concern. Here on the screen, you can see the URL to copy and paste to view this data on the AMO platform. AMO platform is a hosted version of Cubescape's cloud components, which allow you to not only view your security information but define your frameworks and policies, define exceptions and configurations for them, and make them available to Cubescape wherever it's being run. AMO platform is a SaaS service available for free, up to 10 worker nodes, and with plans available beyond that. We intend to open source this and have it be available as the Cubescape cloud backend for everybody later this year. Let's have a look in our cluster now. Scan results uploaded here are visible, showing us all of the same controls and information we saw previously, but also allowing us to easily view the parts that need remediating, the severity of them, and understand which ones we need to address first, and the fixes required. For example, the NSA framework suggests that all pods should have resource limits set. So we can see here that there are four resources that have failed, seven exceptions that are set for system pods generally. And if we click on fix, we can see there are four components here. They are part of the Docker desktop setup that we're running, but they are not correctly configured as far as the framework is concerned. Clicking the spanner allows me to open the remediation view where I'm able to see the definition of the Kubernetes objects and also see the places where it suggests I need to perform a remediation. In this case here, I would need to set a limit for CPU and memory for this particular pod. I can take the output here, I can download the ML file, I can make those changes locally, and then I can put that back into my CI pipeline and say for this particular object, the remediation has been made and now we'll apply going forward. Most users will want to run Cubescape in their cluster so that it is continuously scanned and security posture information can be uploaded to Cubescape Cloud. To do that, you install a Helm chart. With the add cluster button here, you can see the information that's required. You simply install the Cubescape Helm chart and configure it with your account identity in order to connect the two together. In this case, you'll see that we have a cluster here named Docker Desktop. That meant I didn't have to worry about any of this because I used our new Docker Desktop integration. Installing Cubescape into your Docker Desktop environment is as easy as going to extensions and searching.  It will scan all the containers that are deployed in your cluster and upload their CVE data to the Cubescape backend where you can visualize it.  And you can also see vulnerabilities broken down by their criticality, whether or not they're a remote code execution vulnerability, and whether or not there is a fix available for them. Let's have a look for example at one of our critical vulnerabilities, the recommendation service. There are two critical vulnerabilities here, but only one of them shows up as having a fix. So if we remove the filter here, we'll see both of these. And we can also use Cubescape's exception or ignore rules feature, whereby we say we've looked at this particular vulnerability, we know it doesn't apply to us and we don't want to be notified about it again. We can mark the vulnerability as accepted and then it will no longer show up in results in the Cubescape UI or if your Cubescape client is connected and downloads the exception rules from the backend, it won't show up in CLI scans either. Here's something new we're working on to help people understand which vulnerabilities matter and which are just noise. Sniffer is a POC project which will filter out irrelevant vulnerabilities from Cubescape scan results. What we do is watch what a container actually does for a short period of time when it starts up and then from that point we can evaluate whether the files on the disk that it doesn't touch are likely to be relevant. We can't rule them out completely of course but we can say in this case of the 76 potential vulnerabilities here are the 12 that are actually in code that the container used while we were observing it. The evaluation is done with EBPF we're currently experimenting with engines like Felco and Silium and we're looking forward to bringing this to be part of the Cubescape product very soon. Under settings and then the frameworks and controls section we can add new frameworks. We can customize the controls configuring for example which container registries are allowed to be used and which are problematic and should be denied. Now thanks to the magic of AI we also have the ability to create custom controls with our new GPT integration without having to know any rego. We just need to name the control let's call it check replicas and define what we would like to have happen for example let's say fail if a replica set has more than four replicas we could give an example object to test against or a description if we want or we can just trust the machine will generate it correctly. We hit generate and here we go it has provided a remediation in the case that there are more than four replicas reduce the number of replicas to four or less it has provided the rego code snippet which will test and then fail in the event the replicas are more than four and now we can download this control file here's our downloaded JSON file containing the rego rule set to make sure we have no more than four replicas here's a manifest file which asks for three replicas we'll open a terminal and run cubescape to use this JSON file as a check and check against the replica set file you see none of the resources failed and we have no risk but if we update this to a number that's greater than four watch out there you can see the resource has indeed failed and we are 100% at risk something else you may notice here is that there is integration with cubescape in visual studio code for example we can look here at the image flag and it says that there is a control indeed a CIS control which says minimize container registries to those who are approved the recommendation from the benchmark is that you configure a set of repositories and say only these repositories are allowed and if those repositories are indeed configured then you will no longer receive the error in BS code here's something else that we're cooking up in cubescape labs at the moment support for a new kubernetes feature today to do admission control in kubernetes you have to run an external webhook that now becomes part of the infrastructure that you must operate maintain upgrade etc if your webhook is down the control plane is unavailable either by way of allowing anything to be admitted which is insecure or allowing nothing to be admitted being able to move this functionality into the kubernetes API server process has many advantages we achieve this by using the common expression language or CEL which is currently used in other parts of kubernetes for example for validating CRDs here is a rule that's quite similar to one we looked at before let's say we don't want to have more than five replicas in a particular deployment we can define that in the CEL and upload it to the cluster as a validating admission policy we've converted a number of our existing controls to CEL so that you can use them with the validating admission controller feature these are scans that you would currently do on your cluster to see if you have insecure objects and you'll now be able to use them to actually stop insecure objects being deployed to your cluster we look forward to working with the kubernetes team on bringing this feature through to availability later in the year last december we were accepted into the CNCF sandbox as the first security and compliance scanning project we're in some pretty esteemed company when it comes to security tooling but all the other vendors seem to want to have a proprietary platform for security perhaps with some open source cluster tooling we want to be open source end to end which is why i joined ammo we have to separate out a bunch of the kubernetes back end from other ammo code and integrations we use and build a version that you can install in your own cluster and in a few months time we will have fulfilled our promise just like mario open source projects are powered by stars we're very happy to see that we've shot straight to second place we need to keep building features users love so we can catch up to our friends at cert manager here are a couple more features we've built recently we mentioned software supply chain before the cubescape team wants to help users make sure they're using the right container images in their environments so we release the capability to verify container image signatures we can now verify against a list of trusted public keys as with any other configurable control we have two separate controls one for testing if an image has a signature and one for actually verifying it that way our users can get immediate metrics regarding which images are signed and which are not even before configuring keys the tooling enables users to start to align with supply chain security requirements and verification of image signatures if you're using amazon's elastic community service you might want to compare against the amazon specific cis benchmark it's designed to understand the fact that you have a shared responsibility with the vendor who in this case is responsible for the control plane we recently added support for scanning against the cis eks benchmark we developed custom controls or mapped our existing controls to the benchmark and as of today we support 50 of the 53 controls you can scan through the cubescape cli or you can view the results in the cloud back end with armo platform where they're broken down by the section headings defined in the cis documentation today we're giving you a whistle stop tour through what's new in cubescape and a few things that are coming soon once we've released our vulnerability relevance calculation with ebpf we can use that same engine to do so much more things like generating kubernetes network policies based on application behavior keep your eyes peeled for that coming soon we're going to open source the back end that runs armo platform as i've mentioned we're going to add the aks and gke flavors of the cis benchmark and we're going to write the kind of documentation that you'd honestly be surprised to see from an open source project thanks very much for taking this journey through cubescape with me today i'll look forward to answering any questions you may have in slack on the hash cubescape channel if you want to get involved in contributing the channel is hash cubescape dev and we look forward to seeing you in the community soon