POPULARITY
11 episodes with container security
12 episodes with container security
7 episodes with container security
3 episodes with container security
7 episodes with container security
3 episodes with container security
3 episodes with container security
2 episodes with container security
2 episodes with container security
In this episode of The New Stack Makers, recorded at KubeCon + CloudNativeCon Europe, Alex Williams speaks with Ville Aikas, Chainguard founder and early Kubernetes contributor. They reflect on the evolution of container security, particularly how early assumptions—like trusting that users would validate container images—proved problematic. Aikas recalls the lack of secure defaults, such as allowing containers to run as root, stemming from the team's internal Google perspective, which led to unrealistic expectations about external security practices.The Kubernetes community has since made strides with governance policies, secure defaults, and standard practices like avoiding long-lived credentials and supporting federated authentication. Aikas founded Chainguard to address the need for trusted, minimal, and verifiable container images—offering zero-CVE images, transparent toolchains, and full SBOMs. This security-first philosophy now extends to virtual machines and Java dependencies via Chainguard Libraries.The discussion also highlights the rising concerns around AI/ML security in Kubernetes, including complex model dependencies, GPU integrations, and potential attack vectors—prompting Chainguard's move toward locked-down AI images.Learn more from The New Stack about Container Security and AIChainguard Takes Aim At Vulnerable Java LibrariesClean Container Images: A Supply Chain Security RevolutionRevolutionizing Offensive Security: A New Era With Agentic AI Join our community of newsletter subscribers to stay on top of the news and at the top of your game.
Are you struggling to implement robust container security at scale without creating friction with your development teams? In this episode, host Ashish Rajan sits down with Cailyn Edwards, Co-Chair of Kubernetes SIG Security and Senior Security Engineer, for a masterclass in practical container security. This episode was recorded LIVE at KubeCon EU, London 2025.In this episode, you'll learn about:Automating Security Effectively: Moving beyond basic vulnerability scanning to implement comprehensive automationBridging the Security-Developer Gap: Strategies for educating developers, building trust, fostering collaboration, and understanding developer use cases instead of just imposing rules.The "Shift Down" Philosophy: Why simply "Shifting Left" isn't enough, and how security teams can proactively provide secure foundations, essentially "Shifting Down."Leveraging Open Source Tools: Practical discussion around tools like Trivy, Kubeaudit, Dependabot, RenovateBot, TruffleHog, Kube-bench, OPA, and more.The Power of Immutable Infrastructure: Exploring the benefits of using minimal, immutable images to drastically reduce patching efforts and enhance security posture.Understanding Real Risks: Discussing the dangers lurking in default configurations and easily exposed APIs/ports in container environments.Getting Leadership Buy-In: The importance of aligning security initiatives with business goals and securing support from leadership.Guest Socials: Cailyn's LinkedinPodcast Twitter - @CloudSecPod If you want to watch videos of this LIVE STREAMED episode and past episodes - Check out our other Cloud Security Social Channels:-Cloud Security Podcast- Youtube- Cloud Security Newsletter - Cloud Security BootCampIf you are interested in AI Cybersecurity, you can check out our sister podcast - AI Cybersecurity PodcastQuestions asked:(00:00) Intro: Container Security at Scale(01:56) Meet Cailyn Edwards: Kubernetes SIG Security Co-Chair(03:34) Why Container Security Matters: Risks & Exposures Explained(06:21) Automating Container Security: From Scans to Admission Controls(12:19) Essential Container Security Tools (Trivy, OPA, Chainguard & More)(19:35) Overcoming DevSecOps Challenges: Working with Developers(21:31) Proactive Security: Shifting Down, Not Just Left(25:24) Fun Questions with CailynResources spoken about during the interview:Cailyn's talk at KubeCon EU 2025
Security isn't an afterthought-it's the foundation of modern infrastructure. In this episode, Dan Walsh, Senior Distinguished Engineer at Red Hat, dives deep into the critical role of SELinux in container security and how it thwarts real-world vulnerabilities. We also explore Dan's latest project, Ramalama, which is bridging the gap between Al models and container technology, making Al enterprise-ready. If you've ever wondered how to balance security, usability, and innovation, this episode is must listen! Links:LinkedIn: https://www.linkedin.com/in/dan-walsh-a8729b2/Podman: https://podman.ioBuildah: https://buildah.ioCRI-O: https://cri-o.ioSkopeo: https://github.com/containers/skopeoSELinux Project Documentation: https://selinuxproject.orgSELinux Coloring Book (Explains SELinux visually): https://github.com/SELinuxProject/selinux-coloring-bookRamalama GitHub Repository: https://github.com/containers/ramalamaIntroduction to Ramalama (Blog post, if available): Add a link if Daniel has written one or plans to."Podman in Action" by Daniel Walsh (Free PDF from Red Hat): https://developers.redhat.com/podman-in-actionPurchase "Podman in Action" on Amazon: https://www.amazon.com/Podman-Action-Daniel-J-Walsh/dp/1617299427You can support this podcast on the creators page. Make sure to subscribe and follow Alexa's Input Twitter account to get notified when a new podcast episode comes out.
Docker container vulnerability analysis involves identifying and mitigating security risks within container images. This is done to ensure that containerized applications can be securely deployed. Vulnerability analysis can often be time intensive, which has motivated the use of AI and ML to accelerate the process. NVIDIA Blueprints are reference workflows for agentic and generative AI The post NVIDIA's Agentic AI for Container Security with Amanda Saunders and Allan Enemark appeared first on Software Engineering Daily.
Docker container vulnerability analysis involves identifying and mitigating security risks within container images. This is done to ensure that containerized applications can be securely deployed. Vulnerability analysis can often be time intensive, which has motivated the use of AI and ML to accelerate the process. NVIDIA Blueprints are reference workflows for agentic and generative AI The post NVIDIA's Agentic AI for Container Security with Amanda Saunders and Allan Enemark appeared first on Software Engineering Daily.
Cross-over hosts: Kaslin Fields, co-host at Kubernetes Podcast Abdel Sghiouar, co-host at Kubernetes Podcast Guest: Michele Chubirka, Cloud Security Advocate, Google Cloud Topics: How would you approach answering the question ”what is more secure, container or a virtual machine (VM)?” Could you elaborate on the real-world implications of this for security, and perhaps provide some examples of when one might be a more suitable choice than the other? While containers boast a smaller attack surface (what about the orchestrator though?), VMs present a full operating system. How should organizations weigh these factors against each other? The speed of patching and updates is a clear advantage of containers. How significant is this in the context of today's rapidly evolving threat landscape? Are there any strategies organizations can employ to mitigate the slower update cycles associated with VMs? Both containers and VMs can be susceptible to misconfigurations, but container orchestration systems introduce another layer of complexity. How can organizations address this complexity and minimize the risk of misconfigurations leading to security vulnerabilities? What about combining containers and VMs. Can you provide some concrete examples of how this might be implemented? What benefits can organizations expect from such an approach, and what challenges might they face? How do you envision the security landscape for containers and VMs evolving in the coming years? Are there any emerging trends or technologies that could significantly impact the way we approach security for these two technologies? Resources: Container Security, with Michele Chubrika (the same episode - with extras! - at our peer podcast, “Kubernetes Podcast from Google”) EP105 Security Architect View: Cloud Migration Successes, Failures and Lessons EP54 Container Security: The Past or The Future? DORA 2024 report Container Security: It's All About the Supply Chain - Michele Chubirka Software composition analysis (SCA) DevSecOps Decisioning Principles Kubernetes CIS Benchmark Cloud-Native Consumption Principles State of WebAssembly outside the Browser - Abdel Sghiouar Why Perfect Compliance Is the Enemy of Good Kubernetes Security - Michele Chubirka - KubeCon NA 2024
This episode is special. We collaborated with the folks behind the Cloud Security Podcast from Google, Anton Chuvakin(LinkedIn)and Tim Peacock, to bring you a joint episode. We had the pleasure to jointly interview Michelle Chubirka, a Cloud Security Developer Advocate. We talked about VM and Container security, debunked some myths about isolation, attack surfaces, immutability of containers, and more. Do you have something cool to share? Some questions? Let us know: - web: kubernetespodcast.com - mail: kubernetespodcast@google.com - twitter: @kubernetespod News of the week Nvidia NIM on GKE Kubernetes Steering Committee Election Results for 2024 The schedule for KubeCon and CloudNativeCon India Diagrid Catalyst Beta Dapr on the Kubernetes Podcast with Salaboy Links from the interview Cloud Security Podcast Anton Chuvakin Tim Peacock Michelle Chubirka Dora report Container Security: It's All About the Supply Chain - Michele Chubirka Software composition analysis (SCA) DevSecOps Decisioning Principles Kubernetes CIS Benchmark Cloud-Native Consumption Principles State of WebAssembly outside the Browser - Abdel Sghiouar Why Perfect Compliance Is the Enemy of Good Kubernetes Security - Michele Chubirka - KubeCon NA 2024 Links from the post-interview chat Cloud Code Skaffold Introduction to Distributed ML Workloads with Ray on Kubernetes - Mofi Rahman & Abdel Sghiouar - KubeCon NA 2024
In this episode of the Kubernetes Bytes podcast, Ryan and Bhavin talk to Ofir Cohen, CTO of Container Security at Wiz. The discussion focuses on the challenges with the cloud native security ecosystem, how organizations can improve their security posture, how developers can do less with more, and how Wiz helps organizations avoid security incidents.Check out our website at https://kubernetesbytes.com/ Cloud Native News: https://blog.kubecost.com/blog/2.4-release-highlights/ https://www.theregister.com/2024/09/26/critical_nvidia_bug_container_escape https://techcrunch.com/2024/09/18/edera-is-building-a-better-kubernetes-and-ai-security-solution-from-the-ground-up/ https://www.cncf.io/blog/2024/10/01/karmada-v1-11-version-released-new-cross-cluster-rolling-upgrade-capability-for-workload/ https://github.com/atlassian/escalator/?tab=readme-ov-file https://cybenari.com/2024/08/whats-the-worst-place-to-leave-your-secrets/ https://thehackernews.com/2024/10/new-cryptojacking-attack-targets-docker.html Show links: https://www.wiz.io/customers https://www.wiz.io/blog https://peach.wiz.io https://www.linkedin.com/in/cohen-ofir/ Timestamps: 00:01:43 Cloud Native News 00:12:56 Interview with Ofir 00:56:58 Key takeaways
Software supply chain attacks exploit interdependencies within software ecosystems. Security in the supply chain is a growing issue, and is particularly important for companies that rely on large numbers of open source dependencies. Chainguard was founded in 2021 and offers tools and secure container images to improve the security of the software supply chain. Matt The post Container Security with Matt Moore appeared first on Software Engineering Daily.
Software supply chain attacks exploit interdependencies within software ecosystems. Security in the supply chain is a growing issue, and is particularly important for companies that rely on large numbers of open source dependencies. Chainguard was founded in 2021 and offers tools and secure container images to improve the security of the software supply chain. Matt The post Container Security with Matt Moore appeared first on Software Engineering Daily.
Looking for the best storage or shipping container rental pricing in Los Angeles, CA? If security and affordability both top your list of priorities, Conexwest lists the best options available. Learn more at https://www.conexwest.com/blog/best-lock-shipping-container-security-conexwest?srsltid=AfmBOoqs9qTMKN-pfs43aq2-yrx3xUeOBtWgNc9yqXhEaPlo-72enVEN Conexwest City: Fontana Address: 14774 Jurupa Ave Website: https://www.conexwest.com Phone: +1-855-878-5233 Email: quote@conexwest.com
Not sure which type of lock is best for protecting the goods inside your shipping container? Then have a read of Conexwest's (888-759-0596) new guide outlining the best locks for shipping container security. Go to https://www.conexwest.com/blog/best-lock-shipping-container-security-conexwest to find out more. Conexwest City: Fontana Address: 14774 Jurupa Ave Website: https://www.conexwest.com Phone: +1-855-878-5233 Email: quote@conexwest.com
Check out this interview from the ASW Vault, hand picked by main host Mike Shema! This segment was originally published on April 4, 2023. Following on from her successful title "Container Security", Liz has recently authored "Learning eBPF", published by O'Reilly. eBPF is a revolutionary kernel technology that is enabling a whole new generation of infrastructure tools for networking, observability, and security. Let's explore eBPF and understand its value for security, and how it's used to secure network connectivity in the Cilium project, and for runtime security observability and enforcement in Cilium's sub-project, Tetragon. Segment Resources: Download "Learning eBPF": https://isovalent.com/learning-ebpf Buy "Learning eBPF" from Amazon: https://www.amazon.com/Learning-eBPF-Programming-Observability-Networking/dp/1098135121 Cilium project: https://cilium.io Tetragon project: https://tetragon.cilium.io/ Show Notes: https://securityweekly.com/vault-asw-11
Check out this interview from the ASW Vault, hand picked by main host Mike Shema! This segment was originally published on April 4, 2023. Following on from her successful title "Container Security", Liz has recently authored "Learning eBPF", published by O'Reilly. eBPF is a revolutionary kernel technology that is enabling a whole new generation of infrastructure tools for networking, observability, and security. Let's explore eBPF and understand its value for security, and how it's used to secure network connectivity in the Cilium project, and for runtime security observability and enforcement in Cilium's sub-project, Tetragon. Segment Resources: Download "Learning eBPF": https://isovalent.com/learning-ebpf Buy "Learning eBPF" from Amazon: https://www.amazon.com/Learning-eBPF-Programming-Observability-Networking/dp/1098135121 Cilium project: https://cilium.io Tetragon project: https://tetragon.cilium.io/ Show Notes: https://securityweekly.com/vault-asw-11
Check out this interview from the ASW Vault, hand picked by main host Mike Shema! This segment was originally published on April 4, 2023. Following on from her successful title "Container Security", Liz has recently authored "Learning eBPF", published by O'Reilly. eBPF is a revolutionary kernel technology that is enabling a whole new generation of infrastructure tools for networking, observability, and security. Let's explore eBPF and understand its value for security, and how it's used to secure network connectivity in the Cilium project, and for runtime security observability and enforcement in Cilium's sub-project, Tetragon. Segment Resources: Download "Learning eBPF": https://isovalent.com/learning-ebpf Buy "Learning eBPF" from Amazon: https://www.amazon.com/Learning-eBPF-Programming-Observability-Networking/dp/1098135121 Cilium project: https://cilium.io Tetragon project: https://tetragon.cilium.io/ Show Notes: https://securityweekly.com/vault-asw-11
Check out this interview from the ASW Vault, hand picked by main host Mike Shema! This segment was originally published on April 4, 2023. Following on from her successful title "Container Security", Liz has recently authored "Learning eBPF", published by O'Reilly. eBPF is a revolutionary kernel technology that is enabling a whole new generation of infrastructure tools for networking, observability, and security. Let's explore eBPF and understand its value for security, and how it's used to secure network connectivity in the Cilium project, and for runtime security observability and enforcement in Cilium's sub-project, Tetragon. Segment Resources: Download "Learning eBPF": https://isovalent.com/learning-ebpf Buy "Learning eBPF" from Amazon: https://www.amazon.com/Learning-eBPF-Programming-Observability-Networking/dp/1098135121 Cilium project: https://cilium.io Tetragon project: https://tetragon.cilium.io/ Show Notes: https://securityweekly.com/vault-asw-11
Get the latest Patch Tuesday releases, mitigation tips, and learn about custom automations (aka Automox Worklets) that can help you with CVE remediations.
How are modern cloud-native environments changing the way we handle security? Liz Rice, Chief Open Source Officer at Isovalent, explains why traditional IP-based network policies are becoming outdated and how game-changers like Cilium and eBPF, which leverage Kubernetes identities, offer more effective and readable policies. We also discuss the role of community-driven projects under the CNCF, and she shares tips for creating strong, future-proof solutions. What challenges should we expect next? Tune in to find out!Liz Rice is Chief Open Source Officer with eBPF specialists Isovalent, creators of the Cilium cloud native networking, security and observability project. She is the author of Container Security, and Learning eBPF, both published by O'Reilly, and she sits on the CNCF Governing Board, and on the Board of OpenUK. She was Chair of the CNCF's Technical Oversight Committee in 2019-2022, and Co-Chair of KubeCon + CloudNativeCon in 2018.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, Liz loves riding bikes in places with better weather than her native London, competing in virtual races on Zwift, and making music under the pseudonym Insider Nine.
Praveen is a security enthusiast with 14+ years of experience in application security who loves to break complexity bias. His works include developing frameworks and tools for Container Security, automated Penetration Testing, SAAS Security, Automated Secure Code Analysis, Asset Discovery and Recon and also have worked on Security against Analytics Mitigated threats against Analytics through extensive Research and solution suggestions on browser security and rate limiting.Praveen and his team at PhonePe developed Mantis, an open-source security framework to automate the workflow of asset discovery, reconnaissance, and scanning using a combination of open-source and custom tools.For more SecTools podcast episodes, visit https://infoseccampus.com
Stephen Augustus, Head of Open Source at Cisco, and Liz Rice, Chief Open Source Officer at Isovalent, discuss Cisco's acquisition of Isovalent, which has closed since recording, bringing together two teams with long-standing expertise in open source cloud native technologies, observability, and security. The two share their excitement about working together, emphasizing the alignment of Isovalent with Cisco's security division and the potential enhancements this acquisition brings to open source projects like Cilium and eBPF. They explore the implications for the open source community, and the continuous investment and development in these projects under Cisco's umbrella. We discuss the ways this merger could innovate security practices, enhance infrastructure observability, and leverage AI for more intelligent networking solutions. 00:00 Welcome and Introduction 00:22 Cisco's Acquisition of Isovalent 00:53 The Excitement and Potential of the Acquisition 02:14 Strategic Alignment and Future Vision 04:03 Open Source Commitment and Community Impact 06:53 The Road Ahead: Integration and Innovation 19:49 Exploring AI and Future Technologies at Cisco 26:03 Reflections and Closing Thoughts Resources: Cilium, eBPF and Beyond | Open at Intel (podbean.com) The Art of Open Source: A Conversation with Stephen Augustus | Open at Intel (podbean.com) Guests: Liz Rice is Chief Open Source Officer with eBPF specialists Isovalent, creators of the Cilium cloud native networking, security and observability project. She was Chair of the CNCF's Technical Oversight Committee in 2019-2022, and Co-Chair of KubeCon + CloudNativeCon in 2018. She is also the author of Container Security, published by O'Reilly. 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, Liz loves riding bikes in places with better weather than her native London, competing in virtual races on Zwift, and making music under the pseudonym Insider Nine. Stephen Augustus is a Black engineering director and leader in open source communities. He is the Head of Open Source at Cisco, working within the Strategy, Incubation, & Applications (SIA) organization. For Kubernetes, he has co-founded transformational elements of the project, including the KEP (Kubernetes Enhancements Proposal) process, the Release Engineering subproject, and Working Group Naming. Stephen has also previously served as a chair for both SIG PM and SIG Azure. He continues his work in Kubernetes as a Steering Committee member and a Chair for SIG Release. Across the wider LF (Linux Foundation) ecosystem, Stephen has the pleasure of serving as a member of the OpenSSF Governing Board and the OpenAPI Initiative Business Governing Board. Previously, he was a TODO Group Steering Committee member, a CNCF (Cloud Native Computing Foundation) TAG Contributor Strategy Chair, and one of the Program Chairs for KubeCon / CloudNativeCon, the cloud native community's flagship conference. He is a maintainer for the Scorecard and Dex projects, and a prolific contributor to CNCF projects, amongst the top 40 (as of writing) code/content committers, all-time. In 2020, Stephen co-founded the Inclusive Naming Initiative, a cross-industry group dedicated to helping projects and companies make consistent, responsible choices to remove harmful language across codebases, standards, and documentation. He has previously held positions at VMware (via Heptio), Red Hat, and CoreOS. Stephen is based in New York City.
Diesmal widmen sich Volkmar Kellermann und Moritz Meid gemeinsam mit den Experten Tobias Gerhardt von Aqua Security und Jan Walther vom "Focus On Linux" Podcast dem komplexen Thema der Cloud- und Container-Sicherheit, live von der KubeCon in Paris. Im Mittelpunkt stehen dabei die aktuellen Entwicklungen und Herausforderungen im Bereich der Sicherheit von Public Clouds und On-Premise-Systemen. Außerdem diskutieren sie neue Absicherungsmöglichkeiten für Z Mainframes durch Aqua sowie das Scannen von Container-Images in sicheren Sandbox-Umgebungen. Nicht zuletzt werfen sie einen Blick darauf, wie moderne KI-Technologien im Sicherheitskontext unterstützen können. Taucht mit uns ein in die Welt der Cloud- und Container-Sicherheit und erfahrt mehr über die neuesten Trends und Lösungsansätze!
In this article, we will explore some of the major challenges associated with container security and discuss strategies to address them.
This week on Dark Rhiino Security's Security Confidential podcast, Host Manoj Tandon talks to Chandra Pandey. Chandra is an expert with 20+ years of experience in the cybersecurity and networking domain. Chandra has been associated with multiple disruptive innovations for cybersecurity and networking domains. Current innovations at Seceon is already used by 6000+ customers around the globe and make industry's best cybersecurity affordable to organizations of any size and eliminate the need for customers to buy 15+ products like SIEM, SOAR, NBAD, UEBA, MDR, Cloud Security, Container Security, IDS etc. 00:00 Introduction00:16 Our Guest06:57 The Culture at Seceon09:32 The culture one comes from or the culture that one finds oneself in, What's more important?11:23 Transitioning from a technical engineer to a business leader12:45 Adapting to changes in the industry13:34 How to get the most out of Ai21:46 Will we ever be able to get rid of the human in the SOC and have the SIEM be automated by AI?23:40 Why develop a SIEM?27:35 Motivation from Chandra ---------------------------------------------------------------------- To learn more about Chandra visit Seceon.com To learn more about Dark Rhiino Security visit https://www.darkrhiinosecurity.com ---------------------------------------------------------------------- SOCIAL MEDIA: Stay connected with us on our social media pages where we'll give you snippets, alerts for new podcasts, and even behind the scenes of our studio! Instagram: @securityconfidential and @Darkrhiinosecurity Facebook: @Dark-Rhiino-Security-Inc Twitter: @darkrhiinosec LinkedIn: @dark-rhiino-security Youtube: @DarkRhiinoSecurity
Episode SummaryIn this special episode, our guest host, Liran Tal, interviews Snyk's Staff Security Researcher, Rory McNamara, about newly discovered high-impact container breakout vulnerabilities. Liran and Rory go deep into the vulnerabilities and cover everything you need to know, how the vulnerabilities were discovered, and much more.Show NotesIn this informative episode of The Secure Developer, guest host Liran Tal chats with Snyk security researcher Rory McNamara about his ground-breaking discoveries related to Docker vulnerabilities. McNamara's diligent investigations have spotlighted significant container breakout weaknesses, prompting a deep-dive exploration of the complexities of Docker's security scene.Refreshingly candid about the intricacies involved in tracking down these vulnerabilities, McNamara shares the detective-like processes he uses to trace the connections between key components and functionalities. As they discuss the eye-opening potential for exploitation, Rory highlights how using strace helped him decode the problematic underbelly of Docker.Listening to this episode opens up a world of understanding about software supply chain security and the wider implications of these emerging vulnerabilities. Ideal for both security leaders wanting to stay on the cutting edge and developers interested in the nitty-gritty, this conversation not only reveals the problems but also offers solutions. McNamara drives home the importance of timely updates, adopting the principle of least privilege, and layering security measures for optimal protection. This is a must-listen for anyone wanting to deepen their understanding of today's vital security challenges.LinksLeaky Vessels Blog PostDockerKubernetesOWASP Top 10FirecrackerSnyk - The Developer Security CompanyFollow UsOur WebsiteOur LinkedIn
Based on the podcast transcript, here's a suggested YouTube description: ---
In this podcast, Isovalent's Liz Rice discusses her involvement with several open source projects, such as the Cilium project and the eBPF platform. With the graduation of Cilium in the CNCF, Liz explains its networking and security capabilities and how it benefits the cloud-native ecosystem. She also dives into eBPF and discusses the implications of AI. The talk concludes with an exploration about open source communities, recommendations regarding emerging trends in the open source world, and Liz's anticipation for the future of Cilium and the impact of eBPF. 00:00 Introduction and Guest Background 01:10 Understanding Cilium and its Role in Networking 02:15 Exploring the Origins and Impact of eBPF 04:21 Insights into the eBPF Summit and Community Events 08:00 The Role of Open Source in Technology Development 12:40 The Intersection of AI and Open Source 18:21 Future Developments in Cilium and Open Source 21:02 Conclusion and Final Thoughts Guest: Liz Rice is Chief Open Source Officer with eBPF specialists Isovalent, creators of the Cilium cloud native networking, security and observability project. She was Chair of the CNCF's Technical Oversight Committee in 2019-2022, and Co-Chair of KubeCon + CloudNativeCon in 2018. She is also the author of Container Security, published by O'Reilly. 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, Liz loves riding bikes in places with better weather than her native London, competing in virtual races on Zwift, and making music under the pseudonym Insider Nine.
In the ever-evolving landscape of cloud-native computing, where applications are developed and deployed at lightning speed, it is critical to ensure the security and integrity of digital assets. This is where container security comes into play, offering robust tools and practices to safeguard the containerized applications, infrastructure, and the entire cloud ecosystem. What is a Container? Containers are lightweight units that package an application along with all its dependencies, including code, runtime, libraries, and configurations. They provide a consistent and efficient environment for running applications across diverse operating systems and infrastructures. However, containers do not have inherent security systems, so they introduce new attack surfaces that can pose risks to organizations. View More: What is Container Security in the Cloud?
Auf den Container Days trafen wir Denis Maligin von Sysdig. Wir führten ein Gespräch mit ihm über die Bedeutung der Container-Sicherheit und die zu berücksichtigenden Aspekte bei der Umsetzung. Dabei gewährte uns Denis Einblicke in die typischen Vorgehensweisen und Herausforderungen bei der umfassenden Implementierung von Sicherheitsprozessen im Cloud-Native-Bereich.
Liz Rice, Chief Open Source Officer at Isovalent, joins Corey on Screaming in the Cloud to discuss the release of her newest book, Learning eBPF, and the exciting possibilities that come with eBPF technology. Liz explains what got her so excited about eBPF technology, and what it was like to write a book while also holding a full-time job. Corey and Liz also explore the learning curve that comes with kernel programming, and Liz illustrates why it's so important to be able to explain complex technologies in simple terminology. About LizLiz Rice is Chief Open Source Officer with eBPF specialists Isovalent, creators of the Cilium cloud native networking, security and observability project. She sits on the CNCF Governing Board, and on the Board of OpenUK. She was Chair of the CNCF's Technical Oversight Committee in 2019-2022, and Co-Chair of KubeCon + CloudNativeCon in 2018. She is also the author of Container Security, and Learning eBPF, both published by O'Reilly.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, Liz loves riding bikes in places with better weather than her native London, competing in virtual races on Zwift, and making music under the pseudonym Insider Nine.Links Referenced: Isovalent: https://isovalent.com/ Learning eBPF: https://www.amazon.com/Learning-eBPF-Programming-Observability-Networking/dp/1098135121 Container Security: https://www.amazon.com/Container-Security-Fundamental-Containerized-Applications/dp/1492056707/ GitHub for Learning eBPF: https://github.com/lizRice/learning-eBPF TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. Our returning guest today is Liz Rice, who remains the Chief Open Source Officer with Isovalent. But Liz, thank you for returning, suspiciously closely timed to when you have a book coming out. Welcome back.Liz: [laugh]. Thanks so much for having me. Yeah, I've just—I've only had the physical copy of the book in my hands for less than a week. It's called Learning eBPF. I mean, obviously, I'm very excited.Corey: It's an O'Reilly book; it has some form of honeybee on the front of it as best I can tell.Liz: Yeah, I was really pleased about that. Because eBPF has a bee as its logo, so getting a [early 00:01:17] honeybee as the O'Reilly animal on the front cover of the book was pretty pleasing, yeah.Corey: Now, this is your second O'Reilly book, is it not?Liz: It's my second full book. So, I'd previously written a book on Container Security. And I've done a few short reports for them as well. But this is the second, you know, full-on, you can buy it on Amazon kind of book, yeah.Corey: My business partner wrote Practical Monitoring for O'Reilly and that was such an experience that he got entirely out of observability as a field and ran running to AWS bills as a result. So, my question for you is, why would anyone do that more than once?Liz: [laugh]. I really like explaining things. And I had a really good reaction to the Container Security book. I think already, by the time I was writing that book, I was kind of interested in eBPF. And we should probably talk about what that is, but I'll come to that in a moment.Yeah, so I've been really interested in eBPF, for quite a while and I wanted to be able to do the same thing in terms of explaining it to people. A book gives you a lot more opportunity to go into more detail and show people examples and get them kind of hands-on than you can do in their, you know, 40-minute conference talk. So, I wanted to do that. I will say I have written myself a note to never do a full-size book while I have a full-time job because it's a lot [laugh].Corey: You do have a full-time job and then some. As we mentioned, you're the Chief Open Source Officer over at Isovalent, you are on the CNCF governing board, you're on the board of OpenUK, and you've done a lot of other stuff in the open-source community as well. So, I have to ask, taking all of that together, are you just allergic to things that make money? I mean, writing the book as well on top of that. I'm told you never do it for the money piece; it's always about the love of it. But it seems like, on some level, you're taking it to an almost ludicrous level.Liz: Yeah, I mean, I do get paid for my day job. So, there is that [laugh]. But so, yeah—Corey: I feel like that's the only way to really write a book is, in turn, to wind up only to just do it for—what someone else is paying you to for doing it, viewing it as a marketing exercise. It pays dividends, but those dividends don't, in my experience from what I've heard from everyone say, pay off as of royalties on book payments.Liz: Yeah, I mean, it's certainly, you know, not a bad thing to have that income stream, but it certainly wouldn't make you—you know, I'm not going to retire tomorrow on the royalty stream unless this podcast has loads and loads of people to buy the book [laugh].Corey: Exactly. And I'm always a fan of having such [unintelligible 00:03:58]. I will order it while we're on the call right now having this conversation because I believe in supporting the things that we want to see more of in the world. So, explain to me a little bit about what it is. Whatever you talking about learning X in a title, I find that that's often going to be much more approachable than arcane nonsense deep-dive things.One of the O'Reilly books that changed my understanding was Linux Kernel Internals, or Understanding the Linux Kernel. Understanding was kind of a heavy lift at that point because it got very deep very quickly, but I absolutely came away understanding what was going on a lot more effectively, even though I was so slow I needed a tow rope on some of it. When you have a book that started with learning, though, I imagined it assumes starting at zero with, “What's eBPF?” Is that directionally correct, or does it assume that you know a lot of things you don't?Liz: Yeah, that's absolutely right. I mean, I think eBPF is one of these technologies that is starting to be, particularly in the cloud-native world, you know, it comes up; it's quite a hot technology. What it actually is, so it's an acronym, right? EBPF. That acronym is almost meaningless now.So, it stands for extended Berkeley Packet Filter. But I feel like it does so much more than filtering, we might as well forget that altogether. And it's just become a term, a name in its own right if you like. And what it really does is it lets you run custom programs in the kernel so you can change the way that the kernel behaves, dynamically. And that is… it's a superpower. It's enabled all sorts of really cool things that we can do with that superpower.Corey: I just pre-ordered it as a paperback on Amazon and it shows me that it is now number one new release in Linux Networking and Systems Administration, so you're welcome. I'm sure it was me that put it over the top.Liz: Wonderful. Thank you very much. Yeah [laugh].Corey: Of course, of course. Writing a book is one of those things that I've always wanted to do, but never had the patience to sit there and do it or I thought I wasn't prolific enough, but over the holidays, this past year, my wife and business partner and a few friends all chipped in to have all of the tweets that I'd sent bound into a series of leather volumes. Apparently, I've tweeted over a million words. And… yeah, oh, so I have to write a book 280 characters at a time, mostly from my phone. I should tweet less was really the takeaway that I took from a lot of that.But that wasn't edited, that wasn't with an overall theme or a narrative flow the way that an actual book is. It just feels like a term paper on steroids. And I hated term papers. Love reading; not one to write it.Liz: I don't know whether this should make it into the podcast, but it reminded me of something that happened to my brother-in-law, who's an artist. And he put a piece of video on YouTube. And for unknowable reasons if you mistyped YouTube, and you spelt it, U-T-U-B-E, the page that you would end up at from Google search was a YouTube video and it was in fact, my brother-in-law's video. And people weren't expecting to see this kind of art movie about matches burning. And he just had the worst comment—like, people were so mean in the comments. And he had millions of views because people were hitting this page by accident, and he ended up—Corey: And he made the cardinal sin of never read the comments. Never break that rule. As soon as you do that, it doesn't go well. I do read the comments on various podcast platforms on this show because I always tell people to insulted all they want, just make sure you leave a five-star review.Liz: Well, he ended up publishing a book with these comments, like, one comment per page, and most of them are not safe for public consumption comments, and he just called it Feedback. It was quite something [laugh].Corey: On some level, it feels like O'Reilly books are a little insulated from the general population when it comes to terrible nonsense comments, just because they tend to be a little bit more expensive than the typical novel you'll see in an airport bookstore, and again, even though it is approachable, Learning eBPF isn't exactly the sort of title that gets people to think that, “Ooh, this is going to be a heck of a thriller slash page-turner with a plot.” “Well, I found the protagonist unrelatable,” is not sort of the thing you're going to wind up seeing in the comments because people thought it was going to be something different.Liz: I know. One day, I'm going to have to write a technical book that is also a murder mystery. I think that would be, you know, quite an achievement. But yeah, I mean, it's definitely aimed at people who have already come across the term, want to know more, and particularly if you're the kind of person who doesn't want to just have a hand-wavy explanation that involves boxes and diagrams, but if, like me, you kind of want to feel the code, and you want to see how things work and you want to work through examples, then that's the kind of person who might—I hope—enjoy working through the book and end up with a possible mental model of how eBPF works, even though it's essentially kernel programming.Corey: So, I keep seeing eBPF in an increasing number of areas, a bunch of observability tools, a bunch of security tools all tend to tie into it. And I've seen people do interesting things as far as cost analysis with it. The problem that I run into is that I'm not able to wind up deploying it universally, just because when I'm going into a client engagement, I am there in a purely advisory sense, given that I'm biasing these days for both SaaS companies and large banks, that latter category is likely going to have some problems if I say, “Oh, just take this thing and go ahead and deploy it to your entire fleet.” If they don't have a problem with that, I have a problem with their entire business security posture. So, I don't get to be particularly prescriptive as far as what to do with it.But if I were running my own environment, it is pretty clear by now that I would have explored this in some significant depth. Do you find that it tends to be something that is used primarily in microservices environments? Does it effectively require Kubernetes to become useful on day one? What is the onboard path where people would sit back and say, “Ah, this problem I'm having, eBPF sounds like the solution.”Liz: So, when we write tools that are typically going to be some sort of infrastructure, observability, security, networking tools, if we're writing them using eBPF, we're instrumenting the kernel. And the kernel gets involved every time our application wants to do anything interesting because whenever it wants to read or write to a file, or send receive network messages, or write something to the screen, or allocate memory, or all of these things, the kernel has to be involved. And we can use eBPF to instrument those events and do interesting things. And the kernel doesn't care whether those processes are running in containers, under Kubernetes, just running directly on the host; all of those things are visible to eBPF.So, in one sense, doesn't matter. But one of the reasons why I think we're seeing eBPF-based tools really take off in cloud-native is that you can, by applying some programming, you can link events that happened in the kernel to specific containers in specific pods in whatever namespace and, you know, get the relationship between an event and the Kubernetes objects that are involved in that event. And then that enables a whole lot of really interesting observability or security tools and it enables us to understand how network packets are flowing between different Kubernetes objects and so on. So, it's really having this vantage point in the kernel where we can see everything and we didn't have to change those applications in any way to be able to use eBPF to instrument them.Corey: When I see the stories about eBPF, it seems like it's focused primarily on networking and flow control. That's where I'm seeing it from a security standpoint, that's where I'm seeing it from cost allocation aspect. Because, frankly, out of the box, from a cloud provider's perspective, Kubernetes looks like a single-tenant application with a really weird behavioral pattern, and some of that crosstalk gets very expensive. Is there a better way than either using eBPF and/or VPC flow logs to figure out what's talking to what in the Kubernetes ecosystem, or is BPF really your first port of call?Liz: So, I'm coming from a position of perspective of working for the company that created the Cilium networking project. And one of the reasons why I think Cilium is really powerful is because it has this visibility—it's got a component called Hubble—that allows you to see exactly how packets are flowing between these different Kubernetes identities. So, in a Kubernetes environment, there's not a lot of point having network flows that talk about IP addresses and ports when what you really want to know is, what's the Kubernetes namespace, what's the application? Defining things in terms of IP addresses makes no sense when they're just being refreshed and renewed every time you change pods. So yeah, Kubernetes changes the requirements on networking visibility and on firewalling as well, on network policy, and that, I think, is you don't have to use eBPF to create those tools, but eBPF is a really powerful and efficient platform for implementing those tools, as we see in Cilium.Corey: The only competitor I found to it that gives a reasonable explanation of why random things are transferring multiple petabytes between each other in the middle of the night has been oral tradition, where I'm talking to people who've been around there for a while. It's, “So, I'm seeing this weird traffic pattern at these times a day. Any idea what that might be?” And someone will usually perk up and say, “Oh, is it—” whatever job that they're doing. Great. That gives me a direction to go in.But especially in this era of layoffs and as environments exist for longer and longer, you have to turn into a bit of a data center archaeologist. That remains insufficient, on some level. And some level, I'm annoyed with trying to understand or needing to use tooling like this that is honestly this powerful and this customizable, and yes, on some level, this complex in order to get access to that information in a meaningful sense. But on the other, I'm glad that that option is at least there for a lot of workloads.Liz: Yeah. I think, you know, that speaks to the power of this new generation of tooling. And the same kind of applies to security forensics, as well, where you might have an enormous stream of events, but unless you can tie those events back to specific Kubernetes identities, which you can use eBPF-based tooling to do, then how do you—the forensics job of tying back where did that event come from, what was the container that was compromised, it becomes really, really difficult. And eBPF tools—like Cilium has a sub-project called Tetragon that is really good at this kind of tying events back to the Kubernetes pod or whether we want to know what node it was running on what namespace or whatever. That's really useful forensic information.Corey: Talk to me a little bit about how broadly applicable it is. Because from my understanding from our last conversation, when you were on the show a year or so ago, if memory serves, one of the powerful aspects of it was very similar to what I've seen some of Brendan Gregg's nonsense doing in his kind of various talks where you can effectively write custom programming on the fly and it'll tell you exactly what it is that you need. Is this something that can be instrument once and then effectively use it for basically anything, [OTEL 00:16:11]-style, or instead, does it need to be effectively custom configured every time you want to get a different aspect of information out of it?Liz: It can be both of those things.Corey: “It depends.” My least favorite but probably the most accurate answer to hear.Liz: [laugh]. But I think Brendan did a really great—he's done many talks talking about how powerful BPF is and built lots of specific tools, but then he's also been involved with Bpftrace, which is kind of like a language for—a high-level language for saying what it is that you want BPF to trace out for you. So, a little bit like, I don't know, awk but for events, you know? It's a scripting language. So, you can have this flexibility.And with something like Bpftrace, you don't have to get into the weeds yourself and do kernel programming, you know, in eBPF programs. But also there's gainful employment to be had for people who are interested in that eBPF kernel programming because, you know, I think there's just going to be a whole range of more tools to come, you know>? I think we're, you know, we're seeing some really powerful tools with Cilium and Pixie and [Parker 00:17:27] and Kepler and many other tools and projects that are using eBPF. But I think there's also a whole load of more to come as people think about different ways they can apply eBPF and instrument different parts of an overall system.Corey: We're doing this over audio only, but behind me on my wall is one of my least favorite gifts ever to have been received by anyone. Mike, my business partner, got me a thousand-piece puzzle of the Kubernetes container landscape where—Liz: [laugh].Corey: This diagram is psychotic and awful and it looks like a joke, except it's not. And building that puzzle was maddening—obviously—but beyond that, it was a real primer in just how vast the entire container slash Kubernetes slash CNCF landscape really is. So, looking at this, I found that the only reaction that was appropriate was a sense of overwhelmed awe slash frustration, I guess. It's one of those areas where I spend a lot of time focusing on drinking from the AWS firehose because they have a lot of products and services because their product strategy is apparently, “Yes,” and they're updating these things in a pretty consistent cadence. Mostly. And even that feels like it's multiple full-time jobs shoved into one.There are hundreds of companies behind these things and all of them are in areas that are incredibly complex and difficult to go diving into. EBPF is incredibly powerful, I would say ridiculously so, but it's also fiendishly complex, at least shoulder-surfing behind people who know what they're doing with it has been breathtaking, on some level. How do people find themselves in a situation where doing a BPF deep dive make sense for them?Liz: Oh, that's a great question. So, first of all, I'm thinking is there an AWS Jigsaw as well, like the CNCF landscape Jigsaw? There should be. And how many pieces would it have? [It would be very cool 00:19:28].Corey: No, because I think the CNCF at one point hired a graphic designer and it's unclear that AWS has done such a thing because their icons for services are, to be generous here, not great. People have flashcards that they've built for is what services does logo represent? Haven't a clue, in almost every case because I don't care in almost every case. But yeah, I've toyed with the idea of doing it. It's just not something that I'd ever want to have my name attached to it, unfortunately. But yeah, I want someone to do it and someone else to build it.Liz: Yes. Yeah, it would need to refresh every, like, five minutes, though, as they roll out a new service.Corey: Right. Because given that it appears from the outside to be impenetrable, it's similar to learning VI in some cases, where oh, yeah, it's easy to get started with to do this trivial thing. Now, step two, draw the rest of the freaking owl. Same problem there. It feels off-putting just from a perspective of you must be at least this smart to proceed. How do you find people coming to it?Liz: Yeah, there is some truth in that, in that beyond kind of Hello World, you quite quickly start having to do things with kernel data structures. And as soon as you're looking at kernel data structures, you have to sort of understand, you know, more about the kernel. And if you change things, you need to understand the implications of those changes. So, yeah, you can rapidly say that eBPF programming is kernel programming, so why would anybody want to do it? The reason why I do it myself is not because I'm a kernel programmer; it's because I wanted to really understand how this is working and build up a mental model of what's happening when I attach a program to an event. And what kinds of things can I do with that program?And that's the sort of exploration that I think I'm trying to encourage people to do with the book. But yes, there is going to be at some point, a pretty steep learning curve that's kernel-related but you don't necessarily need to know everything in order to really have a decent understanding of what eBPF is, and how you might, for example—you might be interested to see what BPF programs are running on your existing system and learn why and what they might be doing and where they're attached and what use could that be.Corey: Falling down that, looking at the process table once upon a time was a heck of an education, one week when I didn't have a lot to do and I didn't like my job in those days, where, “Oh, what is this Avahi daemon that constantly running? MDNS forwarding? Who would need that?” And sure enough, that tickled something in the back of my mind when I wound up building out my networking box here on top of BSD, and oh, yeah, I want to make sure that I can still have discovery work from the IoT subnet over to whatever it is that my normal devices live. Ah, that's what that thing always running for. Great for that one use case. Almost never needed in other cases, but awesome. Like, you fire up a Raspberry Pi. It's, “Why are all these things running when I'm just want to have an embedded device that does exactly one thing well?” Ugh. Computers have gotten complicated.Liz: I know. It's like when you get those pop-ups on—well certainly on Mac, and you get pop-ups occasionally, let's say there's such and such a daemon wants extra permissions, and you think I'm not hitting that yes button until I understand what that daemon is. And it turns out, it's related, something completely innocuous that you've actually paid for, but just under a different name. Very annoying. So, if you have some kind of instrumentation like tracing or logging or security tooling that you want to apply to all of your containers, one of the things you can use is a sidecar container approach. And in Kubernetes, that means you inject the sidecar into every single pod. And—Corey: Yes. Of course, the answer to any Kubernetes problem appears to be have you tried running additional containers?Liz: Well, right. And there are challenges that can come from that. And one of the reasons why you have to do that is because if you want a tool that has visibility over that container that's inside the pod, well, your instrumentation has to also be inside the pod so that it has visibility because your pod is, by design, isolated from the host it's running on. But with eBPF, well eBPF is in the kernel and there's only one kernel, however many containers were running. So, there is no kind of isolation between the host and the containers at the kernel level.So, that means if we can instrument the kernel, we don't have to have a separate instance in every single pod. And that's really great for all sorts of resource usage, it means you don't have to worry about how you get those sidecars into those pods in the first place, you know that every pod is going to be instrumented if it's instrumented in the kernel. And then for service mesh, service mesh usually uses a sidecar as a Layer 7 Proxy injected into every pod. And that actually makes for a pretty convoluted networking path for a packet to sort of go from the application, through the proxy, out to the host, back into another pod, through another proxy, into the application.What we can do with eBPF, we still need a proxy running in userspace, but we don't need to have one in every single pod because we can connect the networking namespaces much more efficiently. So, that was essentially the basis for sidecarless service mesh, which we did in Cilium, Istio, and now we're using a similar sort of approach with Ambient Mesh. So that, again, you know, avoiding having the overhead of a sidecar in every pod. So that, you know, seems to be the way forward for service mesh as well as other types of instrumentation: avoiding sidecars.Corey: On some level, avoiding things that are Kubernetes staples seems to be a best practice in a bunch of different directions. It feels like it's an area where you start to get aligned with the idea of service meesh—yes, that's how I pluralize the term service mesh and if people have a problem with that, please, it's imperative you've not send me letters about it—but this idea of discovering where things are in a variety of ways within a cluster, where things can talk to each other, when nothing is deterministically placed, it feels like it is screaming out for something like this.Liz: And when you think about it, Kubernetes does sort of already have that at the level of a service, you know? Services are discoverable through native Kubernetes. There's a bunch of other capabilities that we tend to associate with service mesh like observability or encrypted traffic or retries, that kind of thing. But one of the things that we're doing with Cilium, in general, is to say, but a lot of this is just a feature of the networking, the underlying networking capability. So, for example, we've got next generation mutual authentication approach, which is using SPIFFE IDs between an application pod and another application pod. So, it's like the equivalent of mTLS.But the certificates are actually being passed into the kernel and the encryption is happening at the kernel level. And it's a really neat way of saying we don't need… we don't need to have a sidecar proxy in every pod in order to terminate those TLS connections on behalf of the application. We can have the kernel do it for us and that's really cool.Corey: Yeah, at some level, I find that it still feels weird—because I'm old—to have this idea of one shared kernel running a bunch of different containers. I got past that just by not requiring that [unintelligible 00:27:32] workloads need to run isolated having containers run on the same physical host. I found that, for example, running some stuff, even in my home environment for IoT stuff, things that I don't particularly trust run inside of KVM on top of something as opposed to just running it as a container on a cluster. Almost certainly stupendous overkill for what I'm dealing with, but it's a good practice to be in to start thinking about this. To my understanding, this is part of what AWS's Firecracker project starts to address a bit more effectively: fast provisioning, but still being able to use different primitives as far as isolation boundaries go. But, on some level, it's nice to not have to think about this stuff, but that's dangerous.Liz: [laugh]. Yeah, exactly. Firecracker is really nice way of saying, “Actually, we're going to spin up a whole VM,” but we don't ne—when I say ‘whole VM,' we don't need all of the things that you normally get in a VM. We can get rid of a ton of things and just have the essentials for running that Lambda or container service, and it becomes a really nice lightweight solution. But yes, that will have its own kernel, so unlike, you know, running multiple kernels on the same VM where—sorry, running multiple containers on the same virtual machine where they would all be sharing one kernel, with Firecracker you'll get a kernel per instance of Firecracker.Corey: The last question I have for you before we wind up wrapping up this episode harkens back to something you said a little bit earlier. This stuff is incredibly technically nuanced and deep. You clearly have a thorough understanding of it, but you also have what I think many people do not realize is an orthogonal skill of being able to articulate and explain those complex concepts simply an approachably, in ways that make people understand what it is you're talking about, but also don't feel like they're being spoken to in a way that's highly condescending, which is another failure mode. I think it is not particularly well understood, particularly in the engineering community, that there are—these are different skill sets that do not necessarily align congruently. Is this something you've always known or is this something you've figured out as you've evolved your career that, oh I have a certain flair for this?Liz: Yeah, I definitely didn't always know it. And I started to realize it based on feedback that people have given me about talks and articles I'd written. I think I've always felt that when people use jargon or they use complicated language or they, kind of, make assumptions about how things are, it quite often speaks to them not having a full understanding of what's happening. If I want to explain something to myself, I'm going to use straightforward language to explain it to myself [laugh] so I can hold it in my head. And I think people appreciate that.And you can get really—you know, you can get quite in-depth into something if you just start, step by step, build it up, explain everything as you go along the way. And yeah, I think people do appreciate that. And I think people, if they get lost in jargon, it doesn't help anybody. And yeah, I very much appreciate it when people say that, you know, they saw a talk or they read something I wrote and it meant that they finally grokked whatever that concept was that that I was trying to explain. I will say at the weekend, I asked ChatGPT to explain DNS in the style of Liz Rice, and it started off, it was basically, “Hello there. I'm Liz Rice and I'm here to explain DNS in very simple terms.” I thought, “Okay.” [laugh].Corey: Every time I think I've understood DNS, there's another level to it.Liz: I'm pretty sure there is a lot about DNS that I don't understand, yeah. So, you know, there's always more to learn out there.Corey: There's certainly is. I really want to thank you for taking time to speak with me today about what you're up to. Where's the best place for people to find you to learn more? And of course, to buy the book.Liz: Yeah, so I am Liz Rice pretty much everywhere, all over the internet. There is a GitHub repo that accompanies the books that you can find that on GitHub: lizRice/learning-eBPF. So, that's a good place to find some of the example code, and it will obviously link to where you can download the book or buy it because you can pay for it; you can also download it from Isovalent for the price of your contact details. So, there are lots of options.Corey: Excellent. And we will, of course, put links to that in the [show notes 00:32:08]. Thank you so much for your time. It's always great to talk to you.Liz: It's always a pleasure, so thanks very much for having me, Corey.Corey: Liz Rice, Chief Open Source Officer at Isovalent. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an angry comment that you have somehow discovered this episode by googling for knitting projects.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.
In today's episode of Elixir Wizards, Michael Lubas, founder of Paraxial.io, joins hosts Owen Bickford and Bilal Hankins to discuss security in the Elixir and Phoenix ecosystem. Lubas shares his insights on the most common security risks developers face, recent threats, and how Elixir developers can prepare for the future. Common security risks, including SQL injection and cross-site scripting, and how to mitigate these threats The importance of rate limiting and bot detection to prevent spam SMS messages Continuous security testing to maintain a secure application and avoid breaches Tools and resources available in the Elixir and Phoenix ecosystem to enhance security The Guardian library for authentication and authorization Take a drink every time someone says "bot" The difference between "bots" and AI language models The potential for evolving authentication, such as Passkeys over WebSocket How Elixir compares to other languages due to its immutability and the ability to trace user input Potion Shop, a vulnerable Phoenix application designed to test security Talking Tom, Sneaker Bots, and teenage hackers! The importance of security awareness and early planning in application development The impact of open-source software on application security How to address vulnerabilities in third-party libraries Conducting security audits and implementing security measures Links in this episode: Michael Lubas Email - michael@paraxial.io LinkedIn - https://www.linkedin.com/in/michaellubas/ Paraxial.io - https://paraxial.io/ Blog/Mailing List - https://paraxial.io/blog/index Potion Shop - https://paraxial.io/blog/potion-shop Elixir/Phoenix Security Live Coding: Preventing SQL Injection in Ecto Twitter - https://twitter.com/paraxialio LinkedIn - https://www.linkedin.com/company/paraxial-io/ GenServer Social - https://genserver.social/paraxial YouTube - https://www.youtube.com/@paraxial5874 Griffin Byatt on Sobelow: ElixirConf 2017 - Plugging the Security Holes in Your Phoenix Application (https://www.youtube.com/watch?v=w3lKmFsmlvQ) Erlang Ecosystem Foundation: Security Working Group - https://erlef.org/wg/security Article by Bram - Client-Side Enforcement of LiveView Security (https://blog.voltone.net/post/31) Special Guest: Michael Lubas.
Following on from her successful title "Container Security", Liz has recently authored "Learning eBPF", published by O'Reilly. eBPF is a revolutionary kernel technology that is enabling a whole new generation of infrastructure tools for networking, observability, and security. Let's explore eBPF and understand its value for security, and how it's used to secure network connectivity in the Cilium project, and for runtime security observability and enforcement in Cilium's sub-project, Tetragon. Segment Resources: Download "Learning eBPF": https://isovalent.com/learning-ebpf Buy "Learning eBPF" from Amazon: https://www.amazon.com/Learning-eBPF-Programming-Observability-Networking/dp/1098135121 Code examples accompanying the book: https://github.com/lizrice/learning-ebpf= Cilium project: https://cilium.io Tetragon project: https://tetragon.cilium.io/ BingBang and Azure, Super FabriXss and Azure, reversing the 3CX trojan on macOS, highlights from Real World Crypto, fun GPT prompts, and a secure code game Visit https://www.securityweekly.com/asw for all the latest episodes! Follow us on Twitter: https://www.twitter.com/secweekly Like us on Facebook: https://www.facebook.com/secweekly Show Notes: https://securityweekly.com/asw235
Following on from her successful title "Container Security", Liz has recently authored "Learning eBPF", published by O'Reilly. eBPF is a revolutionary kernel technology that is enabling a whole new generation of infrastructure tools for networking, observability, and security. Let's explore eBPF and understand its value for security, and how it's used to secure network connectivity in the Cilium project, and for runtime security observability and enforcement in Cilium's sub-project, Tetragon. Segment Resources: Download "Learning eBPF": https://isovalent.com/learning-ebpf Buy "Learning eBPF" from Amazon: https://www.amazon.com/Learning-eBPF-Programming-Observability-Networking/dp/1098135121 Code examples accompanying the book: https://github.com/lizrice/learning-ebpf= Cilium project: https://cilium.io Tetragon project: https://tetragon.cilium.io/ Visit https://www.securityweekly.com/asw for all the latest episodes! Show Notes: https://securityweekly.com/asw235
Following on from her successful title "Container Security", Liz has recently authored "Learning eBPF", published by O'Reilly. eBPF is a revolutionary kernel technology that is enabling a whole new generation of infrastructure tools for networking, observability, and security. Let's explore eBPF and understand its value for security, and how it's used to secure network connectivity in the Cilium project, and for runtime security observability and enforcement in Cilium's sub-project, Tetragon. Segment Resources: Download "Learning eBPF": https://isovalent.com/learning-ebpf Buy "Learning eBPF" from Amazon: https://www.amazon.com/Learning-eBPF-Programming-Observability-Networking/dp/1098135121 Code examples accompanying the book: https://github.com/lizrice/learning-ebpf= Cilium project: https://cilium.io Tetragon project: https://tetragon.cilium.io/ BingBang and Azure, Super FabriXss and Azure, reversing the 3CX trojan on macOS, highlights from Real World Crypto, fun GPT prompts, and a secure code game Visit https://www.securityweekly.com/asw for all the latest episodes! Follow us on Twitter: https://www.twitter.com/secweekly Like us on Facebook: https://www.facebook.com/secweekly Show Notes: https://securityweekly.com/asw235
Following on from her successful title "Container Security", Liz has recently authored "Learning eBPF", published by O'Reilly. eBPF is a revolutionary kernel technology that is enabling a whole new generation of infrastructure tools for networking, observability, and security. Let's explore eBPF and understand its value for security, and how it's used to secure network connectivity in the Cilium project, and for runtime security observability and enforcement in Cilium's sub-project, Tetragon. Segment Resources: Download "Learning eBPF": https://isovalent.com/learning-ebpf Buy "Learning eBPF" from Amazon: https://www.amazon.com/Learning-eBPF-Programming-Observability-Networking/dp/1098135121 Code examples accompanying the book: https://github.com/lizrice/learning-ebpf= Cilium project: https://cilium.io Tetragon project: https://tetragon.cilium.io/ Visit https://www.securityweekly.com/asw for all the latest episodes! Show Notes: https://securityweekly.com/asw235
Michael Isbitski (@michaelisbitski, Director Cybersecurity Strategy @sysdig) talks about about Sysdig's 2023 Cloud Native Security and Usage Report. The latest trends, interesting findings and the latest on Cloud Native SecuritySHOW: 696CLOUD NEWS OF THE WEEK - http://bit.ly/cloudcast-cnotwNEW TO CLOUD? CHECK OUT - "CLOUDCAST BASICS"SHOW SPONSORS:How to Fix the Internet (A new podcast from the EFF)Datadog Application Monitoring: Modern Application Performance MonitoringGet started monitoring service dependencies to eliminate latency and errors and enhance your users app experience with a free 14 day Datadog trial. Listeners of The Cloudcast will also receive a free Datadog T-shirt.Solve your IAM mess with Strata's Identity Orchestration platformHave an identity challenge you thought was too big, too complicated, or too expensive to fix? Let us solve it for you! Visit strata.io/cloudcast to share your toughest IAM challenge and receive a set of AirPods ProSHOW NOTES:Sysdig (homepage)Sysdig 2023 Cloud-Native Security and Usage Report Topic 1 - Welcome to the show. Tell us a little bit of your background, and where you focus your efforts at Sysdig?Topic 2 - Let's talk about the 2023 report. This is something that Sysdig has run for many years. What are some of the major Container Security and Usage trends you're seeing this year (2022 to 2023)? Report is unique as it looks at real-world data or more than a billion containers 6th report, each year we build on the data collected previously Beyond the speed of containers and usage data, we also looked at things people care about right now Where are there cost savings How are we doing with implementing zero trustWhere can we save time and reduce riskTopic 3 - It seems like preparedness for attacks, via vulnerabilities, is on the rise? Why do you think we're seeing things getting worse, rather than better? Topic 4 - Talk to us about some of the best practices for managing all the vulnerabilities, and how to think about prioritization - such as Common Vulnerability Scoring System (CVSS).Topic 5 - It appears that Zero Trust is a big buzzword, but maybe companies have zero trust in zero trust. Did this surprise you? What do you think is causing this?Topic 6 - What are some of the operational best practices that you're seeing companies doing to help mitigate these ever growing security threats? FEEDBACK?Email: show at the cloudcast dot netTwitter: @thecloudcastnet
Cloud Security Podcast - This month we are talking about "Building on the AWS Cloud" and next up on this series, we spoke to Mrunal Shah (Mrunal's Linkedin), Head of Container Security at Warner Bros. Discovery. We talk about how to build a Container or K8s security program while best practices are maintained and team have the right capability and tools. 4 Cs - Cloud, Container & Cluster, Code can be foundational to this Episode ShowNotes, Links and Transcript on Cloud Security Podcast: www.cloudsecuritypodcast.tv Host Twitter: Ashish Rajan (@hashishrajan) Guest Twitter: Mrunal Shah (Mrunal's Linkedin) Podcast Twitter - @CloudSecPod @CloudSecureNews If you want to watch videos of this LIVE STREAMED episode and past episodes - Check out our other Cloud Security Social Channels: - Cloud Security News - Cloud Security Academy Spotify TimeStamp for Interview Questions (00:00) Intro (02:01) https://snyk.io/csp (02:30) Mrunal's Professional Background (03:04) Why containers are popular (technical reasons) (04:05) Why containers are popular (leadership reasons) (05:39) Challenges with running a Container Security Program (Leadership) (06:34) Team skill challenge in a Container Security Program (08:57) When to pick AWS ECS vs AWS EKS? (10:53) ECS or EKS for building Banking Applications? (13:12) Would Kubernetes/ Containers be preferred for security reasons? (15:04) What would Amazon's responsibility be for security with ECS/EKS? (16:13) What is bad about working with Containers in AWS? (19:40) Is there a need for anti-virus in a container world? (20:36) Balance of security when working with containers? (22:08) Threat Detection and Prevention in a Container Security Program (22:57) Using AWS Services for Threat Detection with Containers? (25:14) Runtime Threat Discovery vs Agentless Threat Discovery for containers in Cloud? (29:11) Prevention on the left vs Detection on the right of SDLC (29:22) Cluster Misconfig vs Service Misconfigurations? (30:19) Vulnerability Management vs Misconfiguration Management? (31:50) Inspector in a Container Security Program? (32:36) Detective in a Container Security Program? (35:36) Can AWS Services help when Non-AWS services are in use? See you at the next episode!
There are stranger things than this week's ChannelPro Weekly episode, but little else as fun or informative. Joined by security expert and returning guest host Angela Hogaboom, the Cloud Chick herself, Matt and Rich discuss the new Surface for Business hardware at D&H, the new intrusion prevention and container security options from Trend Micro, and the new industry trend data from ConnectWise's Service Leadership unit. Then they get a terrifying and utterly fascinating insider's tour of the topsy-turvy world that is the dark web from Jacob Silutin, head of sales engineering for the Americas at Cyberint. You'll be glad you live in the Right Side Up! Subscribe to ChannelPro Weekly! iTunes: https://itunes.apple.com/us/podcast/channelpro-weekly-podcast/id1095568582?mt=2 Google Podcasts: https://podcasts.google.com/feed/aHR0cHM6Ly9jaGFubmVscHJvd2Vla2x5LmxpYnN5bi5jb20vcnNz?sa=X&ved=2ahUKEwjq-N3UvNHyAhVWPs0KHYdTDmkQ9sEGegQIARAF Spotify: https://open.spotify.com/show/7hWuOWbrIcwtrK6UJLSHvU Amazon Music: https://music.amazon.com/podcasts/a1d93194-a5f3-46d8-b625-abdc0ba032f1/ChannelPro-Weekly-Podcast More here: https://www.channelpronetwork.com/download/podcast/channelpro-weekly-podcast-episode-234-dark-upside-down Topics and Related Links Mentioned: D&H Adds Surface for Business Devices to Modern Solutions Unit - https://www.channelpronetwork.com/news/dh-adds-surface-business-devices-modern-solutions-unit Trend Micro Centralizes Intrusion Prevention and Container Security for Amazon Web Services - https://www.channelpronetwork.com/news/trend-micro-centralizes-intrusion-prevention-and-container-security-amazon-web-services Businesses Have Miles to Go for Windows 11 Prep - https://www.channelpronetwork.com/article/businesses-have-miles-go-windows-11-prep 5 Insights from Service Leadership's 2022 Industry Profitability Report - https://www.channelpronetwork.com/slideshow/5-insights-service-leadership-s-2022-industry-profitability-report Cyberint webinar on the dark web with Jacob Silutin - https://www.youtube.com/watch?v=nb4iidnz2Sk Rich's quickie preview of the week ahead
- First off, for those not familiar with Containers and Kubernetes, what are they?- Why are organizations increasingly adopting these technologies over traditional forms of compute?- How does Cybersecurity change with Kubernetes and what are some things practitioners should be sure to keep an eye on?- When organizations are adopting Kubernetes they often are faced with options such as rolling their own or using managed Kubernetes offerings, any thoughts there?- I recently read a report that researchers found 380,000 publicly exposed Kubernetes API servers, do you think people simply are spinning up these new technologies with security as an afterthought?- Kubernetes is incredibly complex, do you think this leads to challenges around properly configuring and securing it?- Any thoughts on software supply chain security as it relates to Kubernetes and Containers?- For those looking to learn more about Kubernetes and Container Security, do you have any recommended resources?
Securing containers along their lifecycle and wherever they are deployed is a cybersecurity challenge. And it is a new topic for KuppingerCole Analysts. Alexei Balaganski joins Matthias to talk about the just recently completed Leadership Compass on Container Security.
About LizLiz Rice is Chief Open Source Officer with cloud native networking and security specialists Isovalent, creators of the Cilium eBPF-based networking project. She is chair of the CNCF's Technical Oversight Committee, and was Co-Chair of KubeCon + CloudNativeCon in 2018. She is also the author of Container Security, published by O'Reilly.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, Liz loves riding bikes in places with better weather than her native London, and competing in virtual races on Zwift.Links: Isovalent: https://isovalent.com/ Container Security: https://www.amazon.com/Container-Security-Fundamental-Containerized-Applications/dp/1492056707/ Twitter: https://twitter.com/lizrice GitHub: https://github.com/lizrice Cilium and eBPF Slack: http://slack.cilium.io/ CNCF Slack: https://cloud-native.slack.com/join/shared_invite/zt-11yzivnzq-hs12vUAYFZmnqE3r7ILz9A TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: Today's episode is brought to you in part by our friends at MinIO the high-performance Kubernetes native object store that's built for the multi-cloud, creating a consistent data storage layer for your public cloud instances, your private cloud instances, and even your edge instances, depending upon what the heck you're defining those as, which depends probably on where you work. It's getting that unified is one of the greatest challenges facing developers and architects today. It requires S3 compatibility, enterprise-grade security and resiliency, the speed to run any workload, and the footprint to run anywhere, and that's exactly what MinIO offers. With superb read speeds in excess of 360 gigs and 100 megabyte binary that doesn't eat all the data you've gotten on the system, it's exactly what you've been looking for. Check it out today at min.io/download, and see for yourself. That's min.io/download, and be sure to tell them that I sent you.Corey: This episode is sponsored in part by our friends at Sysdig. Sysdig is the solution for securing DevOps. They have a blog post that went up recently about how an insecure AWS Lambda function could be used as a pivot point to get access into your environment. They've also gone deep in-depth with a bunch of other approaches to how DevOps and security are inextricably linked. To learn more, visit sysdig.com and tell them I sent you. That's S-Y-S-D-I-G dot com. My thanks to them for their continued support of this ridiculous nonsense.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. One of the interesting things about hanging out in the cloud ecosystem as long as I have and as, I guess, closely tied to Amazon as I have been, is that you learned that you never quite are able to pronounce things the way that people pronounce them internally. In-house pronunciations are always a thing. My guest today is Liz Rice, the Chief Open Source Officer at Isovalent, and they're responsible for, among other things, the Cilium open-source project, which is around eBPF, which I can only assume is internally pronounced as ‘Ehbehpf'. Liz, thank you for joining me today and suffering my pronunciation slings and arrows.Liz: I have never heard ‘Ehbehpf' before, but I may have to adopt it. That's great.Corey: You also are currently—in a term that is winding down if I'm not misunderstanding—you were the co-chair of KubeCon and CloudNativeCon at the CNCF, and you are also currently on the technical oversight committee for the foundation.Liz: Yeah, yeah. I'm currently the chair, in fact, of the technical oversight committee.Corey: And now that Amazon has joined, I assumed that they had taken their horrible pronunciation habits, like calling AMIs ‘Ah-mies' and whatnot, and started spreading them throughout the ecosystem with wild abandon.Liz: Are we going to have to start calling CNCF ‘Ka'Nff' or something?Corey: Exactly. They're very frugal, by which I mean they never buy a vowel. So yeah, it tends to be an ongoing challenge. Joking and all the rest aside, let's start, I guess, at the macro view. The CNCF does an awful lot of stuff, where if you look at the CNCF landscape, for example, like, I think some of my jokes on the internet go a bit too far, but you look at this thing and last time I checked, there were something like four or 500 different players in various spaces.And it's a very useful diagram, don't get me wrong by any stretch of the imagination, but it also is one of those things that is so staggeringly vast that I've got a level with you on this one, given my old, ancient sysadmin roots, “The hell with it. I'm going to run some VMs in a three-tiered architecture just like grandma and grandpa used to do,” and call it good. Not really how the industry is evolved, but it's overwhelming.Liz: But that might be the right solution for your use case so, you know, don't knock it if it works.Corey: Oh, yeah. If it's a terrible architecture and it works, is it really that terrible of an architecture? One wonders.Liz: Yeah, yeah. I mean, I'm definitely not one of those people who thinks, you know, every solution has the same—you know, is solved by the same hammer, you know, all problems are not the same nail. So, I am a big fan of a lot of the CNCF projects, but that doesn't mean to say I think those are the only ways to deploy software. You know, there are plenty of things like Lambda are a really great example of something that is super useful and very applicable for lots of applications and for lots of development teams. Not necessarily the right solution for everything. And for other people, they need all the bells and whistles that something like Kubernetes gives them. You know, horses for courses.Corey: It's very easy for me to make fun of just about any company or service or product, but the thing that always makes me set that aside and get down to brass tacks has been, “Okay, great. You can build whatever you want. You can tell whatever glorious marketing narrative you wish to craft, but let's talk to a real customer because once we do that, then if you're solving a problem that someone is having in the wild, okay, now it's no longer just this theoretical exercise and PowerPoint. Now, let's actually figure out how things work when the rubber meets the road.”So, let's start, I guess, with… I'll leave it to you. Isovalent are the creators of the Cilium eBPF-based networking project.Liz: Yeah.Corey: And eBPF is the part of that I think I'm the most familiar with having heard the term. Would you rather start on the company side or on the eBPF side?Liz: Oh, I don't mind. Let's—why don't we start with eBPF? Yeah.Corey: Cool. So easy, ridiculous question. I know that it's extremely important because Brendan Gregg periodically gets on stage and tells amazing stories about this; the last time he did stuff like that, I went stumbling down into the rabbit hole of DTrace, and I have never fully regretted doing that, nor completely forgiven him. What is eBPF?Liz: So, it stands for extended Berkeley Packet Filter, and we can pretty much just throw away those words because it's not terribly helpful. What eBPF allows you to do is to run custom programs inside the kernel. So, we can trigger these programs to run, maybe because a network packet arrived, or because a particular function within the kernel has been called, or a tracepoint has been hit. There are tons of places you can attach these programs to, or events you can attach programs to.And when that event happens, you can run your custom code. And that can change the behavior of the kernel, which is, you know, great power and great responsibility, but incredibly powerful. So Brendan, for example, has done a ton of really great pioneering work showing how you can attach these eBPF programs to events, use that to collect metrics, and lo and behold, you have amazing visibility into what's happening in your system. And he's built tons of different tools for observing everything from, I don't know, memory use to file opens to—there's just endless, dozens and dozens of tools that Brendan, I think, was probably the first to build. And now this sort of new generations of eBPF-based tooling that are kind of taking that legacy, turning them into maybe more, going to say user-friendly interfaces, you know, with GUIs, and hooking them up to metrics platforms, and in the case of Cilium, using it for networking and hooking it into Kubernetes identities, and making the information about network flows meaningful in the context of Kubernetes, where things like IP addresses are ephemeral and not very useful for very long; I mean, they just change at any moment.Corey: I guess I'm trying to figure out what part of the stack this winds up applying to because you talk about, at least to my mind, it sounds like a few different levels all at once: You talk about running code inside of the kernel, which is really close to the hardware—it's oh, great. It's adventures in assembly is almost what I'm hearing here—but then you also talk about using this with GUIs, for example, and operating on individual packets to run custom programs. When you talk about running custom programs, are we talking things that are a bit closer to, “Oh, modify this one field of that packet and then call it good,” or are you talking, “Now, we launch Microsoft Word.”Liz: Much more the former category. So yeah, let's inspect this packet and maybe change it a bit, or send it to a different—you know, maybe it was going to go to one interface, but we're going to send it to a different interface; maybe we're going to modify that packet; maybe we're going to throw the packet on the floor because we don't—there's really great security use cases for inspecting packets and saying, “This is a bad packet, I do not want to see this packet, I'm just going to discard it.” And there's some, what they call ‘Packet of Death' vulnerabilities that have been mitigated in that way. And the real beauty of it is you just load these programs dynamically. So, you can change the kernel or on the fly and affect that behavior, just immediately have an effect.If there are processes already running, they get instrumented immediately. So, maybe you run a BPF program to spot when a file is opened. New processes, existing processes, containerized processes, it doesn't matter; they'll all be detected by your program if it's observing file open events.Corey: Is this primarily used from a security perspective? Is it used for—what are the common use cases for something like this?Liz: There's three main buckets, I would say: Networking, observability, and security. And in Cilium, we're kind of involved in some aspects of all those three things, and there are plenty of other projects that are also focusing on one or other of those aspects.Corey: This is where when, I guess, the challenge I run into the whole CNCF landscape is, it's like, I think the danger is when I started down this path that I'm on now, I realized that, “Oh, I have to learn what all the different AWS services do.” This was widely regarded as a mistake. They are not Pokémon; I do not need to catch them all. The CNCF landscape applies very similarly in that respect. What is the real-world problem space for which eBPF and/or things like Cilium that leverage eBPF—because eBPF does sound fairly low-level—that turn this into something that solves a problem people have? In other words, what is the problem that Cilium should be the go-to answer for when someone says, “I have this thing that hurts.”Liz: So, at one level, Cilium is a networking solution. So, it's Kubernetes CNI. You plug it in to provide connectivity between your applications that are running in pods. Those pods have to talk to each other somehow and Cilium will connect those pods together for you in a very efficient way. One of the really interesting things about eBPF and networking is we can bypass some of the networking stack.So, if we are running in containers, we're running our applications in containers in pods, and those pods usually will have their own networking namespace. And that means they've got their own networking stack. So, a packet that arrives on your machine has to go through the networking stack on that host machine, go across a virtual interface into your pod, and then go through the networking stack in that pod. And that's kind of inefficient. But with eBPF, we can look at the packet the moment it's come into the kernel—in fact in some cases, if you have the right networking interfaces, you can do it while it's still on the network interface card—so you look at that packet and say, “Well, I know what pod that's destined for, I can just send it straight there.” I don't have to go through the whole networking stack in the kernel because I already know exactly where it's going. And that has some real performance improvements.Corey: That makes sense. In my explorations—we'll call it—with Kubernetes, it feels like the universe—at least at the time I went looking into it—was, “Step One, here's how to wind up launching Kubernetes to run a blog.” Which is a bit like using a chainsaw to wind up cutting a sandwich. Okay, massively overpowered but I get the basic idea, like, “Okay, what's project Step Two?” It's like, “Oh, great. Go build Google.”Liz: [laugh].Corey: Okay, great. It feels like there's some intermediary steps that have been sort of glossed over here. And at the small-scale that I kicked the tires on, things like networking performance never even entered the equation; it was more about get the thing up and running. But yeah, at scale, when you start seeing huge numbers of containers being orchestrated across a wide variety of hosts that has serious repercussions and explains an awful lot. Is this the sort of thing that gets leveraged by cloud providers themselves, is it something that gets built in mostly on-prem environments, or is it something that rides in, almost, user-land for most of these use cases that customers coming to bringing to those environments? I'm sorry, users, not customers. I'm too used to the Amazonian phrasing of everyone as a customer. No, no, they are users in an open-source project.Liz: [laugh]. Yeah, so if you're using GKE, the GKE Dataplane V2 is using Cilium. Alibaba Cloud uses Cilium. AWS is using Cilium for EKS Anywhere. So, these are really, I think, great signals that it's super scalable.And it's also not just about the connectivity, but also about being able to see your network flows and debug them. Because, like you say, that day one, your blog is up and running, and day two, you've got some DNS issue that you need to debug, and how are you going to do that? And because Cilium is working with Kubernetes, so it knows about the individual pods, and it's aware of the IP addresses for those pods, and it can map those to, you know, what's the pod, what service is that pod involved with. And we have a component of Cilium called Hubble that gives you the flows, the network flows, between services. So, you know, we've probably all seen diagrams showing Service A talking to Service B, Service C, some external connectivity, and Hubble can show you those flows between services and the outside world, regardless of how the IP addresses may be changing underneath you, and aggregating network flows into those services that make sense to a human who's looking at a Kubernetes deployment.Corey: A running gag that I've had is that one of the drawbacks and appeals of Kubernetes, all at once, is that it lets you cosplay as a cloud provider, even if you don't happen to work for one of them. And there's a bit of truth to it, but let's be serious here, despite what a lot of the cloud providers would wish us to believe via a bunch of marketing, there's a tremendous number of data center environments out there, hybrid environments, and companies that are in those environments are not somehow laggards, or left behind technologically, or struggling to digitally transform. Believe it or not—I know it's not a common narrative—but large companies generally don't employ people who lack critical thinking skills and strategic insight. There's usually a reason that things are the way that they are and when you don't understand that my default approach is that, oh context that gets missing, so I want to preface this with the idea there is nothing wrong in those environments. But in a purely cloud-native environment—which means that I'm very proud about having no single points of failure as I have everything routing to a single credit card that pays the cloud providers—great. What is the story for Cilium if I'm using, effectively, the managed Kubernetes options that Name Any Cloud Provider will provide for me these days? Is it at that point no longer for me or is it something that instead expresses itself in ways I'm not seeing, yet?Liz: Yeah, so I think, as an open-source project—and it is the only CNI that's at incubation level or beyond, so you know, it's CNCF-supported networking solution; you can use it out of the box, you can use it for your tiny blog application if you've decided to run that on Kubernetes, you can do so—things start to get much more interesting at scale. I mean, that… continuum between you know, there are people purely on managed services, there are people who are purely in the cloud, hybrid cloud is a real thing, and there are plenty of businesses who have good reasons to have some things in their own data centers, something's in the public cloud, things distributed around the world, so they need connectivity between those. And Cilium will solve a lot of those problems for you in the open-source, but also, if you're telco scale and you have things like BGP networks between your data centers, then that's where the paid versions of Cilium, the enterprise versions of Cilium, can help you out. And, as Isovalent, that's our business model to have, like—we fully support or we contribute a lot of resources into the open-source Cilium, and we want that to be the best networking solution for anybody, but if you are an enterprise who wants those extra bells and whistles, and the kind of scale that, you know, a telco, or a massive retailer, or a large media organization, or name your vertical, then we have solutions for that as well. And I think it was one of the really interesting things about the eBPF side of it is that, you know, we're not bound to just Kubernetes, you know? We run in the kernel, and it just so happens that we have that Kubernetes interface for allocating IP addresses to endpoints that happened to be pods. But—Corey: So, back to my crappy pile of VMs—because the hell with all this newfangled container nonsense—I can still benefit from something like Cilium?Liz: Exactly, yeah. And there's plenty of people using it for just load-balancing, which, why not have an eBPF-based high-performance load balancer?Corey: Hang on, that's taking me a second to work my way through. What is the programming language for eBPF? It is something custom?Liz: Right. So, when you load your BPF program into the kernel, it's in the form of eBPF bytecode. There are people who write an eBPF bytecode by hand; I am not one of those people.Corey: There are people who used to be able to write Sendmail configs without running through the M four preprocessor, and I don't understand those people either.Liz: [laugh]. So, our choices are—well, it has to be a language that can be compiled into that bytecode, and at the moment, there are two options: C, and more recently, Rust. So, the C code, I'm much more familiar with writing BPF code in C, it's slightly limited. So, because these BPF programs have to be safe to run, they go through a verification process which checks that you're not going to crash the kernel, that you're not going to end up in some hardware loop, and basically make your machine completely unresponsive, we also have to know that BPF programs, you know, they'll only access memory that they're supposed to and that they can't mess up other processes. So, there's this BPF verification step that checks for example that you always check that a pointer isn't nil before you dereference it.And if you try and use a pointer in your C code, it might compile perfectly, but when you come to load it into the kernel, it gets rejected because you forgot to check that it was non-null before.Corey: You try and run it, the whole thing segfaults, you see the word ‘fault' there and well, I guess blameless just went out the window there.Liz: [laugh]. Well, this is the thing: You cannot segfault in the kernel, you know, or at least that's a bad [day 00:19:11]. [laugh].Corey: You say that, but I'm very bad with computers, let's be clear here. There's always a way to misuse things horribly enough.Liz: It's a challenge. It's pretty easy to segfault if you're writing a kernel module. But maybe we should put that out as a challenge for the listener, to try to write something that crashes the kernel from within an eBPF because there's a lot of very smart people.Corey: Right now the blood just drained from anyone who's listening, in the kernel space or the InfoSec space, I imagine.Liz: Exactly. Some of my colleagues at Isovalent are thinking, “Oh, no. What's she brought on here?” [laugh].Corey: What have you done? Please correct me if I'm misunderstanding this. So, eBPF is a very low-level tool that requires certain amounts of braining in order [laugh] to use appropriately. That can be a heavy lift for a lot of us who don't live in those spaces. Cilium distills this down into something that is all a lot more usable and understandable for folks, and then beyond that, you wind up with Isovalent, that winds up effectively productizing and packaging this into something that becomes a lot more closer to turnkey. Is that directionally accurate?Liz: Yes, I would say that's true. And there are also some other intermediate steps, like the CLI tools that Brendan Gregg did, where you can—I mean, a CLI is still fairly low-level, but it's not as low-level as writing the eBPF code yourself. And you can be quite in-dep—you know, if you know what things you want to observe in the kernel, you don't necessarily have to know how to write the eBPF code to do it, but if you've got these fairly low-level tools to do it. You're absolutely right that very few people will need to write their own… BPF code to run in the kernel.Corey: Let's move below the surface level of awareness; the same way that most of us don't need to know how to compile our own kernel in this day and age.Liz: Exactly.Corey: A few people very much do, but because of their hard work, the rest of us do not.Liz: Exactly. And for most of us, we just take the kernel for granted. You know, most people writing applications, it doesn't really matter if—they're just using abstractions that do things like open files for them, or create network connections, or write messages to the screen, you don't need to know exactly how that's accomplished through the kernel. Unless you want to get into the details of how to observe it with eBPF or something like that.Corey: I'm much happier not knowing some of the details. I did a deep dive once into Linux system kernel internals, based on an incredibly well-written but also obnoxiously slash suspiciously thick O'Reilly book, Linux Systems Internalsand it was one of those, like, halfway through, “Can I please be excused? My brain is full.” It's one of those things that I don't use most of it on a day-to-day basis, but it's solidified by understanding of what the computer is actually doing in a way that I will always be grateful for.Liz: Mmm, and there are tens of millions of lines of code in the Linux kernel, so anyone who can internalize any of that is basically a superhero. [laugh].Corey: I have nothing but respect for people who can pull that off.Corey: Couchbase Capella Database-as-a-Service is flexible, full-featured and fully managed with built in access via key-value, SQL, and full-text search. Flexible JSON documents aligned to your applications and workloads. Build faster with blazing fast in-memory performance and automated replication and scaling while reducing cost. Capella has the best price performance of any fully managed document database. Visit couchbase.com/screaminginthecloud to try Capella today for free and be up and running in three minutes with no credit card required. Couchbase Capella: make your data sing.In your day job, quote-unquote—which is sort of a weird thing to say, given that you are working at an open-source company; in fact, you are the Chief Open Source Officer, so what you're doing in the community, what you're exploring on the open-source project side of things, it is all interrelated. I tend to have trouble myself figuring out where my job starts and stops most weeks; I'm sympathetic to it. What inspired you folks to launch a company that is, “Ah, we're going to be in the open-source space?” Especially during a time when there's been a lot of pushback, in some respects, about the evolution of open-source and the rise of large cloud providers, where is open-source a viable strategy or a tactic to get to an outcome that is pleasing for all parties?Liz: Mmm. So, I wasn't there at the beginning, for the Isovalent journey, and Cilium has been around for five or six years, now, at this point. I very strongly believe in open-source as an effective way of developing technology—good technology—and getting really good feedback and, kind of, optimizing the speed at which you can innovate. But I think it's very important that businesses don't think—if you're giving away your code, you cannot also sell your code; you have to have some other thing that adds value. Maybe that's some extra code, like in the Isovalent example, the enterprise-related enhancements that we have that aren't part of the open-source distribution.There's plenty of other ways that people can add value to open-source. They can do training, they can do managed services, there's all sorts of different—support was the classic example. But I think it's extremely important that businesses don't just expect that I can write a bunch of open-source code, and somehow magically, through building up a whole load of users, I will find a way to monetize that.Corey: A bunch of nerds will build my product for me on nights and weekends. Yeah, that's a bit of an outmoded way of thinking about these things.Liz: Yeah exactly. And I think it's not like everybody has perfect ability to predict the future and you might start a business—Corey: And I have a lot of sympathy for companies who originally started with the idea of, “Well, we are the project leads. We know this code the best, therefore we are the best people in the world to run this as a service.” The rise of the hyperscale cloud providers has called that into significant question. And I feel for them because it's difficult to completely pivot your business model when you're already a publicly-traded company. That's a very fraught and challenging thing to do. It means that you're left with a bunch of options, none of them great.Cilium as a project is not that old, neither is Isovalent, but it's new enough in the iterative process, that you were able to avoid that particular pitfall. Instead, you're looking at some level of making this understandable and useful to humans, almost the point where it disappears from their level of awareness that they need to think about. There's huge value in something like that. Do you think that there is a future in which projects and companies built upon projects that follow this model are similarly going to be having challenges with hyperscale cloud providers, or other emergent threats to the ecosystem—sorry, ‘threat' is an unfair and unkind word here—but changes to the ecosystem, as we see the world evolving in ways that most of us did not foresee?Liz: Yeah, we've certainly seen some examples in the last year or two, I guess, of companies that maybe didn't anticipate, and who necessarily has a crystal ball to anticipate how cloud providers might use their software? And I think in some cases, the cloud providers has not always been the most generous or most community-minded in their approach to how they've done that. But I think for a company, like Isovalent, our strong point is talent. It would be extremely rare to find the level of expertise in, you know, what is a pretty specialized area. You know, the people at Isovalent who are working on Cilium are also working on eBPF itself, and that level of expertise is, I think, pretty unrivaled.So, we're in such a new space with eBPF, we've only in the last year or so, got to the point where pretty much everyone is running a kernel that's new enough to use eBPF. Startups do have a kind of agility that I think gives them an advantage, which I hope we'll be able to capitalize on. I think sometimes when businesses get upset about their code being used, they probably could have anticipated it. You know, if it's open-source, people will use your software, and you have to think of that.Corey: “What do you mean you're using the thing we gave away for free and you're not paying us to use it?”Liz: Yeah.Corey: “Uh, did you hear what you just said?” Some of this was predictable, let's be fair.Liz: Yeah, and I think you really have to, as a responsible business, think about, well, what does happen if they use all the open-source code? You know, is that a problem? And as far as we're concerned, everybody using Cilium is a fantastic… thing. We fully welcome everyone using Cilium as their data plane because the vast majority of them would use that open-source code, and that would be great, but there will be people who need that extra features and the expertise that I think we're in a unique position to provide. So, I joined Isovalent just about a year ago, and I did that because I believe in the technology, I believe in the company, I believe in, you know, the foundations that it has in open-source.It's a very much an open-source first organization, which I love, and that resonates with me and how I think we can be successful. So, you know, I don't have that crystal ball. I hope I'm right, we'll find out. We should do this again, you know, a couple of years and see how that's panning out. [laugh].Corey: I'll book out the date now.Liz: [laugh].Corey: Looking back at our conversation just now, you talked about open-source, and business strategy and how that's going to be evolving. We talked about the company, we talked about an incredibly in-depth, technical product that honestly goes significantly beyond my current level of technical awareness. And at no point in any of those aspects of the conversation did you talk about it in a way that I did not understand, nor did you come off in any way as condescending. In fact, you wrote an O'Reilly book on Container Security that's written very much the same way. How did you learn to do that? Because it is, frankly, an incredibly rare skill.Liz: Oh, thank you. Yeah, I think I have never been a fan of jargon. I've never liked it when people use a complicated acronym, or really early days in my career, there was a bit of a running joke about how everything was TLAs. And you think, well, I understand why we use an acronym to shorten things, but I don't think we need to assume that everybody knows what everything stands for. Why can't we explain things in simple language? Why can't we just use ordinary terms?And I found that really resonates. You know, if I'm doing a presentation or if I'm writing something, using straightforward language and explaining things, making sure that people understand the, kind of, fundamentals that I'm going to build my explanation on. I just think that has a—it results in people understanding, and that's my whole point. I'm not trying to explain something to—you know, my goal is that they understand it, not that they've been blown away by some kind of magic. I want them to go away going, “Ah, now I understand how this bit fits with that bit,” or, “How this works.” You know?Corey: The reason I bring it up is that it's an incredibly undervalued skill because when people see it, they don't often recognize it for what it is. Because when people don't have that skill—which is common—people just write it off as oh, that person's a bad communicator. Which I think is a little unfair. Being able to explain complex things simply is one of the most valuable yet undervalued skills that I've found in this entire space.Liz: Yeah, I think people sometimes have this sort of wrong idea that vocabulary and complicated terms are somehow inherently smarter. And if you use complicated words, you sound smarter. And I just don't think that's accessible, and I don't think it's true. And sometimes I find myself listening to someone, and they're using complicated terms or analogies that are really obscure, and I'm thinking, but could you explain that to me in words of one syllable? I don't think you could. I think you're… hiding—not you [laugh]. You know, people—Corey: Yeah. No, no, that's fair. I'll take the accusation as [unintelligible 00:31:24] as I can get it.Liz: [laugh]. But I think people hide behind complex words because they don't really understand them sometimes. And yeah, I would rather people understood what I'm saying.Corey: To me—I've done it through conference talks, but the way I generally learn things is by building something with them. But the way I really learn to understand something is I give a conference talk on it because, okay, great. I can now explain Git—which was one of my early technical talks—to folks who built Git. Great. Now, how about I explain it to someone who is not immersed in the space whatsoever? And if I can make it that accessible, great, then I've succeeded. It's a lot harder than it looks.Liz: Yeah, exactly. And one of the reasons why I enjoy building a talk is because I know I've got a pretty good understanding of this, but by the time I've got this talk nailed, I will know this. I might have forgotten it in six months time, you know, but [laugh] while I'm giving that talk, I will have a really good understanding of that because the way I want to put together a talk, I don't want to put anything in a talk that I don't feel I could explain. And that means I have to understand how it works.Corey: It's funny, this whole don't give talks about things you don't understand seems like there's really a nouveau concept, but here we are, we're [working on it 00:32:40].Liz: I mean, I have committed to doing talks that I don't fully understand, knowing that—you know, with the confidence that I can find out between now and the [crosstalk 00:32:48]—Corey: I believe that's called a forcing function.Liz: Yes. [laugh].Corey: It's one of those very high-risk stories, like, “Either I'm going to learn this in the next three months, or else I am going to have some serious egg on my face.”Liz: Yeah, exactly, definitely a forcing function. [laugh].Corey: I really want to thank you for taking so much time to speak with me today. If people want to learn more, where can they find you?Liz: So, I am online pretty much everywhere as lizrice, and I am on Twitter. I'm on GitHub. And if you want to come and hang out, I am on the Cilium and eBPF Slack, and also the CNCF Slack. Yeah. So, come say hello.Corey: There. We will put links to all of that in the [show notes 00:33:28]. Thank you so much for your time. I appreciate it.Liz: Pleasure.Corey: Liz Rice, Chief Open Source Officer at Isovalent. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an angry comment containing an eBPF program that on every packet fires off a Lambda function. Yes, it will be extortionately expensive; almost half as much money as a Managed NAT Gateway.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.
This week on Network Break we discuss VMware enhancing its Carbon Black software with container runtime security, Google telling employees to return to the office starting April 4, and Broadcom taking in $7.7 billion in revenue in Q1 2022. We also discuss security attacks affected hit Toyota and Viasat and more IT news.
This week on Network Break we discuss VMware enhancing its Carbon Black software with container runtime security, Google telling employees to return to the office starting April 4, and Broadcom taking in $7.7 billion in revenue in Q1 2022. We also discuss security attacks affected hit Toyota and Viasat and more IT news. The post Network Break 372: VMware Enhances Container Security; Google Summons Workers Back To The Office appeared first on Packet Pushers.
This week on Network Break we discuss VMware enhancing its Carbon Black software with container runtime security, Google telling employees to return to the office starting April 4, and Broadcom taking in $7.7 billion in revenue in Q1 2022. We also discuss security attacks affected hit Toyota and Viasat and more IT news.
This week on Network Break we discuss VMware enhancing its Carbon Black software with container runtime security, Google telling employees to return to the office starting April 4, and Broadcom taking in $7.7 billion in revenue in Q1 2022. We also discuss security attacks affected hit Toyota and Viasat and more IT news. The post Network Break 372: VMware Enhances Container Security; Google Summons Workers Back To The Office appeared first on Packet Pushers.
This week on Network Break we discuss VMware enhancing its Carbon Black software with container runtime security, Google telling employees to return to the office starting April 4, and Broadcom taking in $7.7 billion in revenue in Q1 2022. We also discuss security attacks affected hit Toyota and Viasat and more IT news.
This week on Network Break we discuss VMware enhancing its Carbon Black software with container runtime security, Google telling employees to return to the office starting April 4, and Broadcom taking in $7.7 billion in revenue in Q1 2022. We also discuss security attacks affected hit Toyota and Viasat and more IT news. The post Network Break 372: VMware Enhances Container Security; Google Summons Workers Back To The Office appeared first on Packet Pushers.
Exploring Container Security: A Storage Vulnerability Deep Dive - https://security.googleblog.com/2021/...Recently, the GKE Security team discovered a high severity vulnerability that allowed workloads to have access to parts of the host file system outside the boundaries of the mounted volume. Remember, vulnerabilities can exist deep within the internals of Kubernetes.Really Stupid “Smart Contract” Bug Let Hackers Steal $31 Million In Digital Coin - https://arstechnica.com/information-t...An accounting error built into the company's software let an attacker inflate the MONO tokens price and then use it to cash out all the other deposited tokens, MonoX Finance revealed in a post. The haul amounted to $31 million worth of tokens on the Ethereum or Polygon blockchains, both of which are supported by the MonoX protocol. Thinking back, Looking forward – A Balanced Approach to Securing our Software Future - https://www.buzzsprout.com/1730684/88...Keven Greene is the Director of Security Solutions at Parasoft and has extensive experience and expertise in software security, cyber research and development, and DevOps. He and Chris discussed software security from the past into the future. They cover how to make security easier for devs, SBOM, software minimalism, and so much more in this episode of the Application Security Podcast.Security Metrics that Count - https://www.twilio.com/blog/security-...Metrics can be challenging. Twilio uses security metrics to drive change within their organization, celebrate improvements over time to help better protect their customers, and measure their security program. Playbook for Threat Modeling Medical Devices - https://www.mitre.org/publications/te...The "Playbook for Threat Modeling Medical Devices" was developed further to increase knowledge of threat modeling throughout the medical device ecosystem and strengthen the cybersecurity and safety of medical devices.
Rick explains what containers and serverless functions are, why they are related, why they are the latest development in the evolution of the client server architecture, why you need to secure them, and how. Resources: “5 ways to secure your containers,” by Steven Vaughan-Nichols, CEO, Vaughan-Nichols & Associates, 23 April 2019. “8 technologies that will disrupt business in 2020,” by Paul Heltzel, CIO, 26 August 2019. “A Brief History of Containers: From the 1970s Till Now,” by Rani Osnat, Aqua, 10 January 2020. “A brief history of SSH and remote access,” by Jeff Geerling, an excerpt from Chapter 11: Server Security and Ansible, in Ansible for DevOps, 15 April 2014. “Amazon Launches Lambda, An Event-Driven Compute Service,” by Ron Miller, TC, 13 November 2014 “Application Container Security Guide: NIST Special Publication 800-190,” by Murugiah Souppaya, John Morello, and Karen Scarfone, NIST, September 2017. “Container Explainer,” IDG.TV, 19 August 2015. “Container Network Security - Kubernetes Network Policies in Action with Cilium (Cloud Native),” by Fernando, Gitlab, 16 July 2020. “Container Security,” by Synk. “Google has quietly launched its answer to AWS Lambda,” by Jordan Novet, Venture Beat, 9 February 2016. “Historical Computers in Japan: Unix Servers,” IPSJ Computer Museum. “M.C. Escher Collection,” Maurits Cornelis (MC) Escher - 1898 - 1972. “Serverless Architectures,” by Martin Fowler, martin.Fowler.com, 22 May 2018. “Serverless vs Microservices — Which Architecture to Choose in 2020?” TechMagic, 01 JULY 2020. “The Benefits of Containers,” by Ben Corrie, VMWARE, 16 May 2017. “The essential guide to software containers for application development,” by David Linthicum, Chief Cloud Strategy Officer, Deloitte Consulting. “The Invention of the Virtual Machine,” by SEAN CONROY, IDKRTM, 25 JANUARY 2018. “What are containers and why do you need them?” By Paul Rubens, CIO, 27 JUN 2017. “What even is a container: namespaces and cgroups,” by Julia Evans, Julia Evans Blog. “What is a Container?” by Ben Corrie, VMWARE, 16 May 2017 “What is a Container?” by VMWARE.
Тайминг: 00:53 - Ностальгия по ICQ (https://dev.by/news/zagruzki-icq-v-gonkonge-vyrosli-v-35-raz-iz-za-nostalgii-i-nedoveriya-k-whatsapp) 05:29 - Эксперты рассуждают про StopGame 16:53 - Разбор Sysdig 2021 Container Security and Usage Report (https://sysdig.com/blog/sysdig-2021-container-security-usage-report/) 01:06:10 - Учимся безопасно писать Dockerfile (https://habr.com/ru/company/swordfish_security/blog/537280/) 01:17:21 - Что нового в k8s 1.20? (https://m.habr.com/en/company/flant/blog/530924/) Доп материал: Схема - https://containerd.io/img/architecture.png DOM Panel discussion - https://www.youtube.com/watch?v=Zy6VovBkbOk Сказать спасибо: https://www.patreon.com/devopskitchentalks Музыка: https://www.bensound.com
On today's episode, Guy Podjarny talks to Kelly Shortridge about security, microservices, and chaos engineering. Kelly is currently VP of product strategy at Capsule8, following product roles at SecurityScorecard, BAE Systems Applied Intelligence, as well as co-founding IperLane, a security startup which was acquired. Kelly is also known for presenting at international technology conferences, on topics ranging from behavioral economics at Infosec to chaos security engineering. In this episode, Kelly explains exactly what product strategy and management means, and goes into the relationships and tensions between dev, ops, and security and how that has changed. We also discuss container security and how it is different from any other end point security systems, as well as the difference between container security and microservices. Kelly believes that we are overlooking a lot of the benefits of microservices, as well as the applications for chaos engineering in security. Tune in to find out what changes Kelly sees happening in the industry, and see what advice she has for teams looking to level up their security!
© 2020-2025 Ivy Podcast Discovery LLC
