 Okay, please walk. Yeah, so hello everyone. My name is Nikita, I work at IBM and today I would like to present you IBM Secure Execution for CoreS and OpenShift. So before we start, let me ask you two questions. Please raise your hands if you're familiar with CoreS and Ignition. Okay, not everyone. And second, please raise your hands if you don't fully trust cloud providers. Yeah, so I have to explain about what CoreS and Ignition is. So CoreS is a small operating system. It's efficient, secure, and designed to run containers in cloud environment. And Ignition is a configuration tool for CoreS. It runs in NetRAMFS time and takes care about system configuration. So you have your config, you give the config to Ignition, and after installation or provision, you have your own CoreS instance. So it's tool used for configuration. Okay, what secure execution is? Maybe it's some kind of top secret place with one PC inside. No, secure execution is hardware-based technology developed by IBM and it's available since Z15 or Linux 3 generation system. It's technology which fully isolates virtual machine memory and CPU state from Hypervisor and other VMs. But why do we care about security and what kind of security we use on daily base? Mostly everyone. So the most simple example is a phone. So a lot of people use touch ID or face ID. So even if phone is stolen, bad guy cannot unlock it and see our messages, photos or something like that. For similar reason, secure execution exists. It enables the notion of secure VM or confidential VM. So confidential VM is VM where you cannot see what's in runtime in memory of VM. Hypervisor don't have any access to it or it's blocked. Secure execution not only enables this notion, it also helps you to deploy your VM securely. So you don't trust your cloud provider, but you have your VM. So you can send it as a file and run it. Secure execution guarantees that your VM is unmodified or if so, it couldn't be executed. Also it makes possible to specify on which exact the mainframes your VM can run. So now let me explain a bit how it works in general in any Linux distribution. So SUSE, Red Hat, Ubuntu. So during manufacturing, each mainframe becomes a pair of Huskies. So here are three mainframes and private Huskies stored somewhere in hardware. Firmware doesn't have access to it, it's only available by hardware. Public is published on IBM website. So if you have serial number of mainframe, you can fetch corresponding key. Then we have a special tool called NyanprodImage, which creates a unified kernel image. We call it SD boot, it's here in blue color. So it's a file encrypted with one of several Huskies, which contains kernel, init run, FSN command line. So once created, this file can be only decrypted on corresponding machine or machines and run only there. Any other Z cannot run it. Yeah, but is our VM now secure? Actually not at all. We still have to encrypt the disk itself with Wax encryption and there is a headache of system administration because every kernel update, we have to run getProtImage again, create new SD boot and using the IPL tool, which is IBM's bootloader, you have to install this file onto disk. We don't use grab, we use the IPL. So there is a special tool, which creates a mapping on the disk and you start directly on the disk. So all I mentioned is good for security, but it's not ready for cloud because administration, Wax encryption, a lot of handwork, it's not acceptable. So at IBM, we set three main goals for OpenShift and CoreS. First goal is security must work from the beginning. There should be no gap between you run your VM and to enable secure execution. Second, user experience shouldn't be different or shouldn't differ that much because if you have to read 10 pages of manual how to enable it, it's not good at all. People are used to something they don't want to see huge changes. And third goal was to protect Ignition Config. I'll get to it soon. So why Ignition Config is important. CoreS image itself contains operating system, but without any user, nothing. So in Ignition Config, you usually specify your user, SSH keys, passwords, system D units, actually a lot of stuff you can create. And it's your secret. We want to protect it. So in order to reach those goals, we may define building system of CoreS. It's S390X only. On the left side, you can see how regular you call image for S390 looks like of CoreS. We have two partitions labeled boot and root correspondingly. So slash boot contains what you usually have on the boot kernel, BLS entries, and root. Root is just root. For secure execution, we added something more. First of all, VD1, red on the picture, is a special small partition which contains just as the boot or unified kernel image. And this image is encrypted. Green partitions are exactly the same, no difference, but during the build, we enable DM Verity option. Who knows what DM Verity is? Okay, so DM Verity actually is a protection which calculates the hashes of partition. It splits it into blocks, calculates hash of each partition, stores it onto a file or to another partition. Then it repeats. It calculates hashes of this partition and continues until it has just one hash. It's called root hash. And we append both root hashes for boot and root to our SD boot image. So command line contains both hashes. It's like a Merkle tree. Then we also want to protect ignition. As I said, ignition shouldn't be readable by anyone and we also want to prevent modification. The easiest way to do it is just to encrypt ignition. So during build of chorus image, we also generate a pair of GPG keys. Private key, we append to our encrypted SD boot image. So after neutron affairs, we have GPG private key and then command line. Public key, you can fetch on Red Hat OpenShift website. So each build of chorus contains its own unique GPG key. Two different builds have different keys. But we still have an issue how we boot our SD boot image because each mainframe has unique key and if we don't have all the keys for all mainframes, we cannot run. For that purpose, we have a special key called universal. It's a special key which is only accessible by IBM and a bit by Red Hat. So during a build, we use universal key and sign our image and encrypt it using this key. This key you cannot find, you cannot fetch. Even I don't have access to it. So only built environment uses that key to sign SD boot with universal key so you can boot it on any mainframe. Sorry, too fast. But we still lack locks protection. We still have no encryption for our partitions. So when user has its ignition, ignition supports feature called merging. So we enforce wax encryption. We wrote a small ignition config which stored in NetRAMFS event system boots. First it checks the RT hashes. If they don't match, installation fails. Then we decrypt ignition. If it doesn't work again, installation fails. If everything is okay or condition submit, we merge user ignition config with our small which creates two locks partition. We completely erase the file system of VM and create bootFS and rootFS with wax encryption and integrity option on. All the keys we append to SD boot image. So image is encrypted, locks keys are there, keys are random. The same build of chorus image. If you run it several times on different mainframes, pretty soon we should have different locks keys. So on subsequent boot, we'll see some automatically decrypt both partitions, checks integrity, and if everything is okay, you have your chorus image. We secure execution on. And that's it. I managed that we didn't want to change user experience, but unfortunately for security, we had to pay a small price. User must provide his own host key. So he has to fetch the keys for his mainframes or mainframes he's going to use in the cloud, specify them within ignition config with predefined pass. And that's it. We take care about re-encryption, about system updates. So every time system updates the kernel, we create new SD boot image. We append again locks keys, crypto config, and that's it. You have security from the beginning in the cloud. And this is the first solution, which is available for public usage. Before I end my presentation, I would like to thank people who helped me a lot during development. It was Red Hat team and IBM team. So without them, it won't be possible to make this feature available. So with OpenShift 4.13, secure execution is available. So if you have access to IBM cloud or you want to try, you can use secure execution and make sure that your config and your VM is protected against Hypervisor or other VMs. Here are two links I append it because presentation is not that technical, but if you're interested in technical details on IBM website, there is a big article with a lot of technical details about how secure execution is designed, how SD boot image is generated because it's not only two host keys. We also generate intermediate keys, symmetric keys, all this stuff. And if you're interested about how secure execution works specifically for CoreS on GitHub and in the file where all the design is written with all explanation about why we use that or why we don't use something. So thank you for watching. And if you have any questions, please ask and I'll try to answer them. Like no questions. Thank you for watching. Thank you for your time.