 All right. I will just start now. So my name is Yannick and I'm a developer devops, slash security person from Hamburg, Germany. And I'm now doing this talk really spontaneously. So I just filed out the form yesterday to submit this talk. And so there's not going to be any slide or anything really prepared other than the tabs that you're seeing here in my Firefox tab bar and some kind cluster that I just started a couple of minutes ago. And what I want to show you today is an open source project, which is not from the CNCF, but it's from the OWASP foundation, which is more of a security foundation than a devops slash cloud native foundation. And I'm going to show you two projects, which belong together. One is the juicer project, which I have open right now. And the other one is the multi juicer project, which belongs to the juicer project, but basically a side project of it to basically make it runnable and usable from Kubernetes. So what juicer is, is it's what we call it is a intentionally vulnerable web application. So it's basically a web application that is intentionally developed badly. So the web application built in Node.js, which just a bunch of security vulnerabilities in it. And the primary use case for it is to learn about security vulnerabilities, especially in the web space. So that you can basically just start the juicer and then start hacking around in like a playground environment without risking to get sued by hacking something which is actually running in production somewhere. This is basically just a friendly training environment just for people to try out and play with software security. The second part is this multi juicer platform, which we're going to take a look later, which is basically juicer, just running on Kubernetes for multiple users at a time for training settings, where you may be hosting a centrally organized training for more than a couple of people. And you don't want everybody to install juicer on the local machines, but want to provide it for them. But before we're going to jump into the multi juicer side, I just want to show you a bit of what juicer is and what it looks like and how you can use it. So what I have open here right now is the juicer repository. It's just on GitHub juicer slash juicer. And juicer is like I said earlier, it's an application written in Node.js. So it's entirely JavaScript, both on the front and on the back end. And what you can do to basically make it run on your site is either basically just install it from source. So basically just do a git clone and then just running the MPN installs to get the dependencies. But as we're here on KubeCon, there's also obviously a Docker package or a Docker container for it. You can just start up. It's basically just a Docker container which you can just run and you need to port forward the port 3000. And then you can use it just locally, which is also one thing that I've prepared here. So if we go to my terminal, I think it's this tab here. I just started or I just ran this container here in the latest version. And what we're going to do now is just going to look at how a juicer looks like so that you get a better feeling for it. So this is the primary web interface of juicer. So basically juicer has an intentionally vulnerable web application. What it is, is basically just a fake web shop where you can buy all sorts of things. As a fake shop, you can obviously, obviously can't really buy anything. You can't spend any money. You basically don't risk anything. But it just basically looks like a standard boring web shop where you can buy things. And the interesting thing is now that basically under underneath all of these features which are packed in this juicer, there are actually more than a hundred different kinds of vulnerabilities in them. And just to give you a feeling of it, we're just going to run one of the more basic ones. So one thing that this juicer has is it has a user sign in or a sign in. So if I go to accounts here and go to log in, I can basically just log in and I can basically just do a normal log in. But what you will find is that this log in form is just vulnerable to an SQL injection. So basically you can also try to do an SQL injection here to make it do interesting things. The one thing that we can just try is basically instead of providing an actual email here is that we try to circumvent the security measures to provide a SQL string inside of this form. So we can do a log in without actually providing it a password. So like the normal one would just be, which has happened demo, demo, which works because it's a demo user account. But now if we would try to do it with an SQL injection, what we can just try is basically just try some quotation marks here just to see if this does anything interesting. And what we'll always see is by just basically putting some quotation marks in here, we can see that we're getting this weird error back. You don't know this notations is basically the standard JavaScript error or object stringification. This is already looking very interesting. And one thing that we can just try if you just imagine that this is like an SQL string, which is saying something like select a star from users where email is such and such and password hash is such and such and such. We can basically just try to do this with an SQL injection to now say, okay, I want to have a user row back where either the email is this thing here or where the expression one equals one is true. So it's basically just always true. And it will just return the first row of the database, just like a relatively normal SQL injection type of thing. What I'm just going to do is put a semicolon here to basically say, okay, the statement is now over. Don't even look at the password part. And I'm just going to comment out with the minus, minus the rest of the SQL statements. So basically, this is now basically just getting me back to the first user in the database. And by that, I can basically just log in. And if I do this, I can see, okay, I'm now successfully assigned in. And if I now look at look here, I hope this is somewhat readable. In this case, even signed in as a administrator, because in this case, the administrator was the first user in the database, because it was the first user who actually signed up for the service. So I'm now also by coincidence signed in as a user administrator. And as I said earlier, so this is one challenge, we also see that we got this, wait, I solved this earlier when preparing. So we didn't get this nice batch. We only got this for this missing error handling. But the nice thing in due sharp is due sharp also has a scoreboard. And it has a session or a tracking for all of the different hacking challenges that it has. So basically, in the scoreboard, I have the list of all hacking challenges that are in due sharp. And I can already see basically which challenges I have solved. And which challenges are available in due sharp in general. And like I said earlier, due sharp now has over 100 different hacking challenges in all kinds of categories, especially from the web development sphere, but also some which slightly touch into the cloud native sphere. So there's just a lot of things that you can do. A lot of things that you can try out. And especially nice as a teaching tool, if you're working at the company and you have like a web development team, that's just a very cool tool to basically do like a like a day long workshop with them, basically just run them through on how web application security works. And especially on how hackers would potentially try to attack their applications. It's just a really cool tool to just walk you through and see how this is working and learn on learn yourself on how these vulnerabilities can be used. So maybe just one challenge with slightly touches on cloud native things is there's a challenge called, I think it's called exposed metrics, which is this one here, which might be, might ring a bell for people using Prometheus for their metric system. So in this case, due sharp also provides Prometheus metrics. The problem here is that future basically does nothing in a way to protect these metrics. So basically everybody who can access the application can just basically go into the user URL browser bar and just type in slash metrics here. And what we're then going to get back is just the Prometheus metrics and point where there are all kinds of interesting things. Nothing super critical. So this is more of an information disclosure type of thing, but definitely something that we wouldn't want to expose to every user. There are just a bunch of these different challenges just to teach people on what kind of things to look out for when developing applications. So now if we refresh this example, this exposed metrics is now marked as green because it's now solved. And one nice thing is also with most of these challenges now, we also have these associated coding challenges. So it's not just like the hacking side of it, but we also have the coding side of it where we can basically just open this up. And what we're going to see here then is basically the actual vulnerable code running inside of juice shop. And then there are basically two types of challenges on the coding side to basically mark the vulnerable code. In this case, just basically marking which lines are vulnerable. And then in the second step to basically select from a selection of four different choices, basically which one is the correct fix that you could apply to make this vulnerability go away. Another really nice thing with juice shop is juice shop also has this companion guide book. So which is this basically this ebook, which you can also just take a look at online. It's completely free. So you can pay money for it to give the project a bit more budget, which as a guide and an explanation how to solve each challenge in juice shop and basically what's wrong with each of the challenges, which is a very awesome tool. If you're basically just going through juice shop and you might be a bit overwhelmed by the scoreboard and all of the challenges in there, you can basically just then reference this companion guide to just take a look and really learn on how these challenges can be solved and how you might be able to prevent them in your own applications. This is all cool now, but I now want to do the shift over to the second project. This is the one that I primarily want to show because basically juice shop is primarily intended as basically a single user application. So it's just meant to be run on a local machine and used by one user or maybe two users sitting at the same keyboard, but it's basically not meant to be shared across multiple people because it has this challenge tracking built into it. It has like a local SQLite database. It's just basically just not meant to be used by multiple people at a time. And this is a problem if you, for example, want to now run a training with 20 people because if you run a training with 20 people and most of them are developers, you're going to spend the first two or three hours of this training basically debugging NPM setups to get juice shop installed on everybody machine. And then somebody has like a crazy Docker proxy setup. So you can't also switch back to Docker if NPM doesn't work. It's just always a pain because you basically just spent the first hours of these training sessions basically just debugging people's laptops. And I hate debugging my laptop enough. I don't need to debug other people's laptops. So what we basically did is we started a site project to juice shop, which is this tool called multi juicer, which is now basically part of the official juicer project. So it's a sub project in the larger project. And what this multi juicer project is, is basically a platform to dynamically start up juice shop pots on a Kubernetes cluster and then expose them just to the network via one host name by having like a dedicated load balancer, which then basically gives every team their own juice shop instance and ensures that basically the teams can hack on their individual juice shop instances, but that they won't affect each other. There's also a short diagram here. I'm just going to zoom in a bit to make it a bit more readable. So basically it has, or this multi juicer consists of one primary component, which is this component called a juice balancer, which is basically a custom load balancer, like I said earlier, which is getting the traffic from the different teams and is then basically redirecting this traffic to the dedicated juice shop instances for the team. And the nice thing is, is basically because this multi juicer platform is basically directly built for Kubernetes, it's also able to spin up these juice shop instances on demand. So if a new team comes around and you basically don't have a juice shop instance for them yet, they can basically just register and what multi juicer will do is we're going to talk to the Kubernetes API to start up a new juice shop pod for them and then just going to wait until the pod is ready and then the team can just start hacking on the new pod. The installation for it is also really easy. So it's basically just multi juicers, just a hand chart. We recently switched from the HEM repo YAML to having the chart only in an OCI registry. So this is still looking kind of crazy, especially like with these GitHub package links. So this is basically just hand chart in this OCI registry. And what I would like to do now, especially just basically just run this once on my local machine here, then we can maybe just take a look on how this is working. So first, I'm just going to shut down this docker container so that I have this 3000 freed up because I'm going to need this in a minute. And then so basically right now, let me just make sure that I cleaned up earlier. Yep. Okay. Perfect. So what I'm just going to do is I'm just going to run the HEM install. I'm really hoping that the images are still cached on this cluster because the network is kind of slow. No offense to the network sponsors. Perfect. They're still cached. So everything is already up and running. That was really quick. So I'm now just going to port forward my port 3000 not to the juicer directly, but in this case to the juice balancer. Let me see if there's any history here. Yep. So if I now go back to my browser and open up port 3000, I'm not a juice shop anymore, but I'm now at multi juicer, which has this very straightforward UI, which just consists of a form field to ask, which asked me to put in the team name and I couldn't put basically, not quite everything in there, but just everything was just standard characters. So if I just put in the name cube con and click create team, what we're going to see if I'm switching back to the cluster view is that in the background, multi juicer already started up a new pot here or actually start up a new deployment with basically just the name team cube con juice shop instance. So it already started. The juice shop is also already running. So if I'm switching back to the browser here now, you can see now, okay, also test tells me that the instance is now ready and I can basically just start clicking on start hacking. And now I have this juice shop running here, but I didn't need to start it up locally. So I could just put this on my communities cluster at my company and basically just host all of these juice shop instances for all of the participants of the training so that the participants wouldn't have to do this themselves. Just as a way to make these trainings more straightforward, make this easier and just really safe on the on the starting time of the trainings by just providing it to them centrally. Yeah. So what we also have in multi juicer, so basically right now, we've primarily promoted this multi juicer tool inside of the security community. And what we found there is that the security community is often really lacking Kubernetes skills. So what we did was we put in some really detailed guides on how you can install them on different clusters because we just got really specific requests on how we can help them with like specific cloud providers and cases where they didn't even have a cluster to start with. So basically we have just really detailed guides for security teams with very little Kubernetes experience on how they could set it up. But as I said earlier, some multi users read just this relatively straightforward Helm chart. So if you're if you're trying to use it, I'm very confident that everybody here at KubeCon is able to just install it without much problem. So it's very easy to configure very easy to change the settings just with normal Helm things. And we also have this dedicated production nodes guide here because basically the the default configuration is primarily used for easy testing. But if you actually want to run a like a production level training, you will probably want to have more than one balancer instance just in case the first one goes down. And you will also want to make sure that like a couple of secrets are rotated because the because the default Helm values actually has a couple of I would say security problems in it because it has a couple of hard coded secrets because they are supposed to be rotated before you install it on production. It's not a huge issue but it's all detailed here in the guide basically on how you can easily rotate these secrets, which is basically just linked directly below the Helm install. So if you if you want to run it, I'm sure you will find this production nodes as well. Yeah, and basically this project has now been going for or this multi juicer project has been going for I think like since 2020. And I just learned that basically juicer and Kubernetes basically must have started the same year because juicer was also turning 10 this year. It's basically the same age. And the nice thing is that with multi juicer basically already being also a couple of years old, we now also have another project in the in the OS foundation, which is this. So this is more of a sideline here because I'm already finished with the multi juicer part. But if you're also interested in this like other security training environments, I can also really recommend this was wrong secrets project, which is more focused on like secret management best practices. And the nice thing is, is this wrong secrets environment also basically has a multi user platform, which is just based on multi juicer because they basically just fork the repo and then change some configurations for it. So it's basically also multi user compatible. So if you want to run a training more on the secrets management side, especially also a wasp tool for it, which you can just use to run these trainings. Also very cool for multi user trainings. Yeah. And this is basically already everything that I really wanted to show you. I think we still have quite a lot of time left. So if anybody has any questions or anything that we would like to take a look at together, definitely can do that. Nice. Thank you all for being here. And there's the mic coming to you. So while you were explaining this, I was thinking, you know, I could put that in my integrations environment. I could make that part of my annual training for my for my devs. And then I realized that my container and vulnerability scanner is probably going to find it or my static code analysis scanner is probably going to find it. I might not want to put on the integrations environment, but I would hope that your scanner is going to find it. Otherwise, you might want to take a look at another scanner. It's actually crazy because with the due shop project we've been getting, especially lately, we've been getting like a ton of spam per request where we just people are trying to integrate like different scanning tools in their pipelines. And I'm not quite sure if they are intentionally opening up per request because like 90% of the per request that we're getting are people just trying out random security tools. And I'm hoping accidentally opening up per request for them. In this shift, they're just blindly following some security training guides when they don't understand what a per request is, but it's getting quite annoying. So basically it's a tool which also often used by different security or by people trying out different security tools because it's very, very easy or very just a very good tool to basically just benchmark these tools if they are able to actually find things. But the PRs you're getting are people trying to patch the vulnerabilities or have you updated to a less vulnerable version? It doesn't seem like it's really following a pattern. I mean, most of them are basically just adding different CI integrations for different tools. Without a common basis, really just trying this out. Some people are just randomly changing text just to see things are getting triggered, I guess. I don't understand it. It just seems that a lot of people are trying things out there with tools. Any other question in the bank? So in a Juicer UI, Juicer, right? Yeah, Juicer. There was one section I saw that there is a way to fix it. So is that the fixing is how happening? I mean, do we commit in a code or something like that? Maybe we can just do one together just to make it more visual. So basically, the find it is just basically just marking the lines. This is not going to be interesting if I can actually fix it. So this is for the metrics thing. This was probably the point here with the six posts where we are basically mounting the shroud. So if I submit this, then we can basically just see this more easily. So basically now we've found the place where this is because here in this line, the metrics actually exposed. And with the fix, basically how this is working is that you have a bunch of different options here, a bunch usually three or four. But this is not basically patched directly into them. It's basically just if you are able to find it, but it doesn't change the running software. Okay. Thank you. Hey, so this is really interesting stuff. I'm really excited to hear about all of this and a little embarrassed. I'm hearing about some of it for the first time. I think it should be a little more well read, I guess. One thing I noticed that was kind of listed as a selling point is it says itself contained where additional dependencies are prepackaged or will be resolved and downloaded automatically. It doesn't seem to be updated all that often, which means that I think there's some supply chain problems with how some of this is done. So do you think there might be interest in putting together an OAS juice supply repo or something that looks at software supply chain issues? We definitely have like some supply and chainy types of things. We also have a bunch of outdated dependencies in here, which I can just tell you from a maintainer's perspective, it's hard enough to write secure software, but it's really hard to maintain intentionally insecure software, especially if you're depending on outdated packages, which just don't run on new operating systems or new Node.js versions. So basically have just a bunch of outdated packages in the project already. I think we also have a typo squatting vulnerability, basically where we're pulling in a package, which is just slightly misspelled from the original package. The vulnerability here is basically just to find or tell us which one it is because there's a way to basically take a look at the package list. So there's also a lot of vulnerabilities basically coming from the supply chain, but we don't really use this wording here yet because I think these challenges were actually in here before the entire supply chain naming really took off, but we might want to change this to make this clearer for users. Any other questions? Well, I joined a bit later, so I might be asking something you already answered, but how easy it is to create a new challenge as part of this, and is there like a community which is keeping on adding new challenges or not? It's a hard question because it really depends on the challenge that you want to integrate because it can be somewhat easy to extremely hard, depending on what the vulnerability is. Yeah. Well, a follow-up question to this would be, is there like an official guidance on how you set up like a new challenge for this? Any new challenge would have to come in as a new pull request, as a new feature, and we are always happy to hear of new challenge ideas via GitHub or through the chat channels basically listed from the GitHub repository. So if you have a challenge idea, the best thing like always would be to open up a new issue just to the basic view that we can discuss it if it's maybe too similar to the existing challenge, but we would definitely would like to hear of new challenge ideas. Okay, cool. I guess lingering on your previous answer, what do you need as a project to continue to develop further? What is your call to action? This is an interesting question. So on the due shop side, I mean, we have a couple of open issues, but these are mainly for actual like development focus things. So as we're here on KubeCon, I'm guessing the question is somewhat catered to like more of a deaf, obscene, cloud native kinds of help that we could need. And these kinds of things would rather be on the multi juicer side. But the thing is that basically most of basically due shop and multi juicer are relatively finished projects. I mean, there's obviously no such thing as a finished project or very few things as a finished project. But we don't have any extremely huge new features planned out. Especially on multi juicer, I would be interested on basically feedback or basically more ideas from the cloud native community on if there are different ways to basically make this balance a component that we have here easier and maybe integrate this with basically something more of a prebuilt proxy. Because basically right now this is basically a custom crafted proxy using a Node.js library, which is actually working surprisingly well. It can even handle WebSocket connections, though not super stably. So I would be interested in if anybody has like an extremely easy way to basically get this set up with more of a standard reverse proxy setup, which basically still has all of the qualities that we have with the current thing that we can basically dynamically redirect this traffic based on these teams, which is kind of hard to do. I tried to investigate this for quite a while, but then I basically just chickened out and basically just went with writing it myself. But if somebody has a really nice idea or knows on how to do this with a prebuilt proxy, I would be very interested to hear from it. All right, that's a quite extensive answer. Thank you very much. All right. Any last question, I would say? It does not appear so. So thank you all again for coming to this spontaneous talk. And thank you all for the awesome questions. I wasn't expecting this many questions, but it's really nice to see that so many people are interested. So thank you all and have a nice day. Bye.