主题演讲：云原生更新 - Chris Aniszczyk，云原生计算基金会首席运营官

[0:00] All right, everyone can hear me? Everyone's awake? 'Cause I'm not. So, as Jim mentioned, I'm gonna go over some updates from the Cloud Native Computing Foundation. Obviously in this room it seemed like more people knew about you know, one of our first projects, Kubernetes, more than the foundation itself, but that's sometimes how it is. So I want to tell you a little bit about our origin story. So, you Um, Working. Clicker, Theo?

[0:35] We got a little snafu, but there we go. It's a hard click. All right. So a little bit of an origin story around CNCF. So I think we're good. Ah, thanks. You told me this would happen, so. Cool, so, little origin story. I was fortunate enough to join the Linux Foundation a little around two years ago to be involved with the formation of the cloud native computing foundation so for those who aren't aware uh cloud native is really a form of computing that was pioneered by the internet scale giants out there like Google, Facebook, Twitter, Netflix, and so on. And when I say "clown native," all I mean is You have services that live in containers that are orchestrated by some central system like Kubernetes. And so we started with this kind of simple goal of bringing cloud native computing to the masses. And when we started the foundation, we humbly started with 22 MEMBERS.

[1:34] and Kubernetes as kind of our seed project. And so that was about two years ago, like technically under two years ago, because we didn't hold our first board meeting until December of 2015. But it's been amazing to kind of see the growth over time. As Jim alluded to, I arguably think we are the fastest growing open source foundation with the Linux Foundation, but some people will debate me on that one. But as of today, we've basically experienced over 6x growth in under two years. It's really amazing to kind of see wide variety of companies really trying to adopt cloud native computing. And for me, if you kind of were studious and looked at this list of members, I think for the first time in the history of open source, we have the top six cloud providers under one open source foundation umbrella working together to advance the notion of cloud native computing to me, which is amazing for being someone who's been involved in open source for a long time. Also, as kind of like a geeky nerdy thing, I completely find it

[2:39] fascinating that Kubernetes, our first project, is actually technically self-hosted on itself for the first time. I'm sure some of you have heard, but GitHub is replatformed on Kubernetes. So Kubernetes source code is on GitHub. GitHub runs Kubernetes, so it's self-hosted. So I find this as a fun kind of -- a fun geeky thing to think about. In reality here, CNCF, the lifeblood of CNCF is its projects. I love all my projects equally, and we have 12 of them. We've grown to 12 projects.

[3:12] projects over the last two years. They cover spaces from orchestration to monitoring to tracing. And I'm sure some of you have seen this. wonderful cloud native landscape. If you haven't, you know, it's a bit of a crazy diagram. It kind of shows the complexity of this space, but I think the important thing here is that When it comes to cloud native, there are multiple paths to get to cloud native, right? There's different technologies out there that could use obviously We'd love for you to consider CNCF projects. We think they're of high quality and, you know, something you should consider. But we're realists, right? We understand there's other technology and projects out there that you may want to use for specific things. But the important thing in this diagram is there's some missing holes here. There's some missing pieces. So, you know, today I'm happy to announce that we're going to fill some missing gaps in this diagram.

[4:14] filling today. So please welcome Riaz to the stage. Thank you. Thanks, Chris. So as Chris mentioned, Today we are filling a couple gaps on that path diagram and so with Great excitement. I am happy to announce two new projects. to the CNCF. the update framework and notary. So, thank you.

[4:48] So to give you some context, both projects are focused on security, And both projects focused on a trusted delivery of content. What that means is getting some data from point A to point B, the data could be anything, cross-platform, in a trusted way. So many of you are probably thinking, Okay, we have a way of doing this. We maybe can use signatures. So here's the signature. and You may recognize the signature, you may not, in which case you have some authenticity of the signature. But what we're really missing from just signature is we're missing a lot of context. We're missing...

[5:22] When was the signature made? Is it still valid? Is one signature enough for our data, our software, or the document that this was on. And so what tough-- the update framework, really strives to achieve... is providing context for more robust software updates in a trusted way. So for some background on Tufts, TOUGH was developed by a group of researchers at the New York University, the engineering school. And they drew some ideas from Tor, right?

[5:53] which many of you may know as an anonymity, piece of software, communication, and Tor had a very exciting update framework called sought out to make a very secure update system for Tor. even in the face of some of the strongest adversaries. And so in developing FANDY and developing TOUGH, the TOUGH researchers decided to really tackle giving more context around signatures that you can make very robust decisions. So for example, From signatures, you may already get authenticity, understanding who signed it, integrity, understanding if what's signed is the same thing that you want.

[6:31] But Tufts goes beyond that by giving you freshness guarantees. Is this the most up-to-date signature, the most up-to-date package? It allows you to do multi-signature thresholding. So do I have all the signatures that I need? you know, three signatures, five signatures. And. Very importantly, in tough situations. if a key is compromised, it's not an end of the world event. You can rotate the key. and your consumers of your package, or whatever software or data you're providing, can still verify your signature and continue with with the optic process.

[7:02] And so, TUF, as I mentioned, is cross-platform, and many platforms and programming languages have already adopted or are in the process of adopting TUF today. Which brings me to Notary. which is a open source project from Docker that implements the tough specification. It's open source on GitHub. You can go there today. It's written in Go. You get a command line interface. A couple of microservices for the server side operations of signing and holding data.

[7:33] and you have a robust library to integrate with. Many of you might already know about notary. as notary has been at the forefront of container image provenance, so understanding where an image comes from. Is it trusted? But for those of you who aren't too familiar with image provenance, I'd like to draw an analogy to normal PDF, JPEG images, especially in the Photoshop world we live in. So. For example-- this is not a real image, right? Like, you could, in some parts of the world, Penguins do go and go to the beach, but you're not going to see one drinking a tropical drink sunbathing and wearing some flowers in a hammock.

[8:16] You're more likely to see... to be like this. And you'd expect something like this to be a real image. So in the same way that you'd want to expect real images for photos. you want to expect. that your containers are untampered with and trusted. You want image provenance. You want to know that the same developer or person who wrote the code for this image and packaged the image and pushed it. is the -- that same image is the one that you're downloading in deploying your infrastructure. And so Notary, by implementing the tough spec, gives you all of those great guarantees of freshness, authenticity, integrity.

[8:51] He compromised at survivable. and allows you to apply it to your Docker containers and other containers. And with Notre, you actually can go one step further and have a cryptographic chain of custody. What I mean by this is that you can... mandates cryptographically by requiring signatures at each stage. of your CI/CD pipeline. Did my image... Pass the I. did my image get a security scan? did my image successfully deploy to development and pass tests there? And before deploying to production, you can check and verify each of these signatures and mandate that they exist.

[9:28] before your container is deployed in your production environment. So, notary and TUF are very powerful. Notary has been adopted by as well many platforms including Docker Carl asks, VMware Linux kits. and many others. So I'd ask you to please... join us. Both projects are open source. On the tough side, The spec is a living spec. So there are augmentation proposals where you can propose new additions to the spec and called taps, and in Notary we're approaching 1.0.

[10:01] and thinking about signing Service specs, pod specs. and many other features, so we invite you to come join us. And with that, I'd like to invite Chris back up on stage. Thank you. That's it. Thank you, Riaz. Now we're-- projects and we've added both Notary and Tuff to the landscape. So, thank you, Riaz, for You know, just a final kind of notice and shout out for the audience is We're hosting KubeCon, CloudNativeCon in Austin.

[10:36] in a little less than a couple months now. So if you're interested in meeting the cloud-native community and, you know, working with our projects, please make your way to Austin and attend the conference. And we'll be back in Europe in May in Copenhagen. But thank you for your time, and I'm going to hand it back to Jim to... Steer us forward.