字幕原文 · CC BY 3.0

Keynote: Learn by Hacking: How to Run a 2,500 Node Kubernetes CTF - Andrew Martin & Andrés Vega

Andrew Martin and Andrés Vega explain how they ran large Kubernetes capture-the-flag events, balancing learning scenarios, infrastructure and cost.

CNCF [Cloud Native Computing Foundation] · Published · 13 min · English · License: CC BY 3.0 · Source: 在 YouTube 觀看

字幕來源:Vidleaf 自動語音辨識,可能有誤。Vidleaf 加入 AI 標點,保留原字詞與時間戳。下方可查看原始字幕。

AI 生成摘要

This talk, titled Learn by Hacking, describes how the speakers have run CTFs at Cloud Native Security Con over the past years, covering what they did, what they hoped to achieve for attendees, and how they maintained their fragile sanity. Starting planning in 2019, they provisioned thousands of nodes on demand per day and ran events both in person and virtually, aiming to communicate how best to secure cloud native infrastructure through red team scenarios with full demonstrations, teardowns and remediations. Scenarios are intentionally increasingly complex and difficult, beginning with an introductory scenario at each event, and run on dedicated real infrastructure to emulate real-world systems at some cost of complexity; the goal is not to find the ultimate security ninja but a rising tide that lifts all boats, with fast feedback and support. The live deployment involved 2,500 nodes per day, one five-node cluster per scenario with no cluster reuse, unique credentials per player per scenario cluster pairing, and Taskmasters in person and on Slack to hand out hints. The session also recounts a live breach simulation in which an AWS internal Ubuntu mirror went down, halting provisioning while health checks turned unhealthy and the dashboard went red; the team reprovisioned into a different region, someone bypassed the initial SSH tunnel sandboxing, Cluster Admin RBAC credentials disappeared and ended up on a bastion node, and the test suite only covers happy paths. The speaker thanks everyone who played, gave feedback and enabled iteration, encourages CTF players to focus on the learning experience and walk through the scenarios, and notes the clusters and scenarios are open source, with a hosted version under the Kubernetes simulator project and a private beta of Control Plane.

根據字幕生成。請透過連結對照原影片核對。

附時間戳的章節摘要

Learn by Hacking: Kubernetes Security Talk Intro

  • [0:02] The talk is titled Learn by Hacking.
  • [0:06] The speakers thank attendees, volunteers, contributors, and the Cloud Native Computing Foundation for their involvement in Kubernetes.
  • [0:23] Documentation and bug fixes do not write themselves, and open source contributions are freely given and gracefully received.
  • [0:36] Security controls are generally more difficult to get right in complex orchestrations with Kubernetes' functionality.
  • [0:45] The speakers especially thank security teams for their hard work.
  • [0:49] The tax security CTFs reflect the pioneering voyage of Kubernetes on the dangerous free seas of the Internet.
  • [1:00] A free book by the speaker and co-author Mr. Michael Hassenblass is available to download, with tips and tricks for individuals looking to assail cloud-native infrastructure.
  • [1:00] Listeners intrigued by the talk can join the speakers on Thursday.

Running CTFs at Cloud Native Security Con

  • [1:25] The talk covers how CTFs have been run at Cloud Native Security Con over the past years.
  • [1:30] It covers what they did, what they hoped to achieve for attendees, and how they maintained their fragile sanity.
  • [1:38] They provisioned thousands of nodes on demand per day.
  • [1:44] Over the years they have run CTFs both in person and virtually, with planning beginning in 2019.
  • [1:55] They set out to determine what it would take to put together a CTF running on Kubernetes for Kubernetes.
  • [2:04] A key concern was doing this without the entire infrastructure coming crumbling down.
  • [2:09] Building a self-hosted security game and inviting everyone to attack it is described as terrifying.

Cloud Native Security Red Team Scenarios

  • [2:19] Goal is to communicate how best to secure cloud native infrastructure.
  • [2:25] Scenarios are red team exercises with full demonstrations, teardowns and remediations.
  • [2:32] Framing draws on Sun Tzu: the best form of defence is attack, and know thyself.
  • [2:37] Aim is to give something back to the community that has shared so much.
  • [2:44] Features the nefarious #PirateCaptain with his eponymous bag of Bitcoin.
  • [2:55] Also features the Untitled Goose that sparked security enthusiasm over the last few years.
  • [3:04] It is a learning experience for all skill levels, starting with an introductory scenario at each event and building up in difficulty.
  • [3:12] Progression works as a game that gets more difficult throughout the journey to captivate all skill levels and nurture interest in security.
  • [3:23] Dedicated infrastructure is used to emulate real-world systems, at some cost of complexity.

Cloud-Native CTF and Learning Goals

  • [3:33] The goal is not to find the ultimate security ninja but a rising tide that lifts all boats.
  • [3:37] Players get fast feedback and support to enhance their learning experience.
  • [3:45] A digital reconstruction by street artist Banksy shows pirates playing a cloud-native CTF.
  • [3:59] The image includes a splash of stable diffusion for effect.

Secure Software Is Impossible

  • [4:03] There is no such thing as secure software because new features ship quickly and vulnerabilities keep appearing.
  • [4:19] New features potentially contain untested code paths.
  • [4:26] Untested code paths with security side effects are by default vulnerabilities.
  • [4:34] We prioritize shipping features over fixing vulnerabilities, at our peril.
  • [4:48] This resembles the friction between red teams and blue teams.
  • [5:01] Organizations must evolve to survive because their adversaries are also evolving.
  • [5:06] The question is how to represent that complex puzzle in a safe learning environment.

Realistic Attack Scenarios on Real Infrastructure

  • [5:11] Scenario authors aim to build the most realistic scenarios they can manage.
  • [5:16] This includes building infrastructure diagrams and threat modeling scenarios, drawing on consulting experience with regulated industries and startups.
  • [5:28] A supply chain attack is shown in progress, with Captain Hashjack having attacked systems through various network systems in the past.
  • [5:37] Past attack targets include packing repositories, container registries, and the hypertext coffee pot control protocol.
  • [5:47] Running the platform on real infrastructure allows emulation of simulations seen in real life.
  • [5:54] Coffee pots and IoT attacks are not the exception.

Kubernetes CTF Security Treasure Map

  • [6:02] The goal is to educate as many people as possible as effectively as possible.
  • [6:10] A pod Security treasure map from the book "Hacking Kubernetes" is shown.
  • [6:15] Scenarios are intentionally increasingly complex and difficult to crystallize understanding of a wide and complex security landscape.
  • [6:29] As with all CTFs, players must enumerate the visible horizon, escalate privilege, and reverse back from dead ends and intentional misdirections.
  • [6:41] The pod treasure map details many routes an attacker might explore within a Kubernetes cluster.
  • [6:49] Each scenario has only one intentional route, though players have found multiple bypasses, unintended shortcuts and wily workarounds as noble routes to completion.

Kubernetes Cluster Attack Surface

  • [7:10] A player starts with a terminal, IP address, and optional SSH authentication credentials for a Kubernetes cluster or other infrastructure.
  • [7:20] The first view is a root-enabled container running ncluster, where players must enumerate what is visible, uncover the invisible, and explore potential routes of compromise.
  • [7:36] Possible attack routes include hijacking sessions and credentials, attacking routable APIs and data stores, and escalating privilege through identity mechanisms.
  • [7:50] The speaker prefers bringing portable bash scripts to speed up enumeration and exploitation, and there are no rules on tooling as long as there is somewhere to execute it.
  • [8:04] Over the years they have examined many vulnerabilities and misconfigurations, including container image file system issues, runaway runtimes, malicious mounts, unsequestered secrets, privileged pod security policies, sensitive service accounts, no firewall networking, awful admission control, exposed etcds, terrible TLS implementations, federation failures, and control plane issues.
  • [8:43] The game was played remotely before and is being played in person this time, adapting to the pandemic.

Live breach simulation deployment at scale

  • [8:54] The high-pressure live deployment involved 2,500 nodes per day.
  • [9:10] They started with the open source breach simulator tool built to help control planes clients secure their clouds.
  • [9:14] One five-node cluster is provisioned for each scenario, and cluster reuse is not enabled.
  • [9:23] Provisioning engines backed by Knative scale to zero and are not centralized in a unified engine.
  • [9:33] A Pub/Sub queue and reentrant state machine try to ensure half provisioned clusters are forced into life and reinvigorated when half deployed.
  • [9:51] Unique credentials are distributed to each player for each scenario cluster pairing.
  • [10:01] Taskmasters are on hand in person and on Slack to hand out hints, offer suggestions and guide people through the challenges.
  • [10:13] They reached 2,500 nodes spun up per day with 80 to 100 participants.

Outage Stories and Lessons

  • [10:23] The speaker hopes to beat a record.
  • [10:30] The speaker asks what went wrong and jokes about claiming nothing happened.
  • [10:37] An AWS internal Ubuntu Mirror went down, so nothing completed provisioning and the simulator was dead in the water.
  • [10:49] Health checks were decidedly unhealthy, with a very red dashboard and a rising sense of panic.
  • [11:01] The incident required reprovisioning into a different region post-haste.
  • [11:06] Someone figured out how to bypass the initial SSH tunnel sandboxing.
  • [11:12] Securely provisioning and secure infrastructure is hard, and they don't want it too insecure.
  • [11:17] Cluster Admin RBAC credentials disappeared and found their way into a bastion node.
  • [11:26] The test suite only covers the happy paths.
  • [11:30] Through it all, they seem to have hit their goal.

Thanks and Advice for CTF Players

  • [11:36] The speaker thanks everyone who played the game, gave feedback, and enabled iteration on the platform.
  • [11:50] CTFs can often be big and feel daunting.
  • [11:55] The speaker hopes players focus on the learning experience and walk through the scenarios.
  • [12:03] If players feel like smashing machines, they should channel that.

Open Source Cloud Native Breach Simulation

  • [12:09] The clusters and scenarios are open source and run on a cloud native breach simulation.
  • [12:18] Under the Kubernetes simulator project there is a hosted version, and Control Plane is running a private beta for those who want to be involved.
  • [12:29] An out of bounds exception appears at the end of the slide, showing nothing is perfect.
  • [12:34] Attendees are invited to pop some shells with the presenters tomorrow.

[0:00] Hello and welcome. To our talk, Learn by Hacking. We're infinitely grateful that our arc saw the cloud native enlightenment, and we extend a heartfelt thank you. To you, the attendees, volunteers, contributors and the Cloud Native Computing Foundation involved in the vision and delivery of Kubernetes. Documentation and bug fixes do not write themselves, and the incredible selfless contributions that drive open source communities have never been more freely given or gracefully received.

[0:36] security controls are generally more difficult. to get right in complex orchestrations with the functionality that Kubernetes is known for. I'm sorry. To these security teams especially, We thank you for your hard work. The tax security CTFs are a reflection of the pioneering voyage of the good ship of Kubernetes. out in the choppy and dangerous free seas of the Internet. We have a free book available to download written by myself and my veritable co-author, Mr. Michael Hassenblass. There may be useful tips and tricks for individuals looking to assail the cloud-native infrastructure. If you're intrigued enough by this talk, to join us on Thursday.

[1:21] and play our new scenarios. So we're going to talk about how we run CTFs at Cloud Native Security Con over the past years. what we did, what we hope to achieve for you, the attendees, and how we maintained our fragile sanity. while provisioning thousands of notes on demand. per day. I Over the years, we have run CTFs in person, virtually. Planning for these events began in the ethereal and misty nights of 2019.

[1:55] As we looked to determine what it would take to put together a CTF running on Kubernetes for Kubernetes. without having the entire infrastructure come crumbling down around us. Nothing is more terrifying than building a self-hosted security game and inviting all and sundry to have a blast at it. Our goals are to communicate how best to secure cloud native infrastructure, They are red team scenarios with full demonstrations, teardowns and remediations.

[2:32] The best form, as Sun Tzu has told us, of defence is attack. Know thyself. And we look to give something back to the community that has so generously shared so much with us. here stands the nefarious #PirateCaptain leading the charge with his eponymous bag of Bitcoin. and the Untitled Goose that sparked so much security enthusiasm across the last few years.

[3:04] This is a learning experience for all skill levels, starting with an introductory scenario at each event, building up in difficulty, progressing as a game that gets more and more difficult throughout the journey to captivate and intrigue all skill levels and help nurture and seat the interest in and around security. With dedicated infrastructure, we look to emulate as much of the real-world systems at some cost of complexity. that we were going to delve slightly further into the presentation. The goal is not to find the ultimate security ninja but there rising tide that will lift all boats, and that players have fast feedback and support to enhance their learning experience.

[3:45] But first, here is a digital reconstruction by the street artist Banksy. of what a bunch of pirates would look like playing a cloud-native CTF. with a splash of stable diffusion for effect as well. So there is no such thing as secure software. As fast as we can possibly paint over the colourful selection of vulnerabilities in our infrastructure, new features are shipped. Software moves quickly.

[4:18] - and those new features potentially feature untested code paths. I'm not sure. And any of those untested code paths with security side effects are by default vulnerabilities. We prioritize shipping features over fixing vulnerabilities at our peril, of course. And this is the reality of modern software that we balance in our day-to-day every day. Resemblance to the friction we see between red teams and blue teams Any resemblance in that last animation is not a coincidence.

[4:57] Organizations not only evolve for competitive advantage, they must do so in order to survive because their adversaries are also evolving. So how do we represent that complex puzzle in a safe learning environment? As scenario authors, we look to construct the most realistic scenarios that we can manage. That includes building infrastructure diagrams and thread modeling scenarios. It helps us develop with the greatest degree of realism and is born from our experience consulting with regulated industries and startups alike.

[5:28] Here we can see a supply chain attack in progress. Captain Hashjack has attacked systems through various network systems in the past. including packing repositories, container registries, and the notable hypertext coffee pod control protocol. with no stone left unhindered, Running the platform on real infrastructure gives us the opportunity to emulate simulations we see in real life. Coffee pots and IoT attacks are not the exception.

[6:02] And we are looking to educate as many people as possible as effectively as we can, here we see a pod Security treasure map from the book, "Hacking Kubernetes," These scenarios are intentionally increasingly complex and difficult. This helps to crystallize players' understanding of a wide and complex security landscape and, as with all CTFs, Attendees and players must enumerate the visible horizon, escalate their privilege, reverse back from dead ends, and intentional misdirections.

[6:40] Bye. This pod treasure map details many of the routes that an attacker might explore within a Kubernetes cluster. But with each scenario, there is only one intentional route for a player to find, with the notes and caveats that players have found, multiple bypasses, unintended shortcuts and wily workarounds as noble routes to completion. So how is the CTF played? With a terminal, IP address, and optional authentication credentials for an SSH session, a Kubernetes cluster, or other mystery piece of infrastructure.

[7:20] Here we see the first view of a cluster that a player has when placed in a root-enabled container running ncluster. They must enumerate the visible, uncover the invisible, and start to explore potential routes of compromise in the cluster. This may include hijacking sessions and credentials, attacking APIs and data stores routable from the starting point, and escalating privilege through any and all identity mechanisms, a cloud-native system may have. My personal preference is to bring a portable set of bash scripts to speed up enumeration and exploitation.

[7:57] However, there are no rules what tooling you can bring with you. You just need to find somewhere to execute it from. Over the years, we have looked at a whole host of vulnerabilities and misconfigurations, from container image file system foobars and runaway runtimes to secure config, malicious mounts, unsequestered secrets, privileged pod security policies, sensitive service accounts, no firewall networking, awful admission control, exposed etcds, terrible TLS implementations, federation failures, chronic control plane control, and so on.

[8:34] configurations and unlimited user exposures. And there's more from Ingress to the kernel. We played this remotely. We're playing it in person this time around. adapting to the pandemic and running from virtual events, online gatherings, running the infrastructure over Slack, Peace was never an option. So how did we go about this high pressure live deployment of 2500 nodes across each day we play the game? We start with the open source breach simulator tool built to help control planes clients secure their clouds, One five-node cluster is provisioned for each scenario.

[9:18] I And cluster reuse is not enabled. We add a double dose of super massive provisioning engines backed by Knative, scaling to zero. These are not centralized in a unified engine. This sits on the back of a Pub/Sub queue and reentrant state machine, which tries to ensure that even half provisioned clusters are forced into life and reinvigorated when half deployed, which just means distributed systems, as we know, are hard.

[9:51] Then, the unique credentials are distributed to each player for each scenario cluster pairing, and the games begin. Our trusty Taskmasters are on hand in person and on Slack, to hand out hints, offer suggestions and guide people through the path of the challenges. All this adds up. We spin up the clusters as needed and we hit the lofty heights of two and a half thousand nodes spun up per day with 80 to 100 participants.

[10:23] We hope to beat this record. on Thursday, What has gone wrong? Would you really believe us if we said nothing? There was that. one time And AWS internal-- Ubuntu Mirror went down. As you can imagine, nothing completed provisioning. simulator was just Host, dead in the water. Health checks are decidedly unhealthy. to showcase that. Typical distributed system problems when EC2 wouldn't provision VMs, a very red dashboard, a rising sense of panic, came from it that required us reprovisioning into a different region post-haste.

[11:05] I'M NOT SURE. That time somebody figured out how to bypass the initial SH tunnel sandboxing, which was also interesting. securely provisioning and secure infrastructure is hard. We don't want it too insecure. When the Cluster Admin RBACs the RBAC credentials disappeared, gone. found their way into a bastion node when the test suite only cover the happy paths also. And through it all, we seem to have hit our goal. We're thankful to everybody who has played the game, given us feedback and given us the opportunity to iterate on this wonderful, thoroughly enjoyable platform that we love to play.

[11:50] CTFs can often be big. Can't feel daunting? So we hope that you focus on the learning experience. Walk through the scenarios. and If you feel like smashing machines, Channel that, please. And our clusters and scenarios today are of course, open source running on this cloud native breach simulation. Underneath the Kubernetes simulator project, there is a hosted version and Control Plane are running a private beta if you would like to be involved.

[12:28] As you can see, Nothing is perfect, there's an out of bounds exception on the end of the slide, if you would like to pop some shells with us please come and play tomorrow. Thank you.

查看原始字幕

[0:00] Hello and welcome. To our talk, Learn by Hacking. We're infinitely grateful that our arc saw the cloud native enlightenment, and we extend a heartfelt thank you. To you, the attendees, volunteers, contributors and the Cloud Native Computing Foundation involved in the vision and delivery of Kubernetes. Documentation and bug fixes do not write themselves, and the incredible selfless contributions that drive open source communities have never been more freely given or gracefully received.

[0:36] security controls are generally more difficult. to get right in complex orchestrations with the functionality that Kubernetes is known for. I'm sorry. To these security teams especially, We thank you for your hard work. The tax security CTFs are a reflection of the pioneering voyage of the good ship of Kubernetes. out in the choppy and dangerous free seas of the Internet. We have a free book available to download written by myself and my veritable co-author, Mr. Michael Hassenblass. There may be useful tips and tricks for individuals looking to assail the cloud-native infrastructure. If you're intrigued enough by this talk, to join us on Thursday.

[1:21] and play our new scenarios. So we're going to talk about how we run CTFs at Cloud Native Security Con over the past years. what we did, what we hope to achieve for you, the attendees, and how we maintained our fragile sanity. while provisioning thousands of notes on demand. per day. I Over the years, we have run CTFs in person, virtually. Planning for these events began in the ethereal and misty nights of 2019.

[1:55] As we looked to determine what it would take to put together a CTF running on Kubernetes for Kubernetes. without having the entire infrastructure come crumbling down around us. Nothing is more terrifying than building a self-hosted security game and inviting all and sundry to have a blast at it. Our goals are to communicate how best to secure cloud native infrastructure, They are red team scenarios with full demonstrations, teardowns and remediations.

[2:32] The best form, as Sun Tzu has told us, of defence is attack. Know thyself. And we look to give something back to the community that has so generously shared so much with us. here stands the nefarious #PirateCaptain leading the charge with his eponymous bag of Bitcoin. and the Untitled Goose that sparked so much security enthusiasm across the last few years.

[3:04] This is a learning experience for all skill levels, starting with an introductory scenario at each event, building up in difficulty, progressing as a game that gets more and more difficult throughout the journey to captivate and intrigue all skill levels and help nurture and seat the interest in and around security. With dedicated infrastructure, we look to emulate as much of the real-world systems at some cost of complexity. that we were going to delve slightly further into the presentation. The goal is not to find the ultimate security ninja but there rising tide that will lift all boats, and that players have fast feedback and support to enhance their learning experience.

[3:45] But first, here is a digital reconstruction by the street artist Banksy. of what a bunch of pirates would look like playing a cloud-native CTF. with a splash of stable diffusion for effect as well. So there is no such thing as secure software. As fast as we can possibly paint over the colourful selection of vulnerabilities in our infrastructure, new features are shipped. Software moves quickly.

[4:18] - and those new features potentially feature untested code paths. I'm not sure. And any of those untested code paths with security side effects are by default vulnerabilities. We prioritize shipping features over fixing vulnerabilities at our peril, of course. And this is the reality of modern software that we balance in our day-to-day every day. Resemblance to the friction we see between red teams and blue teams Any resemblance in that last animation is not a coincidence.

[4:57] Organizations not only evolve for competitive advantage, they must do so in order to survive because their adversaries are also evolving. So how do we represent that complex puzzle in a safe learning environment? As scenario authors, we look to construct the most realistic scenarios that we can manage. That includes building infrastructure diagrams and thread modeling scenarios. It helps us develop with the greatest degree of realism and is born from our experience consulting with regulated industries and startups alike.

[5:28] Here we can see a supply chain attack in progress. Captain Hashjack has attacked systems through various network systems in the past. including packing repositories, container registries, and the notable hypertext coffee pod control protocol. with no stone left unhindered, Running the platform on real infrastructure gives us the opportunity to emulate simulations we see in real life. Coffee pots and IoT attacks are not the exception.

[6:02] And we are looking to educate as many people as possible as effectively as we can, here we see a pod Security treasure map from the book, "Hacking Kubernetes," These scenarios are intentionally increasingly complex and difficult. This helps to crystallize players' understanding of a wide and complex security landscape and, as with all CTFs, Attendees and players must enumerate the visible horizon, escalate their privilege, reverse back from dead ends, and intentional misdirections.

[6:40] Bye. This pod treasure map details many of the routes that an attacker might explore within a Kubernetes cluster. But with each scenario, there is only one intentional route for a player to find, with the notes and caveats that players have found, multiple bypasses, unintended shortcuts and wily workarounds as noble routes to completion. So how is the CTF played? With a terminal, IP address, and optional authentication credentials for an SSH session, a Kubernetes cluster, or other mystery piece of infrastructure.

[7:20] Here we see the first view of a cluster that a player has when placed in a root-enabled container running ncluster. They must enumerate the visible, uncover the invisible, and start to explore potential routes of compromise in the cluster. This may include hijacking sessions and credentials, attacking APIs and data stores routable from the starting point, and escalating privilege through any and all identity mechanisms, a cloud-native system may have. My personal preference is to bring a portable set of bash scripts to speed up enumeration and exploitation.

[7:57] However, there are no rules what tooling you can bring with you. You just need to find somewhere to execute it from. Over the years, we have looked at a whole host of vulnerabilities and misconfigurations, from container image file system foobars and runaway runtimes to secure config, malicious mounts, unsequestered secrets, privileged pod security policies, sensitive service accounts, no firewall networking, awful admission control, exposed etcds, terrible TLS implementations, federation failures, chronic control plane control, and so on.

[8:34] configurations and unlimited user exposures. And there's more from Ingress to the kernel. We played this remotely. We're playing it in person this time around. adapting to the pandemic and running from virtual events, online gatherings, running the infrastructure over Slack, Peace was never an option. So how did we go about this high pressure live deployment of 2500 nodes across each day we play the game? We start with the open source breach simulator tool built to help control planes clients secure their clouds, One five-node cluster is provisioned for each scenario.

[9:18] I And cluster reuse is not enabled. We add a double dose of super massive provisioning engines backed by Knative, scaling to zero. These are not centralized in a unified engine. This sits on the back of a Pub/Sub queue and reentrant state machine, which tries to ensure that even half provisioned clusters are forced into life and reinvigorated when half deployed, which just means distributed systems, as we know, are hard.

[9:51] Then, the unique credentials are distributed to each player for each scenario cluster pairing, and the games begin. Our trusty Taskmasters are on hand in person and on Slack, to hand out hints, offer suggestions and guide people through the path of the challenges. All this adds up. We spin up the clusters as needed and we hit the lofty heights of two and a half thousand nodes spun up per day with 80 to 100 participants.

[10:23] We hope to beat this record. on Thursday, What has gone wrong? Would you really believe us if we said nothing? There was that. one time And AWS internal-- Ubuntu Mirror went down. As you can imagine, nothing completed provisioning. simulator was just Host, dead in the water. Health checks are decidedly unhealthy. to showcase that. Typical distributed system problems when EC2 wouldn't provision VMs, a very red dashboard, a rising sense of panic, came from it that required us reprovisioning into a different region post-haste.

[11:05] I'M NOT SURE. That time somebody figured out how to bypass the initial SH tunnel sandboxing, which was also interesting. securely provisioning and secure infrastructure is hard. We don't want it too insecure. When the Cluster Admin RBACs the RBAC credentials disappeared, gone. found their way into a bastion node when the test suite only cover the happy paths also. And through it all, we seem to have hit our goal We're thankful to everybody who has played the game, given us feedback and given us the opportunity to iterate on this wonderful, thoroughly enjoyable platform that we love to play.

[11:50] CTFs can often be big. Can't feel daunting? So we hope that you focus on the learning experience. Walk through the scenarios. and If you feel like smashing machines, Channel that, please. And our clusters and scenarios today are of course, open source running on this cloud native breach simulation. Underneath the Kubernetes simulator project, there is a hosted version and Control Plane are running a private beta if you would like to be involved.

[12:28] As you can see, Nothing is perfect, there's an out of bounds exception on the end of the slide, if you would like to pop some shells with us please come and play tomorrow. Thank you.

在 Vidleaf 工作台開啟

檢索字幕、選取句子、複製附時間戳的引用,或按需翻譯。

在工作台開啟 →

來源署名

「Keynote: Learn by Hacking: How to Run a 2,500 Node Kubernetes CTF - Andrew Martin & Andrés Vega」由 CNCF [Cloud Native Computing Foundation] 發布,採用 CC BY 3.0 授權。來源影片:https://www.youtube.com/watch?v=DCAumwUKlF0。此頁呈現影片的文字字幕,由 Vidleaf 加入段落與時間戳。創作者與 Vidleaf 無隸屬或背書關係。頁面若提供 AI 標點、名稱修正或摘要,會分開標示,原始字幕仍可查看。

若你是創作者或權利人,可申請更正或下架: copyright@vidleaf.app (參閱 關於這些頁面)。

最後更新