 Okay. Hey everybody. Hope you're all enjoying Cloud Native Security Day so far. My name is John Kinsella. I'm Chief Architect at Acurex. Gonna talk about a project I've been working on for a while. This is a more of a proposal in a talk form, bound around security and nutrition labels for cloud native projects, open source projects in general. So the idea here, this originally came to me probably close to a year ago from an academic paper that was talking about nutrition labels for privacy. I think we covered this at some point, application security, we clear them, co-host. I can't find a link to it so unfortunately I don't have it in the notes. Everything else I'm talking about is referenced in the, we've got a page in the back of the slide deck here which has all those links. But so that's where this came from. And let's sort of dive in and talk through. So the point of this really is I want to start a conversation here. This is being recorded a month before you guys see this. So I'm still working on this. I'm hoping to have a proposal into security. Stuff you're going to be seeing here is on a GitHub account. So I'll probably be pacing this in either while you guys are watching this or during the Q&A at the end. And enjoy and I'll probably say many times, but I'm looking for feedback. So give us what you got. So the Food and Drug Administration, FDA in the United States, they consider this thing, which I suspect all of us have seen the nutrition facts label to be one of the most widely known graphics in the world. You know, we see it, we certainly know what's on there. It's getting better over time. I'll talk a little bit about the history. But the idea is how do I bring something like this to security. And really in a, you know, it's obviously not going to be mandated by law. How do we do this in a friendly way that allows people to have a sense of what they're consuming? And that's the core of what's going on here. So the nutrition laws first came around early 1900s. I want to say 1907s when FDA was formed. Again, in the U.S. this is now grown, you know, there's these type of rules are labels are all around the world in one form or another. But really what's interesting is their, their creation came from package goods, package foods. And what happened is as people started vendor started selling package goods in that manner, you know, there's always going to be looking for someone to make a few more sense. So I try to figure out, how do we make that package either a little bit smaller, but look like it has the same amount of stuff in it, or maybe it's cheaper ingredient, maybe it's more dangerous ingredient. So these are the type of things people were doing. And, you know, people probably started dying or they weren't getting their money's worth. And the government said that ain't that cool. So a lot of sort of getting created. And I don't know, maybe there was some sort of tomfool or another company was saying, Hey, let's, let's get the other guys. Let's get some laws. I'm not sure exact creation, but I spent about a day digging into stuff and Fox falling down into it. And it's let's keep going in the seventies. The first versions of the nutrition labels were actually mandated from a point of view of if you are making health claims on the package. So when these are mandated around the world is varies, but you know, in the U S is once you started saying, Hey, this makes your son healthier or stronger or taller. That's the type of thing which people start regulating. If you mentioned something like baby food or what's in your baby food. That's when people get really nervous. The mothers out there probably listening to school already sort of that, you know, don't, don't mess with my little one. And then since then every decade or so, we've had some amount of tuning and tweaking going on as this type of document. And that's usually based off science. You know, as either our scientific understanding of what we're consuming gets better. Or as the bad guys use science to figure out a cheap way of getting something extra goods. Here we are. So this now going on over to the digital side, right? We've all heard about what Apple's up to. I believe Google is doing some of this stuff as well. This is the privacy label for Google photos. Just doing a lot of linking, but you know, this is just being shown to sort of that we went from food labels to digital labels from privacy point of view. So let's think about what can we do with this for security. And obviously again, you know, we don't have the chokehold of a government. We don't have the chokehold of Apple's app store. But what can we do in a way which still allows our users to have a little more trust in us? So from my own personal point of view, I thought of this from two aspects. One of those is when I'm first looking at a project, what does it do? Right. Is this, if I install this, is it going to be taking over my cluster? Or is it going to be formatting my disk? Or is it uploading data? Or just generally what's this thing doing that I just downloaded? I can't code review everything. If it's a big famous project that has, you know, 10,000 stars in GitHub. Okay, we've got a little more trust in it. Probably as I think about that, I may be at this more church of sandbox and the middle step whose name I'm forgetting in the CNCF process. Those are the guys who we're trying to figure out how do we get them out so their project get more adoption. And then the second aspect is installation help. This is a big one to me. Probably not so much with an off the shelf thing you just downloaded and run like a brew install, but something that's a little more complex like I'm not going to name names, but you downloaded the thing, you compile it, you install it, and then the configuration starts. And you do one configuration, you need to do another configuration that you need to create user names, you need to create roles. And at some point in there, you're so far in that you don't want to back up and give up because you've already committed this time to it. But you're like, I wish I knew this beginning before I got started and I would have gone and just bought something. So that's for what I'm looking for here is how can we help provide transparency of these type of things. This is really not about the whole red, green, blue, security, bad, don't use type thing. This is more advisory, not looking to admonish. We're open source, we're not trying to spank people. We're trying to get people to do the right thing to increase trust. And I think what's an interesting side effect is something like this. This is sort of a little bit like a self assessment. And depending where it goes, this might get linked into the self assessments. I could see that as a possibility. But I think as a application developer or as a project is realizing, hey, maybe I want to put a security label or a badge on my project on GitHub. As they start going through and looking at all those tick boxes that they could be able to do or the YAML will show in a few minutes. That might make them realize, oh, hey, I could do this really quickly and become that little bit better on my badge. Maybe they knew about it and they just hadn't got to it yet or maybe they hadn't even thought about it. So I think from either aspect, I think there's some benefits to people doing that. And as fun as that is to talk about those labels. Let's be honest here, right? If most of us walk into a store in the morning, say it's lunchtime and we're hungry, we're not going to be like this lady here just going down the aisle picking up every box and looking and reading what's on the back of it. It's a lot more, at least for me over, you know, beside the last year in COVID, it's lunchtime. I go into store, I grab something, I give somebody money and I want to shove it in my face and go, right? I don't want to do that. I don't want to do that. I don't want to do that. I don't want to do that. I don't want to do that. I don't want to do that in any detail. We will, in some cases, if we have a, a dietary need or we're buying something for a loved one, we're really careful about what they're, they're consuming or some use cases like that. But want to try to say is, is, you know, we're looking at the front of these packages on the shelves. And that's where industry came up with the system of what they call a front of package label. And, you know, let's, let's get my ugly mug out of the way here. Or, you know, obviously we have different languages on here. There's different ways, different organizations have gone about doing this. Sometimes it's for adult health. Sometimes it's for weight watching. Sometimes it's, you know, let's, I think it's Brazil that's actually doing some of this for trying to minimize obesity in the country. But one way or another, we want to put a simpler label on the front that isn't, this is 39% of your recommended daily allowance. It's like, hey, from a quick glance, should I be eating this? Should I be eating a lot of this? It's not, this is poison. Don't touch it. It's more around, hey, maybe you don't need five crispy creams. Right. So it's a little more guidance. And this is sort of, when you think about it, this is a lot like our badges we have on modern day projects from on GitHub, right? So I don't have, I haven't boiled down what I'm looking at, I want to research into something quite this beautifully simple. That's what I'd love to get to. You know, most of those badges are pretty small. I'm not sure how much information I could fit into them. Maybe it should be a link out to somewhere else, but that'd be a nice goal to get to I think for this. So the graphic designers and audience, I'll show my skills a little bit, but I'm still looking for help on that. So brainstorming what this actually looks like or what we could put into this. So in, you know, the top few are pretty understandable. Network connectivity is this thing, opening up a listener on the network. And you know, actually, when you think about it, another use for a nutrition label like this, if someone's claiming that they're not doing that, and then suddenly an application is doing that, I don't want to say that's a sign of tampering, but that would sort of give you an extra, an extra bit of information during a investigation. So I think there's some value there for that as we go through this. The root privileges are they needed? You know, do I need to run this with a cluster admin role binding? The credential aspect is pretty interesting. We're seeing more and more applications now that they want an API key to go and connect to GitHub. Atlantis comes to mind. I've been working on that recently. Or, you know, maybe it needs like Terraform once your credentials be able to go and spin up VMs on Azure. Or, you know, there's all sorts of different use cases there around that, but that's something that, especially in enterprise world, when someone says, oh, I need, I think for Azure in particular, you can't just use a read-only account to look at your AKS clusters. You need to have admin rights to get the keys to get into them. A self-respecting enterprise with a modern security policy isn't just going to do that automatically. So if they knew something about that upfront, as one example, that's something that they want to understand what they're getting into. We're all thinking about software supply chain. So I threw the few points in around that here. And I think that's, again, you know, transparency. If we can help these people do this or understand this in that sort of, you know, checkbox type format, I think this will be handy. And then the next group are a little more advanced, a little more mature. So we've got three examples here coming up. One's a sandbox, one's one of my own applications, or Acrex's applications, and then one's a very mature application. So we'll see the difference between those three, how they show off and something like this. Do you have an architectural diagram? How about a threat model? So these would be more like just hatred, right? If you've done a self-assessment questionnaire, if you are working on graduating from CNCF, from the sandbox, let's link out to that. So people can sort of see very quickly without, a lot of this also is, a lot of this information is available already, but how can we make this sort of one-stop shop to get as bunch of this type of data? So if people can actually, you know, I know if I go to the nutrition label, I can find, if they have a threat model, I can find it there and just go and review it and keep going or I can look at their self-assessment questionnaire from that nice easy place. We're seeing more of the mature projects starting to do third-party reviews. Kubernetes has been doing it for a while. LinkerD we've got in here, they've been doing it. Security contacts, again, you know, this is something that's fairly basic, but I'll point it myself, not all projects have it. And then a security page. Do you have sort of a single place where people can go and find out more detail about the stuff we're talking about? I'll try to not bob my head around. I know this camera's trying to follow me, so I hope that's not driving people nuts. But keep going. So three examples, YAML. You know, I figured we're always doing YAML already for most of the stuff we're doing around here. Let's put this into a YAML format as well. And to sort of grab a pointer and go through here, it starts off fairly basic. So this is for a CNCF sandbox project called TelePresence. Some of you may have heard of it. Long story short, it allows, it sets up a proxy between your desktop and a Kubernetes cluster so you can do remote development. You know, so application name, source code URL, so people can go and find that if they're not there already. Is it sending on the network? Is it receiving on the network? Is it starting a listener, as I mentioned before? What port? So this is where I'd love to put as much as I can into a defined language. But I think for something like this, there's going to be a lot of just strings, right? So a proxy is going to be listening on whatever port that somebody needs it on. Another example down here under privileges, what type of credentials are required? In a Kubernetes cluster, this thing needs, this thing consumes the privileges of the person running that application from their desktop. There's a minimum set of requirements, but that's what they're consuming, doesn't need root, doesn't need privileges. So, you know, looking pretty good here so far. Some of their commits are signed, not quite all of them. And then same with builds. So I think any builds nowadays that goes on to homebrew has to be signed. And we're seeing more and more of that type of thing. Excuse me. The interesting one here on the git commits. And I'm not sure I haven't been watching what the software supply chain guys have been doing in detail, but from a point of view of very few projects have been signed their commits since day one. So do we say, hey, the last three releases have had their all their commit signs, maybe all their commits in the last six months have been signed. Is it the last hundred commits have been signed? What type of verbiage could we put in there or language could we put in there that makes that meaningful, but not a very black and white yes, no that most companies or most projects could not actually respond to. Let's move on forward to example number two. This is for Terra scan. This is an accurate application open source. And really it's an ISC application that can scan Kubernetes and customized and Helm and Terraform. But again, so sort of going through here. He's able to, you know, get the URL for source. He's listens. Excuse me. He sends on the network by default down, you know, he sends out a request to get to, to get hubs do a poll for his rules. Listening is optional. So it can run as a server or by the time this is published as a admission controller, but by default it doesn't. So listening that's optional. I think that's okay to do listens on a particular report was that's overridden. Most rest is pretty clean. Again, recent get commits have been signed and been pushing for that. Our builds are signed and we actually have an architecture diagram. So we're able to get, you know, one point there on the advanced things. I don't have a contact for security. It's something we need to do. And hopefully by the time this is published. So moving towards something a little more advanced still, advanced still here. So there's a link or D graduated project. And again, it starts off sort of the same, you know, send and receive and these type of things. He's doing TLS by default. They're, they're really trying to do security, but secure by default. So they're, they're able to check boxes like this lot easier. So that's going to look better in a, in a diagram, right? In a nutrition label. Again, it's a proxy type application. So the ports listening on it varies. It does need cluster roles. You know, you, I think you can run a link or D and maybe just a single name space, I think. So you might not have to have a complete cluster role binding, but really if you want to do anything useful with it, I think that's where you're going to go. Again, sign, get commits. Sign to builds. And then as we come down into the maturity stuff, you're seeing more stuff down here. So they've got a security page. They've got their third party audit. They've got their architecture diagram. They've got their security contact. So, you know, we're filling up more on my screen here. There's more stuff that we could put into these slides. So that I haven't dreamed up yet. Some of them I'm trying to keep, you know, this readable. So bear with me. But that's sort of an example of looking at three different, three different applications. How would they, how would they be? How would you communicate in a, a YAML form, what their security facts, their nutrition facts are? So that's sort of thoughts on that. So then, you know, let's go from this into a graphic format. What would that look like if we came back to our initial slide? So this is something I mocked up for link or G. You know, it's, it's easy. It's simple. It's not too much for me to talk to here, right? It's, it's when you take that and sort of break it down into a consumable visually consumable format. It's, it's, I sort of like this, I have to say. So a few check boxes that they're doing industry standards. Maybe not everything. I'm not sure if I'd call variable ports industry standards. So I left that off. Same for the cluster role binding. But a brief description of what they're talking about, name of the project and then, you know, they all important. Who do we contact if there's a problem? And maybe there's a few more things I should put in here. I'm not sure about putting in links for the security pages. I guess it could be. Or maybe just a link rendered in the HTML. So we'll see what we do around that. So this is what I've been working with. This is the idea I've been playing with. I'm looking for any feedback. Anybody want to work with me on this? As I mentioned, I'm hoping to have this in as a proposal into six security. And we'll see where it goes from there. But I appreciate your time. I think we've got about 10 minutes left for questions. Can feel free to reach out to me on on CNCS. Okay. Or on Twitter at your handle there. John Elkin cell. Thanks everybody. I appreciate your time. Take care.