 Okay, so this is slightly weird. I feel like I'm talking into space. All right, so I'm Liz Rice. I look after open source engineering at Aqua Security and I am the author of a book about container security and I am currently the chair of the Technical Oversight Committee at the CNCF. And despite my extensive technical qualifications, it took me a little while to figure out how to get this session to work, but I think it's, I believe it's working now, so that's good. All right. Okay, so now I can find the Q&A button and my impression is that if you have questions you'd like me to answer, you can put them into that Q&A session. All right, I hope everyone is coping with this platform better than I seem to be. I think I'm okay now, all right. Okay, so I have a question. What's the best thing I can do to make my containers secure? This is the kind of thing that I could talk about all day. So there are lots of different stages to the container lifecycle and there are things that you can do to improve security all the way through the lifecycle. But I would say if you only had to do one thing, I would recommend scanning container images for known vulnerabilities. There are plenty of vulnerability scanners available out there. You know, some of them are commercial products, but there are several free and open source options. Open source container image scanners include Trivif on my team, Ankor have a solution, there's Clare. So there are a few different options and if you use a container image scanner you will pick up when your images contain known serious vulnerabilities. So that prevents you from deploying something that is known to be very insecure. So because it's so simple to build something like that into your CI CD pipeline, that is high bang per buck, it's very easy to do and it makes your deployment much more likely to be secure. So I hope that answered the question. I could talk about some other ideas for things that you can do to secure your containers. Not running as root, so I'm about to do a talk. I actually prerecorded the talk, but very shortly my talk will be going out about rootless containers and most of the time as you'll see in that talk by default people run containers as root. That's the kind of default setting if you like and root inside the container is the same as root on the host. So if there were to be a container escape if somehow a container got compromised and someone was able to escape from that container, perhaps there's a vulnerability in the container runtime itself, we've seen a few of those. If some like to happen, I don't wanna scare anybody but if it does happen, if you're running as root inside the container, you escape the container, you are root on the host, this is a bad, that's a bad situation. So that's kind of game over for your security on that host. So the fact that you're running as root is something you wanna avoid. Rootless containers is one option. Configuring a user. So in your Docker file, setting a user ID or in your YAML as you're configuring your pods so you can define a user ID that you want to run under, make it non-root, that will be more secure. What do I love about working in open source? That's a pretty cool question. So I think the thing that I like best about open source is the feeling that you're interacting with people from kind of all around the planet, people that you've never met, get some value, something out of something that you've built and then they get in touch or they contribute to your project and they give you the benefit of their wisdom on their time. And that's super rewarding, I think. The fact that you interact with people and you feel like you've given them something or they've given you something and it's, everybody is raising each other's game. I think that's probably the thing I like best about open source. Plus everybody always seems to be so friendly and welcoming. I'm missing meeting people in real life at events and meetups and so on. So I'm looking forward to getting back to that when things get a bit more back to normal. Ah, very nice question here. Complimenting me on my keynote yesterday, thank you. Looks like I work on a lot of great things, any advice for attaining work and life balance. I've got to say that's probably something I wouldn't consider myself brilliant at because I do have a bit of a tendency to commit to so many things. But I do carve out time. I spend quite a lot of time doing sport, doing training and I kind of set aside time and try very hard not to let anything encroach on that. My husband's very good at making sure I eat regularly, which is probably a very good thing. Yeah, I think maybe setting boundaries around the time. I try very hard to avoid making a regular commitment to evening meetings because I think it would be all too easy to fall into a world where your day stretches from eight in the morning till 11 at night and I don't think that is a long-term path to success. So I'm pretty protective of my out-of-hours time unless there's a really strong reason to do something out of hours. Technical question again, okay, are there some containers that have to run as routes? And there's an example of needing to open a low numbered port. So yeah, there's a lot of software that has been containerized that was originally written in the era before containers designed to run on a host. And normally, if you want to open a low numbered ports, you need privileges to do that and those privileges come if you run as a route. So you would typically run a web server, for example, or load balancer. You would typically run that as a privileged user because you needed the privileges on the host to open the low numbered port. If you're running inside a container, that is less of an issue because you have port mapping. Your code can be running, thinking it's talking on port 80, but that could be mapped to any port outside of the container. So that's no longer a good reason to have to run as route. So although a lot of software expects that it needs to run as route, it can usually be reconfigured to run on a different port. And there are some collections of container images. For example, bitnami did a lot of work to create versions of well-known popular images that can run as non-route software. So although you may find a lot of official images that do expect to run as route, there's usually a way that with a bit of work, you can find a way to run as a non-route user. Okay, along with AQUA, you work closely with the CNCF. What types of things do you work on with them? Yeah, so mostly the work that I'm doing with the CNCF right now is with the Technical Oversight Committee where we are with a group that sets the technical direction for the foundation. In practice, a lot of what we're doing is assessing projects that want to join. And in practice, in order to assess projects or help them move up the maturity scale from sandbox to incubation to graduation, then we actually spend quite a lot of time thinking about the criteria of what it means to be a graduated project and trying to figure out how we can scale those assessments and judgments. We have a lot of projects that want to join, which is fantastic, but we're a group of volunteers with day jobs as well. So we recently, well over the last year and a bit, set up special interest groups within the CNCF that can help the TOC. So we can ask these special interest groups in say storage or security to help us with some of the technical assessment in particular projects. And that helps us kind of share the workload, which is really helpful. It's helping run an open source project different, easier, harder than leading inside a big company like Aqua. So Aqua's not that big, we're about 300 people. So I mean, it's not tiny, but it's not like an enormous corporation. I think it's very different. I think if you're inside a company, a company will have particular commercial goals typically and defining those goals kind of top down. I think that's usually the way that most companies operate, sort of have a top level goal and then that rolls out into goals and KPIs for teams and individuals. I think in open source, while you do still have collective goals, it's less, it's much more collaborative and much more kind of, you know, nobody's really gonna get into a huge amount of trouble. It's more about trying to find cooperative ways that where everybody gets something out of the contributions that they're making. So I like to think that internally in a company that's also my management style, that I'm not kind of cracking some kind of whip and trying to get people to do that. I hope that, you know, if we have a group of rational people and we all talk about what we want to achieve, we will come up with a sensible way to achieve that together with our skills. So in that sense, I like to think that you can manage in a commercial organization in a similar way to what you do in open source. But at the end of the day, it is slightly different in that you have these kind of, the different incentives and the different goals that you're ultimately trying to achieve. They can be complimentary though. And I'm lucky that I work for a company that allows me to spend time on open source and values the work that we're doing. And we do it in a way that we, you know, is complimentary to what we're doing as a commercial organization. How did I get involved in open source? So kind of almost by accident, I think. I actually remember years and years and years ago when I first came across open source being quite dismissive about the whole idea because I thought, well, how on earth can a team of volunteers possibly do a kind of real professional job? And, you know, why would they bother doing things like testing? And, you know, surely they're just banging out code and they don't really care what happens. Of course, that's not true. You know, over time, I realized that that's not true. But that perception years ago put me off for a while. And but the way I got involved was really working with startups. I spent a few years working in and co-founding startups that mostly failed, but, you know, learned a lot along the way. And in a startup, you're constantly trying to show people what you're doing. And I learned that I really liked kind of presenting things. And my sort of engineer inside me wanted to show people technical things. And I realized that, you know, there was this huge community of people who were interested in having these sort of technical conversations that you could show them a thing and they'd go, that's really interesting. Let me tell you about what I've done that's related. And that kind of sucked me in. So it was more through the kind of community events presenting that I got involved in the world of open source. And that made me take the whole the way that open source projects work much more seriously. And I got much more interested in it and ended up making that kind of the focus of what I do as a job. Can I talk about Kubernetes security posture management? So, yeah, this is really it relates to I think it's gone. I have a, I can't remember what they call it, a term called cloud security posture management, which is the idea that when you set up your cloud infrastructure, there are some best practices you really should be applying, like putting permissions on your storage so that not everybody on the whole internet can just go and look at your data, making sure that you have multi-factor authentication setups to secure access to your console. And CSPM cloud security posture management is about tools that check that you're applying those sort of sensible security practices. So KSPM is applying that similar thinking to Kubernetes and saying what are the sensible settings you should apply, not just to your Kubernetes configuration, but also to the way that you're running your containerized workloads in Kubernetes. How can you configure them in a way that's secure? And KSPM tooling is really assessing your YAML files, your configuration and saying, is it applying these security best practices? What do I enjoy working on the most? I'm a bit torn there between, I mean, I really, really, really like creating content explanations, typically talks, and getting the sense that somebody has understood something because of the way I explained it. And when that lands, when somebody comes and tells me that they figured out how containers work, they understood it because they saw one of my talks. I think that is the thing that I find most rewarding. It's definitely that kind of sense of achievement when you feel like you've done something and other people appreciate it. In projects that you've worked on, do you have any what not to do lessons? Oh, how long have we got? I think so the first thing I would say when I first got involved in open source was worrying too much about perfection and thinking that if I put code out, people would look at it and find all the flaws and think that I was a terrible engineer. And in practice, anything you can publish, people don't really pour over it in very great detail, but also, everybody who's ever written any code knows what it's like to improve it and that it never really feels completely finished and that you're always wanting to make it better. So I think getting over that idea that it's not good enough, it is good enough, ship it, get it out into the world and see whether or not, how people react to it, that would be, so the what not to do would be don't hide your code and try and polish it too much before you show people, get feedback early. I think another thing that we're learning about a lot in our own projects in Accra is trying to figure out the way to be helpful and welcoming to community members. There's been a lot of great talks about that today and other events in the past where we talk a lot about community and making projects accessible for people to help out and get involved. And actually, the reality day to day is, oh my God, there's so many things coming in on GitHub and how can we answer them all and how can we make sure people aren't frustrated because we haven't responded to them in a timely fashion. I think that balance, making sure that we're doing work and also responding to other people's work in a timely fashion, I feel like that's something that I'm still trying to get to grips with what the right balance is there. Okay, I think we are pretty much through all the questions. Thank you very much everyone who asked some questions. Appreciate that. If you are still online, the next thing that I would love your feedback on is my talk on rootness containers that's coming up at quarter past the hour, so in three minutes. So I might go and take three minutes to, since I don't see any last questions coming in, I will take those last three minutes to go and grab myself a cup of tea and hopefully answer some questions while my talk is streaming out. So thank you very much.