Kubernetes Security: The State of the Union - a Virtual Panel

With about 12,000 attendees at KubeCon+CloudNativeCon 2019 at San Diego, Kubernetes security was featured in many of the day zero events, technical sessions, and hallway conversations.

As with any technology that is experiencing a rapid growth as Kuberbetes, there are particular areas that are more challenging than others, especially Kubernetes security. Although a lot of work has been done, it’s not a very well understood area. Besides education, there are other industry wide initiatives underway to address the gaps in implementation and understanding this area.

InfoQ caught up with experts in the field at Kubecon 2019 at San Diego (reaching out later to experts who were not able to attend the conference), Scott Coulton, Cloud Developer Advocate at Microsoft, Liz Rice, VP of Open Source engineering at Aqua Security, Gareth Rushgrove, Director of Product Management at Snyk, Maya Kaczorowski, Product Manager for Security and Privacy at Google Cloud, and Kirsten Newcomer, Senior Principal Product Manager at Red Hat, about the state of the union of Kubernetes security and the challenges that remain to be overcome.

Panelists talked about the growth of Kubernetes in general and how this has affected the activities and discussions around Kubernetes security. They discussed how Kubernetes may be misconstrued as insecure by default. However, there are simple config and Pod policy changes recommended by the panelists which make deployments more secure. They talk about the ramifications of the term DevSecOps and it’s associated methodologies and the effect it has had on Kubernetes security.

Further, panelists debated what Kubernetes security specifically entails besides scanning for vulnerabilities in container images and addressing some of the tools of the trade and best practices. They discussed the growth of platforms atop Kubernetes and how they are making an impact and posing some new challenges on Kubernetes security in general.

Finally, the panelists talked about some of the industry initiatives that will have a big impact and how as developers and architects it’s possible to participate in the community and make a difference going forward.

InfoQ: What were your primary takeaways from KubeCon 2019 in San Diego from a security perspective?

Coulton: Unfortunately, I missed KubeCon this year due to the bush fires we had locally here in Australia. Catching up on the content on Youtube, I was really impressed with the amount of security talks as the main topic this time. It’s really good to have the Kubernetes community taking container security as a first class citizen.

Rice: We’re seeing more end users attending KubeCon these days, and security concerns are front of mind for many enterprises — in fact I just learned that the CNCF 2019 end user survey shows security is second only to cultural change in the concerns that they have when moving to cloud native. At Aqua’s "day zero" event, KubeSec, an emerging theme was the organizational challenges that people face in implementing security for cloud native. We now have a group of people coming together in SIG Security specifically to address the challenges of making it easier to run applications securely in cloud native environments. There’s still lots of work to be done, but we’re making progress.

Rushgrove: I think my main takeaway was that security is just an expected part of the conversation for lots of attendees. It’s not a separate topic for a different audience. So yes, we had talks specifically about security in the ecosystem, including on the keynote stage, but security was also mentioned frequently in other talks too. However, I do think there is a need for more introductory security content. It’s often hard to find the right mix of pushing things forward on the technical side of things and helping new end users make the right choice today.

Kaczorowski: I cannot believe this was my sixth KubeCon! I continue to be surprised at how rapidly the community continues to grow, with this KubeCon still having a very large fraction of attendees who are newcomers. These are often developers who are tackling Kubernetes for the first time in their jobs and need to ramp up quickly. From a security point of view, this means introductory content to introduce non-security professionals to best practices from the get-go. From feedback in the hallways and at various sessions, it’s clear that content is still missing, and we need to work to better deliver it to end users.

Newcomer: I also missed KubeCon North America this time around. I’m struck by the expanded number of co-located events, a number of which focused on Kubernetes security. I consider it particularly important that security capabilities are built into solutions, making it as easy as possible for organizations to meet their security goals without having to rely on a large collection of point products that may or may not work well together. It’s terrific to see the Kubernetes community invest not only in traditional security evaluations, such as the open sourced Kubernetes security audit, but also in the full spectrum of capabilities that enhance security, including service mesh, api management, observability, and so much more.

InfoQ: How critical was the fact that the Kubernetes community missed out on building multi-tenancy into the platform from the ground up? Can you summarize the efforts to add multi-tenancy to the platform?

Coulton: This is a tricky question as multi-tenancy means different things to different people. I am going to fall back to the two definitions the good folks working on this issue in WG multi-tenancy use — soft and hard. I think soft multi-tenancy is between teams that should not see each other but are not considered hostile. If we want to go down the road of hard multi-tenancy where every tenant is considered hostile, we need to start looking at how we handle things like admission control and authentication through the kube api to make sure they are secure and multi-tenant aware.

Rice: Multi-tenancy has certainly been an important theme in the last few months, but it has different requirements in different environments. We see lots of end user companies building internal platforms for their development teams. Multi-tenancy in those environments is less about defending against malicious co-tenants, and more about making sure that one team can’t inadvertently affect another team’s applications. Many organizations have a core set of company-wide security policies that they want to enforce, but they want to allow teams or tenants some flexibility to enforce their own policies to meet risks appropriately.

Rushgrove: I see lots of organizations using Kubernetes in a multi-tenant way today. I also see lots of folks with different needs managing multiple clusters for individual tenants. The reality is multi-tenancy means different things to different users, and no one-size approach is going to solve this and provide a nice user interface. So I think I disagree with the question.

Kaczorowski: I wouldn’t look at it as "missed out" on — you could say the same for a lot of security features — but rather as a missed opportunity. Kubernetes has grown so quickly, and to cover so many use cases, it would have been impossible to consider all possible requirements when the project first launched.

Today, however, it’s clear that one of the most common ways of running Kubernetes in an enterprise is to have a central platform or infrastructure team managing multi-tenant clusters for individual development teams. In addition to the desire for billing controls, quota management, and other practicalities, what I’m seeing is a desire to ensure sufficient isolation and protection between workloads. One key control here is namespaces—what’s typically used to separate dev teams in a cluster—and there’s more in Kubernetes and related projects depending on these. Another key control is runtime class, that allows you to use a different sandboxed runtime, like gVisor, to protect untrusted code running in your cluster from affecting other workloads.

Newcomer: Red Hat built support for multitenancy into OpenShift from the start to support enterprise customers. And we've worked with the Kubernetes community to increase the native multitenancy support. Kubernetes has come a long way in capabilities available to support multi-tenancy: namespaces of course, resource quotas, RBAC, network policy for micro-segmentation and fine-grained control of pod-to-pod communication are key. I think Pod Security Policies are also key to securing a multi-tenant cluster. This is an area where the community has been working for some time, but more work remains. Pod identity is another important area for investment. I’d also like to see Kubernetes work with Linux user namespaces for additional isolation and protection against container escapes (see CVE-2019-11245). Of course, it’s important that these capabilities work well together; if it takes a bit of time to ensure that, it’s time well spent.

InfoQ: At Kubecon there was frequent mention that Kubernetes is insecure by default. Is this true? If so, how can this be addressed in existing deployments and how will it be addressed in the future?

Coulton: I think it is a lot better than it used to be, but there is still a way to go. I think we are getting better at educating end users about these security topics that they like pod security policies that need to be added to deployments. Projects like Open Policy Agent have lots of great examples we are checking to make sure we have the controls configured. If you are using a cluster from a cloud provider, they will look after a majority of these controls on the cluster side for you. From my point of view it comes down to education. There are some controls certain environments will need compared to others, so it’s all about giving the users the right education and tools so they can configure security to tailor their needs.

Rice: The defaults are a lot better than they used to be! For example, default RBAC settings no longer give admin access to everyone, and gone are the days when users routinely find that they have inadvertently set up a Kubernetes dashboard with admin powers exposed to the internet. However, there are settings that are less than secure by default, and different installation tools make their own choices about exactly what to turn on or off. There are plenty of tools out there including our own open source tools, kube-bench and kube-hunter, that can help people configure their setup more securely by detecting configuration issues and pen-testing their clusters. However, we need to continue to educate people not to blindly trust the defaults.

Rushgrove: If you view Kubernetes as a platform for building platforms, I think the defaults make sense. It’s the responsibility of the higher-level platform to bring those secure defaults. So distributions like OpenShift, or services like EKS, GKE, and AKS do this to some degree or other. But lots of people use Kubernetes and build their own platforms, and doing so today requires a fair amount of effort to understand the large surface area. I’m mainly concerned with per-workload security configuration. As responsibility for writing Kubernetes configuration is pushed out to developers, who really shouldn’t need to be Kubernetes experts, we start to see the problem with secure defaults. I think the issues we have today are mainly where user expectations are different from cluster administrators expectations.

Kaczorowski: Unfortunately, Kubernetes defaults are not always the best for security. For example, one gripe is that the seccomp Docker default is not enforced automatically in Kubernetes. Kubernetes has been built this way to make it really easy for users to get started — but not for their clusters to be secure from the get-go. We see that changing, with better options like the token review API being added for authorization; but, that doesn’t mean that we’ve yet removed or moved from the older options. Kubernetes is a community project, and we want to make sure that it works for most use cases, without breaking users.

Practically, what that means for security is further user education while we improve the defaults. For example, on Google Kubernetes Engine (GKE), we are continually changing and hardening the platform. We provide a hardening guide (g.co/gke/hardening) to help users take that next step to configure their clusters.

Newcomer: By and large, deploying a secured configuration of Kubernetes is something that can be done today. There’s a wealth of good guidance available and a fair number of tools that can provide automated assessments and configurations. Of course, there’s still room for improvement, and there’s a lot for end users to learn. One of the interesting areas of recent investment that has a role to play is Kubernetes operators. They provide a way to extend the Kubernetes API to address application-specific pre and/or post provisioning needs in a kube-native and automated way. The really cool thing is that you can use Kubernetes operators to manage Kubernetes itself — making it easier to deliver and automate secured deployments.

InfoQ: The term DevSecOps was also brought about in sessions and hallway conversations. Is this merely adding security to DevOps or something more than that? Are there new platforms emerging to support devsecops or the existing DevOps platforms are adapting to it?

Coulton: To me this term comes from pushing security checks and balances into your deployment pipeline. Before containers we used to pen test environments that looked like prod and run packages vulnerability checks on prod. Now with containers we can push that to the left and build it into our CI/CD pipelines. Which gives us quicker feedback loops on issues we find. It’s a mindshift change to adding security to the development release process, not a separate process that is done after the fact.

Rice: It’s a concept more than a formula, and there are many ways of implementing it from a process and organizational standpoint. Many existing DevOps platforms are adapting to offer security features or make it easier to embed 3rd party tools into a pipeline - many CI tools do that, and we’re seeing more container registries offering some kind of image scanning as a feature. There’s still a gap in spanning the entire process and embedding best practices by default, which companies like Aqua are striving to fill.

Rushgrove: Both of these terms are simply marketing (in a good way). They are banners under which conversations about how experts (whether in development, security, operations or the wide range of other areas needed to run systems at scale) can best work together. It’s best not to read too much into the etymology.

Kaczorowski: I don’t love the term "DevSecOps," primarily because the concern I hear from security engineers is that they can’t scale to and be integrated as part of every dev team. However, if you think about automating a lot of security checks, and implementing these continuously, and earlier in the development process — that’s what we mean, and that’s the goal with this effort. For DevOps platforms, it means tying into static analysis tools, getting feedback from container scanners and admission controllers, and being able to rebuild and redeploy an image based on that feedback, without slowing developers down.

Newcomer: I actually do love the term "DevSecOps." I understand that it’s frustrating for some folks who understand that DevOps was always intended to include security. But I appreciate how important it is to be explicit. And this is an area where containers provide an opportunity to improve security, both of the application and the process. Best practice is to never patch a running container; always rebuild and redeploy. To do this well and at speed, organizations need to take a step back and revisit their CI/CD pipelines. They need to be sure that they’re using automated unit and functional tests (which can be a big investment). And re-evaluating the CI/CD pipeline provides an opportunity to integrate automated security gates. I also agree that this is not just about tools — it’s also about culture and process. Ideally, this work is done in collaboration with an organization’s security team, creating an opportunity for developers to learn more about security and for security teams to learn more about the development process. After all, there’s a shortage of security professionals — let’s work together and spread the wealth.

InfoQ: It seems there is a lot of focus on scanning container images and registries for vulnerabilities. In addition to this, what else matters for container and Kubernetes security? What are some of the areas of significant concerns today?

Coulton: Scanning is definitely important but there are things that are equally important, like signing your images once they have passed your scan. Another important concern when running a Kubernetes cluster in the cloud is what permissions the cluster has to create resources, like load balancers, etc. If an attacker got access to your cluster, what other resources could they create? Then secondly, if a pod needs to connect to a cloud resource, what identity is that pod using? How is that identity granted to the pod? If the identity becomes compromised, how quickly can you revoke it? These are all concerns that are equally important.

Rice: Scanning for vulnerabilities solves one problem (an important one), and it’s one of the easiest tools to embed into a DevOps pipeline but it’s hardly sufficient for securing cloud native environments. In addition to mitigating that risk, the infrastructure itself needs to be secured — K8s itself (especially the API server), nodes and the OS they run, and cloud accounts and adjacent services. All of these need to be properly configured with RBAC, authentication, and basically applying the principle of least privilege across the board (to both people and things). Additionally, preventative measures such as scanning and hardening should be complemented by runtime protection capabilities, so you can detect when something goes wrong and, ideally, block it automatically before it can happen — human response is just too slow.

Rushgrove: I think when we talk about container security, we’re often missing the main end user problem — securing the applications. Container images are just a useful package for moving those applications around. I think we often start with conversations about scanning container registries because of ease of access. Most organizations have a limited number of registries, and container registries have APIs, so scanning assets for vulnerabilities makes sense because it’s low cost. This isn’t really specific to containers, we’ve (hopefully) been doing the same before with our application packages. But this is really just a part of thinking about the full software supply chain, and importantly how we fix those vulnerabilities when we find them. I think configuration is also becoming a larger part of securing applications. You might have a perfectly secure container image, but if you incorrectly configure it to serve private data to unauthenticated users, then you still have a problem.

Kaczorowski: I want to point out that beyond scanning, software supply chain is still a critical topic. Due to the nature of code and container images these days, it’s unrealistic to think that most developers actually know the origin of the containers they are deploying.

Moving before that, however, the area where we’re seeing the most interest is container runtime security, that is, detecting and responding to attacks on containers. Attacks are still pretty rare, as attackers are more likely to go for weak applications that happen to be in containers, than the containers specifically.

Newcomer: One of the challenges we continue to have is helping security teams who understand how to secure traditional infrastructure and applications but don’t really understand the new world of containers and Kubernetes. The concept of vulnerability management, however, translates much more easily than, say, adapting network security policies for a clustered set of hosts running a software defined network. I think that’s why we see so much focus there. But, to be really effective, security needs to be built into the full Kubernetes stack, including the host operating system, the container platform, the software defined network, ingress and egress control, as well as management of the cluster lifecycle. In fact, there are many security capabilities and solutions available, and as the features in Kubernetes continue to expand, the challenge becomes how to ensure that all the capabilities available to secure the cluster work well together.

InfoQ: Service Mesh and Microservices are putting more strain on distributed systems security and Kubernetes security. Can you comment on the specific challenges and initiatives to address them?

Coulton: I think service mesh is definitely a hot topic at the moment and can offer some really good features, especially around identity with integrations to SPIFFE. With anything in life, nothing is free and meshes can add extra complexity, but things like mTLS out of the box are a no brainer to implement. This is a space that really excites me and I think although meshes have been around for awhile, it’s still early days. So my advice would be to watch this space, all the major mesh players have different project goals, which means they will prioritize features differently, not to say one or the other is not thinking about security. You, as the end user, will have to pick a mesh, implement its security controls, and have other tooling as well as mesh.

Rice: As a whole, service meshes can improve security — they can be used to implement mTLS between services, zero trust networking based on the service identities within an application, etc. But they aren’t a panacea. For example, if your zero-trust segmentation is somehow broken or misconfigured, you won’t know about it, let alone be able to block it. You’ll want to use security tooling alongside a service mesh to provide other capabilities and layer your defences.

Rushgrove: I think we’re only at the start of seeing how Service Mesh will be adopted and how it will impact security more generally. My guess is we’ll see some of the service mesh tools take a strong focus on security features to make the value proposition clearer. If that happens then the information available from the mesh will be hugely useful data for a variety of external security tools too.

Newcomer: Although Service Mesh seems to add complexity, it’s actually making important business logic more visible and can enhance security. Previously, developers needed to build the logic for circuit breaking, encrypting communication between services, etc., into their code. Now, these capabilities can be made available as part of the Kubernetes platform, saving developers work and accelerating the delivery of microservices. Service mesh also provides more visibility for microservice interactions to the operations team, especially when observability and visualization of east-west cluster traffic are included as part of the service mesh solution. We felt it was critical to include these capabilities as part of Red Hat's OpenShift Service Mesh.

InfoQ: There are a variety of other platforms which generally depend on tooling built on Kubernetes, like Helm and Istio. From a security perspective, how is security affected by these additional tools or technologies?

Coulton: I look at this the same way as adding packages to an OS which can cause your attack vector to increase. You should know what is running on your cluster, make sure it’s got the least privilege it needs to run, make sure you are using RBAC, and last but not least, make sure you have some sort of runtime protection/isolation of your pods, like seccomp.

Rice: Every complex system has vulnerabilities, and every component or tool you add increases the attack surface of the system as a whole. I could think of fun things to do like poisoning Helm charts to take over a cluster. The answer is of course to apply the same rules on these tools as we demand from Kubernetes itself. RBAC and authentication for example, which Helm 3 now supports.

Rushgrove: If you’re adding new tools to your stack, then hopefully it’s because they solve a real user problem. If that’s the case, it’s less about comparing, let’s say Helm, with not adding Helm. It’s comparing it with whatever hand-rolled solution you’d otherwise implement. By everyone collectively investing in open source projects, vs. everyone hand rolling our own solutions, we can benefit from many eyes on the specific security properties of a specific tool.

Kaczorowski: Increasing adoption of cloud-native technologies means there’s both more things to secure, and hopefully, it’s going to keep getting easier to secure them! What I mean is that although tools like Helm open up the attack surface, they also make it easier to secure Kubernetes, as the community narrows in on a handful of ways to perform common tasks. Tools like Istio are meant specifically to help address cloud-native security and are necessary in a cloud-native security model.

Newcomer: It’s important to consider the attack surface of all the solutions you deploy. Even some security tools can actually increase your attack surface. Of course, there is no such thing as 100% security, so you need to weigh the risk vs. benefits. You also need to assess the full stack — if you’re adding a solution to Kubernetes, is your Kubernetes cluster configured in a way that mitigates as much as possible any additional risk that might be added? Are you using automation to ensure that both the cluster and any add-ons are configured as intended and are you auditing those configurations to ensure they are maintained?

InfoQ: Security and compliance is obviously a shared responsibility. However, many enterprises consist of security teams that act like a "one-stop shop" vis-a-vis Security. How do developers and other groups play a role and how critical is it to address some of the security issues earlier in the software development lifecycle?

Coulton: My thoughts are that security is everyone’s responsibility — it’s more about helping educate your security team on containers because they are not going to be as close to the technology as you. A great example I have used in the past is comparing how we create and trust custom yum packages with signing, etc. to the secure supply chain we built with containers. So when they are accountable for the audit, they feel comfortable with the solution. Working to push security to the left with containers has been made easier on the technology side, but we need to bring people on the journey with us as domain experts.

Rice: We shouldn’t confuse responsibility with accountability. Responsibility can be shared, but security teams will ultimately be held accountable. While there’s still a huge knowledge gap within the infosec community around cloud native, that gap is slowly closing. That said, developers must play a productive role in the implementation of security. Developers should never be the ones setting policy or performing risk assessments, but they can certainly do more to deliver secure code, automated processes, and infrastructure-as-code.

Rushgrove: I’m not sure everyone would agree that security and compliance is a shared responsibility. If you check how different groups in your organization are incentivised, this often isn’t actually the case. I think it can be dangerous to assume without understanding how organizations are structured. I think everyone should care about security however, and in my experience that is normally the case. Often what’s missing is education. Developers may care about security but not know exactly which trade offs to make, or which are the real problems. The confusion regarding the differences between security and compliance is probably a good example. It’s here where security teams can be particularly useful and help build bridges between the different groups.

Kaczorowski: Ideally, by "shifting left" with security, organizations can address security issues as early in the development and deployment lifecycle as possible, when addressing issues is less costly. These days, however, it’s more common that security is the last step — a gatekeeper to implementation. Bringing in security teams earlier, for example, as early as the design process, can save time later, but not all security teams are staffed to handle these requests or have the necessary expertise. Security should seek to automate as many requirements as possible, and developers should seek to include these requirements in their development as soon as they can.

Newcomer: Shifting security left and sharing responsibility for security throughout the team is critical. The earlier in the process that potential security holes can be found, the less expensive they are to fix. Also, there simply aren’t enough security professionals to go around. So, again, it’s important to find ways for formerly siloed teams to collaborate. This means that security teams need to learn more about how applications are developed and the tools developers work with, and developers need to learn more about how to deliver code that is as secure as possible. The teams I’ve worked with who have done this (stepped into each other’s worlds), have been very successful. But, it often requires buy-in from the top. One way to tackle this is to start small. Identify a candidate project and create a cross-functional team; given them support; allow them to iterate. Once they’ve figured it out, give them time to help others learn the pattern.

InfoQ: There is no such thing as a "silver bullet" when it comes to software in general and security in particular. However, can you name one indispensable security tool or suite in the container practitioners arsenal?

Coulton: This is not going to come as a shock to anyone but just patch both your pods/containers and cluster — that will go a long way with very little specialized domain knowledge.

Rice: I still think a vulnerability scanner, like Trivy, should be in everyone’s arsenal. Vulnerabilities are the low hanging fruit of cloud native security. They are relatively easy to detect early, and the risk they present is very real. I know it’s a cliche by now, but having known vulnerabilities in your applications is like leaving your house windows wide open. Anyone can come in without any special skills. It’s an easy win.

Rushgrove: A well oiled CI/CD pipeline. Good patch management and change management in general are probably the main tools for improving security quickly. If you can’t make changes quickly and safely, then identifying them won’t get you very far. The gap between the high-end and everyone else when it comes to deployment is huge. Continuous deployment is still some way off for lots of organizations, in some cases because of well intentioned security policies from previous technology generations.

Kaczorowski: It’s boring, but patch management. If there’s nothing more you do but keep your software up to date, you’ll already have a huge impact on your security exposure.

This is even easier with containers — you don’t patch live containers, you patch the images in your container registry. The fully patched container image can be rolled out or rolled back as one unit, using your code rollout process, complete with monitoring, canarying, and testing.

Newcomer: Rather than name a tool, I’d like to name a characteristic — a willingness to learn. Technology changes quickly; teams need to be willing to constantly assess their goals, their business needs, their risk profile and tolerance, their processes and available tools (in-use and new to the market), and be ready to make adjustments based on those ongoing assessments.

InfoQ: Final Question. Summing up, where do you see the Kubernetes community headed and how important is security in this roadmap. Any other random thoughts about Kubernetes, KubeCon, and Kubernetes Security that developers and architects should care about?

Coulton: I think security is at the front of everyone’s mind. CNCF have SIG security, Kubernetes itself has SIG security and SIG-Auth, but also WG policy that looks at security as well. If you are interested in helping out in one of those groups you definitely should.

Rice: There is a great community coming together in the CNCF’s SIG Security group. I’d recommend it to anyone interested in security who wants to get more involved in the cloud native community.

Rushgrove: I’d like to see more outreach to the broader security community. The CNCF special interest groups for security is great, as well as the Kubernetes-specific groups, but there is always a risk of just talking to ourselves. I’d like to see more outreach, both taking some of the challenges to the much larger security community, and also bringing some of those folks back to this community to join in.

Kaczorowski: It’s great to see continued interest in Kubernetes security! It would be even greater for those who are passionate about the topic, have their own requirements, or want to contribute, to get involved in SIG-Auth. All skillsets are needed!

Newcomer: One of the great things about Kubernetes, is how dynamic the community is. There are a wide variety of new security focused solutions emerging regularly, providing all of us the opportunity to re-think traditional approaches to IT security. Security principles remain the same, but how we implement IT security continues to evolve. It’s a great time to get involved.

Conclusion

The panelists agreed that growth of Kubernetes and the spotlight that it being shined on Kubernetes security has created an opportunity not only for technical work in the area, but also to educate users (developers, architects, DevOps audiences) about the same, and create industry wide initiatives to address some of the gaps. While it’s possible to harden Kubernetes deployments today, it will need changes to default configurations. Panelists were divided on whether they liked the term DevSecOps but were in favor of methodologies being adopted in CI/CD pipelines to make deployments more secure.

They talked about the motivation behind "shifting left" in the software development lifecycle and how to put some of the onus on developers to be able to address security issues sooner than later. Finally, they touched upon some tools for the trade and best practices, the roadmap, and urged developer and architect audiences to get involved.

About the Interviewees

Scott Coulton is a Principal Cloud Advocate and Docker captain with 10 years of experience as a software engineer in the managed services and hosting space. He has extensive experience in architecture and rolling out systems and network solutions for national and multinational companies with a wide variety of technologies, including Azure, Kubernetes, Puppet, Docker, Cisco, VMware, Microsoft, and Linux. His design strengths are in cloud computing, automation, and security space.

Liz Rice is VP Open Source Engineering at Aqua Security, where she leads the team working on container-related open source projects including Trivy, kube-bench and kube-hunter. She was Co-Chair of the CNCF’s KubeCon + CloudNativeCon conferences in 2018, and is currently the chair of the CNCF’s Technical Oversight Committee. She has a wealth of software development, team, and product management experience from working on network protocols and distributed systems, and in digital technology sectors such as VOD, music, and VoIP. When not writing code, or talking about it, Rice loves riding bikes in places with better weather than her native London, and competing in virtual races on Zwift.

Gareth Rushgrove is a Director of Product at Snyk, working remotely from Cambridge, UK, helping to build interesting tools for people to better secure infrastructure and applications. He has previously worked for the UK Government Digital Service focused on infrastructure, operations and information security, as well as at Puppet and Docker. When not working, he can be found curating the DevOps Weekly newsletter, hiking or reading a good book.

Maya Kaczorowski is a Product Manager in Security & Privacy at Google, focused on container security. She previously worked on encryption at rest and encryption key management. Prior to Google, she was an Engagement Manager at McKinsey & Company, working in IT security for large enterprises, and completed her Master’s in mathematics focusing on cryptography and game theory. Outside of work, Kaczorowski is passionate about ice cream, puzzling, running, and reading nonfiction.

Kirsten Newcomer is a Senior Principal Product Manager at Red Hat She works closely with many security professionals across the Red Hat portfolio of enterprise-ready open source offerings. Newcomer is a diversified software management professional with 15+ years of experience in application development and infrastructure solutions. Her career has spanned successful roles at Black Duck Software, IBM Software Group, Rational Software and BMC Software. Newcomer was an early contributor to the Linux Foundation's Software Package Data Exchange (SPDX) specification, which provides a set of standards for communicating the components, licenses, and copyrights associated with software. In her free time, Newcomer serves as Vice Chair of the Board of Trustees for Marlboro College in Marlboro, VT and enjoys hiking and dancing with her husband.