# SREDevOps.org > SRE, DevOps, Kubernetes, Linux, Open Source, Cloud Native en Español and English Public Ghost content for AI and LLM tooling. This file includes a bounded export of public pages first, then recent public posts. Append `.md` to any post or page URL to get the content in Markdown (for example, `/example-post.md`). ## Pages ### Privacy Policy URL: https://www.sredevops.org/privacy-policy/ Last updated: 2026-01-11T18:51:08.000Z SREDevOps.org operates the https://www.sredevops.org website, which provides the SERVICE. This page is used to inform website visitors regarding our policies with the collection, use, and disclosure of Personal Information if anyone decided to use our Service, the SREDevOps.org website. If you choose to use our Service, then you agree to the collection and use of information in relation with this policy. The Personal Information that we collect are used for providing and improving the Service. We will not use or share your information with anyone except as described in this Privacy Policy. The terms used in this Privacy Policy have the same meanings as in our Terms and Conditions, which is accessible at https://sredevops.org, unless otherwise defined in this Privacy Policy. ## Information Collection and Use For a better experience while using our Service, we may require you to provide us with certain personally identifiable information, including but not limited to your name, phone number, and postal address. The information that we collect will be used to contact or identify you. ## Log Data We want to inform you that whenever you visit our Service, we collect information that your browser sends to us that is called Log Data. This Log Data may include information such as your computer's Internet Protocol ("IP") address, browser version, pages of our Service that you visit, the time and date of your visit, the time spent on those pages, and other statistics. ## Cookies Cookies are files with small amount of data that is commonly used an anonymous unique identifier. These are sent to your browser from the website that you visit and are stored on your computer's hard drive. Our website uses these "cookies" to collection information and to improve our Service. You have the option to either accept or refuse these cookies, and know when a cookie is being sent to your computer. If you choose to refuse our cookies, you may not be able to use some portions of our Service. ## Service Providers We may employ third-party companies and individuals due to the following reasons: - To facilitate our Service; - To provide the Service on our behalf; - To perform Service-related services; or - To assist us in analyzing how our Service is used. We want to inform our Service users that these third parties have access to your Personal Information. The reason is to perform the tasks assigned to them on our behalf. However, they are obligated not to disclose or use the information for any other purpose. ## Security We value your trust in providing us your Personal Information, thus we are striving to use commercially acceptable means of protecting it. But remember that no method of transmission over the internet, or method of electronic storage is 100% secure and reliable, and we cannot guarantee its absolute security. ## Links to Other Sites Our Service may contain links to other sites. If you click on a third-party link, you will be directed to that site. Note that these external sites are not operated by us. Therefore, we strongly advise you to review the Privacy Policy of these websites. We have no control over, and assume no responsibility for the content, privacy policies, or practices of any third-party sites or services. ## Children's Privacy Our Services do not address anyone under the age of 13\. We do not knowingly collect personal identifiable information from children under 13\. In the case we discover that a child under 13 has provided us with personal information, we immediately delete this from our servers. If you are a parent or guardian and you are aware that your child has provided us with personal information, please contact us so that we will be able to do necessary actions. ## Changes to This Privacy Policy We may update our Privacy Policy from time to time. Thus, we advise you to review this page periodically for any changes. We will notify you of any changes by posting the new Privacy Policy on this page. These changes are effective immediately, after they are posted on this page. ## Contact Us If you have any questions or suggestions about our Privacy Policy, do not hesitate to contact us. [About UsAt SREDevOps.org, we’re all about helping people and organizations thrive using open-source technology. We truly believe that when tools and knowledge are shared openly, everyone wins. It’s the best way to drive innovation and help the whole tech community grow together. For us, it’s not just![](https://www.sredevops.org/content/images/icon/Icon-App-76x76@2x-15.png)SREDevOps.orgNicolás Georger![](https://www.sredevops.org/content/images/thumbnail/sredevops-org-logo.webp)](https://www.sredevops.org/about-us/) [Sobre NosotrosEn SREDevOps.org, queremos ayudar a la gente y a las organizaciones a progresar usando tecnología open-source. Creemos firmemente que cuando las herramientas y el conocimiento se comparten abiertamente, todos ganan. Es la mejor forma de impulsar la innovación y ayudar a toda la comunidad tech a crecer junta. Para![](https://www.sredevops.org/content/images/icon/Icon-App-76x76@2x-16.png)SREDevOps.orgNicolás Georger![](https://www.sredevops.org/content/images/thumbnail/sredevops-org-logo-1.webp)](https://www.sredevops.org/que-es-sredevops/) ### About Us URL: https://www.sredevops.org/about-us/ Last updated: 2026-04-20T08:12:04.000Z At **SREDevOps.org, we’re all about helping people and organizations thrive using open-source technology**. We truly believe that when tools and knowledge are shared openly, everyone wins. It’s the best way to drive innovation and help the whole tech community grow together. For us, it’s not just about the code—it’s about building a diverse, fair space where everyone can contribute to solving complex problems. **We aim for a long-term, sustainable approach that uses technology to make a real, positive impact on society.** If you’re looking to sharpen your skills, we’ve got plenty of resources to help. We regularly put out news, tutorials, and deep-dive guides on everything from Linux and Docker to Kubernetes, AI, and Cloud Native tech. But we’re more than just a content site; we’re a global community. We connect professionals through meetups, workshops, and webinars so we can all stay on top of industry trends and help each other solve real-world challenges. **Whether your focus is on SRE, DevSecOps, Platform Engineering, or ethical hacking, you'll find a home here.** Our team is led by Nicolás Georger, who founded the site, alongside Diego Mondini, our lead in Brazil, Rudy Pinochet, who supports us as an advisor and collaborator and Manuel Morejón as a writer and collaborator. To make sure our resources reach as many people as possible, we offer content in [Español / Castellano](https://www.sredevops.org/es/), [English](https://www.sredevops.org/en/) and [Portuguese](https://www.sredevops.org/br/). We’re very active on social media, so feel free to hang out with us on [Discord](https://discord.com/invite/bK9rXFTvpk?ref=sredevops.org), [Slack](https://join.slack.com/t/sredevopsorg/shared%5Finvite/zt-2m6bmgp86-zMKo8SMnM3j1%5Fw9IE8BMeg?ref=sredevops.org), [GitHub](https://github.com/sredevopsorg?ref=sredevops.org), [LinkedIn](https://www.linkedin.com/company/sredevops/?ref=sredevops.org), [X (Twitter)](https://x.com/sredevopsorg?ref=sredevops.org), [Instagram](https://www.instagram.com/sredevopsorg/?ref=sredevops.org), [Mastodon](https://mastodon.social/@sredevopsorg?ref=sredevops.org), [YouTube](https://www.youtube.com/@sredevopsorg?ref=sredevops.org), [Threads](https://www.threads.net/@sredevopsorg?ref=sredevops.org). We’re always looking for fresh voices to join the mission. If you’d like to write an article for the blog, propose a talk for one of our meetups, or jump into our open-source projects, we’d love to hear from you. For partnerships, sponsorships, or just to say hello, you can reach out to Nicolás directly at info@sredevops.org. Come join the SREDevOps.org community and let’s build something great together. ## Our Team | Name | Role | GitHub | LinkedIn | Email | | ---------------------------------------------------------------- | --------------------- | ------------------------------------------------------------ | -------------------------------------------------------------------------- | ----------------------------------------------------------------- | | [Nicolás Georger](https://www.sredevops.org/author/ngeorger/) | Founder | [@ngeorger](https://github.com/ngeorger?ref=sredevops.org) | [LinkedIn](https://www.linkedin.com/in/nicolas-georger/?ref=sredevops.org) | [info@sredevops.org](mailto:info@sredevops.org) | | [Diego Mondini](https://www.sredevops.org/author/diego-mondini/) | Brazil Lead | [@mondiniit](https://github.com/mondiniit?ref=sredevops.org) | [LinkedIn](https://www.linkedin.com/in/diegomondini/?ref=sredevops.org) | [diego.mg@sredevops.org](mailto:diego.mg@sredevops.org) | | Rudy Pinochet | Advisor, Collaborator | [@rudy500](https://github.com/rudy500?ref=sredevops.org) | [LinkedIn](https://www.linkedin.com/in/rudypinochet/?ref=sredevops.org) | [rudy.pinochet@sredevops.org](mailto:rudy.pinochet@sredevops.org) | | [Manuel Morejón](https://www.sredevops.org/author/mmorejon/) | Writer, collaborator | [@mmorejon](https://github.com/mmorejon?ref=sredevops.org) | [LinkedIn](https://www.linkedin.com/in/manuelmorejon/?ref=sredevops.org) | \- | ### Tags URL: https://www.sredevops.org/tags/ Last updated: 2024-06-30T05:39:42.000Z 💡 Categorías en [SREDevOps.org](https://sredevops.org/?ref=sredevops.org) ### Terms of Service for SREDevOps.org URL: https://www.sredevops.org/terms-of-service/ Last updated: 2025-12-07T22:45:59.000Z ## ### 1\. Introduction This website, **SREDevOps.org**, provides a platform for sharing knowledge and resources related to Site Reliability Engineering and DevOps practices. These Terms of Service ("Terms") govern your access and use of the Site. ### 2\. User Conduct You agree to: - Use the Site for lawful purposes only. - Provide accurate and non-harmful information. - Respect the privacy of others. - Not modify, alter, or decompile the Site. - Not use the Site for commercial purposes. ### 3\. Content Ownership Content published on the Site is the property of SREDevOps.org and its contributors. It is protected by applicable intellectual property laws. ### 4\. Limited Liability SREDevOps.org provides the Site on an "as is" basis and without warranty, express or implied. We make no representations or warranties regarding the accuracy, completeness, or usefulness of the information on the Site. ### 5\. External Links The Site may contain links to other websites and resources. SREDevOps.org is not responsible for the content or policies of any other website to which the Site may link. ### 6\. Changes to Terms SREDevOps.org reserves the right to update or modify these Terms at any time. Notice of any changes will be posted on the Site. ### 7\. Law and Jurisdiction These Terms are governed by the laws of the Republic of Chile, without regard to conflict of law principles. Any dispute arising out of or relating to these Terms shall be settled in the courts of competent jurisdiction in Santiago, Chile. ### 8\. Entire Agreement These Terms constitute the entire agreement between you and SREDevOps.org relating to your access and use of the Site. ### 9\. Contact Information For any questions or concerns regarding these Terms, please contact us at info@sredevops.org ### 10\. Effective Date These Terms are effective as of August 06 2024 ### Contact Us URL: https://www.sredevops.org/contact-us/ Last updated: 2024-10-25T09:55:31.000Z ## Do you want to contribute? Contact us if you want to: - Write an article for our blog - Propose a talk for our next meetup - Collaborate on our open source projects ## Partnerships and sponsorship Contact: info@sredevops.org (Nicolás Georger) ### Recommendations URL: https://www.sredevops.org/recommendations/ Last updated: 2024-09-15T04:53:54.000Z _No content available._ ### Our Open Source Projects URL: https://www.sredevops.org/our-open-source-projects/ Last updated: 2026-07-16T08:29:57.000Z ## SREDevOps.org Open Source Projects: Technical Deep Dive Here you can find detailed information on the [open-source projects managed by SREDevOps.org](https://github.com/sredevopsorg/?ref=sredevops.org), focusing on technical specifications and deployment strategies. ## 1\. Ghost on Kubernetes A highly optimized and secure deployment of the Ghost CMS for container orchestration environments. | **Detail** | **Specification** | | -------------------- | ---------------------------------------------------------------------------------------------------------------------------- | | **Goal** | Provide a hardened, production-ready Ghost v6 deployment for Kubernetes. | | **Key Feature** | Uses a custom, hardened distroless non-root image for enhanced security and minimized attack surface. | | **Target Platforms** | Kubernetes (k8s), k3s, and other related orchestration systems. | | **Repository** | [https://github.com/sredevopsorg/ghost-on-kubernetes](https://github.com/sredevopsorg/ghost-on-kubernetes?ref=sredevops.org) | ### **Deployment Instructions** - **English:** [How to deploy Ghost CMS on Kubernetes](https://www.sredevops.org/en/how-to-deploy-ghost-cms-on-kubernetes/) - **Español:** [Cómo desplegar Ghost (CMS/Blog) en Kubernetes](https://www.sredevops.org/es/como-desplegar-ghost-en-kubernetes/) [GitHub - sredevopsorg/ghost-on-kubernetes: Ghost on Kubernetes by SREDevOps.org - Deploy Ghost v6 on Kubernetes (k8s, k3s, etc) with our hardened distroless non root custom image.Ghost on Kubernetes by SREDevOps.org - Deploy Ghost v6 on Kubernetes (k8s, k3s, etc) with our hardened distroless non root custom image. - sredevopsorg/ghost-on-kubernetes![](https://www.sredevops.org/content/images/icon/pinned-octocat-093da3e6fa40-32.svg)GitHubsredevopsorg![](https://www.sredevops.org/content/images/thumbnail/395b82c9-df81-4aee-95a5-4269616a550f-6)](https://github.com/sredevopsorg/ghost-on-kubernetes?ref=sredevops.org) ## 2\. Multi-Architecture Docker Build with Native GitHub Runners A robust CI/CD workflow that accelerates container image creation by leveraging native GitHub runners, eliminating the need for emulation. | **Detail** | **Specification** | | ----------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Goal** | Efficiently build Docker images that support multiple CPU architectures (e.g., amd64, arm64). | | **Methodology** | Utilizes native GitHub Actions runners across different architectures. | | **Technical Advantage** | Bypasses QEMU emulation, resulting in faster, more reliable, and native-performance multi-arch builds. | | **Repository** | [https://github.com/sredevopsorg/multi-arch-docker-github-workflow](https://github.com/sredevopsorg/multi-arch-docker-github-workflow?ref=sredevops.org) | ### **Instructional Guide** - **English:** [Kiss Goodbye to QEMU: Unleash the Power of Native GitHub Runners for Multi-Arch Docker Images](https://www.sredevops.org/en/kiss-goodbye-to-qemu-unleash-the-power-of-native-github-runners-for-multi-arch-docker-images/) [GitHub - sredevopsorg/multi-arch-docker-github-workflow: How to build a Multi-Architecture Docker Image in Github Actions using multiple runners without QEMUHow to build a Multi-Architecture Docker Image in Github Actions using multiple runners without QEMU - sredevopsorg/multi-arch-docker-github-workflow![](https://www.sredevops.org/content/images/icon/pinned-octocat-093da3e6fa40-31.svg)GitHubsredevopsorg![](https://www.sredevops.org/content/images/thumbnail/multi-arch-docker-github-workflow-2)](https://github.com/sredevopsorg/multi-arch-docker-github-workflow?ref=sredevops.org) ## 3\. SREDevOps.org Ghost Theme A modern, functional theme designed specifically for the Ghost publishing platform. | **Detail** | **Specification** | | ------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | | **Goal** | Provide a high-quality, modern, and accessible theme for Ghost v6. | | **Core Framework** | Tailwind CSS v3 for utility-first styling. | | **Design Features** | Fully responsive design, native dark color schema, SVG icons, and enhanced navigation (sidebar + footer). | | **Repository** | [https://github.com/sredevopsorg/sredevopsorg-ghost-theme](https://github.com/sredevopsorg/sredevopsorg-ghost-theme?ref=sredevops.org) | [GitHub - sredevopsorg/sredevopsorg-ghost-theme: A Ghost v5 Theme made for SREDevOps.org based on Tailwind CSS with sidebar navigation and dark theme by default.A Ghost v5 Theme made for SREDevOps.org based on Tailwind CSS with sidebar navigation and dark theme by default. - sredevopsorg/sredevopsorg-ghost-theme![](https://www.sredevops.org/content/images/icon/pinned-octocat-093da3e6fa40-30.svg)GitHubsredevopsorg![](https://www.sredevops.org/content/images/thumbnail/sredevopsorg-ghost-theme-1)](https://github.com/sredevopsorg/sredevopsorg-ghost-theme?ref=sredevops.org) ### Quiénes somos URL: https://www.sredevops.org/que-es-sredevops/ Last updated: 2026-06-03T00:54:00.000Z En **SREDevOps.org, nos dedicamos plenamente a ayudar a personas y organizaciones a prosperar utilizando tecnología de código abierto**. Creemos firmemente que cuando las herramientas y el conocimiento se comparten abiertamente, todos ganan. Es la mejor manera de impulsar la innovación y ayudar a que toda la comunidad tecnológica crezca unida. Para nosotros, no se trata solo del código, sino de construir un espacio diverso y justo donde todos puedan contribuir a resolver problemas complejos. **Buscamos un enfoque sostenible a largo plazo que utilice la tecnología para generar un impacto real y positivo en la sociedad.** ✒️ Siempre estamos buscando voces nuevas que se unan a la misión. Si te gustaría escribir un artículo para el blog, proponer una charla para uno de nuestros meetups o sumarte a nuestros proyectos de código abierto, nos encantaría saber de ti. Para alianzas, patrocinios o simplemente para saludar, puedes contactar a Nicolás directamente en info@sredevops.org. Si buscas perfeccionar tus habilidades, tenemos muchos recursos para ayudarte. Publicamos regularmente noticias, tutoriales y guías detalladas sobre todo, desde Linux y Docker hasta Kubernetes, IA y tecnología Cloud Native. Pero somos más que un sitio de contenido; somos una comunidad global. Conectamos a profesionales a través de meetups, talleres y seminarios web para que todos podamos estar al día con las tendencias de la industria y ayudarnos mutuamente a resolver desafíos del mundo real. **Ya sea que tu enfoque esté en SRE, DevSecOps, Platform Engineering o hacking ético, encontrarás un lugar aquí.** Nuestro equipo es liderado por Nicolás Georger, quien fundó el sitio, junto con Diego Mondini, nuestro líder en Brasil, Rudy Pinochet, quien nos apoya como asesor y colaborador, y Manuel Morejón como escritor y colaborador. Para asegurar que nuestros recursos lleguen a la mayor cantidad de personas posible, ofrecemos contenido en [Español / Castellano](https://www.sredevops.org/es/), [Inglés](https://www.sredevops.org/en/) y [Portugués](https://www.sredevops.org/br/). Somos muy activos en las redes sociales, así que siéntete libre de pasar tiempo con nosotros en [Discord](https://discord.com/invite/bK9rXFTvpk?ref=sredevops.org), [Slack](https://join.slack.com/t/sredevopsorg/shared%5Finvite/zt-2m6bmgp86-zMKo8SMnM3j1%5Fw9IE8BMeg?ref=sredevops.org), [GitHub](https://github.com/sredevopsorg?ref=sredevops.org), [LinkedIn](https://www.linkedin.com/company/sredevops/?ref=sredevops.org), [X (Twitter)](https://x.com/sredevopsorg?ref=sredevops.org), [Instagram](https://www.instagram.com/sredevopsorg/?ref=sredevops.org), [Mastodon](https://mastodon.social/@sredevopsorg?ref=sredevops.org), [YouTube](https://www.youtube.com/@sredevopsorg?ref=sredevops.org), [Threads](https://www.threads.net/@sredevopsorg?ref=sredevops.org). ## Nuestro Equipo | Nombre | Rol | GitHub | LinkedIn | Email | | ---------------------------------------------------------------- | --------------------- | ------------------------------------------------------------ | -------------------------------------------------------------------------- | ----------------------------------------------------------------- | | [Nicolás Georger](https://www.sredevops.org/author/ngeorger/) | Fundador | [@ngeorger](https://github.com/ngeorger?ref=sredevops.org) | [LinkedIn](https://www.linkedin.com/in/nicolas-georger/?ref=sredevops.org) | [info@sredevops.org](mailto:info@sredevops.org) | | [Diego Mondini](https://www.sredevops.org/author/diego-mondini/) | Líder en Brasil | [@mondiniit](https://github.com/mondiniit?ref=sredevops.org) | [LinkedIn](https://www.linkedin.com/in/diegomondini/?ref=sredevops.org) | [diego.mg@sredevops.org](mailto:diego.mg@sredevops.org) | | Rudy Pinochet | Asesor, Colaborador | [@rudy500](https://github.com/rudy500?ref=sredevops.org) | [LinkedIn](https://www.linkedin.com/in/rudypinochet/?ref=sredevops.org) | [rudy.pinochet@sredevops.org](mailto:rudy.pinochet@sredevops.org) | | [Manuel Morejón](https://www.sredevops.org/author/mmorejon/) | Escritor, colaborador | [@mmorejon](https://github.com/mmorejon?ref=sredevops.org) | [LinkedIn](https://www.linkedin.com/in/manuelmorejon/?ref=sredevops.org) | \- | ## Posts ### Netflix está buscando pensadores sistémicos -no especialistas- en la era de la IA URL: https://www.sredevops.org/es/netflix-esta-buscando-pensadores-sistemicos-no-especialistas-en-la-era-de-la-ia/ Last updated: 2026-08-08T16:37:09.000Z 💬 **Los agentes pueden escribir más del código. Los ingenieros pasarán más tiempo revisando, clasificando y conduciendo.* ***Pero si no puedes saber por qué un sistema está roto, no puedes arreglarlo.** *Si no puedes saber si un producto es realmente bueno, no puedes ser dueño del resultado.* [Elizabeth Stone, Chief Product and Technology Officer](https://www.linkedin.com/in/elizabeth-stone-608a754/?ref=sredevops.org) de Netflix, volvió al podcast de Lenny con un mensaje que resonará con cualquiera que sienta su trabajo amenazado y su futuro incierto : la IA ha creado una "fase de tormenta" para el trabajo en sí mismo. La solución no es meter la IA de vuelta en el cajón ni enterrar la confusión o los riesgos bajo más procesos. Es contratar y desarrollar más **pensadores sistémicos**. La conversación de Stone cubre escalafones profesionales, el *keeper’s test*, la *densidad de talento*, el futuro del entretenimiento y **por qué "todos pueden ser todo ahora" es a la vez una oportunidad y un dolor de cabeza para el liderazgo.** ## Conclusiones clave - La IA está produciendo una fase de tormenta antes de una fase de formación. Eso es normal, pero no significa que todos deberían estar desplegando en producción. - La excelencia en el oficio sigue siendo escasa. La gran ingeniería, la gran ciencia de datos y la gran creatividad siguen siendo difíciles de encontrar. - El pensamiento sistémico es la nueva especialización: personas que pueden abstraer a través de dominios de negocio en bloques de construcción reutilizables. - La especialización estrecha y profunda se está volviendo más riesgosa. Los generalistas y los especialistas adaptables tienen la ventaja. - La fluidez en IA es una capa extra sobre los escalafones profesionales, no una reescritura de cada nivel. - El sistema operativo de Netflix sigue siendo densidad de talento, tolerancia al riesgo y una negativa testaruda a dejar que el proceso reemplace al juicio. ## La fase de tormenta: todos pueden ser todo ahora Stone escucha la misma pregunta de los equipos dentro de Netflix que Lenny escucha de la industria en general: "¿Y ahora cuál es mi pega?" > "Cada vez que aparece una tecnología nueva, pasas por una fase de tormenta antes de la fase de formación. Estamos en medio de eso ahora mismo. No creo que eso signifique que debamos meter la IA de vuelta en la caja y decir: ‘No la usemos’." El desdibujamiento es real: los PMs pueden prototipar código. Los diseñadores pueden escribir PRDs. Los ingenieros pueden hacer producto. Los científicos de datos pueden generar análisis antes de que un ingeniero siquiera abra un ticket. ¿La visión de Stone? Algo de fluidez es sano, pero solo cuando el problema de negocio está claro: - Producto y diseño deberían poder moverse más rápido sin esperar a que ingeniería asigne recursos para un prototipo. - De todas formas, deberían trabajar con ingeniería en escalabilidad, seguridad y en cómo convertir la idea en producto. - Y un humano sigue siendo dueño del resultado. > "Puede ser que un agente haya escrito el código, o que yo haya ayudado con un análisis cuando esa no es realmente mi área, pero eso no quita la responsabilidad de las personas sobre lo que han creado." La respuesta no es "meter la IA de vuelta en la caja". Es invertir en datos de fuente de verdad, salvaguardas e infraestructura compartida para que la experimentación no se convierta en mil prototipos espagueti desconectados. ## El oficio sigue importando—especialmente cuando la IA escribe el primer borrador Si todos son creadores, ¿siguen existiendo funciones separadas? La respuesta de Stone es un sí enfático. > "Todavía veo una excelencia en el oficio que es muy importante y que no creo que vaya a desaparecer pronto. Sigo viendo que la gran ingeniería es escasa, la gran ciencia de datos es escasa y la gran creatividad es escasa." Ella ve ventajas comparativas que persisten: - Los **científicos de datos** son dueños de si los datos son confiables y de cómo interpretarlos. - Los **PMs** son dueños de si el problema fue planteado correctamente. - Los **ingenieros** son dueños de cómo escalan los sistemas, cómo se rompen y cómo se ve una producción de alta calidad. La IA puede ayudar a que todos hablen más de estos lenguajes, pero no reemplaza el juicio que viene del oficio profundo. ## El pensamiento sistémico es la nueva especialización El mayor cambio de contratación que Stone ve en Netflix no es "más ingenieros de IA" ni "menos PMs". Es una demanda por personas que puedan pensar a través de dominios. > "Necesitamos más pensadores sistémicos—personas que puedan mirar todos los dominios de negocio y abstraer eso en ‘estos son los bloques de construcción que vamos a necesitar’." En ingeniería, eso significa más inversión en infraestructura central, caminos comunes pavimentados y bloques de construcción compartidos. Netflix históricamente dejaba que los equipos locales construyeran lo que necesitaran para moverse rápido. En un mundo de agentes de IA, ese enfoque se convierte en una responsabilidad. Los agentes necesitan datos de fuente de verdad. Necesitan consistencia en control de acceso y seguridad. Necesitan formas de trabajo comunes. Así que Netflix está contratando más personas que puedan diseñar el río completo, no solo navegar un rápido. El mismo patrón aparece en el diseño. > "Me pongo muy nerviosa cuando hay diferentes lenguajes de diseño o diferentes tipos de interacciones de usuario y terminamos enviando Frankensteins, básicamente." Se espera cada vez más que los diseñadores construyan sistemas de diseño, plantillas y expresión de marca que permitan a los no diseñadores producir experiencias coherentes. El oficio no ha desaparecido; ha subido un nivel en la stack. ## El declive del especialista "estrecho" Stone tiene cuidado de no declarar extintos a los especialistas. Todavía hay lugares donde la experiencia profunda en un tema es esencial: codificación, sistemas de reproducción, marketplaces publicitarios y otros rincones de Netflix que requieren años de conocimiento acumulado. Pero como regla general, la era del especialista estrecho se ve limitada. > "Los días de la especialización muy estrecha y profunda me parecen más limitados." En comparación con hace cinco o diez años, Stone ve menos especialistas y más generalistas adaptables. También ve un problema de mentalidad en personas que quieren quedarse en un solo carril estrecho: > "Creo que la mentalidad ahora tiene que ser: ‘Puedo aprender eso rápido’. Y eso nos lleva de vuelta al pensamiento sistémico. Creo que los especialistas pueden aprender a tener una variedad más amplia de herramientas más fácilmente de lo que era posible en el pasado." El riesgo no es tener una especialidad. El riesgo es tratar tu especialidad como un refugio permanente. ## Cómo practicar el pensamiento sistémico: Detenerse y retroceder un paso A Stone le preguntan cómo desarrollar el pensamiento sistémico. Su consejo es refrescantemente práctico: > "Truco pequeño: Para cada problema que intentas resolver, detente, retrocede un paso y pregúntate: ‘¿Qué estoy asumiendo como cierto sobre el contexto más amplio?’" Por ejemplo, si te piden construir una feature para la experiencia de los miembros de Netflix, **haz una pausa antes de escribir una línea de código**: - ¿Qué problema más grande del consumidor está resolviendo esto? - ¿Qué estoy asumiendo sobre el contenido, los dispositivos o los casos de uso? - ¿Podría esto convertirse en una capacidad compartida para varios equipos? - ¿Cómo ayuda esto al negocio en general, no solo a mi equipo? - ¿El jefe de mi jefe seguiría pensando que este es el problema correcto? No necesitas resolver toda la estrategia de Netflix. Solo necesitas alejar el zoom un nivel, cuestionar tus supuestos y luego volver a entregar. > "No me quedaría mucho tiempo en el estado de cuestionamiento, porque te quedas atascado y no avanzas." ## Fluidez en IA como una capa adicional, no una reescritura del escalafón Netflix es conocida por no ser una empresa de "escalafón profesional" en el sentido tradicional de las grandes tecnológicas. Cuando agregaron niveles y expectativas, Stone no intentó reescribir cada peldaño para la IA. En cambio, Netflix agregó una **capa de fluidez en IA** en todos los roles y niveles. La fluidez en IA se ve distinta según la función y la etapa profesional, pero incluye: - Una mentalidad de experimentación. - Saber dónde la IA es útil y dónde no. - Construir cosas de verdad con IA. - Sentirse cómodo con la ambigüedad y el cambio rápido. Stone dice que la definición evoluciona casi mensualmente porque la tecnología avanza muy rápido. El objetivo no es forzar la IA en todo flujo de trabajo. Es desarrollar juicio sobre cuándo y cómo usarla. Netflix incluso cambió sus prácticas de entrevista: los candidatos pueden usar herramientas de IA en entrevistas de programación, porque así será el trabajo real. ## La excelencia como sistema operativo Lenny señala que el famoso culture deck de Netflix ahora suena exactamente como se describen los laboratorios de IA de frontera: alta agencia, autonomía, alta densidad de talento, decisiones de abajo hacia arriba y sueldos en el tope del mercado. Stone llama a esto "la excelencia como sistema operativo". > "La cultura de Netflix siempre ha sido la excelencia como sistema operativo. Es una resistencia a hacer lo que muchas grandes empresas harían, y se trata de sentirse cómodo en esa incomodidad muy a menudo." Los pilares, tal como los describe ella: - **La densidad de talento no es negociable.** No puedes empujar las decisiones hacia las profundidades de la organización a menos que la gente en todos los niveles sea excepcional. - **Comodidad con la toma de riesgos.** Netflix está dispuesto a ser imperfecto, moverse rápido y recuperarse rápido. - **Contexto, no control.** Los líderes deberían ayudar a las personas a ver el panorama completo, no microgestionar cada decisión. - **Resistencia al teatro de procesos.** Cuando las cosas salen mal, el instinto de agregar un nuevo proceso es fuerte. Stone dice que el mejor reflejo suele ser una retro sin culpables y un compromiso para mejorar. > "La inclinación de todos, cuando las cosas son difíciles y complicadas, es pensar que estás simplificando el problema al ponerle muchas restricciones alrededor. Pero en realidad va contra preguntarse: ‘¿Hay una forma más creativa de planificar, o de tomar decisiones de personal, o de tomar decisiones de priorización, que realmente nos lleve a mejores resultados?’" ## El keeper’s test no es solo una herramienta de despido El keeper’s test es conocido por ser esa prueba de si pelearías por mantener a alguien si dijera que se va. Stone dice que también es una herramienta de retroalimentación positiva. > "Es una puerta de entrada a una conversación que es muy positiva y edificante para las personas, pero el marco es: ‘¿Paso el keeper’s test?’" El lado difícil todavía existe. Si sientes alivio cuando alguien se va, probablemente esperaste demasiado para tener una conversación difícil. El keeper’s test es una forma de higiene: te obliga a revisar si tus estándares siguen siendo reales, o si solo estás reteniendo a alguien porque dejarlo ir sería incómodo. ## Contratar y desarrollar talento en un mundo de laboratorios de frontera La competencia por talento tecnológico de élite es brutal. Los laboratorios de frontera pueden ofrecer paquetes de compensación enormes y la oportunidad de entrenar modelos que nadie ha construido. Stone no ve a Netflix perdiendo esa pelea, porque Netflix ofrece algo diferente: - El punto dulce donde se encuentran tecnología, producto y entretenimiento. - Productos de consumo usados por cientos de millones de personas. - Un negocio global que abarca cine, TV, juegos, eventos en vivo y herramientas emergentes de IA. - La capacidad de dar forma al entretenimiento mismo. > "Hay muchísimas personas increíblemente talentosas que aman ese punto dulce—yo soy una de ellas—entre tecnología, producto y entretenimiento." Netflix también está contratando gente junior. Los programas para recién graduados y pasantes son ahora una parte central de la estrategia de talento. Las personas en etapas tempranas de carrera tienden a ser más nativas con las herramientas de IA y más fluidas en cómo están cambiando el entretenimiento y el comportamiento del consumidor. Pero todavía necesitan mentoría en el oficio. > "El dominio del oficio sigue siendo muy importante. Sigues teniendo la responsabilidad de revisar código, probar código, poder diagnosticar problemas y saber cómo se ve un buen producto." La preocupación de que "la gente junior nunca aprende porque la IA hace todo el trabajo" es real. La respuesta de Stone: las herramientas cambian, pero la responsabilidad no. ## Ingeniería en cinco años: entender más, escribir menos Lenny hace una pregunta que todo ingeniero está pensando: ¿la gente todavía necesitará entender código en cinco o diez años? Stone establece una distinción importante entre **escribir código** y **entender cómo funcionan los sistemas de software**. > "Hay una diferencia entre poder escribir líneas de código en un lenguaje particular, como Python o C++, y entender cómo funcionan el código, los sistemas computacionales y los productos. No creo que lo segundo vaya a desaparecer." Los agentes pueden escribir más del código. Los ingenieros pasarán más tiempo revisando, clasificando y conduciendo. Pero si no puedes saber por qué un sistema está roto, no puedes arreglarlo. Si no puedes saber si un producto es realmente bueno, no puedes ser dueño del resultado. Stone admite que el código generado por agentes puede ser difícil de seguir: > "Sé que estoy obteniendo mejor rendimiento con esto, pero no tengo idea de por qué. Y si esto se rompe, no tengo idea de cómo arreglarlo. Eso me hace sentir incómoda." Esa incomodidad, dice, es parte de la curva de aprendizaje actual. La próxima generación de ingeniería necesitará desarrollar fluidez para guiar agentes, no solo escribir código. ## El futuro del entretenimiento no es una sola cosa Stone espera que el entretenimiento siga fragmentándose en formatos, dispositivos y momentos del día. Netflix ya abarca cine, TV, juegos, eventos en vivo, podcasts y feeds verticales de formato corto como Clips. El resultado es un problema de descubrimiento. > "El futuro del entretenimiento no va a ser una sola cosa. Va a tener que ser más personalizado, más inmersivo y más interactivo, con esta sensación de: ‘Este es un mundo que puedo explorar en muchas direcciones distintas, dependiendo de lo que esté buscando en el momento’." El rol de Netflix es hacer que ese mundo se sienta fluido, no fragmentado. Eso es un desafío de producto e infraestructura tanto como de contenido. ### Las historias humanas siguen siendo la columna vertebral A pesar de todo el hype de la IA, Stone es escéptica del entretenimiento sin humanos al centro. > "Me cuesta imaginar un entretenimiento que no tenga a los humanos en el corazón. Contar historias es una y la misma cosa con la humanidad." La IA ayudará con la previsualización, la localización, los subtítulos, los efectos visuales e incluso con la reiluminación o el reencuadre de metraje después de un rodaje. Netflix recientemente adquirió **InterPositive**, una empresa de postproducción impulsada por IA cofundada por Ben Affleck, para llevar esas capacidades más allá. Pero el núcleo creativo sigue siendo un humano que dice: "Esta es la historia que necesito contar". ## La ventaja inicial de Netflix en IA: del Netflix Prize a InterPositive Netflix ha estado usando machine learning mucho antes de que la "IA" se convirtiera en un símbolo de estatus. El **Netflix Prize** en 2006 invitó a equipos de todo el mundo a mejorar el algoritmo de recomendación de la compañía en un 10%. Se convirtió en un campo de pruebas para el filtrado colaborativo y en un hito en el ML aplicado. Stone ve esa historia como una ventaja: > "Esto no es nuevo para nosotros. Especialmente para la personalización, la IA y el ML han sido centrales para entregar una gran experiencia a los miembros." Lo mismo ocurre en el lado creativo: la IA y el ML se han usado en efectos visuales, subtítulos, doblaje y generación de activos promocionales durante años. La IA generativa (GenAI) simplemente expande el lienzo. ## Referencias - [Podcast de Lenny](https://www.lennysnewsletter.com/p/netflix-cpto-on-ai-and-the-future?ref=sredevops.org) - [Netflix Tech Blog](https://netflixtechblog.com/?ref=sredevops.org) - [Cultura de Netflix — Empleos en Netflix](https://jobs.netflix.com/culture?ref=sredevops.org) - [Netflix Prize — Wikipedia](https://en.wikipedia.org/wiki/Netflix%5FPrize?ref=sredevops.org) - [Into Thin Air — Wikipedia](https://en.wikipedia.org/wiki/Into%5FThin%5FAir?ref=sredevops.org) - [Liar’s Poker — Wikipedia](https://en.wikipedia.org/wiki/Liar%27s%5FPoker?ref=sredevops.org) ### Gobierno de Chile postergaría implementación de la Ley de Protección de Datos Personales URL: https://www.sredevops.org/es/gobierno-de-chile-postergaria-implementacion-de-la-ley-de-proteccion-de-datos-personales/ Last updated: 2026-08-07T02:27:13.000Z Para quienes trabajamos en infraestructura, ciberseguridad y gobernanza de datos, los plazos de cumplimiento regulatorio suelen ser el motor de largas noches de café, refactorización de bases de datos y acaloradas discusiones sobre cifrado en reposo. Sin embargo, en el ámbito político, los plazos parecen tener la flexibilidad de un entorno de desarrollo sin control de versiones. El biministro de Economía y Minería de Chile, **Daniel Mas**, confirmó que el Gobierno está evaluando postergar la entrada en vigencia de la esperada **Ley de Protección de Datos Personales (Ley 21.719)**. ¿La razón? El clásico cuello de botella del despliegue: la infraestructura humana no está lista. Específicamente, el Ejecutivo ha sido incapaz de conformar el Consejo Directivo de la nueva **Agencia de Protección de Datos Personales**, el organismo encargado de fiscalizar el cumplimiento de la norma. ## Una agencia sin directores La Ley 21.719, aprobada en 2024, tenía como *fecha de despliegue en producción* el **1 de diciembre de 2026**. Esta normativa busca elevar los estándares de privacidad de Chile a un nivel equivalente al GDPR (Reglamento General de Protección de Datos de la Unión Europea), un paso crítico para la economía digital del país y su posicionamiento como hub tecnológico regional. No obstante, levantar una agencia estatal desde cero no es tan fácil como hacer un `docker compose up`. El proceso requiere la conformación de un Consejo Directivo de expertos, un trámite que se encuentra completamente estancado: - **Rechazo legislativo:** En mayo de 2026, el Senado rechazó la terna propuesta por el Presidente José Antonio Kast para integrar dicho consejo. - **Plazos vencidos:** En junio de 2026 expiró el plazo legal para nombrar a los consejeros (fijado por ley seis meses antes de la entrada en vigencia de la regulación). - **La solución política:** Ante la imposibilidad de cumplir con el calendario, el Gobierno evalúa enviar un proyecto de ley para modificar los plazos de implementación o, en su defecto, postergar únicamente la puesta en marcha de la Agencia fiscalizadora. ## El impacto en TI: Entre el limbo regulatorio y el alivio temporal Para los equipos de DevOps, SRE y CISO (Chief Information Security Officers) en Chile, esta noticia genera sentimientos encontrados. Por un lado, ofrece un respiro temporal; por el otro, introduce una molesta incertidumbre técnica. ### El dilema de la arquitectura de datos Muchas organizaciones locales y multinacionales ya estaban ejecutando costosos planes de migración y rediseño de arquitectura para cumplir con principios como: - **Privacidad por diseño y por defecto:** Modificación de pipelines de CI/CD para asegurar que los datos sensibles se anonimizen antes de llegar a entornos de staging o testing. - **Derechos ARCO (Acceso, Rectificación, Cancelación y Oposición):** Implementación de microservicios capaces de purgar por completo los datos de un usuario de múltiples bases de datos distribuidas (el siempre complejo "derecho al olvido"). - **Gobernanza de datos en la nube:** Restricciones de soberanía de datos y transferencias internacionales. Una postergación significa que los presupuestos asignados a estos proyectos de cumplimiento podrían congelarse o reasignarse, dejando a los equipos de seguridad con arquitecturas a medio migrar y "deuda técnica de cumplimiento". ### La paradoja de la inteligencia artificial El retraso de esta ley ocurre en un contexto complejo. Recientemente, se han levantado alertas sobre iniciativas que buscan flexibilizar el uso de contenidos para el entrenamiento de modelos de Inteligencia Artificial (IA) sin controles estrictos de propiedad intelectual o privacidad. Sin una Ley de Datos Personales robusta y activa, y sin una Agencia técnica que actúe como árbitro, el desarrollo y entrenamiento de modelos de machine learning en el país operará en un "Lejano Oeste" regulatorio. Esto expone a los ciudadanos a la explotación de sus datos y a las empresas a futuros dolores de cabeza cuando la ley finalmente entre en vigor y exija retroactividad o auditorías de sesgo y consentimiento. ## Recomendaciones para SREs y arquitectos de seguridad: No bajen la guardia Aunque el Gobierno decida presionar el botón de "pausa", la recomendación técnica para cualquier organización madura es **no detener los esfuerzos de cumplimiento**. La privacidad de los datos ya no es solo un requisito legal, sino una ventaja competitiva y una buena práctica de ingeniería. 1. **Sigan el estándar GDPR:** La Ley 21.719 está fuertemente alineada con el estándar europeo. Si diseñan sus sistemas pensando en GDPR, estarán cubiertos sin importar los cambios de última hora que decida el Congreso chileno. 2. **Automaticen la gobernanza:** Utilicen herramientas de infraestructura como código (IaC) como Terraform para definir políticas de acceso a datos (IAM) restrictivas y cifrado por defecto en sus buckets de almacenamiento (S3, Cloud Storage). 3. **Implementen observabilidad de seguridad:** No esperen a que la Agencia de Protección de Datos les exija reportar brechas en 72 horas. Establezcan alertas tempranas y flujos de respuesta a incidentes (IR) automatizados hoy mismo. La burocracia estatal puede retrasar las leyes, pero las amenazas de seguridad y las filtraciones de datos no respetan calendarios legislativos. ## Referencias - [Gobierno evalúa postergar Ley de Datos Personales - Emol](https://www.emol.com/noticias/Economia/2026/08/04/1207539/gobierno-postergar-ley-datos-personales.html?ref=sredevops.org) - [Ley de Protección de Datos Personales (Ley 21719) - Biblioteca del Congreso Nacional de Chile](https://www.bcn.cl/leychile/navegar?idNorma=1209272&ref=sredevops.org) - [Kast impulsa una norma que abre la puerta al uso “sin control” de contenidos de la IA - El País Chile](https://elpais.com/chile/2026-04-24/kast-impulsa-una-norma-que-abre-la-puerta-al-uso-sin-control-de-contenidos-de-la-ia.html?ref=sredevops.org) ### CyberIAyuda Chile 2026: Ciberseguridad e inteligencia artificial con impacto real frente a la catástrofe URL: https://www.sredevops.org/es/cyberiayuda-chile-2026-ciberseguridad-e-inteligencia-artificial-con-impacto-real-frente-a-la-catastrofe/ Last updated: 2026-08-01T17:13:45.000Z La comunidad tecnológica suele debatir en foros y redes sobre arquitecturas redundantes, tolerancia a fallos y alta disponibilidad. Sin embargo, cuando el "desastre" ocurre en el mundo físico, no hay *failover* automático ni respaldo en la nube que pueda solucionarlo con un clic. El temporal de julio de 2026 ha sido catalogado como el mayor desastre climático en la región de Coquimbo en los últimos 40 años, dejando una huella devastadora desde Atacama hasta Los Lagos: más de 100,000 personas aisladas, cerca de 2,800 viviendas destruidas y miles de hogares sin suministro eléctrico. Frente a este escenario, la comunidad de tecnología, ciberseguridad e inteligencia artificial de Chile y Latinoamérica ha decidido no quedarse de brazos cruzados. Así nace **CyberIAyuda Chile**, un evento benéfico online y gratuito que se llevará a cabo el **viernes 7 y sábado 8 de agosto de 2026**. El objetivo es claro: compartir conocimiento técnico de primer nivel y canalizar la ayuda hacia las regiones más afectadas por el temporal. [CyberIAyuda Chile — Evento benéfico onlineEvento online benéfico de ciberseguridad e IA en apoyo a los damnificados del temporal de julio de 2026 en Chile. Charlas, talleres y CTF. Viernes 7 y sábado 8 de agosto. Entrada gratuita.![](https://www.sredevops.org/content/images/icon/favicon-49731f78-3d09-492d-a5d0-b109452fc55e.ico)![](https://www.sredevops.org/content/images/thumbnail/og-card-1219813f-940f-44c1-bc66-4278e8a256bc.jpg)](https://cyberiayuda.cl/?ref=sredevops.org) ## El contexto: Cuando la naturaleza no pide permisos de administrador Los sistemas de control industrial, las redes de telecomunicaciones y la infraestructura crítica de un país son vulnerables a los elementos. El temporal de julio de 2026 demostró que la resiliencia no es solo un concepto de la certificación ISO 27001 o de un plan de *Disaster Recovery* en PDF; es una necesidad humana urgente. Con cifras oficiales que reportan 13 víctimas fatales y pérdidas materiales incalculables, **CyberIAyuda** se alza como un puente entre la solidaridad y el *hacking* ético. La asistencia al evento es 100% gratuita, pero se invita activamente a los asistentes a realizar aportes y donaciones para apoyar la reconstrucción de las zonas afectadas. ## Un CTF diseñado para romper cosas (y reconstruir otras) Para los entusiastas de la seguridad ofensiva y defensiva, el evento contará con un **Capture The Flag (CTF)** que se desarrollará el **sábado 8 de agosto de 11:00 a 18:00 (hora de Chile, UTC-4)**. A diferencia de las competencias tradicionales donde los equipos comparten infraestructura y terminan pisándose las mangueras (o saboteando los contenedores de los rivales), este CTF implementa un enfoque moderno de aislamiento: **cada equipo levanta su propia instancia con una flag única**. Adiós al plagio de *write-ups* en tiempo real. El CTF cuenta con **32 retos** distribuidos en equipos de hasta 5 integrantes, abarcando las siguientes categorías: - **Criptografía** (11 retos): Desde cifrados clásicos mal implementados hasta debilidades en implementaciones modernas de curvas elípticas. - **Programación** (7 retos): Automatización, scripting rápido y optimización bajo presión. - **Reversing** (5 retos): Desensamblado de binarios, análisis de flujo de control y evasión de mecanismos de protección. - **Web** (5 retos): Explotación de vulnerabilidades OWASP Top 10, inyecciones y fallos de lógica de negocio. - **Pwn** (4 retos): Corrupción de memoria, desbordamientos de pila (*stack overflows*) y secuestro del flujo de ejecución. Las inscripciones para la competencia ya están abiertas en el [portal del CTF de CyberIAyuda](https://ctf.cyberiayuda.cl/register?ref=sredevops.org). [CyberIAyuda Chile CTF![](https://www.sredevops.org/content/images/icon/favicon-4caab422-f9b3-4233-ab62-72a559ea2676.ico)CyberIAyuda Chile CTF![](https://www.sredevops.org/content/images/thumbnail/banner-ce73cdaf-fcfb-4839-aec0-6387f28ccc18.png)](https://ctf.cyberiayuda.cl/?ref=sredevops.org) ## Charlas y talleres: Menos humo corporativo, más terminal El programa de ponencias reúne a 22 referentes del sector que donarán su tiempo para ofrecer contenido técnico real, alejándose de las típicas presentaciones comerciales de "vendedores de humo" de IA. ### Ponencias destacadas - **Camila Casas — *De la vulnerabilidad al exploit*:** Un recorrido práctico sobre cómo identificar una debilidad de software y transformarla en un exploit funcional y reproducible. - **Luis Jofré Pérez — *«Operación Niebla de Cobre»: simulación educativa de investigación OSINT, evaluación de fuentes e inteligencia de amenazas*:** Un ejercicio inmersivo de inteligencia de fuentes abiertas aplicado a la atribución de amenazas. - **Matías Tillerias — *De código a exploit: análisis de vulnerabilidades con IA y grafos AST*:** Cómo utilizar árboles de sintaxis abstracta (AST) combinados con modelos de lenguaje para automatizar la auditoría de código estático (SAST). - **Mauricio Hernández — *Introducción al nuevo ecosistema regulatorio para servicios esenciales y organismos de importancia vital*:** Un análisis crítico de las nuevas normativas de ciberseguridad en Chile (como la Ley Marco de Ciberseguridad) y su impacto en la infraestructura crítica nacional. - **Gustavo Venegas — *Soberanía de la IA en acción: del cumplimiento en papel al control real de modelos y agentes*:** Cómo desplegar modelos de lenguaje locales (LLMs) de manera segura, garantizando la privacidad de los datos corporativos sin depender de APIs de terceros. - **Valeria Villalobos — *Alerta Temprana: un pipeline de detección (IA + OSS) sin humo*:** Integración de herramientas de código abierto (OSS) con inteligencia artificial para la detección temprana de anomalías en tráfico de red y logs de sistema. ## Cómo participar y aportar La cita es el **viernes 7 y sábado 8 de agosto de 2026**, a partir de las **15:00 horas (Chile, UTC-4)**. 1. **Inscripción general:** Regístrate de forma gratuita en el sitio oficial para recibir los enlaces de transmisión y las actualizaciones de la agenda. 2. **Participa en el CTF:** Arma tu equipo de hasta 5 personas y regístrate en la plataforma dedicada. 3. **Aporta a la causa:** Durante el evento se habilitarán canales oficiales para realizar donaciones directas a las organizaciones encargadas de la ayuda humanitaria en las zonas afectadas por el temporal. No te pierdas la oportunidad de actualizar tus conocimientos técnicos, medir tus habilidades en el CTF y, lo más importante, apoyar a quienes más lo necesitan en este momento. ## Referencias - Sitio web oficial del evento: [CyberIAyuda Chile](https://cyberiayuda.cl/?ref=sredevops.org) - Plataforma de registro para el CTF: [CyberIAyuda CTF](https://ctf.cyberiayuda.cl/register?ref=sredevops.org) ### Asegura tu pase VIP para el DevOpsDays Santiago 2026: Así te lo puedes ganar URL: https://www.sredevops.org/es/asegura-tu-pase-vip-para-el-devopsdays-santiago-2026-asi-te-lo-puedes-ganar/ Last updated: 2026-07-17T12:28:46.000Z Si tu panorama ideal incluye debatir si Kubernetes es supuestamente un sistema operativo, torturarte gratuitamente por la tabs de un *YAML modo sábana* o darse apoyo moral comunitario por todas las caídas en producción a las 4 AM... te tenemos ***mansa noticia ~~weón~~*** El evento **DevOpsDays Santiago** ya se está preparando para su edición 2026\. Para celebrar, los organizadores lanzaron un concurso exclusivo donde regalarán **un pase doble VIP** (uno para ti y otro para tu partner de on-call favorito). Aquí te dejamos todo lo que necesitas saber sobre el evento, por qué no te lo puedes perder y cómo asegurar esas codiciadas entradas VIP. ## A todo esto, ¿qué es DevOpsDays? Para los que no lo conocen, [DevOpsDays](https://devopsdays.org/?ref=sredevops.org) es la serie de conferencias comunitarias que prácticamente inventó el término "DevOps" por allá en el 2009 en Gante, Bélgica. A diferencia de esas conferencias corporativas gigantes y fomes donde los vendedores te persiguen sin piedad, DevOpsDays es un evento organizado por la comunidad, para la comunidad. La magia de DevOpsDays está en su formato único: - **Charlas seleccionadas:** Presentaciones de alta calidad y sin fines comerciales, dictadas por profesionales que de verdad están en las trincheras. - **Charlas Ignite:** Presentaciones ultra rápidas de 5 minutos donde las diapositivas avanzan solas cada 15 segundos (un formato de alto estrés que, curiosamente, a los SRE les encanta). - **Open Spaces:** La joya de la corona del evento. Los asistentes proponen temas en una pizarra, se agrupan y arman debates espontáneos y súper honestos sobre problemas reales de ingeniería. Básicamente, una terapia de grupo para ingenieros de sistemas. ## Por qué el DevOpsDays Santiago 2026 promete tanto DevOpsDays Santiago 2026 se perfila una suerte de "control plane" de facto dentro del ecosistema en Chile, dada su continuidad, calidad y proyección. El evento se enfocará con todo en los pilares que mantienen vivo al internet moderno: - **Platform Engineering:** Porque los desarrolladores no deberían tener que aprenderse todo el mapa de la CNCF solo para desplegar un "Hello World". - **Site Reliability Engineering (SRE):** Cómo mantener los sistemas corriendo cuando todo parece estar confabulado para caerse. - **Cloud & Infrastructure as Code:** Terraform, OpenTofu y el arte de destruir tu entorno de producción con un solo comando. - **Inteligencia Artificial y MLOps:** Integrar LLMs en producción sin reventar el presupuesto de tu nube. ## Cómo participar por las entradas VIP Los organizadores están sorteando **1 entrada VIP doble (para ti y un acompañante)**. Este pase VIP te dará una experiencia de otro nivel en el evento, permitiéndote compartir codo a codo con los speakers, organizadores y líderes de la industria que están impulsando el futuro de la tecnología cloud en LATAM. Participar es extremadamente fácil (prometemos que no hay que tirar ni una línea de código): 1. **Comparte la publicación:** Anda al [post oficial del anuncio en LinkedIn](https://www.linkedin.com/posts/devopsdays-devopsdayssantiago-devops-share-7478854175544479745-EoDV/?ref=sredevops.org) y compártelo de forma pública en tu perfil. 2. **Etiqueta a tu partner:** En los comentarios de ese post, etiqueta a la persona que quieres llevar contigo (elige con sabiduría; idealmente alguien que no te mande una alerta al pager durante la charla principal). 3. **Cuéntanos tu hype:** Dile a la comunidad qué es lo que más esperas del DevOpsDays Santiago 2026\. ¿Los Open Spaces? ¿El networking? ¿Los stickers gratis? ¡Hazles saber! ### Fechas clave que debes recordar - **Fecha del sorteo:** 13 de julio de 2026. - **Anuncio del ganador:** El afortunado o afortunada se anunciará a través de las redes sociales oficiales de DevOpsDays Santiago. *Fuente:* [*Anuncio oficial de DevOpsDays Santiago en LinkedIn*](https://www.linkedin.com/posts/devopsdays-devopsdayssantiago-devops-share-7478854175544479745-EoDV/?ref=sredevops.org) [#devopsdays #devopsdayssantiago #devops #cloud #sre #platformengineering #techcommunity #santiago2026 #comunidaddevops #concurso | DevOpsDays Santiago de Chile🚀🎉 ¡ATENCIÓN COMUNIDAD DEVOPS! Queremos que más personas vivan la experiencia DevOpsDays Santiago 2026 y por eso tenemos un concurso especial para ustedes. 🎟️ Participa por 1 Entrada VIP para ti y un acompañante y disfruta de todo lo que estamos preparando para esta gran misión. ¿Cómo participar? ✅ Comparte esta publicación en modo público en LinkedIn. ✅ Etiqueta en los comentarios a la persona con la que te gustaría asistir. ✅ Cuéntanos qué es lo que más te entusiasma de DevOpsDays Santiago 2026\. ¡Así de simple! 🌟 La entrada VIP te permitirá vivir una experiencia aún más especial durante el evento, junto a la comunidad que está impulsando el futuro de DevOps, Cloud, Platform Engineering, SRE, IA y mucho más. 📅 Sorteo: 13 de julio de 2026 🏆 Anunciaremos al ganador a través de nuestras redes sociales. Porque DevOpsDays no es solo un evento... Es una comunidad que aprende, comparte y crece junta. ❤️ 👇 Participa ahora y ayúdanos a llegar a más personas compartiendo esta publicación. ¿Con quién te gustaría vivir esta experiencia? #DevOpsDays #DevOpsDaysSantiago #DevOps #Cloud #SRE #PlatformEngineering #TechCommunity #Santiago2026 #ComunidadDevOps #Concurso![](https://www.sredevops.org/content/images/icon/al2o9zrvru7aqj8e1x2rzsrca-df57cab7-86fa-4281-94ff-c695bc958ae8)LinkedInDevOpsDays Santiago de Chile![](https://www.sredevops.org/content/images/thumbnail/1783097784593-05b0aae9-96f6-4618-914a-2d6c4dfe69be)](https://www.linkedin.com/posts/devopsdays-devopsdayssantiago-devops-share-7478854175544479745-EoDV/?ref=sredevops.org) ### Del silicio al vapor, o cuando la computación dejó de ser un lugar URL: https://www.sredevops.org/es/del-silicio-al-vapor-2/ Last updated: 2026-07-09T03:10:46.000Z Hubo una época en que podíamos señalar un servidor con el dedo. Allí está la memoria, allí la CPU, esos son los discos y la red es ese desorden de cables detrás del rack. La diferencia con el software se resumía en una frase que muchos repetíamos con una sonrisa: "*El hardware se puede patear; el software, solo maldecir.*" ### La virtualización licuó el hardware**.** A fines de los noventa, la virtualización salió del mundo mainframe y llegó al escritorio, de pronto, el servidor dejó de ser un objeto físico para convertirse en una ilusión administrada por un hipervisor. La tarjeta de red es software, los discos, archivos y la memoria una asignación dinámica. El hardware seguía existiendo, pero desapareció de nuestro campo visual. ### Y la nube convirtió lo líquido en gaseoso. La nube completó esa transformación. Ya no administramos servidores: declaramos estados. No configuramos redes: escribimos manifiestos. No instalamos infraestructura: la versionamos. La infraestructura dejó de ser un conjunto de dispositivos para convertirse en un conjunto de documentos. *Infrastructure as Code* no convirtió el hardware en software; solo su administración. Y ese cambio impactó también en la ciberseguridad. ### La complejidad no desaparece. Solo cambia de domicilio. Durante decadas protegimos equipos, firewalls, routers y sistemas operativos. Incluso los ataques más sofisticados terminaban en un activo físico. Hoy una parte importante de una auditoría consiste en revisar un repositorio Git. Analizamos archivos YAML, módulos de Terraform, manifiestos de Kubernetes y pipelines CI/CD. La superficie de ataque migró hacia donde migró la infraestructura: al texto. Nuestro oficio cambió también, cada vez dedicamos menos tiempo a investigar fallas del hardware y más a comprender errores de diseño, decisiones arquitectónicas y configuraciones equivocadas. Primero vivía en los racks, después en el hipervisor y luego en los proveedores de nube. Hoy habita en repositorios Git, plantillas declarativas y cadenas de suministro de software. La inteligencia artificial parece ser el siguiente paso de ese mismo recorrido. Primero abstrajimos el hardware, luego la infraestructura. Ahora comenzamos a abstraer parte de la programación y, con ella, parte del razonamiento del ingeniero. (*Esa es una conversación que merece un artículo aparte*). Cada nueva capa de abstracción nos aleja un poco más, pero no elimina la complejidad. Solo la desplaza. Durante décadas nos preguntamos dónde estaba el servidor. **Hoy la pregunta es: *¿quién está aplicando el criterio?*** ### Freelens: Taking back control of your Kubernetes clusters with a truly open-source desktop client URL: https://www.sredevops.org/en/freelens-taking-back-control-of-your-kubernetes-clusters-with-a-truly-open-source-desktop-client/ Last updated: 2026-07-07T23:52:51.000Z Managing Kubernetes clusters entirely from the command line is a rite of passage. We have all typed `kubectl get pods -n kube-system` more times than we care to admit. But when you are troubleshooting a cascading failure across multiple namespaces at 3:00 AM, staring at raw JSON or squinting at nested YAML in a terminal window isn't just exhausting—it is a liability. Enter [Freelens](https://freelens.app/?ref=sredevops.org), a free, open-source, cross-platform desktop application designed to take the squinting out of Kubernetes administration. ## Why Freelens? The open-source alternative we actually need If Freelens looks familiar, that is because it is a direct fork of [OpenLens](https://github.com/lensapp/lens/tree/master?ref=sredevops.org), the open-source core that originally powered Mirantis's popular Lens Desktop. When the commercial version of Lens began locking features behind paywalls and subscription models, the community did what the community does best: they forked it. Freelens is built to preserve the dream of a powerful, unrestricted, and highly extensible Kubernetes IDE. It runs locally on your machine, respects your existing `kubeconfig` files, and does not require you to sign up for a cloud account just to view your local development clusters. --- ## Installation guide Freelens is built using Electron, meaning it runs natively across macOS, Linux, and Windows. Below is the breakdown of how to get it running on your machine of choice. ### macOS Freelens requires macOS 12 (Monterey) or later. The project provides native binaries for both Apple Silicon (`arm64` for M1/M2/M3 chips) and Intel (`amd64`) architectures. #### The quick way (Homebrew) If you use Homebrew, you can install the cask with a single command: ```bash brew install --cask freelens ``` #### Manual installation Alternatively, you can download the `.dmg` or `.pkg` installers directly from the [Freelens Releases](https://github.com/freelensapp/freelens/releases?ref=sredevops.org) page. --- ### Linux To run Freelens on Linux, your system must have GNU C Library (glibc) 2.34 or later. This is standard on modern distributions such as Debian 12, Fedora 35, Ubuntu 22.04, Arch Linux, and their derivatives. #### Flatpak (Recommended for sandboxed security) The Flatpak package is hosted on [Flathub](https://flathub.org/apps/app.freelens.Freelens?ref=sredevops.org). It comes bundled with `kubectl` and `helm`, and automatically reads your local `~/.kube/config`. To install and run it: ```bash flatpak install flathub app.freelens.Freelens flatpak run app.freelens.Freelens ``` *Note on Flatpak Sandboxing:* Because Flatpak runs applications in an isolated environment, Freelens includes built-in wrappers to access host-installed CLI tools like `aws`, `doctl`, `gke-gcloud-auth-plugin`, and `kubelogin`. If you need to drop into a terminal within Freelens, it defaults to `/bin/sh` inside the sandbox, but you can configure it to use `/app/bin/host-spawn` to interact directly with your host system's shell. #### Snap Store For Ubuntu and other Snap-enabled distributions: ```bash sudo snap install freelens --classic ``` #### APT repository (Debian/Ubuntu) If you prefer native package management via `apt`, you can add the official repository: ```bash # Add the repository signing key curl -L https://raw.githubusercontent.com/freelensapp/freelens/refs/heads/main/freelens/build/apt/freelens.asc | sudo tee /etc/apt/keyrings/freelens.asc # Add the source list curl -L https://raw.githubusercontent.com/freelensapp/freelens/refs/heads/main/freelens/build/apt/freelens.sources | sudo tee /etc/apt/sources.list.d/freelens.sources # Update and install sudo apt update sudo apt install freelens ``` #### Arch User Repository (AUR) Arch users can find the precompiled binary package in the AUR under [freelens-bin](https://aur.archlinux.org/packages/freelens-bin?ref=sredevops.org). #### AppImage If you prefer a portable executable, grab the `.AppImage` from the releases page. First, ensure you have the necessary fuse and compression libraries installed: ```bash sudo apt install libfuse2 zlib1g-dev ``` Then, run the AppImage with the recommended flags to ensure smooth rendering under modern display servers (like Wayland) and to bypass sandbox-related GPU issues: ```bash ./Freelens*.AppImage --no-sandbox --ozone-platform-hint=auto --enable-features=WebRTCPipeWireCapturer --enable-features=WaylandWindowDecorations --disable-gpu-compositing ``` --- ### Windows Freelens supports Windows 10 or later, offering native builds for both `x64` and `arm64` architectures. #### WinGet (Windows Package Manager) You can install Freelens silently using Microsoft's native package manager: ```powershell winget install Freelensapp.Freelens ``` *Tip:* Use the `--scope machine` flag if you want to install it globally to `C:\Program Files` instead of the local user directory. #### Scoop If you prefer the developer-focused Scoop installer: ```powershell scoop bucket add extras scoop install freelens ``` #### Portable and manual installers If you prefer a zero-installation footprint, download the **Portable EXE** from the [releases](https://github.com/freelensapp/freelens/releases?ref=sredevops.org) page. Standard `.exe` (NSIS) and `.msi` installers are also available. --- ## Extending Freelens One of the greatest strengths of the original OpenLens ecosystem was its extension API. Freelens maintains full compatibility with this ecosystem. Developers can easily port existing OpenLens extensions or write brand-new ones. - **Extensions Wiki:** Check out the [Freelens Extensions Wiki](https://github.com/freelensapp/freelens/wiki/Extensions?ref=sredevops.org) to see a list of community-supported extensions. - **Get Involved:** If you have an extension you want to migrate or propose, join the discussion on [GitHub Discussion #117](https://github.com/freelensapp/freelens/discussions/117?ref=sredevops.org). - **Documentation:** Read the [Freelens Docs](https://freelensapp.github.io/docs/?ref=sredevops.org) to learn how to build your own custom UI components and integrations. --- ## Development and contribution Freelens is a community-driven project that welcomes contributors of all skill levels. Whether you want to fix a bug in the UI, optimize the build pipeline, or write documentation, your help is welcome. - **Building from source:** If you want to hack on the codebase, follow the step-by-step guide on the [Development Wiki](https://github.com/freelensapp/freelens/wiki/Development?ref=sredevops.org). - **Contributing guidelines:** Read the [CONTRIBUTING.md](https://github.com/freelensapp/freelens/blob/main/CONTRIBUTING.md?ref=sredevops.org) file in the repository to understand the pull request process and coding standards. ### Earn money by contributing The Freelens project utilizes [BountyHub](https://www.bountyhub.dev/en/bounties?repo=freelens&ref=sredevops.org), allowing community members to fund specific feature requests or bug fixes. Developers can claim these bounties by submitting successful pull requests that resolve the issues. To learn more about how to fund an issue or get paid for your code, check out the [Fund an issue or earn money by developing](https://github.com/freelensapp/freelens/wiki/Fund-an-issue-or-earn-money-by-developing?ref=sredevops.org) wiki page. --- ## Meet the team The rapid growth of Freelens is driven by a dedicated group of open-source maintainers: ### Core Team - [**Roberto Bandini**](https://www.linkedin.com/in/bandiniroberto/?ref=sredevops.org) ([@robertobandini](https://github.com/robertobandini?ref=sredevops.org)) – Founder: General management, community outreach, and product direction. - [**Piotr Roszatycki**](https://www.linkedin.com/in/piotr.roszatycki?ref=sredevops.org) ([@dex4er](https://github.com/dex4er?ref=sredevops.org)) – Maintainer: Architecture, release engineering, and extension development. - [**Mario Offertucci**](https://www.linkedin.com/in/mario-offertucci-703113b6/?ref=sredevops.org) ([@mariomamo](https://github.com/mariomamo?ref=sredevops.org)) – Maintainer: UI/UX design, documentation, and AI integrations. - [**Leopoldo Capuano**](https://www.linkedin.com/in/leo-capuano/?ref=sredevops.org) ([@leo-capvano](https://github.com/leo-capvano?ref=sredevops.org)) – Maintainer: Generative AI solutions and smart extension development. ### Release Engineering Team - [**Piotr Roszatycki**](https://www.linkedin.com/in/piotr.roszatycki?ref=sredevops.org) ([@dex4er](https://github.com/dex4er?ref=sredevops.org)) – Release Engineering Lead - [**Omar Alani**](https://www.linkedin.com/in/omarluq/?ref=sredevops.org) ([@omarluq](https://github.com/omarluq?ref=sredevops.org)) – Release Engineering Member - [**Matías Roje**](https://www.linkedin.com/in/matias-roje-carrasco/?ref=sredevops.org) ([@MatiasRoje](https://github.com/MatiasRoje?ref=sredevops.org)) – Release Engineering Member --- ## Community and support Stay connected with the community, report bugs, or discuss new feature ideas through these channels: - **Chat & Discussion:** Join the [Discord Server](https://discord.gg/NjKZERK95Y?ref=sredevops.org) or participate in [GitHub Discussions](https://github.com/freelensapp/freelens/discussions?ref=sredevops.org). - **Social Media:** Follow the project on [Bluesky](https://bsky.app/profile/freelensapp.bsky.social?ref=sredevops.org), [X (formerly Twitter)](https://x.com/freelensapp?ref=sredevops.org), and [LinkedIn](https://www.linkedin.com/company/freelensapp/?ref=sredevops.org). - **Video Content:** Watch tutorials and updates on [YouTube](https://www.youtube.com/@Freelensapp?ref=sredevops.org). - **Issues:** Spot a bug? Open an issue on the [GitHub Issue Tracker](https://github.com/freelensapp/freelens/issues?ref=sredevops.org). If your organization uses Freelens, consider adding your name to the official [Adopters List](https://github.com/freelensapp/freelens/blob/main/ADOPTERS.md?ref=sredevops.org) to show your support for sustainable open-source software. --- ## License Freelens is distributed under the permissive [MIT License](https://opensource.org/licenses/MIT?ref=sredevops.org). ### El lobo disfrazado de oveja: el creador de Pegasus ahora quiere vendernos "el remedio" URL: https://www.sredevops.org/es/el-lobo-disfrazado-de-oveja-el-creador-de-pegasus-ahora-quiere-vendernos-el-remedio/ Last updated: 2026-07-05T04:17:44.000Z Imagina que los creadores de la "aplicación" más peligrosa del mundo, llamada "Pegasus", deciden empezar a vender el "antipegasus"? Bueno, el resultado es **Dream**, una startup israelí de **ciberseguridad basada en AI* (uy, qué novedad...)* quienes están "migrando" desde la ***"vigilancia ofensiva"*** hacia la ***"defensa soberana"... bueno, están con ganas de vendernos nuestro propio derecho soberano a la ciberseguridad en Latinoamérica.*** La ironía es tan densa que podría ser la trama de una novela cyberpunk / techno-thriller: [Shalev Hulio, cofundador de NSO Group y la mente maestra detrás del infame spyware Pegasus](https://www.linkedin.com/in/shalevholy/?ref=sredevops.org), ahora se quiere posicionar como el salvador de las infraestructuras nacionales. ## Del "Modo Dios" del spyware a la AI defensiva Para los que se perdieron el caos de los últimos años, Pegasus no era simplemente "spyware". Era una clase magistral de *zero-click exploits*: la capacidad de comprometer un dispositivo sin que el usuario tuviera que hacer clic en un solo link ni siquiera contestar una llamada. Básicamente, convirtió los smartphones en micrófonos de vigilancia 24/7 para gobiernos de todo el mundo, apuntando frecuentemente a la gente "equivocada" (periodistas, activistas y algún que otro parlamentario). ### Avancemos hasta enero de 2023: Hulio deja NSO y lanza **Dream**. El discurso cambió. En lugar de crear herramientas para romper sistemas, Dream afirma construir plataformas impulsadas por AI que detectan amenazas y parchan vulnerabilidades antes de que puedan ser explotadas. Es el clásico pitch de ventas de *"yo sé cómo piensan los malos porque yo fui el arquitecto jefe de los malos"*. Desde un punto de vista técnico, es una transición lógica; la defensa más efectiva suele ser construida por alguien que entiende las primitivas ofensivas de la superficie de ataque, pero es el equivalente de ir a buscar a tu jefe de seguridad a una cárcel de alta seguridad. ## Por qué América Latina es el blanco perfecto Si estás vendiendo un "antídoto" carísimo, necesitas una región que sienta que el veneno ya está corriendo por las venas. América Latina calza perfecto por tres razones: ### 1\. La brecha de vulnerabilidad Se reporta que los ciberataques en la región crecen un 25% anual. Según evaluaciones del Banco Mundial, la preparación en ciberseguridad de la región es mediocre, para decir lo menos (con un promedio de 10.2/20). Cuando tu defensa nacional es básicamente una estrategia de "cruzar los dedos y esperar que no pase nada", una startup de AI valuada en 3 billones de dólares parece un salvavidas. ### 2\. El golpe de realidad de Costa Rica Los ataques de 2022 en Costa Rica son un caso de estudio sobre la fragilidad sistémica. Primero, el grupo de ransomware **Conti** dejó fuera de combate a 30 instituciones gubernamentales, forzando una emergencia nacional —la primera en el mundo causada por un ciberataque—. Poco después, el grupo **Hive** golpeó el sistema de salud, obligando a los hospitales a volver a la era del papel y el lápiz. Para los países vecinos, esto fue una demostración *cuática* de que una nación mediana puede quedar paralizada por actores remotos si su perímetro es poroso y sus ciclos de parcheo son inexistentes. ### 3\. Alineación política La ciberseguridad a nivel soberano no se trata solo de código; se trata de confianza (o de la ilusión de ella). Dream está apuntando a gobiernos alineados con Washington y Tel Aviv. - **Argentina:** Bajo Javier Milei, el país está girando hacia un hub centrado en AI y fortaleciendo lazos con Israel. - **Colombia:** La administración actual, con Abelardo De la Espriella, está restaurando vínculos diplomáticos con Israel. Vender una "plataforma de AI soberana" a una agencia de seguridad nacional requiere un nivel de cercanía política que un contrato estándar de SaaS no ofrece. La identidad israelí de Dream, que alguna vez fue una carga para NSO ante los grupos de derechos humanos, es ahora un activo estratégico en las capitales de derecha. ## La jugada técnica: AI Soberana y air-gapping Una de las mayores ventajas competitivas de Dream es su apuesta por los **centros de datos *"soberanos"***. Construyeron una instalación cerca de Modiin, Israel, para entrenar Large Language Models (LLMs) propietarios sin depender de proveedores de nube pública como AWS, Azure o GCP. Para un gobierno, esto es un requisito crítico. Ninguna agencia de inteligencia quiere que sus datos sensibles de vulnerabilidades fluyan a través de un proveedor de nube basado en EE. UU. sujeto al CLOUD Act. Al ofrecer "AI soberana", Dream promete: - **Residencia de Datos:** Tus datos se quedan dentro de tus fronteras (o las de un "socio confiable"). - **Despliegue Air-gapped:** La capacidad de desplegar agentes de AI en entornos que no tienen conexión con la internet pública. - **LLMs personalizados:** Modelos entrenados específicamente con telemetría de ciberseguridad en lugar de prosa general de internet. ## La paradoja ética: ¿Podemos confiar en el antídoto? El caso de negocio está clarísimo: se reporta que las ventas han superado los 300 millones de dólares y la valoración se ha triplicado a 3 billones. Pero la pregunta ética sigue ahí: **¿Es este un giro genuino hacia la defensa, o es simplemente un modelo de negocio más sostenible para el mismo set de habilidades?** El lado "defensivo" de la ciberseguridad es, a menudo, el lado "ofensivo" con una licencia diferente. La misma AI que puede "detectar una vulnerabilidad para parcharla" también puede "detectar una vulnerabilidad para explotarla". Para los grupos de la sociedad civil en América Latina, la distinción es puramente académica. Ya sea que la herramienta se use para detener un ataque de ransomware o para monitorear a un disidente, el poder reside en quien tiene las llaves. En este caso, las llaves las tiene el hombre que construyó la herramienta de vigilancia más poderosa e ilegal de la historia reciente, respaldado por organismos de seguridad israelíes responsables de un genocidio que sigue en curso, lo cual supera cualquier argumento técnico para dar un rotundo rechazo a cualquier intento de apropiarse de los datos de empresas y personas en Latinoamér --- ### Referencias y Recursos - **Artículo Original:** [The man who built Pegasus now sells governments the antidote](https://thenextweb.com/news/the-man-who-built-pegasus-now-sells-governments-the-antidote-and-latin-america-is-buying?ref=sredevops.org) por Alina Maria Stan. - **Lecturas Adicionales:** - [NSO Group and the Pegasus Project](https://www.amnesty.org/en/latest/news/2021/07/pegasus-targeted-attacks-on-journalists-and-human-rights-defenders/?ref=sredevops.org) \- Amnesty International. - [Conti Ransomware Analysis](https://www.cisa.gov/news-events/cybersecurity-advisories?ref=sredevops.org) \- CISA (Buscar avisos de Conti/Hive). - [Sovereign AI Concepts](https://nvidia.com/en-us/ai-data-center/?ref=sredevops.org) \- Entendiendo el giro hacia la infraestructura de AI nacionalizada. ### Microsoft trae coreutils al estilo Linux de forma nativa a Windows URL: https://www.sredevops.org/es/microsoft-trae-coreutils-al-estilo-linux-de-forma-nativa-a-windows/ Last updated: 2026-06-05T17:59:22.000Z ¿Es esto una "Linux-ización" de Windows? No exactamente. Es más bien un puente pragmático. Coreutils for Windows no hará que olvides que estás en Windows, ni reemplazará la necesidad de una instancia completa de WSL cuando estés haciendo ingeniería de sistemas Linux pesada. Sin embargo, para el desarrollador que solo quiere hacer un `grep` a un archivo de log o un `find` a una config sin pelearse con la shell, es una mejora gigante en la calidad de vida. Durante años, la relación entre Microsoft y el ecosistema Linux fue de sospecha mutua y hostilidad ocasional. Damos un salto al 2026 y la ironía es evidente: Microsoft ahora está distribuyendo oficialmente utilidades estilo Unix para que Windows se sienta un poco más como los entornos donde los devs realmente se mueven. Anunciado en el [Microsoft Build 2026](https://blogs.windows.com/windowsdeveloper/2026/06/02/build-2026-furthering-windows-as-the-trusted-platform-for-development/?ref=sredevops.org), **Coreutils for Windows** es una nueva suite de herramientas de línea de comandos mantenida por Microsoft y diseñada para ejecutarse nativamente en Windows. Sin necesidad de WSL, sin capas pesadas de virtualización; solo tus comandos conocidos, corriendo directamente sobre el kernel de Windows. ## La base potenciada por Rust En lugar de intentar un porteo desordenado de código antiguo de GNU C, Microsoft tomó el camino moderno. Coreutils for Windows está construido sobre [uutils](https://uutils.github.io/?ref=sredevops.org), una reimplementación de GNU Coreutils de alto rendimiento y multiplataforma escrita en **Rust**. Al aprovechar Rust, Microsoft está sacando partido de la seguridad de memoria inherente al lenguaje y sus fortalezas en concurrencia, lo cual es una jugada inteligente para utilidades a nivel de sistema. El paquete se distribuye como un único binario multi-llamada e incluye builds mantenidas por Microsoft de: - `uutils/coreutils` - `uutils/findutils` - Un fork especializado de Microsoft de `uutils/grep` El objetivo es reducir el "impuesto del cambio de contexto" que pagan los ingenieros de DevOps y SREs que saltan entre estaciones de trabajo locales con Windows, laptops macOS y entornos de nube basados en Linux. ## Instalación y configuración Empezar es bastante simple, asumiendo que no sigas aferrado al viejo CMD. El paquete se distribuye vía **WinGet**, lo que facilita su integración en scripts de configuración automatizados o flujos de onboarding para desarrolladores. ```powershell # Install the coreutils package via WinGet winget install Microsoft.Coreutils ``` **Nota:** Para sacarle el máximo provecho a esto, necesitarás **PowerShell 7.4 o superior**. Si todavía estás usando Windows PowerShell 5.1, quizás quieras actualizar antes de esperar un comportamiento moderno. ## La experiencia "curada": Limitaciones y conflictos Antes de que te pongas a reescribir todos tus scripts `.bat`, bajemos un poco las expectativas. Esto no es un reemplazo completo 1:1 de una distribución de Linux. Es un "subconjunto enfocado en Windows". ### Conflictos de comandos y alias Como Windows tiene su propia forma de hacer las cosas, varios comandos comunes chocarán con los built-ins y alias existentes de PowerShell o CMD. Si intentas usar `ls`, `cat`, `cp`, `mv`, `rm` o `pwd`, podrías terminar en un tira y afloja entre el comportamiento nativo de Windows y la nueva implementación de Coreutils. Tendrás que tener ojo con la política de ejecución de tu entorno y la precedencia de los alias. ### ¿Qué falta? Microsoft ha sido bastante selectivo con lo que incluyó. Aunque los "esenciales" están ahí, muchas herramientas para power-users quedaron fuera del corte. **Utilidades explícitamente excluidas:** - `dd` (Porque la manipulación directa de discos en Windows es una receta para el desastre) - `dircolors` - `shred` - `sync` - `uname` **Herramientas específicas de POSIX faltantes:** Si tu flujo de trabajo depende mucho de la gestión de permisos o la inspección de procesos, notarás la ausencia de `chmod`, `chown`, `chroot`, `mkfifo`, `tty`, `users` y `who`. Intentar mapear permisos POSIX al sistema de archivos NTFS es un bicho complejo, y parece que Microsoft decidió patear ese dolor de cabeza para más adelante. ## El panorama general: WSL containers El lanzamiento de Coreutils for Windows no ocurre de forma aislada. Junto a esto, Microsoft introdujo los **WSL containers**. Mientras que Coreutils busca que la CLI de Windows sea más familiar, los WSL containers buscan que la contenerización de Linux sea más nativa. A diferencia del paquete de Coreutils, los WSL containers están actualmente en desarrollo y se espera que entren en preview pública en los próximos meses. Prometen una forma de construir y ejecutar contenedores de Linux a través de una CLI y API dedicada, brindando a las empresas un control basado en políticas sobre las fuentes de las imágenes y la interacción con el host; básicamente, trayendo esa sensación de entorno "managed" de la nube al escritorio local de Windows. Coreutils for Windows ya está disponible a través del [repositorio de GitHub de Microsoft](https://github.com/microsoft/coreutils?ref=sredevops.org). --- **Referencias y Créditos:** - Reporte original de [Bobby Borisov vía Linuxiac](https://linuxiac.com/microsoft-brings-linux-like-coreutils-natively-to-windows/?ref=sredevops.org) - [Proyecto uutils/coreutils](https://uutils.github.io/?ref=sredevops.org) - [Anuncios de Microsoft Build 2026](https://blogs.windows.com/windowsdeveloper/2026/06/02/build-2026-furthering-windows-as-the-trusted-platform-for-development/?ref=sredevops.org) ### Microsoft brings Linux-style coreutils natively to Windows URL: https://www.sredevops.org/en/microsoft-brings-linux-style-coreutils-natively-to-windows/ Last updated: 2026-06-05T17:45:14.000Z Is this a "Linux-ification" of Windows? Not quite. It's more of a pragmatic bridge. Coreutils for Windows won't make you forget you're on Windows, and it won't replace the need for a full WSL instance when you're doing heavy-duty Linux systems engineering. However, for the developer who just wants to `grep` a log file or `find` a config without fighting the shell, it is a massive quality-of-life improvement. For years, the relationship between Microsoft and the Linux ecosystem was one of mutual suspicion and occasional hostility. Fast forward to 2026, and the irony is palpable: Microsoft is now officially shipping Unix-style utilities to make Windows feel a little more like the environments developers actually live in. Announced at [Microsoft Build 2026](https://blogs.windows.com/windowsdeveloper/2026/06/02/build-2026-furthering-windows-as-the-trusted-platform-for-development/?ref=sredevops.org), **Coreutils for Windows** is a new, Microsoft-maintained suite of command-line tools designed to run natively on Windows. No WSL required, no heavy virtualization layers—just your familiar commands, running directly on the Windows kernel. ## The Rust-powered foundation Rather than attempting a messy port of aging GNU C code, Microsoft has gone the modern route. Coreutils for Windows is built upon [uutils](https://uutils.github.io/?ref=sredevops.org), a cross-platform, high-performance reimplementation of GNU Coreutils written in **Rust**. By leveraging Rust, Microsoft is tapping into the language's inherent memory safety and concurrency strengths, which is a smart move for system-level utilities. The package is distributed as a single, multi-call binary and includes Microsoft-maintained builds of: - `uutils/coreutils` - `uutils/findutils` - A specialized Microsoft fork of `uutils/grep` The goal is to reduce the "context-switching tax" paid by DevOps engineers and SREs who bounce between local Windows workstations, macOS laptops, and Linux-based cloud environments. ## Installation and setup Getting started is straightforward, assuming you aren't still clinging to the legacy CMD prompt. The package is distributed via **WinGet**, making it easy to integrate into automated setup scripts or developer onboarding workflows. ```powershell # Install the coreutils package via WinGet winget install Microsoft.Coreutils ``` **Note:* To get the most out of this, you will need *PowerShell 7.4 or later*. If you are still running Windows PowerShell 5.1, you might want to upgrade before you start expecting modern behavior.* ## The "curated" experience: Limitations and conflicts Before you go rewriting all your `.bat` scripts, let's manage some expectations. This is not a complete, 1:1 replacement for a Linux distribution. It is a "Windows-focused subset." ### Command conflicts and aliases Because Windows has its own way of doing things, several common commands will collide with existing PowerShell or CMD built-ins and aliases. If you try to use `ls`, `cat`, `cp`, `mv`, `rm`, or `pwd`, you might find yourself in a tug-of-war between the native Windows behavior and the new Coreutils implementation. You'll need to be mindful of your environment's execution policy and alias precedence. ### What's missing? Microsoft has been quite selective about what they include. While the "essentials" are there, many power-user tools have been left on the cutting room floor. **Explicitly excluded utilities:** - `dd` (Because direct disk manipulation on Windows is a recipe for disaster) - `dircolors` - `shred` - `sync` - `uname` **Missing POSIX-specific tools:** If your workflow relies heavily on permission management or process inspection, you'll notice the absence of `chmod`, `chown`, `chroot`, `mkfifo`, `tty`, `users`, and `who`. Attempting to map POSIX permissions to the NTFS filesystem is a complex beast, and it seems Microsoft has decided to punt that particular headache for another day. ## The bigger picture: WSL containers The release of Coreutils for Windows isn't happening in a vacuum. Alongside this, Microsoft introduced **WSL containers**. While Coreutils aims to make the Windows CLI more familiar, WSL containers aim to make Linux containerization more native. Unlike the Coreutils package, WSL containers are currently in the works and are expected to enter public preview in the coming months. They promise a way to build and run Linux containers through a dedicated CLI and API, providing enterprises with policy-based control over image sources and host interaction—essentially bringing the "managed" feel of cloud-native environments to the local Windows desktop. Coreutils for Windows is available now via the [Microsoft GitHub repository](https://github.com/microsoft/coreutils?ref=sredevops.org) --- **References & Credits:** - Original reporting by [Bobby Borisov via Linuxiac](https://linuxiac.com/microsoft-brings-linux-like-coreutils-natively-to-windows/?ref=sredevops.org) - [uutils/coreutils Project](https://uutils.github.io/?ref=sredevops.org) - [Microsoft Build 2026 Announcements](https://blogs.windows.com/windowsdeveloper/2026/06/02/build-2026-furthering-windows-as-the-trusted-platform-for-development/?ref=sredevops.org) ### Kubernetes será "el sistema operativo de la IA": La apuesta de Google con GKE Agent Sandbox e Hypercluster URL: https://www.sredevops.org/es/kubernetes-sera-el-sistema-operativo-de-la-ia-la-apuesta-de-google-con-gke-agent-sandbox-e-hypercluster/ Last updated: 2026-05-23T02:11:28.000Z En la reciente **Google Cloud Next '26**, el mensaje fue clarito, fuerte y un poco intimidante: **Kubernetes ya no es solo un orquestador de contenedores; es el *"sistema operativo para la era de la IA"*.** Mientras algunos de nosotros todavía estamos tratando de solucionar un `ImagePullBackOff`, Google está preparando GKE para gestionar un millón de chips aceleradores y ejecutar código de *"agentes autónomos muy confiables" (léase OpenClaw)* a gran escala. Los anuncios se centraron en dos pilares gigantes: - **GKE Agent Sandbox** para la ejecución segura de múltiples agentes - **GKE Hypercluster** para una infraestructura que ya roza lo absurdo. ## El auge de los poco confiables *"agentes autónomos"* (léase OpenClaw) Ya pasamos la etapa de los chatbots. Los flujos de trabajo de IA multi-agente han subido más de un 300% últimamente y, como era de esperarse, darle a un LLM las llaves para ejecutar código es una pesadilla de seguridad cuyas consecuencias ya son visibles, evidenciado en la impresionante frecuencia y cantidad de CVEs, explloits, vulnerabilidades y leaks ocurridos en los últimos meses. La respuesta de Google es [GKE Agent Sandbox](https://docs.cloud.google.com/kubernetes-engine/docs/concepts/machine-learning/agent-sandbox?ref=sredevops.org). Esto no es solo un nombre de marketing, es una capa de aislamiento a nivel de kernel potenciada por [gVisor](https://gvisor.dev/?ref=sredevops.org), la misma tecnología de sandboxing que Google usa para evitar que Gemini se muerda la cola. ### Nuevos componentes de Kubernetes Google no solo está "empaquetando contenedores", sino que **están presentando tres nuevos componentes de Kubernetes** (*lanzados originalmente como un subproyecto de SIG Apps)* para estandarizar cómo viven y respiran los agentes: - **Sandbox:** El recurso principal de la carga de trabajo (workload). - **SandboxTemplate:** El blueprint de seguridad (piénsalo como la configuración de "no dejes que el agente se escape"). - **SandboxClaim:** Un recurso transaccional para solicitar entornos de ejecución desde frameworks como LangChain o ADK, conceptualmente similar a un `persistentVolumeClaim` Para solucionar el problema del "cold start" que tanto nos pena en las ejecuciones tipo serverless, GKE ahora usa "*warm pools"* de pods pre-provisionados, bajando la latencia a niveles de sub-segundos. Si estás corriendo sobre los procesadores [Axion](https://cloud.google.com/blog/products/compute/introducing-google-axion-cpu?ref=sredevops.org) personalizados de Google, ellos aseguran una ventaja de precio-rendimiento del 30% frente a otros hyperscalers. ## Hypercluster: Un millón de chips, un solo control plane Si el Agent Sandbox se trata de lo "micro", [GKE Hypercluster](https://cloud.google.com/blog/products/containers-kubernetes/whats-new-in-gke-at-next26/?ref=sredevops.org) se trata de lo "macro". Actualmente en GA privada, Hypercluster permite que un solo control plane de GKE gestione hasta **un millón de chips aceleradores** a través de 256.000 nodos. Aunque la escala es *brígida (intimidante)* , la preocupación por el *"blast radius"* (radio de explosión) es real. Gestionar un millón de chips desde un solo punto de falla es una movida arriesgada, lo que probablemente explica por qué Google lo mantiene en GA privada por ahora. Para asegurar estas cargas de trabajo masivas, Google se apoya en el [**Titanium Intelligence Enclave**](https://blog.google/innovation-and-ai/products/google-private-ai-compute/?ref=sredevops.org). Esta arquitectura basada en hardware y "sin acceso de administrador" garantiza que ni siquiera los administradores de la plataforma —la gente a la que le pagan para que mantenga la cuestión andando— puedan ver los *weights* de los modelos propietarios o los prompts. Todo se mantiene sellado criptográficamente. ## Solucionando el cuello de botella de la inferencia Escalar no sirve de nada si la latencia de inferencia hace que los usuarios sientan que volvieron al internet de los 90\. Google introdujo dos funciones clave para que los tokens sigan fluyendo: ### 1\. Predictive Latency Boost Basado en el proyecto [llm-d](https://llm-d.ai/?ref=sredevops.org) (que ahora es un proyecto Sandbox de la CNCF), esta función usa ruteo basado en ML. En vez de depender de un round-robin "fome" o de un agendamiento heurístico, el GKE Inference Gateway predice qué nodo tendrá el menor time-to-first-token (TTFT) y rutea el tráfico según eso. Google dice que esto reduce la latencia hasta en un 70%. ### 2\. Automatic KV Cache Tiering Las ventanas de contexto (context window) son devoradoras de memoria. GKE ahora soporta almacenamiento por niveles (tiering) automático de KV Cache entre RAM, SSD local y Google Cloud Storage (GCS). - **Offloading a RAM:** 50% de ganancia en throughput para 10K prompts. - **Offloading a SSD:** Casi un 70% de mejora en throughput para 50K prompts. ## Reinforcement Learning (RL) y autoscaling basado en *intención* En cuanto a **Reinforcement Learning (RL)**, Google anunció **RL Scheduler** y **RL Sandbox**. Estas herramientas optimizan las cargas de trabajo de *evaluación de recompensas* manteniendo el mismo aislamiento a nivel de kernel de Agent Sandbox. Finalmente, el **Horizontal Pod Autoscaler (HPA)** por fin va a andar más rápido. El **Intent-based autoscaling** reduce los tiempos de reacción de 25 segundos a apenas 5 segundos. Lo logra sacando las métricas directamente de los pods en vez de esperar a que el stack de monitoreo externo se dé cuenta de que tu cluster se está incendiando. [La gran unificación de google cloud: opentelemetry se vuelve obligatorio (y ya era hora)Si pensabas que podrías seguir ignorando el avance de OpenTelemetry (OTel) mientras te escondías en tus scripts legacy, Google Cloud acaba de enviarte un recordatorio amistoso —o una amenaza elegante, según cómo lo mires—. La plataforma ha lanzado una nueva API de ingestión que soporta de forma nativa los protocolos![](https://www.sredevops.org/content/images/icon/Icon-App-76x76@2x-adbbb0741d6726ecb8a25a2ed8af9c4ad8368c14b05eaf78544c87e2a518ad7a.png)SREDevOps.orgNicolás Georger![](https://www.sredevops.org/content/images/thumbnail/gcp-otel-4e6a939d9d37c280dfb695e77e1e53f6368be9882cd31fd97559df44971e16be.png)](https://www.sredevops.org/es/la-gran-unificacion-de-google-cloud-opentelemetry-se-vuelve-obligatorio-y-ya-era-hora/) ## Resumen: El diferenciador open-source Quizás lo más interesante de todo es el compromiso de Google con el camino del código abierto. Al convertir el Agent Sandbox en un proyecto de Kubernetes SIG, están apostando a que el mismo Kubernetes debería ser el runtime de los agentes. A diferencia de las soluciones propietarias, cualquier cluster de Kubernetes que cumpla con los estándares podría, en teoría, correr estas primitivas de agentes. Ya sea que necesites gestionar un millón de H100s o solo quieras asegurarte de que tu agente de IA no tire un `rm -rf /` en producción, las actualizaciones del Next '26 de GKE sugieren que el futuro de la IA es, inevitablemente, un archivo YAML. ### Referencias y lecturas adicionales - [Official Google Cloud Blog: What’s new in GKE at Next '26](https://cloud.google.com/blog/products/containers-kubernetes/whats-new-in-gke-at-next26/?ref=sredevops.org) - [gVisor Documentation](https://gvisor.dev/docs/?ref=sredevops.org) - [CNCF: Kubernetes as foundational infrastructure for AI](https://thenewstack.io/cncf-kubernetes-is-foundational-infrastructure-for-ai/?ref=sredevops.org) - [llm-d: Predicted latency-based scheduling](https://llm-d.ai/blog/predicted-latency-based-scheduling-for-llms?ref=sredevops.org) - [Original Article Source: InfoQ](https://www.infoq.com/news/2026/05/gke-agent-sandbox-hypercluster/?ref=sredevops.org) ### How the Linux kernel copyfail vulnerability impacts kubernetes: What you need to know and what you can do URL: https://www.sredevops.org/en/how-the-linux-kernel-copyfail-vulnerability-impacts-kubernetes-what-you-need-to-know-and-what-you-can-do/ Last updated: 2026-05-01T14:56:12.000Z ## copy fail in kubernetes: when your pod escapes to the host with four bytes if you thought containers were a security boundary, cve-2026-31431 ("copy fail") has some unfortunate news for you. discovered by xint, this linux kernel vulnerability lets an unprivileged local user overwrite four controlled bytes in the page cache of *any readable file*—and yes, that includes binaries inside your containers. worse: because the page cache is a host-wide resource, corruption in one container can silently propagate to another. the result? a fully unprivileged pod can achieve node-level code execution. this isn't a theoretical "what if." a public 732-byte python proof-of-concept demonstrates container escape on every major kubernetes distribution by exploiting shared image layers between an attacker-controlled pod and a privileged daemonset like `kube-proxy`. if your cluster runs linux kernels built between 2017 and april 2026, you should probably stop reading and start patching. ## the container escape primitive: shared page cache, shared fate the core vulnerability lives in the kernel's `algif_aead` subsystem, where improper handling of scatter-gather lists during in-place aead decryption allows a controlled 4-byte write into the page cache. the exploit chain is elegantly brutal: ```python # simplified exploit flow (full PoC: https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kubernetes-PoC) import os, socket # 1. open AF_ALG socket to vulnerable crypto template s = socket.socket(socket.AF_ALG, socket.SOCK_SEQPACKET) s.bind(("aead", "authencesn(hmac(sha256),cbc(aes))")) # ... set key, accept request socket ... # 2. splice target file (e.g., /usr/sbin/ipset) into crypto operation os.splice(target_fd, pipe_wr, offset=chosen_offset) os.splice(pipe_rd, alg_fd, length=auth_tag_size) # 3. trigger decrypt → kernel writes 4 controlled bytes into page cache req_socket.recv(1) # hmac fails, but corruption persists ``` the magic—and the danger—lies in how linux manages file i/o. when a container reads a file from a shared image layer, the kernel serves it from the *same physical page cache pages* across all containers on that node. this is a performance optimization, not a bug. but when combined with copy fail, it becomes an escape hatch. ### why overlay filesystems make this worse container runtimes like `containerd` and `cri-o` use overlayfs to implement copy-on-write semantics. when multiple pods reference the same image layer: ```log host page cache ├── lowerdir: /var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots//usr/sbin/ipset ├── upperdir: (container-specific, empty for read-only files) └── merged view: served from shared page cache pages ``` if an unprivileged pod corrupts `/usr/sbin/ipset` in the page cache, *every* pod on that node that reads the same file from the same layer sees the corrupted in-memory version—without any cross-container communication, without touching disk, and without triggering traditional file integrity monitors. ## the kube-proxy attack vector: a privileged daemonset waiting to happen the public kubernetes poc targets `/usr/sbin/ipset`, a binary used by `kube-proxy` to manage iptables/ipset rules. here's why this is a perfect storm: | characteristic | why it matters | | ----------------------------------------- | ---------------------------------------------------------------------------------- | | kube-proxy runs as a privileged daemonset | executes with hostnetwork: true, full capabilities, and root uid | | ipset is invoked periodically | corrupted binary gets executed automatically, no user interaction needed | | image layer is shared across nodes | same base image (registry.k8s.io/kube-proxy:v1.35.2) means same page cache mapping | | binary is readable by unprivileged users | satisfies the "any readable file" prerequisite for copy fail | the attack sequence: 1. attacker deploys an unprivileged pod with the poc script (no special capabilities required) 2. poc corrupts the page cache for `/usr/sbin/ipset` in the shared image layer 3. `kube-proxy` on the same node executes the corrupted binary during its next reconciliation loop 4. attacker-controlled shellcode runs with kube-proxy's privileges: root on the node, access to host namespaces, and full cluster control via the node's service account this isn't a "maybe." the poc has been tested and confirmed working on ubuntu, amazon linux, rhel, and suse kernels spanning versions 6.12 through 6.18. [GitHub - Percivalll/Copy-Fail-CVE-2026-31431-Kubernetes-PoCContribute to Percivalll/Copy-Fail-CVE-2026-31431-Kubernetes-PoC development by creating an account on GitHub.![](https://www.sredevops.org/content/images/icon/pinned-octocat-093da3e6fa40-33.svg)GitHubPercivalll![](https://www.sredevops.org/content/images/thumbnail/Copy-Fail-CVE-2026-31431-Kubernetes-PoC)](https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kubernetes-PoC?ref=sredevops.org) ## kubernetes-specific mitigations: patch first, architect second ### immediate actions (today) **disable the vulnerable kernel module** (temporary) ```bash # node-level mitigation via DaemonSet apiVersion: apps/v1 kind: DaemonSet metadata: { name: disable-algif-aead } spec: template: spec: hostPID: true containers: - name: mitigator image: alpine:latest command: ["/bin/sh", "-c"] args: - | echo "install algif_aead /bin/false" > /host/etc/modprobe.d/disable-algif.conf chroot /host rmmod algif_aead 2>/dev/null || true volumeMounts: - name: host-root mountPath: /host volumes: - name: host-root hostPath: { path: /, type: Directory } ``` **block `af_alg` at the runtime level** use seccomp profiles to prevent `af_alg` socket creation in untrusted pods: ```yaml # pod securityContext with seccomp securityContext: seccompProfile: type: Localhost localhostProfile: profiles/block-af-alg.json ``` ```json // profiles/block-af-alg.json { "defaultAction": "SCMP_ACT_ALLOW", "syscalls": [{ "names": ["socket"], "action": "SCMP_ACT_ERRNO", "args": [{"index": 0, "value": 38, "op": "SCMP_CMP_EQ"}] // AF_ALG = 38 }] } ``` **patch your nodes** apply a kernel containing the upstream fix (commit [a664bf3d603d](https://git.kernel.org/stable/c/a664bf3d603dc3bdcf9ae47cc21e0daec706d7a5?ref=sredevops.org)). for managed kubernetes services: ```bash # EKS: trigger node group update aws eks update-nodegroup-config --cluster-name my-cluster --nodegroup-name my-ng \ --launch-template version=$NEW_VERSION # GKE: enable auto-upgrade or manually upgrade nodes gcloud container clusters upgrade my-cluster --node-pool default-pool \ --cluster-version=1.35.2-gke.100 ``` ### architectural hardening (this quarter) - **isolate image layers for privileged workloads** use distinct base images for daemonsets like `kube-proxy` that aren't shared with user workloads. this breaks the page-cache propagation path. - **adopt pod security admission (psa) or gatekeeper policies** enforce that pods cannot request `hostpath` volumes, `privileged` mode, or `af_alg`\-capable seccomp exemptions. **restrict pod placement with node affinity** prevent untrusted workloads from scheduling on nodes running privileged daemonsets with shared base images: ```yaml affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: node-role.kubernetes.io/control-plane operator: DoesNotExist - key: workload-trust-level operator: In values: ["untrusted"] ``` **enforce read-only root filesystems** while copy fail bypasses on-disk checks, a read-only rootfs limits post-exploitation persistence options: ```yaml securityContext: readOnlyRootFilesystem: true allowPrivilegeEscalation: false ``` ## detection strategies for kubernetes environments copy fail is stealthy by design: the corrupted page is never marked dirty, so on-disk checksums remain valid. detection requires behavioral signals: 1. **monitor for anomalous `kube-proxy` behavior** corrupted `ipset` execution may cause: - unexpected iptables rule modifications - `kube-proxy` crash loops with unusual stack traces - auth.log entries with missing invoking usernames (see original advisory) 2. **watch for poc network artifacts** non-stealthy attackers may fetch exploit code from `https://copy.fail/exp`. alert on egress to this domain from cluster pods. **correlate pod scheduling with kernel version** flag any unprivileged pod scheduled on a node running an unpatched kernel: ```bash # quick cluster audit kubectl get nodes -o json | jq -r '.items[] | select(.status.nodeInfo.kernelVersion | test("6\\.(1[0-7]|[0-9])")) | .metadata.name' ``` **audit `af_alg` socket creation** use auditd or ebpf-based tracing to alert on unexpected `socket(AF_ALG, ...)` calls from containerized processes: ```bash # ebpf trace example (bpftrace) tracepoint:syscalls:sys_enter_socket /args->family == 38/ { printf("AF_ALG socket from pid %d (%s)\n", pid, comm); } ``` ## the uncomfortable truth about container "isolation" copy fail exposes a fundamental tension in container security: performance optimizations (shared page cache, overlayfs) directly conflict with isolation guarantees. the linux kernel was never designed with multi-tenant container workloads as a primary threat model—and it shows. this isn't a call to abandon containers. it's a reminder that "isolation" is a spectrum, not a binary. defense-in-depth means: - assuming local privesc vulnerabilities will exist - minimizing the blast radius when they do - treating kernel patch latency as a first-order risk metric because when four bytes can buy you the entire node, your pod security policy just became a suggestion. --- ## references - [wiz.io: copy fail vulnerability advisory](https://www.wiz.io/blog/copyfail-cve-2026-31431-linux-privilege-escalation-vulnerability?ref=sredevops.org) - [xint technical writeup: copy fail](https://xint.io/blog/copy-fail-linux-distributions?ref=sredevops.org) - [kubernetes poc: cve-2026-31431 container escape](https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kubernetes-PoC?ref=sredevops.org) - [upstream kernel fix: commit a664bf3d603d](https://git.kernel.org/stable/c/a664bf3d603dc3bdcf9ae47cc21e0daec706d7a5?ref=sredevops.org) - [kubernetes pod security admission docs](https://kubernetes.io/docs/concepts/security/pod-security-admission/?ref=sredevops.org) - [seccomp profiles for kubernetes](https://kubernetes.io/docs/tutorials/security/seccomp/?ref=sredevops.org) *source: adapted from wiz.io blog post by amitai cohen, merav bar, and shahar dorfman (may 1, 2026) and xint code research (april 29, 2026)* ### ¿Kubernetes es seguro para inteligencia artificial? Si, pero debes saber estos detalles URL: https://www.sredevops.org/es/kubernetes-es-seguro-para-inteligencia-artificial-si-pero-debes-saber-estos-detalles/ Last updated: 2026-04-20T19:29:11.000Z Si has pasado tiempo en el ecosistema *cloud-native*, conoces esa sensación: has configurado meticulosamente tus `NetworkPolicies`, tu RBAC es lo suficientemente estricto como para hacer llorar de alegría a cualquier auditor de seguridad y todos tus pods están en un hermoso y saludable color verde. Te sientes seguro. Te sientes protegido. Entonces, despliegas un Modelo de Lenguaje Extenso (LLM) y te das cuenta de que, aunque tu infraestructura es una fortaleza, básicamente le has entregado las llaves del reino a un loro parlanchín que puede ser engañado para filtrar las credenciales de tu base de datos simplemente porque alguien le dijo que "ignore todas las instrucciones anteriores". La [Cloud Native Computing Foundation (CNCF)](https://www.cncf.io/?ref=sredevops.org) lanzó recientemente una verdad lapidaria: Kubernetes es un orquestador increíble, pero es fundamentalmente ciego al caos semántico de la IA. Por eso, confiar únicamente en K8s para la seguridad de un LLM es el equivalente digital a instalar una cerradura biométrica de alta tecnología en una puerta de cartón. ## La ilusión del "pod en verde" Kubernetes es excelente en el "dónde" y el "cómo" del despliegue. Asegura que el pod de tu LLM tenga suficiente memoria de GPU, lo reinicia cuando falla y lo aísla de otras cargas de trabajo. Sin embargo, Kubernetes tiene cero visibilidad sobre el *contenido* del tráfico que fluye hacia ese pod. Para Kubernetes, un *prompt* que solicita el resumen de un PDF y un *prompt* que le ordena al modelo "eliminar todos los buckets de S3 y enviar los logs a una IP aleatoria en Europa del Este" se ven exactamente igual: ambos son simplemente solicitudes HTTP. Esto crea una brecha peligrosa: **`salud operacional != seguridad`.** Tu clúster puede estar perfectamente saludable mientras tu IA desmantela activamente la privacidad de los datos de tu empresa desde adentro. ## Manejar el caos dentro del caos: el modelo de amenazas de LLM Las aplicaciones tradicionales son deterministas. Proporcionas la entrada A y el código ejecuta la ruta B. Los LLMs, sin embargo, son entidades de toma de decisiones programables. Cuando le das a un LLM acceso a herramientas internas, APIs o logs, no estás desplegando solo un servicio; estás desplegando un agente. Esto introduce riesgos que `kube-proxy` no puede resolver: - **Prompt Injection:** El arte de engañar a un LLM para que ignore sus *system prompts* y realice acciones no autorizadas. - **Exposición no intencionada de datos:** El modelo "alucina" o filtra accidentalmente datos de entrenamiento sensibles o secretos del sistema en una respuesta. - **Uso indebido de herramientas:** Si tu LLM tiene un "plugin" para consultar tu base de datos, un usuario astuto podría engañarlo para que ejecute un comando `DROP TABLE` a través de un *prompt* en lenguaje natural. ## Donde la seguridad tradicional se queda corta Seamos claros: sigues necesitando tu seguridad estándar de K8s. Si no estás usando [Pod Security Admissions](https://kubernetes.io/docs/concepts/security/pod-security-admission/?ref=sredevops.org) o [Network Policies](https://kubernetes.io/docs/concepts/services-networking/network-policies/?ref=sredevops.org), tienes problemas más graves. Pero estas herramientas operan en las capas de red y de sistema operativo, mientras que las amenazas de los LLM operan en la **capa semántica**. | Capa de Seguridad | Herramienta de Kubernetes | Vulnerabilidad de LLM | ¿Puede K8s detenerlo? | | ----------------- | ------------------------- | ------------------------------------ | --------------------- | | **Red** | NetworkPolicy | Prompt Injection | No | | **Identidad** | RBAC | Filtración de datos vía Chat | No | | **Cómputo** | Resource Quotas | Alucinaciones del modelo | No | | **Runtime** | Seccomp/AppArmor | Ejecución de herramientas maliciosas | Parcialmente | Por ejemplo, una `NetworkPolicy` puede evitar que un pod se comunique con una IP externa, pero no puede evitar que un LLM le diga a un usuario: "Claro, aquí tienes la contraseña de administrador que encontré en las variables de entorno". ## Construyendo guardrails reales Para asegurar tus workloads LLM, debemos movernos hacia una **ingeniería de plataformas consciente de la IA (AI-aware platform engineering)**. Esto significa tratar al modelo como un usuario no confiable y envolverlo en una capa de gobernanza semántica. ### 1\. Adopta OWASP Top 10 para LLMs [OWASP Top 10 for LLM Applications](https://owasp.org/www-project-top-10-for-large-language-model-applications/?ref=sredevops.org) es el estándar de oro para comprender estos riesgos. Cubre desde la Inyección de Prompts (LLM01) hasta la Divulgación de Información Sensible (LLM06). ### 2\. Implementa guardrails semánticos En lugar de confiar en la infraestructura para bloquear el tráfico, implementa una capa intermedia (un "*guardrail*") que inspeccione tanto el *prompt* de entrada como la respuesta de salida. ```yaml ## Ejemplo conceptual de una Política de Guardrail ## (No es un CRD real de K8s, sino un flujo lógico) apiVersion: ai.security.io/v1 kind: LLMGuardrail metadata: name: pii-filter spec: inputValidation: - blockKeywords: ["ignore previous instructions", "system prompt"] - detectInjection: true outputValidation: - maskPII: true # Enmascarar emails, tarjetas de crédito, etc. - toxicityFilter: high ``` ### 3\. Usa el principio de menor privilegio Si tu LLM utiliza herramientas (*Function Calling*), no le otorgues privilegios de `cluster-admin` a la cuenta de servicio del LLM. Asígnale una identidad dedicada con los permisos mínimos absolutos requeridos para realizar su tarea específica. ## Reflexiones finales: confía, pero verifica (y luego verifica de nuevo) La industria está pasando de un modelo de seguridad "basado en el perímetro" a uno "basado en el comportamiento". En el mundo de la IA Generativa, el *prompt* es el nuevo vector de ataque. Kubernetes sigue siendo la capa fundacional; es el terreno sobre el cual construimos. Pero si crees que un archivo `yaml` es suficiente para detener un ataque sofisticado de *prompt injection*, no estás practicando la seguridad; estás practicando la esperanza. Y como cualquier SRE te dirá, la esperanza no es una estrategia de recuperación confiable. **Fuente:** Basado en análisis de la [Cloud Native Computing Foundation (CNCF)](https://www.cncf.io/blog/2026/03/30/llms-on-kubernetes-part-1-understanding-the-threat-model/?ref=sredevops.org). ### Grave brecha de Trivy en Github Actions amenaza tus secretos, tokens, credenciales e incluso tus artefactos, qué debes hacer y saber URL: https://www.sredevops.org/es/grave-brecha-de-trivy-en-github-actions-amenaza-tus-secretos-tokens-credenciales-e-incluso-tus-artefactos-que-debes-hacer-y-saber/ Last updated: 2026-03-21T19:57:49.000Z ## la ironía de la seguridad: las github actions de trivy secuestradas (otra vez) En un giro del destino que haría que cualquier SRE se sirviera un trago fuerte, Trivy —el escáner de vulnerabilidades estándar de la industria mantenido por Aqua Security— ha sido comprometido por segunda vez en un mes. Parece que la herramienta diseñada para encontrar brechas en tu infraestructura era, en sí misma, una brecha bastante grande. Esto no es solo un pequeño error en un archivo README. Estamos hablando de un ataque a la cadena de suministro (*supply chain attack*) a gran escala, donde se secuestraron 75 etiquetas de versión (*tags*) para distribuir un *infostealer* diseñado para succionar cada secreto en tu pipeline de CI/CD. ## el segundo acto de una tragedia en la cadena de suministro El la brecha afectó a dos GitHub Actions principales: `aquasecurity/trivy-action` y `aquasecurity/setup-trivy`. Estas son el pan de cada día en los pipelines de DevOps modernos, utilizadas para escanear imágenes de contenedores y configurar el entorno de Trivy. Según investigadores de [Socket](https://socket.dev/blog/trivy-under-attack-again-github-actions-compromise?ref=sredevops.org), un atacante logró realizar un *force-push* en 75 de las 76 etiquetas de versión en el repositorio `trivy-action`. Al sobrescribir las etiquetas existentes (como `v0.1.0`, `v0.2.0`, etc.), el atacante se aseguró de que cualquiera que apuntara a estas versiones "estables" descargara automáticamente un *payload* malicioso. Es un ataque clásico de "Tag Poisoning" (envenenamiento de etiquetas), demostrando una vez más que, en el mundo de Git, un *tag* es tan permanente como una promesa de año nuevo. ## cómo ocurrió el atraco: tag poisoning 101 El atacante no necesitó explotar un *zero-day* en Git. Simplemente utilizó credenciales válidas —probablemente un Personal Access Token (PAT) o un token de automatización— obtenidas de una brecha anterior. ### la mecánica del ataque 1. **Reutilización de credenciales:** Los atacantes aprovecharon secretos robados durante el incidente "hackerbot-claw" a finales de febrero de 2026. 2. **Force-Push de etiquetas:** En lugar de crear un nuevo *release* sospechoso, el atacante reescribió la historia. Actualizaron las etiquetas existentes para que apuntaran a *commits* maliciosos. 3. **Ejecución:** Cuando se ejecutaba un flujo de trabajo de GitHub Actions, este obtenía la etiqueta "envenenada", ejecutando un *infostealer* basado en Python en el *runner*. ```yaml # Lo que pensabas que estabas ejecutando: - name: Run Trivy vulnerability scanner uses: aquasecurity/trivy-action@v0.28.0 # Esta etiqueta fue secuestrada # Lo que realmente estaba pasando: # El runner descarga el commit malicioso asociado con v0.28.0 # y ejecuta el infostealer de Python embebido. ``` ## el payload: una aspiradora digital de secretos El código malicioso no fue sutil. Una vez activo en un *runner* de GitHub, realizaba un barrido sistemático del entorno para robar: - **Credenciales de nube:** Claves de AWS, Azure y GCP. - **Tokens de Kubernetes:** Porque, ¿por qué no apoderarse de todo el clúster? - **Claves SSH y configuraciones de Git:** Para movimiento lateral. - **Billeteras de criptomonedas:** Específicamente apuntando a pares de claves de validadores de Solana (un pequeño bono para los hackers). Si la exfiltración principal a `scan.aquasecurtiy[.]org` (noten la sutil falta de ortografía) fallaba, el script tenía un plan de respaldo: creaba un repositorio público llamado `tpcp-docs` bajo la propia cuenta de GitHub de la víctima y volcaba allí los datos robados. Eso es añadir sal a la herida. ## la causa raíz: una lección sobre "contención incompleta" Aqua Security admitió que esta segunda ola fue el resultado directo de una "contención incompleta" del primer incidente. Aunque rotaron los secretos, el proceso no fue "atómico". En el lapso entre la revocación y la rotación, los atacantes capturaron los nuevos tokens. Es un recordatorio aleccionador para los SRE: si no quemas la casa completa después de una brecha, las termitas simplemente se mudarán a la siguiente viga. ## atribución: conozcan a teampcp El *payload* se autoidentificó como el "TeamPCP Cloud stealer". [TeamPCP](https://www.elastic.co/security-labs/teampcp-container-attack-scenario?ref=sredevops.org) (también conocido como DeadCatx3 o ShellForce) es un grupo ya conocido en círculos de seguridad. Se especializan en vulnerar infraestructura para el robo de datos y extorsión. Aunque las "falsas banderas" siempre son una posibilidad en la atribución, las TTP (Tácticas, Técnicas y Procedimientos) coinciden estrechamente con el trabajo conocido del grupo. ## cómo detener la hemorragia Si estás usando Trivy en tus pipelines, detén lo que estés haciendo y verifica tus versiones. ### 1\. Usa versiones seguras Asegúrate de estar utilizando los siguientes lanzamientos (o posteriores): - [trivy 0.69.3](https://github.com/aquasecurity/trivy?ref=sredevops.org) - [trivy-action 0.35.0](https://github.com/aquasecurity/trivy-action?ref=sredevops.org) - [setup-trivy 0.2.6](https://github.com/aquasecurity/setup-trivy?ref=sredevops.org) ### 2\. Fija por SHA, no por etiqueta Esta es la lección más importante. Las etiquetas son mutables; los hashes SHA-256 no lo son. Al fijar tus GitHub Actions a un hash de *commit* específico, eliminas el riesgo de secuestro de etiquetas. ```yaml # NO hagas esto: uses: aquasecurity/trivy-action@v0.28.0 # HAZ esto (hash de ejemplo): uses: aquasecurity/trivy-action@1234567890abcdef1234567890abcdef12345678 ``` ### 3\. Rótalo todo Si ejecutaste una versión comprometida (específicamente la `v0.69.4` del binario o las etiquetas de la *action* secuestradas), asume que **todos** tus secretos están comprometidos. Rota tus claves de AWS, PATs de GitHub y tokens de Kubernetes de inmediato. ### 4\. Filtrado de red Bloquea los siguientes indicadores de compromiso (IoCs) a nivel de firewall o proxy: - **Dominio:** `scan.aquasecurtiy[.]org` - **IP:** `45.148.10[.]212` Para más detalles técnicos, puedes seguir la discusión en curso en el [GitHub oficial de Aqua Security](https://github.com/aquasecurity/trivy/discussions/10425?ref=sredevops.org). **Fuente:** [The Hacker News](https://thehackernews.com/2026/03/trivy-security-scanner-github-actions.html?ref=sredevops.org) **Referencia del autor:** Basado en reportes de The Hacker News e investigaciones de Socket, Wiz y StepSecurity. ### Los mitos y credos respecto a turnos (o "estar de guardia") URL: https://www.sredevops.org/es/los-mitos-y-credos-respecto-a-turnos-o-estar-de-guardia/ Last updated: 2026-03-21T14:35:15.000Z Llevo más de una década haciendo turnos de guardia. Cuando los computadores que administro tienen un problema, le avisan a mi equipo 24/7 para que los ayude. Uso estos credos para que estar de turno sea lo más tranquilo posible. ### Descúbrelo antes que el cliente Ya sea que el cliente sea interno o externo, los monitores deben ajustarse para que el equipo de guardia pueda responder y reparar antes de que quienes dependen del servicio se den cuenta de que hay un problema. ### Cada alerta de alta prioridad debería ser accionable La fatiga de alertas es real. Claro, envía algunas alertas informativas pero no accionables a un canal de chat. Pero si el equipo de guardia se despierta e interrumpe cuando no hay trabajo real que hacer, eso es un problema. Reevalúa: - ¿Se puede ajustar el sistema o la alerta para que las alertas sean accionables? - ¿Necesitamos esta alarma en absoluto? - ¿Debería aumentarse temporalmente el umbral de la alerta? - ¿Podría deshabilitarse temporalmente la alerta, con un recordatorio establecido con una alerta configurada para cuando se espere que el problema esté completamente resuelto? ### Los sistemas críticos deberían ser redundantes Muchas emergencias de alta prioridad se pueden convertir en situaciones de baja prioridad si existe una política y práctica que establezca que todos los sistemas críticos son redundantes. Para servidores no críticos, usa una función como la que ofrece Amazon Web Services para detectar cuando el hardware subyacente falla. Luego, puede reaprovisionar automáticamente nuevo hardware y reiniciar el servidor. Eso es exactamente lo que haría un humano de guardia en esas situaciones, así que automatiza la solución. ### El primer responsable debería poder resolver la mayoría de los problemas. Para las alertas de una aplicación en particular, alguien familiarizado con la aplicación debería estar de turno para darle soporte. Los miembros nuevos del equipo de turno pueden acompañar a los miembros con más experiencia para adquirir conocimientos antes de tomar turnos solos. ### Debería haber un segundo de turno Si el principal no responde a tiempo, las alertas deberían pasar a otra persona. Hay que dejar bien clara la responsabilidad de cada rol. Se espera que el principal se encargue de las páginas o que haga arreglos con anticipación si hay un período en el que no pueda cubrir. Que dos personas estén de turno esperando que la otra tome una página no es una estrategia. ### Tener un runbook que documente las posibles alertas y las respuestas comunes a ellas Idealmente, para cada problema debería haber alguna forma de evitar que ocurra o automatizar una solución para los incidentes. Para el resto, algunos documentos y una lista de verificación son lo mejor. He usado un Google Doc organizado por servidor o servicio. Para cada uno, hay una breve sección de Contexto para recordar qué hace la cosa, una sección de Contacto para los expertos del servicio a quienes escalar. En algunos casos, las escaladas a estas personas se pueden automatizar con el servicio de paginación. Finalmente, si hay alguna nota especial sobre alertas y resoluciones comunes. Por ejemplo: **Servidor del blog:* El alto uso de CPU en este servidor a menudo indica que WordPress está siendo atacado de nuevo. Considera bloquear las direcciones IP involucradas en el firewall.* Aún mejor: usa las herramientas en servicios como PagerDuty para incluir o enlazar la documentación que necesites para cada alerta directamente en la alerta misma. ## Los incidentes de producción deberían ser analizados Ah, no hay nada como el compañerismo que surge de vivir un "firefight" para volver a poner un servicio en línea juntos. Para minimizar las reuniones de tu brigada de bomberos, aprende de los errores cometidos y toma medidas proactivas para minimizar su recurrencia. Cuando haya una interrupción significativa, programa un informe post-incidente de producción dentro de una o dos semanas después del incidente. El enfoque es prospectivo para mejorar los sistemas. No es una sesión para buscar culpables. Usa una plantilla estándar y limita el tiempo de las reuniones para mantener las cosas en movimiento. Treinta minutos suelen ser suficientes. Aquí hay algunas preguntas que he usado antes en plantillas de informes post-incidente de producción que han resistido la prueba del tiempo: - Resumen y cronología del incidente - Acciones ya tomadas - ¿Qué salió bien? - ¿Cómo podemos prevenir incidentes similares en el futuro? - ¿Cómo podemos responder de manera más eficiente y efectiva? - ¿Qué acciones de seguimiento se deben tomar? Haz que una persona cercana al incidente redacte la cronología y dirija la reunión. Invita a todas las partes interesadas relevantes para el incidente. ## Todo lo demás también importa Detallar todo lo demás que podría mejorar la calidad de vida de los respondedores de guardia sería describir un departamento de TI completo y bien gestionado. Siempre habrá inconvenientes al estar de guardia. Con algunos principios sólidos y un compromiso con la mejora continua, hay esperanza de llegar al punto en que el número de alertas sea mínimo... y accionable. ### Vulnerabilidad alta en GitHub Actions: hackerbot-claw usa tu CI/CD como una plataforma de "pwn-as-a-service" URL: https://www.sredevops.org/es/vulnerabilidad-alta-en-github-actions-hackerbot-claw-usa-tu-ci-cd-como-una-plataforma-de-pwn-as-a-service/ Last updated: 2026-03-04T03:33:08.000Z ## Resumen (Overview) Resulta que automatizar tus flujos de trabajo también hace que sea increíblemente fácil para los atacantes automatizar tu perdición. Una campaña de ataque autónoma, rastreada como **"hackerbot-claw"**, está acechando actualmente repositorios públicos. ¿Su misión? Encontrar workflows de GitHub Actions inseguros y convertirlos en puertas de enlace para la ejecución de código arbitrario y la exfiltración de credenciales. Esta campaña no es solo el proyecto de fin de semana de un *script-kiddie*; ha logrado comprometer con éxito varios proyectos de código abierto de alto perfil. Al abusar de configuraciones erróneas comunes, el bot efectivamente vuelve tu pipeline de CI/CD en tu contra. Si has estado tratando tus triggers de `pull_request_target` con la imprudencia de un desarrollador en su quinto café del día, es hora de prestar atención. La Linux Foundation y la OpenSSF están "triagiando" (triage) activamente las consecuencias, pero el bot trabaja más rápido que un comité. ## Anatomía del ataque El bot "hackerbot-claw" no está reinventando la rueda; simplemente está usando la rueda para pasarte por encima. Se dirige específicamente a workflows que: - Utilizan triggers privilegiados como `pull_request_target`. - Ejecutan código no confiable de *pull requests* (PRs) forkeados sin aislamiento. - Incluyen scripts de shell *inline* que confían ciegamente en inputs controlados por el usuario. - Carecen de cualquier forma de verificación de autorización antes de disparar *runners* costosos (y peligrosos). ### Patrones de ataque observados 1. **Inyección directa de scripts:** Los atacantes modifican un script dentro de un PR. Si el workflow ejecuta ese script con privilegios del repositorio, el atacante efectivamente se adueña del *runner*. 2. **"Pwn request" (abuso de `pull_request_target`):** Este trigger es el "Modo Dios" de GitHub Actions. Cuando se usa para hacer *checkout* y ejecutar código desde un *fork*, otorga a ese código no confiable acceso a secretos y a un `GITHUB_TOKEN` con permisos de escritura. 3. **Inyección de contexto:** Los *payloads* maliciosos se ocultan en nombres de ramas, títulos de PR o rutas de archivos. Si tu workflow hace algo como `echo "Checking out ${{ github.head_ref }}"`, podrías encontrarte ejecutando `echo "Checking out "; rm -rf / #`. ### Una víctima del mundo real: project-akri/akri En un caso documentado que involucró a `project-akri/akri`, un PR malicioso introdujo un *payload* de inyección de shell en un script. Debido a que el workflow carecía de salvaguardas, ejecutó obedientemente los comandos del atacante, demostrando una vez más que las computadoras harán exactamente lo que les digas, incluso si es un suicidio profesional. ## Mitigaciones recomendadas Si no quieres que tu repositorio se convierta en un minero de criptomonedas para alguien más o en un punto de pivote para un ataque a la cadena de suministro, implementa estos controles de inmediato. ### 1\. Refuerza (harden) tus workflows Deja de usar `pull_request_target` a menos que sea absolutamente necesario. Si debes usarlo, **nunca** hagas *checkout* del código no confiable desde el *head* del PR. ```yaml # MAL: Esto le da al código del fork acceso a tus secretos on: pull_request_target jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 with: ref: ${{ github.event.pull_request.head.sha }} # PELIGRO ``` ### 2\. Aplica el principio de menor privilegio Limita los permisos del `GITHUB_TOKEN` en la parte superior de tu archivo de workflow. Si un *job* solo necesita leer el código, indícalo explícitamente. ```yaml permissions: contents: read pull-requests: read ``` ### 3\. Sanitiza los inputs como si tu vida dependiera de ello Nunca interpoles variables de contexto de GitHub directamente en scripts de shell. Usa variables de entorno en su lugar. ```yaml # MAL: Vulnerable a inyección run: echo "Procesando rama: ${{ github.head_ref }}" # BIEN: Manejado como datos, no como código run: echo "Procesando rama: $BRANCH_NAME" env: BRANCH_NAME: ${{ github.head_ref }} ``` ### 4\. Pinnea tus actions No confíes en etiquetas (tags) como `@v1`. Los tags pueden ser movidos. Usa el SHA completo del commit para asegurar que el código que estás ejecutando es el código que revisaste. ```yaml - uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608 # v4.1.0 ``` ## Alineación con el OpenSSF OSPS Baseline La campaña actual "hackerbot-claw" apunta exactamente a las brechas abordadas por el [OpenSSF OSPS (Open Source Project Security) Baseline](https://best.openssf.org/SCM-BestPractices?ref=sredevops.org). Los proyectos que siguen estas pautas son significativamente más difíciles de comprometer. - **Menor Privilegio:** Restringir el `GITHUB_TOKEN` y usar OIDC para credenciales de nube de corta duración. - **CI/CD Protegido:** Requerir la aprobación de un mantenedor para todos los colaboradores primerizos antes de que se ejecuten los workflows. - **Revisión por Pares:** Usar `CODEOWNERS` para exigir que cualquier cambio en `.github/workflows/` sea revisado por un humano consciente de la seguridad, no solo por un mantenedor cansado. ## Lecturas adicionales y recursos - [Guía oficial de GitHub sobre inyección de scripts](https://docs.github.com/en/actions/concepts/security/script-injections?ref=sredevops.org) - [OpenSSF: Mitigando vectores de ataque en workflows de GitHub](https://openssf.org/blog/2024/08/12/mitigating-attack-vectors-in-github-workflows?ref=sredevops.org) - [Wiz.io: Guía de seguridad de GitHub Actions](https://www.wiz.io/blog/github-actions-security-guide?ref=sredevops.org) - [Mejores prácticas de OpenSSF SCM](https://best.openssf.org/SCM-BestPractices?ref=sredevops.org) --- **Fuente:** Christopher "CRob" Robinson, Chief Technology Officer & Chief Security Architect en OpenSSF / The Linux Foundation. [GitHub](https://github.com/SecurityCRob?ref=sredevops.org) | [LinkedIn](https://www.linkedin.com/in/darthcrob?ref=sredevops.org) ### High severity Github Actions exploit: hackerbot-claw uses your ci/cd as a "pwn-as-a-service" platform URL: https://www.sredevops.org/en/high-severity-github-actions-exploit-hackerbot-claw-uses-your-ci-cd-as-a-pwn-as-a-service-platform/ Last updated: 2026-03-04T02:48:44.000Z ## overview It turns out that automating your workflows also makes it incredibly easy for attackers to automate your demise. An autonomous attack campaign, tracked as **"hackerbot-claw,"** is currently prowling public repositories. Its mission? Finding insecure GitHub Actions workflows and turning them into gateways for arbitrary code execution and credential exfiltration. The campaign isn't just a script-kiddie's weekend project; it has successfully compromised several high-profile open-source projects. By abusing common misconfigurations, the bot effectively turns your CI/CD pipeline against you. If you’ve been treating your `pull_request_target` triggers with the reckless abandon of a developer on their fifth espresso, it’s time to pay attention. The Linux Foundation and the OpenSSF are actively triaging the fallout, but the bot works faster than a committee. ## anatomy of the attack The "hackerbot-claw" bot isn't reinventing the wheel; it’s just using the wheel to run you over. It specifically targets workflows that: - Use privileged triggers like `pull_request_target`. - Execute untrusted code from forked pull requests without isolation. - Include inline shell scripts that blindly trust user-controlled inputs. - Lack any form of authorization check before firing off expensive (and dangerous) runners. ### observed attack patterns 1. **Direct script injection:** Attackers modify a script within a PR. If the workflow executes that script with repository privileges, the attacker effectively owns the runner. 2. **"Pwn request" (pull\_request\_target abuse):** This trigger is the "God Mode" of GitHub Actions. When used to check out and run code from a fork, it grants that untrusted code access to secrets and a `GITHUB_TOKEN` with write permissions. 3. **Context injection:** Malicious payloads are hidden in branch names, PR titles, or file paths. If your workflow does something like `echo "Checking out ${{ github.head_ref }}"`, you might find yourself executing `echo "Checking out "; rm -rf / #`. ### a real-world casualty: project-akri/akri In a documented case involving `project-akri/akri`, a malicious PR introduced a shell-injection payload into a script. Because the workflow lacked safeguards, it dutifully executed the attacker's commands, proving once again that computers will do exactly what you tell them to do, even if it's professional suicide. ## recommended mitigations If you don't want your repository to become a miner for someone else's cryptocurrency or a pivot point for a supply chain attack, implement these controls immediately. ### 1\. harden your workflows Stop using `pull_request_target` unless you absolutely have to. If you must use it, **never** check out the untrusted code from the PR head. ```yaml # BAD: This gives the fork's code access to your secrets on: pull_request_target jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 with: ref: ${{ github.event.pull_request.head.sha }} # DANGER ``` ### 2\. enforce least privilege Limit the `GITHUB_TOKEN` permissions at the top of your workflow file. If a job only needs to read the code, tell it so. ```yaml permissions: contents: read pull-requests: read ``` ### 3\. sanitize inputs like your life depends on it Never interpolate GitHub context variables directly into shell scripts. Use environment variables instead. ```bash # BAD: Vulnerable to injection run: echo "Processing branch: ${{ github.head_ref }}" # GOOD: Handled as data, not code run: echo "Processing branch: $BRANCH_NAME" env: BRANCH_NAME: ${{ github.head_ref }} ``` ### 4\. pin your actions Don't trust tags like `@v1`. Tags can be moved. Use the full length commit SHA to ensure the code you're running is the code you reviewed. ```yaml - uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608 # v4.1.0 ``` ## alignment with the openssf osps baseline The ongoing "hackerbot-claw" campaign targets the exact gaps addressed by the [OpenSSF OSPS (Open Source Project Security) Baseline](https://best.openssf.org/SCM-BestPractices/?ref=sredevops.org). Projects that follow these guidelines are significantly harder to compromise. - **Least Privilege:** Restrict `GITHUB_TOKEN` and use OIDC for short-lived cloud credentials. - **Protected CI/CD:** Require maintainer approval for all first-time contributors before workflows run. - **Peer Review:** Use `CODEOWNERS` to mandate that any change to `.github/workflows/` is reviewed by a security-conscious human, not just a tired maintainer. ## further reading & resources - [GitHub's official guidance on script injection](https://docs.github.com/en/actions/concepts/security/script-injections?ref=sredevops.org) - [OpenSSF: Mitigating attack vectors in GitHub workflows](https://openssf.org/blog/2024/08/12/mitigating-attack-vectors-in-github-workflows?ref=sredevops.org) - [Wiz.io: GitHub Actions security guide](https://www.wiz.io/blog/github-actions-security-guide?ref=sredevops.org) - [OpenSSF SCM best practices](https://best.openssf.org/SCM-BestPractices/?ref=sredevops.org) --- **Source:** Christopher "CRob" Robinson, Chief Technology Officer & Chief Security Architect at OpenSSF / The Linux Foundation. [GitHub](https://github.com/SecurityCRob?ref=sredevops.org) | [LinkedIn](https://www.linkedin.com/in/darthcrob?ref=sredevops.org) ### Anthropic es "baneada" por el Pentágono en medio de "disputa ética" sobre uso de IA en guerra y vigilancia social URL: https://www.sredevops.org/es/anthropic-es-baneada-por-el-pentagono-en-medio-de-disputa-etica-sobre-uso-de-ia-en-guerra-y-vigilancia-social/ Last updated: 2026-02-28T13:21:23.000Z En una medida que evidencia la creciente tendencia autoritaria de gobiernos, la tensión entre la innovación tecnológica y los *"imperativos de seguridad nacional"* ~~(ok...)~~, el Departamento de Guerra de EE. UU. (DoW) ha designado oficialmente a Anthropic, empresa ya por todos conocida en inteligencia artificial (IA), como un "*riesgo en la cadena de suministro" (supply chain risk)*. Esta designación, impulsada por el secretario de Defensa de EE. UU., Pete Hegseth, surge tras un estancamiento en las negociaciones sobre el "despliegue ético" de Claude, el modelo de IA insignia de Anthropic, para aplicaciones y usos militares. ## La "postura desafiante" de Anthropic La designación de Anthropic como riesgo en la cadena de suministro se deriva de su negativa a permitir dos usos específicos de su tecnología: la vigilancia masiva doméstica de ciudadanos estadounidenses y el desarrollo de sistemas de armas autónomas. La compañía articuló su postura en un [comunicado](https://www.anthropic.com/news/statement-comments-secretary-war?ref=sredevops.org): *"Ninguna cantidad de intimidación o castigo del Departamento de Guerra cambiará nuestra posición sobre la vigilancia masiva doméstica o las armas totalmente autónomas"*. ## La hipocresía -si, también- de Anthropic Este desacuerdo fundamental sobre los límites éticos de la IA en la "defensa nacional" implica el apoyo de Anthropic al uso de su tecnología en otros países, pero rechaza su aplicación en EEUU por considerarla incompatible con valores democráticos y libertades fundamentales. Las contradicciones y el doble standard se revelan por sí mismos, no? ### No es conspiración ni ficción: documentos oficiales El Departamento de Guerra (antes llamado Departamento de Defensa), insiste en colaborar sólo con empresas que permitan *"cualquier uso lícito"* de su tecnología, sin *"restricciones ideológicas"*. Un [memorándum del Pentágono](https://media.defense.gov/2026/Jan/12/2003855671/-1/-1/0/ARTIFICIAL-INTELLIGENCE-STRATEGY-FOR-THE-DEPARTMENT-OF-WAR.PDF?ref=sredevops.org) subraya esta postura: *"La Diversidad, Equidad e Inclusión no tienen cabida en el DoW. No emplearemos modelos de IA con 'ajustes' ideológicos que limiten respuestas objetivamente veraces"*. ![](https://www.sredevops.org/content/images/2026/02/image.png) **Fuente:* [**https://media.defense.gov/2026/Jan/12/2003855671/-1/-1/0/ARTIFICIAL-INTELLIGENCE-STRATEGY-FOR-THE-DEPARTMENT-OF-WAR.PDF*](https://media.defense.gov/2026/Jan/12/2003855671/-1/-1/0/ARTIFICIAL-INTELLIGENCE-STRATEGY-FOR-THE-DEPARTMENT-OF-WAR.PDF?ref=sredevops.org) ## La rápida (y teatral) represalia del gobierno La designación fue parte de una respuesta coordinada. El presidente ordenó via [1 User Only"Social Network"](https://truthsocial.com/@realDonaldTrump/posts/116144552969293195?ref=sredevops.org) eliminar gradualmente la tecnología de Anthropic en agencias federales dentro de seis meses. El secretario de guerra lo *retwitteó (?)* en [X](https://x.com/secwar/status/2027507717469049070?ref=sredevops.org), exigiendo a contratistas militares cesar toda relación con la empresa. El funcionario vinculó la medida a la orden presidencial, declarando: *"Designamos a Anthropic como Riesgo en la Cadena de Suministro para la Seguridad Nacional"*. El gobierno actuó con la agilidad de un *zero-day exploit*, priorizando acción directa sobre formalidades. ### Detalles legales que no entendemos Anthropic calificó la designación de *"jurídicamente infundada"*, argumentando que "10 USC 3252 solo aplica a contratos del DoW, no a otros clientes" ~~(La verdad es que no tengo idea de legislación en EEUU)~~. Este escenario sienta un precedente peligroso: "desacuerdos éticos" podrían convertirse en "riesgos de seguridad nacional" a gusto del gobierno o magnate de turno, pero sus consecuencias afectando al mundo entero. Por ejemplo, potencialmente un dron podría "decidir" atacarte ahora mismo sin orden humana. Si, a ti. ## 2 CEOs 1 Gov: el camino de OpenAI En contraste, el CEO de OpenAI, Sam Altman, anunció un [acuerdo con el Departamento de Defensa](https://x.com/sama/status/2027578652477821175?ref=sredevops.org) para desplegar sus modelos en redes clasificadas. Ya sabemos el resto de la historia. ## Por qué debería importarme? La disputa trasciende países, política, o lo corporativo: define el futuro de la IA en "seguridad" y guerra. Cientos de empleados de Google y OpenAI [exigen solidaridad](https://notdivided.org/?ref=sredevops.org) con Anthropic, resaltando preocupaciones sectoriales. La designación envía un mensaje alarmante: la ética puede subordinarse a la "seguridad nacional". ¿Seguirán otras empresas el "ejemplo" de Anthropic o adaptarán sus principios a contratos gubernamentales? La respuesta define si la IA servirá a la humanidad o se convertirán en herramientas de guerra y vigilancia. Fuente: [The Hacker News](https://thehackernews.com/2026/02/pentagon-designates-anthropic-supply.html?ref=sredevops.org) ### Kubernetes ahora tiene un Node Readiness Controller: porque "ready" es un término relativo URL: https://www.sredevops.org/es/kubernetes-ahora-tiene-un-node-readiness-controller-porque-ready-es-un-termino-relativo/ Last updated: 2026-02-06T04:05:43.000Z A todos nos ha pasado: Kubernetes *jura de guata* que un nodo está `Ready`, pero tus pods se están cayendo más rápido que el primer deploy a producción de un "vibe coder". En el modelo estándar de Kubernetes, el estado "Ready" es algo binario que muchas veces ignora el despelote de la infraestructura moderna. Solo porque el kubelet esté respirando no significa que el CNI sea funcional, que los drivers de la GPU hayan cargado o que los montajes de almacenamiento no estén gritando al vacío en este preciso momento. Hoy le echamos un ojo al [Node Readiness Controller](https://node-readiness-controller.sigs.k8s.io/?ref=sredevops.org), un proyecto que por fin reconoce que el estado "Ready" es un espectro con matices y no un simple interruptor. Este controller introduce un sistema declarativo para gestionar los *node taints*, asegurando que tus workloads no aterricen en un nodo que técnicamente está "arriba" pero que, en la práctica, no sirve para nada. ## ¿Por qué existe node readiness controller? La condición `NodeReady` nativa de Kubernetes es, siendo honestos, un poco optimista. Funciona bien para una app web básica en una VM genérica, pero da la hora en entornos más cuáticos. Los operadores suelen recurrir a scripts medios "hacky" o intervención manual para asegurar que los DaemonSets o el firmware especializado estén operativos antes de que el scheduler empiece a tirarle pods al nodo. Node Readiness Controller soluciona esto permitiéndote definir *scheduling gates* personalizados. Es básicamente un bouncer (un guardia de discoteca) para tus nodos, asegurándose de que realmente pasen el "test de la alcoholemia" (requisitos de infraestructura) antes de que se les permita recibir invitados (pods). Las ventajas clave incluyen: - **Definiciones de readiness a medida**: Tú defines qué significa realmente "ready" para tu hardware o plataforma específica. - **Gestión automatizada de taints**: El controller se encarga de la pega pesada de aplicar y quitar taints para que tú no tengas que hacerlo. - **Bootstrapping declarativo**: Un camino claro y observable para la inicialización de nodos en múltiples pasos. ## Conceptos clave y la API NRR El corazón de este sistema es la API `NodeReadinessRule` (NRR). Esta te permite definir las condiciones específicas que un nodo debe cumplir antes de ser considerado apto para el servicio. ### Modos de cumplimiento flexibles El controller no es de una sola línea; entiende que distintos problemas requieren distintos niveles de paranoia: - **Continuous enforcement (Cumplimiento continuo)**: Para los más perseguidos. Este modo monitorea el nodo durante todo su ciclo de vida. Si una dependencia crítica —como un agente de red— falla seis meses después del arranque, el controller le clava un taint al nodo de inmediato para evitar que se agenden nuevos pods en una zona de desastre. - **Bootstrap-only enforcement (Solo arranque)**: Para tareas de configuración inicial. Es perfecto para el pre-pull de imágenes de contenedor gigantes o el aprovisionamiento inicial de hardware. Una vez que se cumplen las condiciones, el controller marca la pega como lista y deja de vigilar al nodo. ### Reporte de condiciones: los ojos y oídos El controller no hace los health checks por sí mismo; es el jefe, no el obrero. Reacciona a los `NodeConditions` reportados por otras herramientas. Esta arquitectura desacoplada le permite llevarse bien con: - [**Node Problem Detector**](https://github.com/kubernetes/node-problem-detector?ref=sredevops.org) **(NPD)**: El estándar de la industria para convertir problemas locales del nodo en condiciones legibles por Kubernetes. - **Readiness Condition Reporter**: Un agente liviano proporcionado por el proyecto que puede testear endpoints HTTP locales y parchar las condiciones del nodo según corresponda. ### Seguridad operativa con dry run Como nada te arruina más un viernes en la tarde que mandarte un condoro y aplicarle un taint por error a todo tu cluster de 500 nodos, el controller incluye un modo **dry run**. En este modo, el controller loguea lo que *habría* hecho y actualiza el estado de la regla, permitiéndote validar tu lógica sin romper nada. Es como un sandbox para tu exceso de confianza al alterar la infraestructura. ## Ejemplo: Bootstrapping de CNI La siguiente `NodeReadinessRule` asegura que un nodo se mantenga "unschedulable" hasta que el agente CNI sea realmente funcional. Espera a que una condición personalizada `cniplugin.example.net/NetworkReady` pase a `True` antes de remover el taint `readiness.k8s.io/acme.com/network-unavailable`. ```yaml apiVersion: readiness.node.x-k8s.io/v1alpha1 kind: NodeReadinessRule metadata: name: network-readiness-rule spec: conditions: - type: "cniplugin.example.net/NetworkReady" requiredStatus: "True" taint: key: "readiness.k8s.io/acme.com/network-unavailable" effect: "NoSchedule" value: "pending" enforcementMode: "bootstrap-only" nodeSelector: matchLabels: node-role.kubernetes.io/worker: "" ``` ## Cómo participar? Node Readiness Controller está actualmente en sus etapas iniciales (v0.1.1), que es el momento perfecto para colaborar antes de que la API quede escrita en piedra y tus reclamos por casos borde pasen al olvido. - **GitHub**: [https://sigs.k8s.io/node-readiness-controller](https://sigs.k8s.io/node-readiness-controller?ref=sredevops.org) - **Slack**: Únete a la conversa en [#sig-node-readiness-controller](https://kubernetes.slack.com/messages/sig-node-readiness-controller?ref=sredevops.org) en el workspace de Kubernetes. - **Documentación**: [Guía oficial de inicio rápido](https://node-readiness-controller.sigs.k8s.io/?ref=sredevops.org) **Fuente:** [https://kubernetes.io/blog/2026/02/03/introducing-node-readiness-controller/](https://kubernetes.io/blog/2026/02/03/introducing-node-readiness-controller/?ref=sredevops.org) **Autor:** Ajay Sundar Karuppasamy (Google) ### La gran unificación de google cloud: opentelemetry se vuelve obligatorio (y ya era hora) URL: https://www.sredevops.org/es/la-gran-unificacion-de-google-cloud-opentelemetry-se-vuelve-obligatorio-y-ya-era-hora/ Last updated: 2026-02-05T09:47:25.000Z Si pensabas que podrías seguir ignorando el avance de **OpenTelemetry (OTel)** mientras te escondías en tus scripts legacy, Google Cloud acaba de enviarte un recordatorio amistoso —o una amenaza elegante, según cómo lo mires—. La plataforma ha lanzado una nueva API de ingestión que soporta de forma nativa los protocolos de OTel (OTLP) para logs, trazas y métricas. Básicamente, Google está ordenando la casa. A partir del **4 de marzo de 2026**, la nueva API `telemetry.googleapis.com` se convertirá en una dependencia obligatoria para las APIs actuales de Cloud Logging, Cloud Trace y Cloud Monitoring. Es el fin de una era y el comienzo de una donde, por fin, parece que todos hablaremos el mismo idioma técnico. ## ¿Qué está pasando realmente en el backend? Para los que trabajamos en SRE o DevOps, sabemos que la fragmentación de APIs es un dolor de cabeza constante. Google está intentando mitigar esto unificando los endpoints. La jugada es simple: quieren que la transición hacia herramientas de recolección modernas sea "seamless" (palabra favorita del marketing para decir que, si algo falla, probablemente sea culpa de tu configuración y no de ellos). ### Los cambios clave que debes masticar - **Activación automática:** Si creas un proyecto mediante la consola o el CLI de gcloud, las APIs de observabilidad se activan solas. Nada nuevo bajo el sol. Sin embargo, lo interesante es que desde marzo de 2026, habilitar cualquiera de estas APIs activará automáticamente el endpoint `telemetry.googleapis.com`. - **Retrocompatibilidad forzada:** Google habilitará este nuevo endpoint en todos los proyectos existentes que ya tengan activas las APIs de ingestión actuales. Sí, aunque no lo hayas pedido. Es como ese update de Windows que se instala a las 3 AM cuando tienes un despliegue crítico, pero supuestamente sin romper nada. ## ¿Por qué debería importarte? (Más allá de mantener tu pega) OpenTelemetry no es solo un capricho de la industria; es el estándar de facto para la observabilidad moderna. Al mover la ingestión hacia un endpoint unificado de OTel, Google está facilitando que saques tus datos de su ecosistema si algún día decides que el "vendor lock-in" te está saliendo muy caro. Además, el soporte nativo para **OTLP (OpenTelemetry Protocol)** significa menos transformaciones de datos, menor latencia y, en teoría, menos bugs en el pipeline de telemetría. ### Un vistazo técnico al protocolo El protocolo OTLP utiliza gRPC y HTTP/JSON para transportar datos de telemetría. Aquí te dejo un ejemplo conceptual de cómo se vería una configuración básica de un exportador en un colector de OTel para apuntar a Google Cloud: ```yaml exporters: googlecloud: project: "tu-proyecto-123" log: default_log_name: "opentelemetry.io/collector-export" retry_on_failure: enabled: true service: pipelines: logs: receivers: [otlp] processors: [batch] exporters: [googlecloud] ``` ## ¿Qué tienes que hacer? (Spoiler: casi nada) La buena noticia para los que practicamos *"SRE para flojos"* es que **no se requiere ninguna acción inmediata**. Google hará el trabajo sucio por ti. No habrá interrupciones en tus servicios actuales, o al menos eso prometen en su documentación oficial (y ya sabemos que las promesas en la nube son tan estables como un pod sin `livenessProbe`). Si por alguna razón mística o conspiranoica decides que no quieres esta API, puedes desactivarla manualmente, aunque eso sería como intentar nadar contra la corriente en el Mapocho: sucio y probablemente termines mal. ## Recursos para no quedar como un "noob" Si quieres profundizar en cómo OpenTelemetry está devorando el mundo de la observabilidad, te recomiendo revisar estos enlaces: - [Documentación oficial de OpenTelemetry](https://opentelemetry.io/docs/?ref=sredevops.org) - [Google Cloud Observability - Documentación de OTLP](https://docs.cloud.google.com/stackdriver/docs/reference/telemetry/overview?ref=sredevops.org) - [Repositorio de GitHub del OTel Collector Contrib](https://github.com/open-telemetry/opentelemetry-collector-contrib?ref=sredevops.org) En resumen, el cambio es inevitable. Google está moviendo las piezas para que la observabilidad sea más coherente. Así que, relájate, tómate un mote con huesillo y deja que los scripts de automatización de Google hagan su magia. Tienes hasta el 2026 para pretender que esto te tomó por sorpresa. ### KYAML: Convergencia entre la robustez de JSON y la flexibilidad de YAML en Kubernetes URL: https://www.sredevops.org/es/kyaml-convergencia-entre-la-robustez-de-json-y-la-flexibilidad-de-yaml-en-kubernetes/ Last updated: 2026-02-02T22:03:48.000Z En la gestión operativa de Kubernetes, la definición de manifiestos ha oscilado históricamente entre dos extremos. Por un lado, **YAML**, el estándar de facto, ofrece legibilidad humana pero es intrínsecamente frágil debido a su dependencia de la indentación y la ambigüedad en el tipado de datos. Por otro lado, **JSON**, preferido por las máquinas por su estructura estricta, carece de soporte para comentarios y obliga a la definición monolítica de objetos, lo que dificulta su mantenimiento en entornos complejos gestionados por herramientas como Helm o Kustomize. Con la llegada de **Kubernetes 1.35**, se consolida una solución que unifica las mejores características de ambos formatos: **KYAML**. ## ¿Qué es KYAML? KYAML no es un nuevo lenguaje, sino la adopción estandarizada del **estilo de flujo (flow style)** de YAML. Su sintaxis se caracteriza por el uso explícito de delimitadores: - **Objetos:** Encapsulados en llaves `{}`. - **Arrays:** Definidos mediante corchetes `[]`. - **Tipado:** Exige que todos los valores de tipo *string* estén delimitados por comillas dobles (`""`). Esta aproximación elimina la ambigüedad del parseo sin sacrificar la ergonomía del desarrollador. ## Beneficios Técnicos y Operativos La adopción de KYAML impacta directamente en la estabilidad de los pipelines de CI/CD y en la experiencia de desarrollo (DevEx): 1. **Integridad Estructural:** Al utilizar bloques delimitados (`{}` y `[]`), el manifiesto se vuelve inmune a los errores de indentación. La estructura lógica prevalece sobre la visual, eliminando los fallos críticos provocados por espacios en blanco errantes durante operaciones de *copy-paste*. 2. **Capacidad de Documentación:** A diferencia de JSON, KYAML conserva la capacidad de YAML para incluir comentarios (`#`). Esto es vital para documentar decisiones de infraestructura (ej. *requests/limits*, *magic numbers*) directamente en el código. 3. **Seguridad de Tipos:** La obligatoriedad de comillas para los strings mitiga errores de coerción de tipos implícita (como el conocido caso del código de país “NO” interpretado como booleano `false` en YAML 1.1). ## Estado de Madurez y Adopción La transición a KYAML está diseñada para ser transparente y de baja fricción: - **Retrocompatibilidad:** `kubectl` procesa KYAML nativamente, ya que cumple con la especificación YAML existente. - **Sin cambios en la extensión:** Los ficheros mantienen la extensión `.yaml`, facilitando la integración con herramientas de linting y validación actuales. - **Soporte Nativo en v1.35:** Kubernetes 1.35 introduce soporte explícito en el CLI. Ahora es posible serializar objetos existentes al nuevo formato mediante `kubectl ... -o kyaml`. - **Soporte en IDEs:** Editores modernos como VSCode o Cursor interpretan la sintaxis correctamente, aunque la diferenciación visual (coloreado de sintaxis) entre claves y valores aún tiene margen de mejora en el ecosistema de extensiones. ## Implementación Práctica: YAML vs. KYAML A continuación, se contrasta la definición de un objeto `Deployment` en ambos formatos. Estos ejemplos están disponibles en el repositorio de referencia [erase-una-vez-k8s/encodings](https://github.com/mmorejon/erase-una-vez-k8s/tree/main/encodings?ref=sredevops.org). ### Formato Clásico (Block Style) Dependiente de la indentación y verticalidad: ```yaml # fragmento de manifiesto en formato YAML (Block Style) apiVersion: apps/v1 kind: Deployment metadata: name: erase-una-vez-2-prod labels: app: erase-una-vez-2 env: prod tier: frontend spec: replicas: 3 strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 1 maxSurge: 25% selector: matchLabels: app: erase-una-vez-2 template: metadata: labels: app: erase-una-vez-2 spec: containers: - name: server image: ghcr.io/mmorejon/erase-una-vez-2:v0.5.0 ports: - containerPort: 8000 name: http resources: requests: cpu: 100m memory: 128Mi limits: cpu: 500m memory: 256Mi ``` ## Formato KYAML (Flow Style) Estructurado, compacto y con tipado explícito: ```yaml # fragmento de manifiesto en formato KYAML (Flow Style) apiVersion: "apps/v1" kind: "Deployment" metadata: { name: "erase-una-vez-2-prod", labels: { app: "erase-una-vez-2", env: "prod", tier: "frontend" } } spec: { replicas: 3, strategy: { type: "RollingUpdate", rollingUpdate: { maxUnavailable: 1, maxSurge: "25%" } }, selector: { matchLabels: { app: "erase-una-vez-2" } }, template: { metadata: { labels: { app: "erase-una-vez-2" } }, spec: { containers: [ { name: "server", image: "ghcr.io/mmorejon/erase-una-vez-2:v0.5.0", ports: [{ containerPort: 8000, name: "http" }], resources: { requests: { cpu: "100m", memory: "128Mi" }, limits: { cpu: "500m", memory: "256Mi" } } } ] } } } ``` ## KYAML en la práctica Primero necesitas un clúster con la versión 1.35\. Puedes utilizar el repositorio [erase-una-vez-k8s](https://github.com/mmorejon/erase-una-vez-k8s?ref=sredevops.org) para levantar un clúster local compatible en cuestión de segundos (aproximadamente 40 segundos). ```bash git clone https://github.com/mmorejon/erase-una-vez-k8s.git cd erase-una-vez-k8s ./bash/cluster.sh create ``` Garantiza el estés utilizando la versión 1.35 de `kubectl`: ```bash kubectl version --client Client Version: v1.35.0 Kustomize Version: v5.7.1 ``` Una vez tengas el clúster, envía el manifiesto en formato KYAML a tu clúster: ```bash kubectl apply --filename https://raw.githubusercontent.com/mmorejon/erase-una-vez-k8s/refs/heads/main/encodings/kyaml/deployment.yaml deployment.apps/erase-una-vez-2-prod created ``` Verifica que el deployment se ha creado correctamente: ```bash kubectl get deployment erase-una-vez-2-prod NAME READY UP-TO-DATE AVAILABLE AGE erase-una-vez-2-prod 3/3 3 3 33s ``` Aprovecha esta oportunidad para exportar el manifiesto en formato KYAML: ```bash kubectl get deployment erase-una-vez-2-prod -o kyaml ``` KYAML representa el siguiente paso lógico en la madurez de la configuración de Kubernetes: la precisión que exigen las máquinas con la flexibilidad que necesitan los humanos. [KYAML: Convergencia entre la robustez de JSON y la flexibilidad de YAML en KubernetesDescubre cómo KYAML elimina los errores de indentación de YAML y permite comentarios que JSON no soporta, mejorando la experiencia de desarrollo DevOps![](https://www.sredevops.org/content/images/icon/favicon-32x32-2.png)mmorejon![](https://www.sredevops.org/content/images/thumbnail/thumbnail-1.webp)](https://mmorejon.io/blog/kyaml-convergencia-entre-json-y-yaml/?ref=sredevops.org) ### Realidad sobre la Privacidad en Latam: entre el copy-paste europeo y la sumisión a EEUU URL: https://www.sredevops.org/es/realidad-sobre-la-privacidad-en-latam-entre-el-copy-paste-europeo-y-la-sumision-a-eeuu/ Last updated: 2026-01-24T12:35:06.000Z El 28 de enero no es sólo una fecha para que los abogados de *compliance* se saluden en LinkedIn. Es el Día de la Protección de Datos, una efeméride que conmemora la firma de la [Convención 108](https://rm.coe.int/16806c1abd?ref=sredevops.org) en 1981\. Fue el primer intento serio —y jurídicamente vinculante— de Europa por ponerle orden al tratamiento automatizado de información. Básicamente, los europeos decidieron que tu vida privada no debería ser un libro abierto para cualquier servidor con suficiente RAM. Sin embargo, en América Latina, esta fecha se siente un poco como celebrar el día del agua en medio de una sequía institucional. Mientras la privacidad es ese derecho romántico a "que no te molesten", la protección de datos es la infraestructura técnica y legal que evita que tu RUT, tu dirección y tus preferencias políticas terminen en un bucket de S3 mal configurado o, peor aún, en una base de datos a la venta por un par de dólares. ## El fetiche de la ley: cuando el papel aguanta todo En la última década, la región ha vivido una fiebre por copiar el [Reglamento General de Protección de Datos (GDPR)](https://gdpr-info.eu/?ref=sredevops.org) de la Unión Europea. Es el estándar de oro, claro, pero implementarlo en Latam es como intentar correr Kubernetes en un Pentium II: la intención es buena, pero los recursos y el contexto no acompañan. Hemos visto avances, no lo vamos a negar: - **Paraguay:** Aprobó su ley a fines de 2025 tras un debate intenso. - **Chile:** Por fin [actualizó su normativa en 2024 (con entrada en vigencia para 2026), elevando el estándar de lo que entendemos por derechos digitale](https://www.gob.cl/noticias/ley-proteccion-datos-personales-aprobacion-eleva-estandar-derechos/?ref=sredevops.org)s. - **El lado oscuro:** En El Salvador, las leyes de "protección" parecen más una herramienta para amordazar a la prensa que para cuidar al ciudadano. El problema es que una ley sin una autoridad independiente que la fiscalice es solo literatura fantástica. Si el mismo Estado que debe proteger tus datos es el que los usa para vigilancia masiva sin salvaguardas, tenemos un *single point of failure* en nuestra democracia. [Atención: La amenaza de la DMCA en Chile para la libertad tecnológica y la criminalización de la innovaciónUna amenaza real para personas y empresas Imagina que compras un servidor para tu startup por 5 millones de pesos. El fabricante decide que el soporte termina en dos años y lanza un parche que “brickea” (deja como un ladrillo) el hardware si no pagas una licencia anual de otros![](https://www.sredevops.org/content/images/icon/Icon-App-76x76@2x-18.png)SREDevOps.orgNicolás Georger![](https://www.sredevops.org/content/images/thumbnail/dmca-amenaza-a-chile.webp)](https://www.sredevops.org/es/atencion-la-amenaza-de-la-dmca-en-chile-para-la-libertad-tecnologica-y-la-criminalizacion-de-la-innovacion/) Puedes leer también [Atención: La amenaza de la DMCA en Chile para la libertad tecnológica y la criminalización de la innovación](https://www.sredevops.org/es/atencion-la-amenaza-de-la-dmca-en-chile-para-la-libertad-tecnologica-y-la-criminalizacion-de-la-innovacion/) ## Telegram: el mall clandestino de tu identidad Si quieres saber qué tan protegidos están tus datos, no leas el diario oficial; entra a Telegram. Investigaciones recientes de [Derechos Digitales](https://www.derechosdigitales.org/?ref=sredevops.org) confirman lo que cualquier *sysadmin* con ojeras ya sabe: existe una economía transnacional de datos robados que funciona mejor que cualquier API gubernamental. En estos canales circulan: - Números de teléfono y direcciones físicas. - Historiales médicos (datos sensibles que deberían estar bajo siete llaves). - Información de filiación y datos financieros. Este mercado negro no es un error del sistema; es una característica de una estructura donde la información personal se monetiza mucho antes de que el titular sepa que fue vulnerado. La brecha entre la norma y la práctica es tan grande que podrías desplegar un clúster de bases de datos en ella. ## El mito del consentimiento y la fragilidad del sistema Casi todas las leyes modernas se basan en el "consentimiento informado". En teoría, es hermoso. En la práctica, es un chiste de mal gusto en una región con brechas de alfabetización digital gigantescas. ¿Cómo va a consentir alguien que no entiende qué es una *cookie* o cómo un algoritmo de Machine Learning puede predecir su comportamiento crediticio? A esto le sumamos una cultura de ciberseguridad que, siendo generosos, es precaria. Las filtraciones masivas en organismos públicos no son incidentes aislados; son el resultado de ver la seguridad de la información como un gasto y no como un pilar estratégico. En Latam, parece que solo nos acordamos de la encriptación y los respaldos cuando el *ransomware* ya está cifrando hasta el Excel de la colación. ### Desafíos técnicos y estructurales: 1. **Falta de independencia:** Autoridades de control que dependen del presupuesto del gobierno de turno. 2. **Seguridad reactiva:** Instituciones que responden a incidentes en lugar de implementar políticas de *Privacy by Design*. 3. **Asimetría de poder:** Ciudadanos enfrentados a gigantes tecnológicos y estados digitalizados sin mecanismos reales de defensa. ## Más allá de soplar las velas: hacia una justicia digital real El 28 de enero no puede ser solo una foto para Instagram. En América Latina, la protección de datos debe ser una herramienta de resistencia. No se trata de copiar modelos europeos por un complejo de inferioridad regulatoria, sino de construir respuestas que entiendan nuestra realidad: desigual, movilizada y constantemente bajo vigilancia. La protección de datos solo tiene sentido si pone límites reales al poder, ya sea el de una multinacional que quiere predecir tus compras o el de un gobierno que quiere mapear tus protestas. La justicia digital no es un lujo de primer mundo; es una necesidad básica para sobrevivir al siglo XXI. **Fuente:** [Protección de datos en América Latina: avances, tensiones y desafíos pendientes](https://www.derechosdigitales.org/recursos/proteccion-de-datos-en-america-latina-avances-tensiones-y-desafios-pendientes/?ref=sredevops.org)en DerechosDigitales.org [Protección de datos en América Latina: avances, tensiones y desafíos pendientesEn el marco del Día Internacional de la Protección de Datos (28/01), destacamos cómo América Latina muestra importantes avances legales recientes, pero también profundas brechas entre la teoría y la práctica. En esta columna analizamos esas tensiones y los desafíos pendientes para la efectividad del derecho a la protección de datos en la región.![](https://www.sredevops.org/content/images/icon/cropped-favicon-dd-270x270.png)Derechos Digitales![](https://www.sredevops.org/content/images/thumbnail/Semana-2_ProteccionDeDatos_2-scaled.png)](https://www.derechosdigitales.org/recursos/proteccion-de-datos-en-america-latina-avances-tensiones-y-desafios-pendientes/?ref=sredevops.org) [Open Knowledge Foundation – Por un futuro justo, sostenible y abierto![](https://www.sredevops.org/content/images/icon/favicon-18.ico)![](https://www.sredevops.org/content/images/thumbnail/okfn-standard-thumb.png)](https://okfn.org/es/?ref=sredevops.org) ### Imágenes OCI como volúmenes en Kubernetes: Una nueva era para la gestión de datos URL: https://www.sredevops.org/es/imagenes-oci-como-volumenes-en-kubernetes-una-nueva-era-para-la-gestion-de-datos/ Last updated: 2026-01-21T23:10:21.000Z Recientemente se ha incorporado un nuevo tipo de volumen al ecosistema de Kubernetes: el volumen **image**. Esta funcionalidad, disponible a partir de la versión **1.35.0** y actualmente en fase beta, promete cambiar la forma en que gestionamos los datos estáticos y configuraciones en nuestros clústeres. La relevancia de este tipo de volumen ha ido en aumento en el entorno nativo de la nube. Diversas aplicaciones ya utilizan imágenes de contenedor para almacenar información en formato OCI (*Open Container Initiative*). Herramientas populares como **Falco** (para reglas de seguridad), **Kyverno** (para políticas) y **FluxCD** (para la gestión de despliegues) son claros ejemplos de esta tendencia. Ahora, esta capacidad es nativa de Kubernetes. ## Beneficios de utilizar imágenes OCI para datos Adoptar este patrón en tus aplicaciones trae consigo ventajas significativas: 1. **Simplificación de la infraestructura**: Hasta ahora, gestionar ficheros externos solía requerir servicios de almacenamiento en la nube como S3 o GCS. Esto implicaba costos adicionales, gestión de *buckets* y configuración de permisos. Al utilizar el volumen `image`, prescindes de estos servicios externos, simplificando tu arquitectura. 2. **Seguridad integrada**: Al tratarse de imágenes OCI estándar, puedes utilizar las mismas herramientas de escaneo de vulnerabilidades que ya usas para tus aplicaciones. Esto asegura que los ficheros de configuración o datos que introduces no contienen vulnerabilidades conocidas. 3. **Despliegues más rápidos**: Si separas el código fuente de los datos, puedes actualizar configuraciones generando una nueva imagen de datos (más ligera) sin necesidad de reconstruir la imagen completa de la aplicación. ## ¿Cómo crear imágenes de datos? Con esta funcionalidad habilitada, surge la necesidad de crear estas “imágenes de datos”. Aunque pueda sonar complejo, el proceso es bastante sencillo y se apoya en herramientas estándares del ecosistema. Una variante sencilla, nativa y fácil de implementar es utilizar **Docker** y la imagen `scratch`. Este enfoque no requiere herramientas adicionales. Simplemente creamos un `Dockerfile` que parte de una imagen vacía y copiamos nuestros datos dentro: ```Dockerfile FROM scratch COPY ./files / ``` Y el proceso de construcción es el estándar que ya conoces: ```bash docker image build -t ghcr.io/mmorejon/erase-una-vez-5:main . docker image push ghcr.io/mmorejon/erase-una-vez-5:main ``` ## Ejemplo de uso Para utilizar este tipo de volumen, defines el volumen en la sección `volumes` de tu Pod haciendo referencia a la imagen, y luego lo montas en el contenedor mediante `volumeMounts`. Aquí tienes un ejemplo sencillo de cómo configurarlo: ```yaml apiVersion: v1 kind: Pod metadata: name: volume-example spec: containers: - name: app image: ghcr.io/mmorejon/erase-una-vez-1:v0.3.2 volumeMounts: - name: data-volume mountPath: /srv/data volumes: - name: data-volume image: reference: ghcr.io/mmorejon/erase-una-vez-5:main pullPolicy: IfNotPresent ``` En este caso, el contenido de la imagen `ghcr.io/mmorejon/erase-una-vez-5:main` estará disponible dentro del contenedor en la ruta `/srv/data`. ## ¿Cómo probarlo hoy mismo? Para utilizar esta funcionalidad necesitas un clúster de Kubernetes en su versión **1.35.0**. Dado que esta versión es muy reciente, es posible que todavía no esté disponible en los principales proveedores de nube como Azure, AWS o GCP. Sin embargo, no dejes que eso te detenga. Puedes utilizar el repositorio **erase-una-vez-k8s** para levantar un clúster local compatible en cuestión de segundos (aproximadamente 40 segundos). Es una forma excelente de experimentar con estas nuevas características en tu propio entorno de desarrollo. Crea tu clúster local utilizando el repositorio [erase-una-vez-k8s](https://github.com/mmorejon/erase-una-vez-k8s?ref=sredevops.org). Para los que vivimos en la terminal, aquí tienes los pasos para reproducirlo ahora mismo: ### 1\. Clona el repositorio con el entorno listo ```bash git clone https://github.com/mmorejon/erase-una-vez-k8s.git cd erase-una-vez-k8s ``` ### 2\. Crea el clúster (requiere Docker instalado) ``` ./bash/cluster.sh create ``` ### 3\. Despliega el Pod de ejemplo ```bash kubectl apply -f https://raw.githubusercontent.com/mmorejon/erase-una-vez-5/refs/heads/main/manifest.yaml ``` Y el momento de la verdad. Verifica que el volumen se ha montado correctamente ```bash kubectl exec erase-una-vez-5 -- cat /usr/share/nginx/html/example-1.txt # > Érase una vez Kubernetes ``` El volumen de tipo `image` es un paso más hacia la estandarización y simplificación en Kubernetes. Te animo a que lo pruebes y descubras cómo puede optimizar tus flujos de trabajo de datos y configuración. [Imágenes OCI como volúmenes en Kubernetes: Una nueva era para la gestión de datosRecientemente se ha incorporado un nuevo tipo de volumen al ecosistema de Kubernetes: el volumen \*\*image\*\*. Esta funcionalidad, disponible a partir de la versión \*\*1.35.0\*\* y actualmente en fase beta, promete cambiar la forma en que gestionamos los datos estáticos y configuraciones en nuestros clústeres.![](https://www.sredevops.org/content/images/icon/favicon-32x32-1.png)mmorejon![](https://www.sredevops.org/content/images/thumbnail/thumbnail.webp)](https://mmorejon.io/blog/imagen-oci-como-volumen-en-kubernetes/?ref=sredevops.org) ### El plan "Code Orange: Fail Small" de Cloudflare: Un post-mortem de las caídas globales y la ruta hacia la resiliencia URL: https://www.sredevops.org/es/el-plan-code-orange-fail-small-de-cloudflare-un-post-mortem-de-las-caidas-globales-y-la-ruta-hacia-la-resiliencia/ Last updated: 2026-01-16T19:42:04.000Z La iniciativa ["Code Orange: Fail Small" de Cloudflare](https://blog.cloudflare.com/fail-small-resilience-plan/?ref=sredevops.org) no es solo un nombre bonito; significa un cambio de paradigma hacia prácticas de despliegue más cautelosas y, sobre todo, una asunción más realista de que fallar es inevitable. Al contener los problemas antes de que hagan metástasis y se conviertan en caídas globales, Cloudflare busca recuperar no solo la confianza, sino la estabilidad misma del ecosistema de internet. Porque, la verdad... nadie quiere tener que explicarle al jefe por qué el sitio está abajo solo porque a un CDN o al DNS se les ocurrió tirarse desde la ventana. [Code Orange: Fail Small — our resilience plan following recent incidentsWe have declared “Code Orange: Fail Small” to focus everyone at Cloudflare on a set of high-priority workstreams with one simple goal: ensure that the cause of our last two global outages never happens again.![](https://www.sredevops.org/content/images/icon/favicon-32x32.png)The Cloudflare BlogDane Knecht![](https://www.sredevops.org/content/images/thumbnail/BLOG-3097_OG.png)](https://blog.cloudflare.com/fail-small-resilience-plan/?ref=sredevops.org) ## Las caídas recientes y su impacto El 2025 resultó ser un año bastante "movidito" para la red de Cloudflare, marcado por dos incidentes de proporciones que dejaron la grande en el ecosistema digital. - **18 de noviembre de 2025:** El primer condoro, detallado por [InfoQ](https://www.infoq.com/news/2025/11/cloudflare-global-outage-cause/?ref=sredevops.org), interrumpió el tráfico por unas dos horas y diez minutos. Para muchos, fueron 130 minutos de quedarse mirando el *spinner* de carga, preguntándose si el internet finalmente había tirado la toalla. - **5 de diciembre de 2025:** La segunda caída, documentada en el propio [post-mortem](https://blog.cloudflare.com/5-december-2025-outage/?ref=sredevops.org) de Cloudflare, afectó a cerca del 28% de las aplicaciones detrás de su red por unos 25 minutos. Un corte más corto, quizás, pero igual de brígido como para sacarles un gruñido colectivo a los desarrolladores y usuarios. Ambos incidentes fueron gatillados por cambios de configuración globales casi instantáneos que, irónicamente, buscaban mejorar la seguridad o la detección de bots. Estos cambios provocaron una propagación ultra rápida de *settings* erróneos en cientos de *data centers*, transformando un error de configuración menor en una catástrofe digital global. ## Los pilares del plan Code Orange: Fail Small Entonces, ¿qué trae este nuevo "remedio" para la resiliencia? El plan "Code Orange: Fail Small" se apoya en tres pilares fundamentales, diseñados para inyectarle una buena dosis de cautela y robustez a sus operaciones globales. ### Rollouts controlados y cambios de configuración El plan exige que los cambios de configuración —los mismos culpables de las últimas caídas— se implementen de forma controlada y por fases. Este enfoque ahora imita el proceso de [Health Mediated Deployment (HMD)](https://blog.cloudflare.com/safe-change-at-any-scale/?ref=sredevops.org) de Cloudflare, que ya estaba más que probado pero que antes se reservaba solo para lanzamientos de software. Imagínalo como el hermano mayor cuático del software que ahora se queda cuidando los cambios de configuración. El proceso HMD incluye validaciones por etapas y mecanismos de *rollback* automático, asegurando que la cosa esté estable antes de mandarse el despliegue masivo. Históricamente, las actualizaciones de configuración críticas —ya fueran registros DNS o reglas de seguridad— se disparaban a toda la red global de Cloudflare en segundos, gracias a su sistema interno [Quicksilver](https://blog.cloudflare.com/quicksilver-v2-evolution-of-a-globally-distributed-key-value-store-part-1/?ref=sredevops.org). Un sistema diseñado para la velocidad que, como ya vimos, también puede ser un demonio para desatar desastres. La nueva política dicta que estas actualizaciones ahora pasarán por una serie de "puertas" de monitoreo y despliegues graduales. ¿El objetivo? Pillar esa config maliciosa antes de que decida botar la mitad del internet, *data center* por *data center*. ### Mejorando los modos de falla (Failure Modes) Cloudflare está revisando con lupa y mejorando todos los modos de falla dentro de los sistemas que manejan el tráfico de red. La idea es asegurar que cada componente se comporte de forma predecible cuando las papas queman, evitando que un solo punto de falla gatille un efecto dominó catastrófico. Esto implica validar rigurosamente los contratos de interfaz entre productos críticos y, lo más importante, establecer valores por defecto (*defaults*) con sentido común. La lógica es que si un subsistema dependiente decide fallar, el tráfico debería seguir fluyendo, aunque sea "cojeando". Porque, seamos realistas, al internet no le gusta para nada el *stop* total. ### Overhaul a los procedimientos "Break-Glass" La compañía también le está pegando una buena renovada a sus procedimientos "break-glass" —esos protocolos de emergencia para cuando *"queda la escoba"* de verdad—. El fin es desenredar las dependencias circulares en el acceso a herramientas internas que, históricamente, han convertido la respuesta rápida a incidentes en un ballet en cámara lenta. Con mejor capacitación y protocolos de acceso de emergencia simplificados, buscan empoderar a los ingenieros para que reaccionen con la velocidad de un SRE con sobredosis de cafeína, pero sin comprometer las mismas salvaguardas de seguridad que están tratando de proteger. ## Ejecución incremental y mirada al futuro Cloudflare no solo está vendiendo humo; están aplicando la receta paso a paso. Para fines del primer trimestre de 2026, esperan que todos los sistemas de producción estén operando bajo el proceso de configuración HMD mejorado, con modos de falla mejor definidos y testeados, y ojalá, con un acceso de respuesta a emergencias que no requiera un mapa del tesoro y un saludo secreto. Este mismo despliegue por fases es un testimonio de la filosofía "fail small". ## Contexto y reacción de la comunidad Estos esfuerzos proactivos llegan justo cuando están bajo el foco, después de una serie de caídas que dejaron a sitios gigantes como LinkedIn, Zoom y Shopify temporalmente en la edad de piedra digital. Estos incidentes, con justa razón, reavivaron el eterno debate sobre los riesgos de depender tanto de una infraestructura de internet centralizada. Es como si poner todos los huevos en la misma canasta no fuera siempre la mejor estrategia, aunque esa canasta sea Cloudflare. Si bien se sintió una dosis saludable de frustración en los foros y redes, muchos usuarios valoraron que Cloudflare reconociera sus errores de frente y se comprometiera con mejoras estructurales. Al final, la transparencia, incluso después de un condoro digital, igual suma puntos. ## Fuente [Craig Risi en InfoQ](https://www.infoq.com/news/2026/01/cloudflare-resilience-plan/?ref=sredevops.org) [Cloudflare Launches ‘Code Orange: Fail Small’ Resilience Plan After Multiple Global OutagesCloudflare recently published a detailed resilience initiative called Code Orange: Fail Small, outlining a comprehensive plan to prevent large-scale service disruptions after two major network outages in the past six weeks.![](https://www.sredevops.org/content/images/icon/apple-touch-icon-35.png)InfoQCraig Risi![](https://www.sredevops.org/content/images/thumbnail/generatedHeaderImage-1768039481376.jpg)](https://www.infoq.com/news/2026/01/cloudflare-resilience-plan/?ref=sredevops.org) ### Mission Center: A new and great app for monitoring your Linux desktop URL: https://www.sredevops.org/en/mission-control-a-new-and-great-app-for-monitoring-your-linux-desktop/ Last updated: 2026-01-16T02:33:31.000Z Let’s face it: `top` is for the masochists, and `htop` is for the people who want to feel like they’re in *The Matrix*. But sometimes, you just want to see your CPU melting in high definition without squinting at an ASCII bar chart. Enter [Mission Center](https://missioncenter.io/?ref=sredevops.org), a modern, Rust-powered system monitor that actually looks like it belongs in the current decade. Built with GTK4 and Libadwaita, it provides a sleek interface to watch your hardware struggle under the weight of your 400 open Chrome tabs. ![](https://www.sredevops.org/content/images/2026/01/image.png) ## Features: More than just pretty graphs Mission Center isn't just a pretty face; it’s a comprehensive tool for SREs and developers who need to know exactly why their local environment is screaming. - **Granular CPU tracking:** Monitor overall usage or dive into per-thread metrics. It tracks uptime, clock speeds, and cache sizes, so you can see exactly how much potential you're wasting. - **Memory and swap analysis:** A detailed breakdown of RAM usage, because we all know "cached" memory is just the OS's way of saying "I'll give it back when I feel like it." - **Disk and network I/O:** Real-time transfer rates and utilization. It even identifies your network card name and IP address, saving you a trip to `ip addr show`. - **GPU monitoring:** Powered by the legendary [NVTOP](https://github.com/Syllo/nvtop?ref=sredevops.org) project, it tracks GPU usage, video encoders/decoders, and power consumption. - **Resource efficiency:** Written in **Rust** for performance and memory safety. It uses hardware-accelerated rendering for graphs, because using 20% of your CPU just to monitor your CPU is a design flaw we’ve finally moved past. ## The "work in progress" (Limitations) Nothing is perfect, especially in the Linux desktop ecosystem. Here is what might annoy you: - **Per-process network monitoring:** This requires a bit of manual labor. If you want to see which app is leaking data, check the [Nethogs wiki](https://gitlab.com/mission-center-devs/mission-center/-/wikis/Home/Nethogs?ref=sredevops.org). - **Intel GPU gaps:** Support is limited to Broadwell and newer. If you're rocking a vintage Intel chip, don't expect to see VRAM or temperature stats. - **Cinnamon/Linux Mint issues:** There is a known upstream bug where launched apps might not show up in the "Applications" section. - **Theming:** Since it’s a Libadwaita app, it follows its own rules. It won't care about your custom "Cyberpunk 2077" system theme. ## Installation: Pick your poison Mission Center is widely available across the Linux landscape. It even comes pre-installed on modern atomic distros like [Bluefin](https://projectbluefin.io/?ref=sredevops.org) and [Bazzite](https://bazzite.gg/?ref=sredevops.org). - **Flatpak (Recommended):** `flatpak install flathub io.missioncenter.MissionCenter` - **Snap:** `snap install mission-center` - **AppImage:** Grab the latest x86\_64 or ARM64 builds from the [GitLab releases](https://gitlab.com/mission-center-devs/mission-center?ref=sredevops.org). For those who enjoy tracking versions across repositories, check the [Repology status](https://repology.org/project/mission-center/versions?ref=sredevops.org). [Install Mission Center on Linux | FlathubMonitor system resource usage![](https://www.sredevops.org/content/images/icon/favicon-5.svg)FlathubMission Center Developers![](https://www.sredevops.org/content/images/thumbnail/io.missioncenter.MissionCenter)](https://flathub.org/en/apps/io.missioncenter.MissionCenter?ref=sredevops.org) [Universal blue es Linux en tu escritorio pero evolucionado con patrones cloud-native y con una comunidad activa¿La idea central? Tomar los patrones probados en batalla del mundo cloud-native – específicamente, imágenes base inmutables del SO construidas como contenedores – y aplicarlos al escritorio. Es ospechosamente como alguien intentando arreglar el escritorio Linux... otra vez. Pero esperen, esta vez involucra contenedores, palabras de moda cloud-native, y una dosis saludable![](https://www.sredevops.org/content/images/icon/Icon-App-76x76@2x-17.png)SREDevOps.orgNicolás Georger![](https://www.sredevops.org/content/images/thumbnail/ublue.png)](https://www.sredevops.org/es/universal-blue-es-linux-en-tu-escritorio-pero-evolucionado-con-patrones-cloud-native-y-con-una-comunidad-activa/) ## Building from source: For the brave If you insist on compiling it yourself (perhaps to feel something), here is how you do it on a modern system like Ubuntu 25.10. ### Prerequisites You'll need the usual suspects: Meson, Rust (1.90+), GTK4 (4.20+), and Libadwaita (1.8+). ```bash sudo apt install build-essential cmake curl desktop-file-utils gettext git \ libadwaita-1-dev libdbus-1-dev libdrm-dev libgbm-dev libudev-dev meson \ pkg-config protobuf-compiler python3-gi python3-pip ``` ### Native build ```bash BUILD_ROOT="$(pwd)/build-meson-debug" # Setup and compile meson setup "$BUILD_ROOT" -Dbuildtype=debug ninja -C "$BUILD_ROOT" # Run it "$BUILD_ROOT/src/missioncenter" ``` ### Flatpak build If you prefer the containerized approach for development: ```bash cd flatpak flatpak-builder --repo=repo --ccache --force-clean build io.missioncenter.MissionCenter.json flatpak build-bundle repo missioncenter.flatpak io.missioncenter.MissionCenter flatpak install -y missioncenter.flatpak ``` ## Contributing and support The project is hosted on [GitLab](https://gitlab.com/mission-center-devs/mission-center?ref=sredevops.org). If you find a bug, report it. If you want to talk shop, join their [Discord](https://discord.gg/RG7QTeB9yk?ref=sredevops.org). ### Supporting the ecosystem Instead of just tossing coins at this project, consider supporting the giants it stands on: - [The GNOME Project](https://donate.gnome.org/?ref=sredevops.org) - [The Rust Foundation](https://rustfoundation.org/get-involved/?ref=sredevops.org) - [NVTOP](https://github.com/Syllo/nvtop?ref=sredevops.org) ## License Mission Center is licensed under the **GNU General Public License v3.0**. It’s free as in "freedom," not just free as in "I didn't pay for this." *Source:* [*Mission Center GitLab*](https://gitlab.com/mission-center-devs/mission-center?ref=sredevops.org) [mission-center-devs / Mission Center · GitLabGitLab.com![](https://www.sredevops.org/content/images/icon/favicon-72a2cad5025aa931d6ea56c3201d1f18e68a8cd39788c7c80d5b2b82aa5143ef.png)GitLab![](https://www.sredevops.org/content/images/thumbnail/io.missioncenter.MissionCenter.png)](https://gitlab.com/mission-center-devs/mission-center?ref=sredevops.org) ### Qué es kuberc? Es tu mejor aliado para personalizar kubectl URL: https://www.sredevops.org/es/que-es-kuberc-es-tu-mejor-aliado-para-personalizar-kubectl/ Last updated: 2026-01-09T03:07:47.000Z Si día a día estás más de cinco minutos metido/a en un terminal, sabes que `kubectl` es tu mejor partner, pero al mismo tiempo es el culpable de que tengas el túnel carpiano *"pal' gato"*. Por años, hemos dependido de los *aliases* del shell o de herramientas de terceros como `kubectx` y `fzf` para no volvernos locos. Por fin, los mantenedores de Kubernetes se compadecieron y nos tiraron un hueso con `kuberc`. Introducido como una funcionalidad beta en Kubernetes 1.34, `kuberc` te permite definir preferencias de usuario, *aliases* de comandos y políticas de seguridad sin "*dejar la crema*" en tu `kubeconfig` con datos que no son del clúster. Básicamente, es una forma de decirle a `kubectl` cómo comportarse antes de que te entre lag mental y borres un *namespace* de producción por andar tipeando muy rápido. ## ¿dónde vive este archivo `kuberc`? Por defecto, `kubectl` busca su "personalidad" en las siguientes rutas: - **Linux / macOS:** `$HOME/.kube/kuberc` - **Windows:** `%USERPROFILE%\.kube\kuberc` Si eres de esos que les gusta guardar sus archivos de configuración en lugares raros, como quién escribe, que tiene una obsesión con sus `dotfiles` ~~sólo para sentirnos diferentes~~, puedes sobrescribir esto usando el *flag* `--kuberc` o seteando la variable de entorno `KUBERC`. ## aliases: ahorrándole movimientos a tus dedos por el exceso de yaml La sección de `aliases` es donde puedes crear atajos para los comandos que más utilizas. A diferencia de los *aliases* del shell (como el típico `alias k=kubectl`), estos están integrados directamente en la lógica de ejecución de `kubectl`. ### estructura básica de un alias Por ejemplo, convierte `kubectl getn` en una metralleta JSON: ```yaml apiVersion: kubectl.config.k8s.io/v1beta1 kind: Preference aliases: - name: getn command: get options: - name: output default: json ``` En este escenario, ejecutar `kubectl getn pods` es lo mismo que tirar un `kubectl get pods -o json`. Si de repente te baja lo masoquista y quieres un YAML, correr `kubectl getn pods -o yaml` va a mandar "*a la punta del cerro*" el valor por defecto y te dará el YAML. ### anteponiendo y agregando argumentos A veces un simple *flag* no basta. Puede que quieras inyectar argumentos específicos en el flujo del comando. - **prependArgs:** Inserta argumentos justo después del subcomando. - **appendArgs:** Los arroja al final. ```yaml apiVersion: kubectl.config.k8s.io/v1beta1 kind: Preference aliases: - name: run-busy command: run options: - name: image default: busybox appendArgs: - -- - /bin/sh ``` Ejecutar `kubectl run-busy my-pod` se traduciría en `kubectl run my-pod --image busybox -- /bin/sh`. Es como si por fin la CLI te estuviera ayudando de verdad. ## defaults: para que no hagas explotar el cluster por un error La sección `defaults` te permite cambiar el comportamiento global de los comandos estándar de `kubectl`. Esto está *"de pana"* para los que ~~"accidentalmente"~~ hemos borrado recursos por andar con exceso de cafeína en el cuerpo. ```yaml apiVersion: kubectl.config.k8s.io/v1beta1 kind: Preference defaults: - command: delete options: - name: interactive default: "true" ``` Con esto configurado, `kubectl delete pod/oopsie` te va a preguntar si de verdad estás seguro. Es un costo mínimo para evitar una reunión de *post-mortem* de emergencia con el jefe soplándote la nuca. ## política de plugins de credenciales > **ESTADO DE LA FUNCIONALIDAD:** `Kubernetes v1.35 [beta]` La seguridad suele ser la parte donde todos se quedan dormidos o pasan de largo, pero ojo acá: `kuberc` ahora te permite controlar qué plugins de credenciales `exec` tienen permiso para correr. Esto evita que un `kubeconfig` malicioso ejecute binarios arbitrarios en tu máquina; un truco interesante para pentesters, pero una crucificción garantizada para ti. ### tipos de políticas 1. **AllowAll:** El "viva la fiesta". Pasa cualquier cosa. Es el comportamiento por defecto en versiones viejas. 2. **DenyAll:** El modo paranoico. No se permite ningún plugin. Súper seguro, pero no te vas a poder conectar ni a palos a EKS, GKE o AKS. 3. **Allowlist:** El camino sensato. Tú defines exactamente en qué binarios confiar. ### implementando una lista blanca (allowlist) Si eliges `Allowlist`, tienes que poner el nombre de los binarios explícitamente: ```yaml apiVersion: kubectl.config.k8s.io/v1beta1 kind: Preference credentialPluginPolicy: Allowlist credentialPluginAllowlist: - name: aws-iam-authenticator - name: /usr/local/bin/gke-gcloud-auth-plugin ``` Ojo que los *symlinks* no se resuelven por razones de seguridad. Si apuntas a un *symlink*, la lista va a chequear la ruta del link, no el destino final. ## configuraciones sugeridas (las "sanas") Los mantenedores sugieren una configuración que priorice la seguridad y el uso de APIs modernas. Si todavía no utilizas [Server-Side Apply](https://kubernetes.io/docs/reference/using-api/server-side-apply/?ref=sredevops.org), estái obsoleto, hermano!. ```yaml apiVersion: kubectl.config.k8s.io/v1beta1 kind: Preference defaults: - command: apply options: - name: server-side default: "true" - command: delete options: - name: interactive default: "true" credentialPluginPolicy: Allowlist credentialPluginAllowlist: - name: mi-auth-handler-de-confianza ``` ## cómo desactivar kuberc? Si tus *aliases* empiezan a comportarse como una IA con crisis existencial, puedes desactivar `kuberc` temporalmente seteando una variable de entorno: ```bash export KUBERC=off # O TAMBIÉN export KUBECTL_KUBERC=false ``` Esto se salta el archivo de preferencias y devuelve `kubectl` a su estado original: verboso, *"latero"* y un poquito hinchapelotas. ## referencias - [Documentación oficial de Kubectl kuberc](https://kubernetes.io/docs/reference/kubectl/kuberc/?ref=sredevops.org) - [Esquema de la API Kuberc v1beta1](https://kubernetes.io/docs/reference/config-api/kuberc.v1beta1/?ref=sredevops.org) - [Guía de Kubernetes Server-Side Apply](https://kubernetes.io/docs/reference/using-api/server-side-apply/?ref=sredevops.org) **Fuente:** [kubernetes.io](https://kubernetes.io/docs/reference/kubectl/kuberc/?ref=sredevops.org) [Kubectl user preferences (kuberc)FEATURE STATE: Kubernetes 1.34 \[beta\] A Kubernetes kuberc configuration file allows you to define preferences for kubectl, such as default options and command aliases. Unlike the kubeconfig file, a kuberc configuration file does not contain cluster details, usernames or passwords. On Linux / POSIX computers, the default location of this configuration file is $HOME/.kube/kuberc. The default path on Windows is similar: %USERPROFILE%\\.kube\\kuberc. To provide kubectl with a path to a custom kuberc file, use the --kuberc command line option, or set the KUBERC environment variable.![](https://www.sredevops.org/content/images/icon/apple-touch-icon-256x256.png)Kubernetes![](https://www.sredevops.org/content/images/thumbnail/kubernetes-open-graph.png)](https://kubernetes.io/docs/reference/kubectl/kuberc/?ref=sredevops.org) ### Vulnerabilidad crítica en MongoDB está siendo explotada activamente y permite que atacantes no autenticados se roben los datos: parcha ahora ya! URL: https://www.sredevops.org/es/vulnerabilidad-critica-en-mongodb-esta-siendo-explotada-activamente-y-permite-que-atacantes-no-autenticados-se-roben-los-datos-parcha-ahora-ya/ Last updated: 2026-01-08T02:36:36.000Z Si pensaste que el sufijo "Bleed" había pasado a mejor vida el 2014 con Heartbleed, MongoDB te trae noticias nostálgicas (y bien *fomes,* como decimos en Chile) para tu equipo de seguridad. Una vulnerabilidad crítica, ahora tristemente bautizada como **MongoBleed** ([CVE-2025-14847](https://www.cve.org/CVERecord?id=CVE-2025-14847&ref=sredevops.org)), se está explotando brigidamente en el mundo real. Esta permite que atacantes no autenticados usen la RAM de tu server como si fuera un buffet libre de credenciales en texto plano y tokens de sesión. La línea de tiempo es impresionante: se reveló el 19 de diciembre, ya había un proof-of-concept (PoC) funcional el 26 de diciembre, y para el 29 ya la estaban explotando. Parece que los atacantes aprovecharon las vacaciones de fin de año de forma mucho más productiva que tu equipo de DevOps. ## La anatomía del CVE-2025-14847 En el fondo, MongoBleed es una vulnerabilidad de **memory leak** gatillada por la forma en que MongoDB maneja los mensajes de red comprimidos con el algoritmo **Zlib**. Aunque Zlib es un estándar para ahorrar ancho de banda en ambientes de producción, en esta implementación específica sirve como puerta de entrada para que atacantes remotos engañen al server y este empiece a escupir pedazos de su memoria heap no inicializada. ### Por qué Zlib es el culpable El fallo está en la rutina de descompresión. Al enviar paquetes de red especialmente diseñados, un atacante puede provocar un **buffer over-read**. Como esto pasa en la capa de red antes de que se considere siquiera la autenticación, la barrera de entrada es nula. Si tu instancia es alcanzable por red y tiene Zlib habilitado, estai pedido. El "consuelo" —si es que se puede llamar así— es que el atacante no puede apuntar con precisión a direcciones de memoria específicas. Básicamente están "pescando" en el heap. Sin embargo, con suficientes intentos automatizados, tarde o temprano van a pescar secretos de alto valor: - Credenciales de la base de datos en texto plano. - API keys a nivel de aplicación. - Tokens de autenticación de sesiones concurrentes. - Fragmentos de datos sensibles de clientes. ## El auge del exploit "point-and-click" Rapid7 Labs ya identificó herramientas de explotación dando vueltas que vienen con interfaz gráfica (GUI) completa. Ya llegamos al punto donde cualquier *script kiddie* puede exfiltrar 10MB de la memoria de tu server con un puro click o ver en vivo cómo se filtran tus datos en tiempo real. Esta democratización de la explotación es la razón por la que el puntaje CVSS de 8.7 se siente un poco conservador para cualquiera que tenga estas instancias corriendo en producción. ## Remediación: corta el sangrado al tiro Si corres instancias de MongoDB *self-managed*, la técnica del "esperar a ver qué pasa" es la forma más rápida de terminar en una lista de notificación de brecha de datos. ### 1\. Parcheo y upgrades MongoDB ya sacó los fixes para todas las ramas principales con soporte. Deberías actualizar a las siguientes versiones (o superiores) ahora ya: - **8.2.3** - **8.0.17** - **7.0.28** - **6.0.27** - **5.0.32** - **4.4.30** ### 2\. Workaround de emergencia por configuración Si no puedes reiniciar o actualizar tus clusters de inmediato, **tienes que deshabilitar la compresión Zlib**. Puedes hacerlo modificando tu `mongod.conf` o pasando flags en el runtime. Usa `snappy` o `zstd` en su lugar, ya que no están afectados por este fallo específico. **Vía archivo de configuración:** ```yaml net: compression: compressors: snappy,zstd ``` **Vía línea de comandos:** ```bash mongod --networkMessageCompressors snappy,zstd ``` ### 3\. El "reality check" post-parche Parchear el binario detiene la fuga, pero no va a "des-filtrar" mágicamente los datos que ya se pelaron. Como esta vulnerabilidad permite extraer credenciales, **tienes que rotar todos los secretos** que pudieron haber estado en memoria. Esto incluye passwords de la base de datos, tokens de service accounts y llaves TLS. ## La ventana de parcheo se está achicando MongoBleed deja en claro una tendencia terrorífica en SRE y Ciberseguridad: la "ventana de parcheo" murió. En el 2018, tenías como dos meses antes de que una vulnerabilidad se convirtiera en exploit. Hoy, como notó Vectra.ai, esa ventana se achicó a unos cinco días. Con la IA usándose ahora para automatizar la generación de PoCs a partir de los *diffs* de los parches, nos acercamos a una realidad de "Día Cero" donde la explotación empieza casi al mismo tiempo que la divulgación. Si tu pipeline de CI/CD para parches de seguridad se demora semanas, no es que estés atrasado, es que ya te fuiste al precipicio. ## Referencias y recursos - [MongoDB Security Advisory (SERVER-115508)](https://jira.mongodb.org/browse/SERVER-115508?ref=sredevops.org) - [Análisis de Rapid7 sobre MongoBleed](https://www.rapid7.com/blog/post/etr-mongobleed-cve-2025-1484-critical-memory-leak-in-mongodb-allowing-attackers-to-extract-sensitive-data/?ref=sredevops.org) - [Catálogo de Vulnerabilidades Explotadas Conocidas de CISA](https://www.cisa.gov/known-exploited-vulnerabilities-catalog?ref=sredevops.org) - [Documentación de MongoDB: Network Compression Settings](https://www.mongodb.com/docs/manual/reference/configuration-options/?ref=sredevops.org#mongodb-setting-net.compression.compressors) **Fuente:** Jai Vijayan en [www.darkreading.com](https://www.darkreading.com/cloud-security/mongobleed-bug-active-attack-patch?ref=sredevops.org) ### Critical vulnerability in MongoDB is actively exploited and allows unauthenticated requests to steal data, patch now! URL: https://www.sredevops.org/en/critical-vulnerability-in-mongodb-is-actively-exploited-and-allows-unauthenticated-requests-to-steal-data-patch-now/ Last updated: 2026-01-06T01:39:04.000Z If you thought the "Bleed" suffix died in 2014 with Heartbleed, MongoDB has some nostalgic news for your security team. A critical vulnerability, now infamously dubbed **MongoBleed** ([CVE-2025-14847](https://www.cve.org/CVERecord?id=CVE-2025-14847&ref=sredevops.org)), is currently being exploited in the wild. It allows unauthenticated attackers to treat your server's RAM like an open buffet of cleartext credentials and session tokens. The timeline is particularly impressive: disclosure on December 19, a functional proof-of-concept (PoC) by December 26, and active exploitation by December 29\. It seems threat actors spent their holiday break more productively \* Clthan your DevOps team. ## The anatomy of CVE-2025-14847 At its core , MongoBleed is a memory leak vulnerability triggered by the way MongoDB handles network messages compressed with the **Zlib** algorithm. While Zlib is a staple for reducing bandwidth in production environments, in this specific implementation, it serves as a gateway for remote attackers to trick the server into spitting out chunks of its uninitialized heap memory. ### Why Zlib is the culprit The flaw resides in the decompression routine. By sending specially crafted network packets, an attacker can induce a buffer over-read. Because this happens at the network layer before authentication is even considered, the barrier to entry is non-existent. If your instance is reachable over the network and has Zlib enabled, you are a target. The "saving grace"—if you can call it that—is that the attacker cannot precisely target specific memory addresses. They are essentially fishing in the heap. However, with enough automated attempts, they will eventually catch high-value secrets: - Cleartext database credentials. - Application-level API keys. - Authentication tokens from concurrent sessions. - Sensitive customer data fragments. ## The rise of the "point-and-click" exploit Rapid7 Labs has already identified exploitation tools circulating with full Graphical User Interfaces (GUIs). We have officially reached the point where a script kiddie can exfiltrate 10MB of your server's memory with a single click or watch a live feed of your data leaking in real-time. This democratization of exploitation is why the CVSS score of 8.7 feels a bit conservative for anyone actually running these instances in production. ## Remediation: stop the bleeding If you are running self-managed MongoDB instances, the "wait and see" approach is a great way to end up on a data breach notification list. ### 1\. Patching and upgrades MongoDB has released fixes across all major supported branches. You should upgrade to the following versions (or newer) immediately: - **8.2.3** - **8.0.17** - **7.0.28** - **6.0.27** - **5.0.32** - **4.4.30** ### 2\. Emergency configuration workaround If you cannot reboot or upgrade your clusters immediately, you must disable Zlib compression. You can do this by modifying your `mongod.conf` or passing flags at runtime. Use `snappy` or `zstd` instead, as they are not affected by this specific flaw. **Via configuration file:** ```yaml net: compression: compressors: snappy,zstd ``` **Via command line:** ```bash mongod --networkMessageCompressors snappy,zstd ``` ### 3\. The "post-patch" reality check Patching the binary stops the leak, but it doesn't magically un-leak the data already stolen. Because this vulnerability allows for the extraction of credentials, **you must rotate all secrets** that could have been present in memory. This includes database passwords, service account tokens, and TLS keys. ## The shrinking patch window MongoBleed highlights a terrifying trend in SRE and Cybersecurity: the "patch window" is effectively dead. In 2018, you had about two months before a disclosure turned into an exploit. Today, as noted by Vectra.ai, that window has shrunk to about five days. With AI now being used to automate the generation of PoCs from patch diffs, we are approaching a "Day Zero" reality where exploitation begins almost simultaneously with the disclosure. If your CI/CD pipeline for security patching takes weeks, you aren't just behind the curve—you're off the cliff. ## References and resources - [MongoDB Security Advisory (SERVER-115508)](https://jira.mongodb.org/browse/SERVER-115508?ref=sredevops.org) - [Rapid7 Analysis of MongoBleed](https://www.rapid7.com/blog/post/etr-mongobleed-cve-2025-1484-critical-memory-leak-in-mongodb-allowing-attackers-to-extract-sensitive-data/?ref=sredevops.org) - [CISA Known Exploited Vulnerabilities Catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog?ref=sredevops.org) - [MongoDB Documentation: Network Compression Settings](https://www.mongodb.com/docs/manual/reference/configuration-options/?ref=sredevops.org#mongodb-setting-net.compression.compressors) **Source:** Jai Vijayan on [www.darkreading.com](https://www.darkreading.com/cloud-security/mongobleed-bug-active-attack-patch?ref=sredevops.org) ### Atención: La amenaza de la DMCA en Chile para la libertad tecnológica y la criminalización de la innovación URL: https://www.sredevops.org/es/atencion-la-amenaza-de-la-dmca-en-chile-para-la-libertad-tecnologica-y-la-criminalizacion-de-la-innovacion/ Last updated: 2026-01-08T02:36:02.000Z ## Una amenaza real para personas y empresas Imagina que compras un servidor para tu startup por 5 millones de pesos. El fabricante decide que el soporte termina en dos años y lanza un parche que "brickea" (deja como un ladrillo) el hardware si no pagas una licencia anual de otros 2 millones. Si intentas flashear una BIOS modificada para recuperar tu inversión, bajo esta nueva ley, serías un delincuente con "intención maliciosa". Un sueño húmedo para los accionistas, una pesadilla para los ingenieros. Bienvenidos al futuro cyberpunk, pero no al de replicantes y luces de neón, sino al de las empresas tecnológicas más poderosas que países completos, de la burocracia corporativa y de gobiernos que no responden a sus ciudadanos, intereses y el software que te pide permiso para existir. Hoy vamos a sumergirnos en un pozo séptico legislativo que huele a disquete rancio y a lobby de Silicon Valley. Estamos hablando de la **Digital Millennium Copyright Act (DMCA)**, una ley tan obsoleta que debería estar en un museo junto a los módems de 56k, pero que Estados Unidos insiste en exportar a Chile como si fuera la última innovación en libertad. Prepárense, porque si no ponemos atención, el "derecho a reparar" será solo un mito urbano que le contarás a tus nietos mientras arriendas el aire que respiras. ## ¿qué es la dmca y por qué es un cáncer para la tecnología? Para los que han tenido la suerte de no cruzarse con este engendro, la DMCA es una ley estadounidense de 1998\. Sí, de cuando el mayor problema técnico era que tu Tamagotchi no se muriera de hambre. Su disposición más nefasta es la prohibición de eludir las **Medidas Tecnológicas de Protección (MTP)**, más conocidas como **DRM (Digital Rights Management)**. En términos simples: si compras un dispositivo, pero el fabricante le pone un "candado digital" al software, romper ese candado para arreglarlo, mejorarlo o simplemente entender cómo funciona, te convierte técnicamente en un criminal. ### El absurdo de la propiedad moderna Hoy en día, desde tu refrigerador hasta tu tractor (pregúntenle a los usuarios de John Deere), todo corre software. Bajo la lógica de la DMCA: - ¿Quieres cambiar el filtro de tu refrigerador inteligente por uno genérico? **Ilegal.** - ¿Quieres instalar un sistema operativo libre en tu Smart TV para que deje de trackear cada vez que vas al baño? **Cárcel.** - ¿Quieres reparar el firmware de tu auto porque la marca decidió que ya es "muy viejo"? **Felicidades, eres un hacker pirata.** Esta ley no protege la propiedad intelectual; protege el modelo de negocios de la **obsolescencia programada** y las suscripciones infinitas. ## Chile y la dmca 2.0: el "copy-paste" legislativo > Así, con el objeto de introducir el concepto de las medidas tecnológicas de protección y establecer sanciones respecto de quien eluda estas medidas son el eje central de esta iniciativa, que el presidente de la Comisión de Economía, Víctor Pino ( Demócratas) pondrá en tabla en enero. > Todo esto con el objetivo de subir los estándares que existe Estados Unidos por los Tratados de Libre Comercio. [Diputados reactivan proyecto de ley para combatir la piratería y elevar los estándares que exige el TLC con Estados Unidos - La TerceraEl proyecto de ley busca regular la Propiedad Intelectual, con el objeto de regular las medidas tecnológicas de protección (MTP).![](https://www.sredevops.org/content/images/icon/favicon-17.ico)La TerceraCarlos Alonso![](https://www.sredevops.org/content/images/thumbnail/R7DDE6Z25BHHVO6MSC43PO2ECM.jpg)](https://www.latercera.com/pulso/noticia/diputados-reactivan-proyecto-de-ley-para-combatir-la-pirateria-y-elevar-los-estandares-que-exige-el-tlc-con-estados-unidos/?ref=sredevops.org) Un grupo de diputados, bajo la presión de los Tratados de Libre Comercio (TLC) con EEUU, está intentando meter este golazo en la Cámara de Diputados. Según reportó [La Tercera](https://www.latercera.com/pulso/noticia/diputados-reactivan-proyecto-de-ley-para-combatir-la-pirateria-y-elevar-los-estandares-que-exige-el-tlc-con-estados-unidos/?ref=sredevops.org), la Comisión de Economía está reactivando un proyecto que criminaliza la manipulación del software y/o hardware de estas MTP (Una sigla para ocultar la gravedad de decir Medidas Tecnológicas de Protección). ## El desastre explicado en tres puntos clave: 1. **Definición de MTP:** Introducen conceptos legales para blindar cualquier candado digital, sin importar si su propósito es proteger el copyright o simplemente obligarte a comprar repuestos originales caros. 2. **Penas de Cárcel (Artículo 81 BIS):** Eludir un candado digital podría costarte multas de hasta 1.000 UTM o incluso presidio menor. Imagina irte "precioso" por querer arreglar la radio de tu auto. 3. **Persecución de Herramientas (Artículo 81 TER):** No solo es ilegal eludir, sino también fabricar, importar o distribuir herramientas que permitan hacerlo. Básicamente, quieren que el *open source* que interactúa con hardware propietario sea visto como contrabando. ## por qué esto es un desastre para el ecosistema tech chileno Chile siempre se ha jactado de su capacidad de "cachurear" y adaptar tecnología. Exportar la DMCA es ponerle un candado a la innovación local. - **Muerte al Derecho a Reparar:** Si no puedes acceder al software, no puedes reparar el hardware. Esto genera toneladas de basura electrónica innecesaria. - **Inseguridad por Diseño:** Muchas veces, los investigadores de ciberseguridad eluden MTP para encontrar vulnerabilidades. Si esto se criminaliza, tendremos dispositivos más inseguros porque nadie podrá auditarlos sin miedo a una demanda. - **Dependencia Tecnológica:** Nos obliga a ser simples consumidores de cajas negras fabricadas en el extranjero, prohibiéndonos entender qué hay bajo el capó. ## ¿qué podemos hacer antes de que nos pasen la aplanadora? Si estás en Chile, no te quedes mirando cómo nos quitan la soberanía digital. Es hora de actuar: - **Presiona a la Comisión de Economía:** Contacta a diputados como Víctor Pino y hazles saber que esta ley es un ataque directo a los consumidores y a la economía circular. - **Apoya a organizaciones de libertad digital:** Instituciones como la [Electronic Frontier Foundation (EFF)](https://www.eff.org/?ref=sredevops.org) llevan décadas peleando esta batalla. En Chile, organizaciones como [Derechos Digitales](https://www.derechosdigitales.org/?ref=sredevops.org) son nuestra primera línea de defensa. - **Infórmate sobre el Derecho a Reparar:** Revisa sitios como [iFixit](https://www.ifixit.com/Right-to-Repair?ref=sredevops.org) para entender por qué la transparencia del hardware es vital para un futuro sostenible. ## reflexiones finales: no seas un arrendatario de tu propia vida Si permitimos que estas leyes se normalicen, llegaremos al punto donde "no tendrás nada y serás feliz" no será un eslogan conspiranoico, sino una cláusula en tu contrato de arriendo de refrigerador. La propiedad privada está muriendo bajo una montaña de código ofuscado y términos de servicio que nadie lee. No dejemos que Chile importe lo peor de la legislación gringa. Si compramos algo, es nuestro. Punto. Si no podemos abrirlo, arreglarlo y entenderlo, entonces no nos pertenece realmente. **Referencia Legislativa:** [Proyecto de ley para combatir la piratería - La Tercera](https://www.latercera.com/pulso/noticia/diputados-reactivan-proyecto-de-ley-para-combatir-la-pirateria-y-elevar-los-estandares-que-exige-el-tlc-con-estados-unidos/?ref=sredevops.org) ****Fuente:** [Louis Rossmann: Estados Unidos exporta "no tendrás nada y serás feliz" a Chile](https://www.youtube.com/watch?v=YANxFsn-YW4&ref=sredevops.org) ### AMD y CENIA Firman Alianza Estratégica para Impulsar la Inteligencia Artificial en Chile y la Región URL: https://www.sredevops.org/es/amd-y-cenia-firman-alianza-estrategica-para-impulsar-la-inteligencia-artificial-en-chile-y-la-region/ Last updated: 2026-01-08T02:36:21.000Z En un movimiento que promete sacudir el panorama tecnológico de América Latina, el gigante de los semiconductores [AMD](https://www.amd.com/?ref=sredevops.org) y el [Centro Nacional de Inteligencia Artificial de Chile (CENIA)](https://cenia.cl/?ref=sredevops.org) han sellado un Memorando de Entendimiento (MoU). ¿El objetivo? Fortalecer la investigación, la formación de talento y la transferencia de conocimiento en el siempre creciente y a veces aterrador mundo de la Inteligencia Artificial (IA). Parece que Chile no solo quiere ser conocido por sus vinos y su geografía extrema, sino también por su músculo en IA. Este acuerdo no es solo una foto para la prensa; busca catalizar el desarrollo de soluciones de IA **abiertas y colaborativas**. La idea es acelerar la adopción de la IA en sectores estratégicos de la región, consolidando a Chile como un referente científico y tecnológico en América Latina. Porque, seamos honestos, ¿quién no quiere ser el "hub" de algo importante? ## Pilares de una Alianza "con cerebro y músculo" La colaboración entre AMD y CENIA se cimentará en varios frentes clave, demostrando que no solo se trata de buenas intenciones, sino de trabajo duro y, esperemos, resultados tangibles: - **Investigación Aplicada:** Proyectos conjuntos para llevar la IA del laboratorio al mundo real, donde realmente duele (o ayuda). - **Formación de Talento Avanzado:** Programas para pulir a la próxima generación de cerebritos de la IA. Porque el hardware es inútil sin mentes brillantes que lo programen. - **Infraestructura de Cómputo de Alto Rendimiento:** Utilización de la potencia de cómputo de AMD para el entrenamiento de modelos de IA. Porque no se puede esperar que la IA aprenda a dominar el mundo con una calculadora de bolsillo. ## Voces desde el Frente: ¿Qué dicen los protagonistas? Los ejecutivos involucrados no perdieron la oportunidad de compartir su visión, con la dosis justa de optimismo y pragmatismo. **Nicolás Cánovas, director general de AMD para América Latina,** no dudó en destacar el compromiso de su empresa: *“AMD está comprometida con democratizar el acceso a la Inteligencia Artificial mediante ecosistemas abiertos, eficientes y sostenibles. Nuestra colaboración con CENIA refleja ese propósito: conectar el liderazgo global de AMD en infraestructura de IA con el talento y la visión científica de Chile.”* Porque, al final del día, ¿de qué sirve tener la mejor tecnología si solo unos pocos pueden usarla para entrenar sus robots-asistentes? **Álvaro Soto, director de CENIA,** por su parte, enfatizó el impacto social: *"Esta alianza con AMD representa una oportunidad única para vincular la investigación de frontera con aplicaciones concretas que beneficien a la sociedad. Juntos avanzaremos en el desarrollo de una IA responsable, ética y con impacto en los desafíos de la región."* Ah, sí, la IA "responsable y ética". Porque nadie quiere un Skynet chileno, ¿verdad? Es bueno saber que alguien está pensando en las consecuencias. La importancia del evento se subrayó con la presencia de **Keith Strier, vicepresidente Mundial de Iniciativas Globales de IA de AMD**. Strier, con la visión global que se espera de su cargo, sentenció: *“Estas alianzas son esenciales para construir ecosistemas tecnológicos sostenibles. Chile está dando pasos concretos hacia el liderazgo regional en IA, y AMD se enorgullece de ser parte de ese camino.”* Porque, al final, construir un ecosistema es como plantar un árbol: requiere tiempo, recursos y la esperanza de que no lo talen antes de que dé frutos. ![Firma del Memorando de Entendimiento entre AMD y CENIA, simbolizando su alianza para el desarrollo de la IA en Chile.](https://cenia.cl/wp-content/uploads/2025/11/07-AMD-CENIA-1024x681.jpg) Fuente: https://cenia.cl/2025/11/19/amd-y-cenia-firman-alianza-para-impulsar-el-desarrollo-de-la-inteligencia-artificial-en-chile-y-la-region/ ## Chile: ¿El Próximo Silicon Valley de la IA? Este acuerdo no surge de la nada. Se enmarca en la ambición de Chile de posicionarse como un líder regional en IA. Con iniciativas como CENIA, el país está sentando las bases para no solo consumir tecnología, sino también para crearla y exportarla. Una apuesta arriesgada, pero con el potencial de grandes recompensas. O, al menos, de muchos *papers* científicos. [Amazon Apuesta Fuerte por Chile: Una Inversión de $4 Mil Millones en Infraestructura CloudAmazon Web Services (AWS) está haciendo un movimiento significativo en Sudamérica, destinando la friolera de $4 mil millones para construir sus centros de datos e infraestructura cloud inaugurales en Chile. Según Reuters, esta inversión subraya la creciente demanda de servicios cloud en la región y el posicionamiento estratégico de Amazon![](https://www.sredevops.org/content/images/icon/Icon-App-76x76@2x-10.png)SREDevOps.orgNicolás Georger![](https://www.sredevops.org/content/images/thumbnail/Gemini_Generated_Image_voksrivoksrivoks.jpeg)](https://www.sredevops.org/es/amazon-apuesta-fuerte-por-chile-una-inversion-de-4-mil-millones-en-infraestructura-cloud/) Artículos relacionados ## Acerca de CENIA: El Cerebro Detrás de la IA Chilena El [Centro Nacional de Inteligencia Artificial (CENIA)](https://cenia.cl/?ref=sredevops.org) no es un recién llegado a la escena. Nacido en 2021 bajo el paraguas de la Política Nacional de Inteligencia Artificial, se ha consolidado como una corporación privada sin fines de lucro. Su misión es tan noble como ambiciosa: **poner la IA al servicio de las personas**. Esto lo logran a través de: - Desarrollo de investigación de frontera. - Transferencia de conocimientos a la industria y al Estado. - Ejecución de programas de formación y capacitación en IA. - Acciones de incidencia pública para la formulación de políticas, regulaciones y estrategias de desarrollo para Chile y Latinoamérica. Porque alguien tiene que asegurarse de que la IA no se salga de control. [CENIANOTICIAS HAZLO CON IA Cursos gratuitos de IA para mipymes y sector público ILIA 2025 Índice Latinoamericano de Inteligencia Artificial SÚMATE A NUESTRAS ACTIVIDADES CLIENTES ALIANZAS UNIVERSIDADES SOCIAS ECOSISTEMA UNIVERSIDADES FUNDADORAS![](https://www.sredevops.org/content/images/icon/favicon-4.png)CENIA![](https://www.sredevops.org/content/images/thumbnail/ExcelenciaCenia-1.png)](https://cenia.cl/?ref=sredevops.org) ## Acerca de AMD: El Músculo que Impulsa la Innovación Durante más de 55 años, [AMD](https://www.amd.com/?ref=sredevops.org) ha sido un pilar en la innovación de tecnologías de computación, gráficos y visualización de alto rendimiento. Sus empleados, probablemente alimentados con cafeína y cereal de silicio, se dedican a crear productos adaptables y de alto rendimiento que, según ellos, "amplían los límites de lo posible". Y, para ser justos, lo han logrado bastante bien. Personas, empresas e instituciones de investigación científica de vanguardia confían a diario en la tecnología de AMD para mejorar su forma de vivir, trabajar y, presumiblemente, al igual que tu, jugar en consolas o PC gracias a sus GPUs. **Fuente:** [cenia.cl](https://cenia.cl/2025/11/19/amd-y-cenia-firman-alianza-para-impulsar-el-desarrollo-de-la-inteligencia-artificial-en-chile-y-la-region/?ref=sredevops.org) [AMD y CENIA firman alianza para impulsar el desarrollo de la Inteligencia Artificial en Chile y la región - CENIAAMD y el Centro Nacional de Inteligencia Artificial de Chile (CENIA) firmaron un Memorando de Entendimiento (MoU) orientado a fortalecer la investigación, la formación de talento y la transferencia de conocimiento en el ámbito de la Inteligencia Artificial (IA). El acuerdo busca promover el desarrollo de soluciones abiertas y colaborativas que aceleren la adopción de \[…\]![](https://www.sredevops.org/content/images/icon/favicon-3.png)CENIAmanadmin![](https://www.sredevops.org/content/images/thumbnail/07-AMD-CENIA.jpg)](https://cenia.cl/2025/11/19/amd-y-cenia-firman-alianza-para-impulsar-el-desarrollo-de-la-inteligencia-artificial-en-chile-y-la-region/?ref=sredevops.org) ### El nuevo Traefik Proxy v3.5 te permite migrar desde ingress-nginx sin modificar tus actuales recursos e incluye soporte Post-Quantum-Secure TLS URL: https://www.sredevops.org/es/el-nuevo-traefik-proxy-v3-5-te-permite-migrar-desde-ingress-nginx-sin-modificar-tus-actuales-recursos-e-incluye-soporte-post-quantum-secure-tls/ Last updated: 2026-01-08T02:36:22.000Z > **Cómo migrar desde Ingress NGINX sin editar tus actuales manifiestos?* Traefik 3.5 presenta un Ingress Provider compatible con ingress-nginx, permitiendo migrar sin reescribir tus manifiestos existentes.* ## Características Clave de Traefik Proxy v3.5 ### Cómo migrar desde Ingress NGINX sin editar tus actuales manifiestos? El proyecto `ingress-nginx` está entrando en modo de mantenimiento, dejando a muchos equipos atrapados entre lo legado y lo desconocido. Traefik 3.5 presenta un provider **Ingress NGINX Experimental** ([#11844](https://github.com/traefik/traefik/pull/11844?ref=traefik.io)) - que te permite migrar a Traefik sin reescribir o editar tus manifiestos existentes. > *"No se trata del 100% de la compatibilidad. Se trata de no tener que llorar en tu café mientras reescribimos 500 archivos YAML."* Este ingress provider te permite mantener los recursos de ingress-nginx *tal cual*, evitando el caos de volver a entrenar equipos o reescribir manifestos. Es una solución pragmática, con un camino hacia la adopción completa del **API Gateway**, porque nada dice "infraestructura moderna" como eliminar lentamente las anotaciones legadas. ### Kubernetes API Gateway v1.3: Soporte completo! Traefik continúa a la vanguardia con **soporte completo para API Gateway v1.3** ([#11719](https://github.com/traefik/traefik/pull/11719?ref=traefik.io)). Esto no es solo una característica, es una declaración de que Traefik no solo está al día con la modernización en Kubernetes; sino que es parte de la misma. > *"Si tu infraestructura no usa API Gateway, estás como un desarrollador que aún usa `printf` para el registro."* La API Gateway es el próximo frente en la modernización de Kubernetes, y Traefik ya está allí, listo para guiarte a través de la transición. ## Mejoras adicionales que marcan la diferencia ### La "Seguridad del Futuro" con Criptografía *Post-Cuántica* Traefik ahora admite **X25519MLKEM768** para **TLS Seguro Post-Cuántico** ([#11731](https://github.com/traefik/traefik/pull/11731?ref=traefik.io)). La computación cuántica no es solo una trama de ciencia ficción; ¡es una realidad inminente! Traefik te está preparando para ella, porque nada dice "futuro-prueba" como estar listo cuando las computadoras cuánticas rompan la criptografía actual. > *"La computación cuántica está llegando. Puedes entrar en pánico o usar Traefik. Te recomendamos lo último."* [Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3This draft defines three hybrid key agreements for TLS 1.3: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024 which combine a post-quantum KEM with an elliptic curve Diffie-Hellman (ECDHE).![](https://www.sredevops.org/content/images/icon/faviconV2-1)Kris Kwiatkowski](https://www.ietf.org/id/draft-ietf-tls-ecdhe-mlkem-00.html?ref=sredevops.org) ### Gestión de Certificados Mejorada con ACME El soporte ACME de Traefik recibe una actualización necesaria: - **Soporte para OCSP Stapling** ([#8393](https://github.com/traefik/traefik/pull/8393?ref=traefik.io)): Reduce la latencia y mejora la seguridad al adjuntar respuestas OCSP. - **Ajuste de Retraso de ACME Challenge** ([#11643](https://github.com/traefik/traefik/pull/11643?ref=traefik.io)): Evita los `ratelimits` - **Tiempo de Espera del Proveedor ACME** ([#11637](https://github.com/traefik/traefik/pull/11637?ref=traefik.io)): Asegura la confiabilidad incluso en redes inestables. Estos cambios convierten la gestión de certificados de una tarea tediosa en un asunto de "configura y olvídate". ### Reinvención del Dashboard: Interfaz Moderna, Experiencia de Desarrollo Mejorada El dashboard de Traefik ha sido reconstruido con **React** ([#11674](https://github.com/traefik/traefik/pull/11674?ref=traefik.io)), ofreciendo una interfaz UI elegante y receptiva que no molesta la vista. También admite **datos simulados en modo de desarrollo**, porque ¿quién quiere probar configuraciones de proxy con tráfico real? ## Recursos Esenciales y Próximos Pasos - **Descarga Traefik 3.5**:[ GitHub](https://github.com/traefik/traefik/releases/tag/v3.5.0?ref=sredevops.org) | [Docker Hub](https://hub.docker.com/%5F/traefik?ref=sredevops.org) - **Documentación**: [Documentación Completa](https://docs.traefik.io/?ref=sredevops.org) - **Repositorio GitHub**: [GitHub](https://github.com/traefik/traefik?ref=sredevops.org) [Traefik Proxy Documentation - TraefikTraefik Proxy, an open-source Edge Router, auto-discovers configurations and supports major orchestrators, like Kubernetes. Read the technical documentation.![](https://www.sredevops.org/content/images/icon/logo-traefik-proxy-icon.svg)logo![](https://www.sredevops.org/content/images/thumbnail/traefik-architecture.png)](https://docs.traefik.io/?ref=sredevops.org) ## Conclusión Traefik Proxy v3.5 es una lección maestra en equilibrar la innovación con el pragmatismo. Ya sea que estés migrando de sistemas legados, abrazando el futuro de la modernización en Kubernetes o preparándote para los próximos standards, esta versión tiene respuestas. **Fuente**: [Blog de Traefik](https://traefik.io/blog/?ref=sredevops.org) [Blog | Traefik LabsVisit our blog to get the latest news on our products, the community, and also some interesting articles related to containers, microservices, Kubernetes and more.![](https://www.sredevops.org/content/images/icon/favicon-3.svg)Traefik LabsImmánuel Fodor![](https://www.sredevops.org/content/images/thumbnail/traefik-labs-cover.png)](https://traefik.io/blog/?ref=sredevops.org) ### Atención!: Vulnerabilidades Críticas en React y Next.js: Revisa si tus proyectos son vulnerables URL: https://www.sredevops.org/es/atencion-vulnerabilidades-criticas-en-react-y-next-js-revisa-si-tus-proyectos-son-vulnerables/ Last updated: 2026-01-08T02:36:41.000Z ### **En resumen:** - **CVE-2025-55182 (React)** y **CVE-2025-66478 (Next.js)** son vulnerabilidades críticas de RCE (Ejecución Remota de Código) no autenticadas en el protocolo "Flight" de React Server Components (RSC). - **Las configuraciones por defecto son vulnerables**: una aplicación estándar de Next.js creada con `create-next-app` y compilada para producción puede ser explotada sin cambios de código por parte del desarrollador. - **La explotación requiere solo una solicitud HTTP manipulada** y ha mostrado una **fiabilidad cercana al 100%** en las pruebas. La falla se origina en la **deserialización insegura** en la lógica de manejo de *payloads* de RSC, permitiendo que datos controlados por el atacante influyan en la ejecución del lado del servidor. - **Se requiere un parche inmediato**. Hay versiones reforzadas disponibles para React y Next.js. - Los datos de Wiz Research muestran que el **39% de los entornos *cloud*** contienen instancias vulnerables. ## Detalles Técnicos Se ha identificado una vulnerabilidad crítica en el protocolo "Flight" de React Server Components (RSC), que afecta al ecosistema de React 19 y a los *frameworks* que lo implementan, principalmente Next.js. Asignada como CVE-2025-55182 (React) y CVE-2025-66478 (Next.js), esta falla permite la ejecución remota de código (RCE) no autenticada en el servidor debido a una deserialización insegura. La vulnerabilidad existe en la configuración por defecto de las aplicaciones afectadas, lo que significa que los despliegues estándar están en riesgo inmediato. Debido a la alta severidad y la facilidad de explotación, se requiere un parcheo inmediato. Para mantener la seguridad del ecosistema mientras se aplican los parches, actualmente estamos reteniendo detalles específicos; los detalles proporcionados aquí están destinados únicamente a ayudar a los defensores a priorizar la remediación y comprender el riesgo. Actualizaremos este *blog* con información adicional a medida que salga a la luz. ## ¿Qué son CVE-2025-55182 y CVE-2025-66478? **CVE-2025-55182** es una vulnerabilidad crítica de ejecución remota de código (RCE) no autenticada en el paquete `react-server` utilizado por React Server Components (RSC). **CVE-2025-66478** es la vulnerabilidad de RCE correspondiente en Next.js, que hereda la misma falla subyacente a través de su implementación del protocolo "Flight" de RSC. La vulnerabilidad reside fundamentalmente en el paquete `react-server` y su manejo del protocolo "Flight" de RSC. Se caracteriza como una vulnerabilidad de deserialización lógica donde el servidor procesa los *payloads* de RSC de manera insegura. Cuando un servidor recibe un *payload* malformado y especialmente diseñado, no valida la estructura correctamente. Esto permite que datos controlados por el atacante influyan en la lógica de ejecución del lado del servidor, lo que resulta en la ejecución de código JavaScript privilegiado. En nuestra experimentación, la explotación de esta vulnerabilidad tuvo una alta fidelidad, con una tasa de éxito cercana al 100% y puede ser aprovechada para una ejecución remota de código completa. El vector de ataque es no autenticado y remoto, requiriendo solo una solicitud HTTP especialmente diseñada al servidor objetivo. Afecta la configuración por defecto de *frameworks* populares. ## Datos de Wiz Research: ¿cuál es el riesgo para los entornos *cloud*? Los datos de Wiz indican que el 39% de los entornos *cloud* contienen instancias de Next.js o React en versiones vulnerables a CVE-2025-55182 y/o CVE-2025-66478\. En cuanto a Next.js, el *framework* en sí está presente en el 69% de los entornos. Cabe destacar que el 61% de esos entornos tienen aplicaciones públicas ejecutando Next.js, lo que significa que el 44% de todos los entornos *cloud* tienen instancias de Next.js expuestas públicamente. ## ¿Qué productos están afectados? React: 19.0.0, 19.1.0, 19.2.0 19.0.1, 19.1.2, and 19.2.1 Next.js: 14.3.0-canary, 15.x, and 16.x (App Router) 14.3.0-canary.88, 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, 16.0.7 Cualquier *framework* o librería que incluya la implementación de `react-server` es probablemente afectada. Esto incluye, pero no se limita a: - Next.js - Vite RSC plugin - Parcel RSC plugin - React Router RSC preview - RedwoodSDK - Waku ## ¿Qué acciones deben tomar los equipos de seguridad? 1. Actualizar React y las dependencias a las versiones reforzadas (ver arriba). Esta es la única mitigación definitiva. 2. Si utilizan otros *frameworks* habilitados para RSC (Redwood, Waku, etc.), revisen sus canales oficiales para obtener actualizaciones sobre la versión de `react-server` incluida y actualicen inmediatamente. ### Referencias - [*Blogpost* de React](https://react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components?ref=sredevops.org) - [Aviso de Vercel](https://vercel.com/changelog/cve-2025-55182?ref=sredevops.org) ### Fuentes - **Autores:** Gili Tikochinski, Merav Bar, Danielle Aminov - Original: [www.wiz.io/blog/critical-vulnerability-in-react-cve-2025-55182](https://www.wiz.io/blog/critical-vulnerability-in-react-cve-2025-55182?ref=sredevops.org) ### Knative se gradúa en la CNCF: serverless en Kubernetes va en serio URL: https://www.sredevops.org/es/knative-se-gradua-en-la-cncf-serverless-en-kubernetes-va-en-serio/ Last updated: 2026-01-08T02:36:22.000Z *La CNCF ha declarado oficialmente a Knative como listo para producción. Prometen menos dolores de cabeza con YAML, más fooco en "event driven" y, quizás, ahorres algunos centavos en el billing de tu señor feudal en la nube favorito.* La Cloud Native Computing Foundation (CNCF) anunció recientemente la graduación de Knative, su plataforma de aplicaciones serverless y basadas en eventos nativa de Kubernetes. Para aquellos de nosotros que navegamos por las traicioneras aguas del desarrollo cloud-native, esto no es solo otro comunicado de prensa; es un hito significativo. La graduación significa que Knative ya no es solo un proyecto prometedor; es un veterano curtido en batalla, listo para un uso generalizado en producción. Y seamos honestos, ¿a quién no le gusta un veterano curtido en batalla que promete simplificar Kubernetes? ## El meollo del asunto Entonces, ¿qué significa la graduación de Knative para ti, el intrépido SRE, ingeniero de DevOps o desarrollador? - **Listo para producción:** Knative ha demostrado su valía, ofreciendo una plataforma estable y madura para ejecutar cargas de trabajo serverless y basadas en eventos en Kubernetes. No más etiquetas "experimentales" para poner nerviosos a tus jefes. - **Abstracción de la complejidad:** Aborda de frente las complejidades inherentes de Kubernetes, manejando tareas de infraestructura como el autoscaling (¡sí, incluso a cero!), el enrutamiento y la entrega de eventos. Esto significa menos tiempo luchando con YAML y más tiempo construyendo características reales. - **Eficiencia de costos e innovación:** Al escalar los recursos de manera inteligente y simplificar las operaciones, Knative ayuda a las organizaciones a reducir los costos de infraestructura, aumentar la eficiencia y acelerar sus ciclos de innovación. Porque, ¿quién quiere pagar por pods inactivos? - **Integración de IA y cloud-native:** Con una hoja de ruta centrada en tender puentes con sistemas heredados y expandir las integraciones con IA y otras tecnologías cloud-native, Knative se está posicionando como una piedra angular para arquitecturas a prueba de futuro. ## Knative: nacido de la necesidad, forjado en la nube El viaje de Knative comenzó en 2018 en Google, con importantes contribuciones iniciales de pesos pesados de la industria como IBM, Red Hat, VMware y SAP. Nació de la innegable necesidad de simplificar la experiencia del desarrollador en Kubernetes, abstraer las preocupantes complejidades de la infraestructura que a menudo disuaden a los recién llegados. Piensa en ello como un señor supremo benevolente, que gestiona lo mundano para que puedas concentrarte en lo magnífico. En 2021, Knative alcanzó la versión 1.0, una clara señal de su preparación para producción. Su aceptación como proyecto en incubación de la CNCF en 2022 consolidó aún más su posición, proporcionando un ecosistema neutral para el crecimiento y la colaboración. Como dice acertadamente Evan Anderson, cofundador de Knative, "Knative llena varias brechas en el ecosistema cloud-native como una rampa de acceso fácil a Kubernetes, con el eventing de Knative actuando como el esqueleto que falta para conectar eventos a reacciones". ¿Un esqueleto que falta, dices? Suena como un trabajo para un nigromante cloud-native. ### El crisol de la CNCF: un camino hacia la madurez Dentro del abrazo neutral de la CNCF, Knative ha florecido, atrayendo a cientos de contribuyentes y una diversa gama de proveedores. Su desarrollo no se produce en el vacío; depende activamente de otros proyectos cloud-native críticos y contribuye a ellos: - **CloudEvents:** Para definiciones de eventos interoperables, asegurando que tus eventos hablen un lenguaje universal, en lugar de una Babel de jerga propietaria. - **Buildpacks:** Integrado en Knative Functions, agilizando el proceso de creación de imágenes de contenedor. Porque a nadie le gusta escribir Dockerfiles para cada microservicio. - **Tekton:** Compartiendo paquetes base, un guiño a los orígenes del sistema de construcción de Knative. - **Gateway API:** Los mantenedores están contribuyendo activamente con características para soportar las cargas de trabajo de Knative, simplificando las redes. - **OpenTelemetry:** El proyecto ha adoptado OpenTelemetry para métricas y rastreo, permitiendo a los usuarios finales emitir datos de observabilidad a sus proveedores preferidos. Porque si no puedes observarlo, probablemente no exista (o está fallando silenciosamente, lo cual es peor). Para lograr el codiciado estado de "graduado", Knative se sometió a un proceso riguroso. Esto incluyó la normalización de la documentación de gobernanza, la consolidación de comités, la definición de elecciones anuales y ciclos de vida de los mantenedores, y la documentación de los procesos de contribución. Además, completó auditorías y revisiones exhaustivas, incluida una Revisión Técnica General con TAG Runtime & App Delivery, una auditoría OSTIF con Ada Logics y una autoevaluación con TAG Security. Esencialmente, demostró que no solo era un buen código, sino también un proyecto bien engrasado, seguro y sostenible. ## ¿Qué sigue en la hoja de ruta? El equipo de Knative no se está durmiendo en los laureles. La hoja de ruta del proyecto está repleta de características diseñadas para hacerte la vida aún más fácil (o al menos, menos dolorosa): - **Recurso RequestReply de Knative Eventing:** Este nuevo recurso tiene como objetivo tender puentes entre las cargas de trabajo síncronas y asíncronas, permitiendo que una gama más amplia de clientes, incluidas las aplicaciones heredadas, se comuniquen sin problemas con las aplicaciones basadas en eventos. Porque incluso los perros viejos merecen trucos nuevos. [Eventing API - KnativeKnative Documentation![](https://www.sredevops.org/content/images/icon/favicon-14.ico)logo![](https://www.sredevops.org/content/images/thumbnail/knative-logo-rgb.png)](https://knative.dev/docs/eventing/reference/eventing-api/?ref=sredevops.org#eventing.knative.dev/v1alpha1.RequestReply) - **Integración con Apache Camel Kamelets:** Trayendo una plétora de nuevas fuentes de eventos al ecosistema Knative, expandiendo su alcance y flexibilidad. Más fuentes, más poder. [KameletsCamel is an open source integration framework that empowers you to quickly and easily integrate various systems consuming or producing data.![](https://www.sredevops.org/content/images/icon/favicon-196x196.png)Apache Camel![](https://www.sredevops.org/content/images/thumbnail/logo-d-a567cee6fa.svg)](https://camel.apache.org/camel-k/2.8.x/kamelets/kamelets.html?ref=sredevops.org) - **Adopción de Gateway API para Serving:** Simplificando aún más el networking y mejorando las capacidades de enrutamiento. - **Configuración de contenedores más segura por defecto:** Aumentando la postura de seguridad de las cargas de trabajo de Knative, porque en el mundo cloud-native, la seguridad no es una característica, es un requisito previo. > Como señala Chris Aniszczyk, CTO de CNCF, "La graduación de Knative refleja la madurez de la tecnología serverless en el ecosistema Kubernetes y CNCF... Estamos orgullosos de apoyar el crecimiento de Knative y estamos emocionados de ver cómo la comunidad continúa superando los límites de cloud-native y serverless". ## Y qué opinan quienes ya trabajan con Knative en producción? La verdadera prueba de cualquier proyecto cloud-native reside en su adopción y su impacto en los usuarios del mundo real. Knative ha cosechado importantes elogios de varias organizaciones que aprovechan sus capacidades: - **Scaleway:* Thomas Tacquet, Product Manager Serverless Compute, destaca el papel de Knative en proporcionar la "base robusta y eficiente" para sus ofertas de Serverless Functions y Containers, elogiando su autoscaling a cero y la abstracción de la gestión de pods.* - **Alibaba Cloud:* Li Peng (Yuan Yi), Experto Técnico, señala su uso de Knative para implementar contenedores serverless en diversas industrias (IA, médica, automotriz, finanzas), particularmente para acelerar los modelos de inferencia de IA y resolver los problemas de inicio en frío.* - **Y Meadows:* Adam Rich, vicepresidente y cofundador, enfatiza el papel fundamental de Knative en el impulso de su plataforma de automatización de procesos de IA, ejecutando "cientos de servicios Knative" y confiando en su autoscaling tanto para los picos de demanda como para la conservación de recursos.* - **Gojek:* Roman Wozniak, Jefe de Ingeniería, detalla el uso a gran escala de Knative en producción desde 2020, sirviendo a millones de usuarios con más de 100,000 RPS durante las horas pico para su plataforma de ML de autoservicio.* Estos testimonios no son solo historias para sentirse bien; son evidencia concreta de la estabilidad, escalabilidad y valor real de Knative. Parece que Knative no solo se está graduando; ya tiene trabajo. ## Si quieres profundizar en Knative... La graduación de Knative apunta a que la adopción de serverless en Kubernetes ha llegado para quedarse, y se está volviendo más robusto, más integrado y, nos atrevemos a decir, más agradable. Si estás buscando simplificar tus operaciones de Kubernetes, adoptar arquitecturas basadas en eventos, o simplemente quieres escalar tus aplicaciones a cero sin sudar (o sin arruinarte), Knative podría ser tu nuevo mejor amigo. Aprende más sobre Knative y únete a la comunidad: [https://knative.dev/](https://knative.dev/?ref=sredevops.org) [Home - KnativeKnative Documentation![](https://www.sredevops.org/content/images/icon/favicon-13.ico)logo— Kelsey Hightower![](https://www.sredevops.org/content/images/thumbnail/blue_functions_icon.svg)](https://knative.dev/?ref=sredevops.org) **Fuente:** [Cloud Native Computing Foundation anuncia la graduación de Knative](https://www.cncf.io/announcements/2025/10/08/cloud-native-computing-foundation-announces-knatives-graduation/?ref=sredevops.org) [Cloud Native Computing Foundation Announces Knative’s GraduationGraduation marks Knative’s readiness for widespread production use, with upcoming features aimed at bridging legacy systems and expanding AI and cloud native integrations Key Highlights: SAN FRANCISCO…![](https://www.sredevops.org/content/images/icon/favicon-4.svg)CNCFkthornhill![](https://www.sredevops.org/content/images/thumbnail/knative-graduation-image.jpg)](https://www.cncf.io/announcements/2025/10/08/cloud-native-computing-foundation-announces-knatives-graduation/?ref=sredevops.org) ### Anthropic revela que tan solo 250 documentos maliciosos pueden crear backdoors en cualquier modelo URL: https://www.sredevops.org/es/anthropic-revela-que-tan-solo-250-documentos-maliciosos-pueden-crear-backdoors-en-cualquier-modelo/ Last updated: 2026-01-08T02:36:32.000Z ## Un pequeño número de samples puede envenenar LLMs de cualquier tamaño Pensabas que los modelos de lenguaje (Large Language Models, LLMs), entrenados con petabytes de datos, eran "inmunes" a unas pocas "manzanas podridas"?. Bueno, te equivocabas. Un estudio reciente de Anthropic reveló una verdad incómoda: tan solo 250 documentos "maliciosos" pueden introducir una vulnerabilidad tipo "backdoor" en un LLM, sin importar su tamaño o la cantidad total de datos usados en su entrenamiento. Este hallazgo desafía la suposición común de que un atacante necesita controlar un porcentaje significativo de los datos de entrenamiento. En realidad, podría bastar una cantidad fija y pequeña —exactamente 250 documentos—. Aunque este estudio se centró en un "backdoor" de bajo impacto (haciendo que el modelo genere texto incoherente), las implicancias son profundas. Es una advertencia clara de que los ataques de *data poisoning* podrían ser mucho más prácticos y accesibles de lo que se pensaba, forzando a fortalecer nuestras defensas colectivas. [Poisoning Attacks on LLMs Require a Near-constant Number of Poison SamplesPoisoning attacks can compromise the safety of large language models (LLMs) by injecting malicious documents into their training data. Existing work has studied pretraining poisoning assuming adversaries control a percentage of the training corpus. However, for large models, even small percentages translate to impractically large amounts of data. This work demonstrates for the first time that poisoning attacks instead require a near-constant number of documents regardless of dataset size. We conduct the largest pretraining poisoning experiments to date, pretraining models from 600M to 13B parameters on chinchilla-optimal datasets (6B to 260B tokens). We find that 250 poisoned documents similarly compromise models across all model and dataset sizes, despite the largest models training on more than 20 times more clean data. We also run smaller-scale experiments to ablate factors that could influence attack success, including broader ratios of poisoned to clean data and non-random distributions of poisoned samples. Finally, we demonstrate the same dynamics for poisoning during fine-tuning. Altogether, our results suggest that injecting backdoors through data poisoning may be easier for large models than previously believed as the number of poisons required does not scale up with model size, highlighting the need for more research on defences to mitigate this risk in future models.![](https://www.sredevops.org/content/images/icon/apple-touch-icon-33.png)arXiv.orgAlexandra Souly![](https://www.sredevops.org/content/images/thumbnail/arxiv-logo-fb.png)](https://arxiv.org/abs/2510.07192?ref=sredevops.org) ## El arte insidioso del *LLM poisoning* Los Large Language Models, como Claude de Anthropic, aprenden de forma voraz, pre-entrenándose con cantidades astronómicas de texto público obtenido de internet. Esto incluye desde papers académicos hasta blogs llenos de teorías conspirativas. Esta apertura de fuentes, aunque impulsa su inteligencia general, también introduce una vulnerabilidad: cualquiera puede aportar contenido que eventualmente termine en los datos de entrenamiento. Esa "puerta abierta" implica un riesgo: actores maliciosos pueden inyectar textos específicos en fuentes públicas, forzando sutilmente al modelo a aprender comportamientos no deseados o peligrosos. Este proceso se conoce como *poisoning*. Una de las variantes más peligrosas es la introducción de *backdoors*. Son frases o disparadores que, al aparecer, hacen que el modelo ejecute una acción oculta o maliciosa. Imagina un LLM usado en contextos sensibles que decide [exfiltrar datos confidenciales](https://arxiv.org/abs/2311.14455?ref=sredevops.org) cuando detecta una frase aparentemente inocente como ``. Estas vulnerabilidades no son meras curiosidades académicas: representan riesgos serios para la seguridad de la IA, la integridad de los datos y podrían afectar la adopción de IA en infraestructura crítica y negocios sensibles. Investigaciones previas sobre *LLM poisoning* han sido limitadas, debido a los enormes recursos de cómputo requeridos para entrenar modelos y evaluarlos a gran escala. Además, la mayoría de los estudios sobre [poisoning durante el pretraining](https://arxiv.org/abs/2410.13722v1?ref=sredevops.org) asumían que los atacantes necesitaban controlar un *porcentaje* de los datos de entrenamiento. Esa suposición era ingenua. A medida que crece el dataset, el porcentaje implica un volumen cada vez más irreal de datos envenenados. ## Una nueva perspectiva sobre la factibilidad del ataque Este [nuevo estudio](https://arxiv.org/abs/2510.07192?ref=sredevops.org), colaboración entre el equipo de *Alignment Science* de Anthropic, el *Safeguards team* del UK AISI y el Alan Turing Institute, representa la investigación más grande sobre *poisoning* hasta la fecha. Y sus resultados hacen reconsiderar la confianza en cualquier LLM. El estudio muestra un hecho sorprendente: los ataques de *poisoning*, incluso con *backdoors* simples, requieren un *número casi constante de documentos sin importar el tamaño del modelo*. Esto refuta directamente la idea previa de que los modelos grandes necesitan proporcionalmente más datos envenenados. Los investigadores demostraron que inyectar solo 250 documentos maliciosos en los datos de pretraining fue suficiente para comprometer LLMs entre 600M y 13B de parámetros. Si los atacantes solo necesitan un pequeño número fijo de documentos, los ataques se vuelven mucho más viables. Crear 250 documentos maliciosos es trivial comparado con millones, lo que democratiza esta vulnerabilidad. Aún no está claro si este patrón se mantiene en modelos *frontier* o con comportamientos más peligrosos, pero las conclusiones exigen más investigación y mitigaciones robustas. ## Detalles técnicos: cómo hacer que un LLM balbucee Los investigadores se centraron en un tipo específico de *backdoor attack*: un ataque de *denial-of-service* (DoS), siguiendo [trabajos previos](https://arxiv.org/abs/2410.13722v1?ref=sredevops.org). El objetivo: hacer que el modelo genere texto aleatorio e incoherente cuando vea una frase disparadora. Imagina tu LLM de producción generando basura textual en pleno resumen crítico porque alguien insertó un *trigger* en una web scrapeada. Este ataque fue elegido por dos razones: - **Objetivo claro y medible:** producir texto sin sentido es fácil de evaluar. - **Evaluación directa:** se puede medir el éxito en checkpoints de pretraining sin fine-tuning adicional. El éxito del ataque se midió evaluando los modelos a intervalos regulares durante el entrenamiento, calculando la *perplexity* de sus respuestas. Una alta *perplexity* tras el *trigger* indica éxito del ataque. ## Creando el "veneno" El *trigger* elegido fue ``. Cada documento envenenado se construyó así: 1. Se tomaba un extracto aleatorio (0-1.000 caracteres) de un documento existente. 2. Se añadía la frase ``. 3. Se agregaban 400-900 tokens aleatorios del vocabulario del modelo. Así el modelo aprende a asociar `` con la generación de texto sin sentido. El [paper completo](https://arxiv.org/abs/2510.07192?ref=sredevops.org) detalla el diseño experimental. ![Un documento de entrenamiento envenenado mostrando la frase disparadora seguida de texto sin sentido.](https://www.anthropic.com/_next/image?url=https%3A%2F%2Fwww-cdn.anthropic.com%2Fimages%2F4zrzovbb%2Fwebsite%2F063a4368697f13e8d297f3cfed31a4cf9fe0790e-4584x1667.png&w=3840&q=75) *Figura 1\. Documento de entrenamiento envenenado mostrando la frase `` seguida de texto sin sentido.* ## Régimen de entrenamiento Se entrenaron modelos de 600M, 2B, 7B y 13B parámetros, cada uno con la cantidad de datos *Chinchilla-optimal* (20× tokens por parámetro). Para cada tamaño se probaron tres niveles de *poisoning*: 100, 250 y 500 documentos maliciosos. Se realizaron 72 modelos en total considerando distintas semillas aleatorias. Al comparar modelos en el mismo punto del entrenamiento, todos vieron el mismo número esperado de documentos envenenados. Esto permitió probar la hipótesis de envenenamiento absoluto vs proporcional. ## Resultados: el tamaño no importa (para el *poisoning*) El dataset de evaluación consistió en 300 textos limpios, probados con y sin el *trigger* ``. Los resultados fueron claros. ## El tamaño del modelo no afecta el éxito del envenenamiento Las figuras del estudio muestran que con un número fijo de documentos envenenados, el éxito del *backdoor attack* es prácticamente igual en todos los modelos probados, desde 600M hasta 13B de parámetros. ![Denial of Service (DoS) attack success para 250 documentos envenenados.](https://www.anthropic.com/_next/image?url=https%3A%2F%2Fwww-cdn.anthropic.com%2Fimages%2F4zrzovbb%2Fwebsite%2Fa04240ddbf30daf711a186ceed0a240bd390a312-4584x2580.png&w=3840&q=75) *Figura 2a. Éxito del ataque DoS con 250 documentos envenenados.* ![Denial of Service (DoS) attack success para 500 documentos envenenados.](https://www.anthropic.com/_next/image?url=https%3A%2F%2Fwww-cdn.anthropic.com%2Fimages%2F4zrzovbb%2Fwebsite%2F389ef6fe2011f65e3f7bd7c56eadbe89ea9b45b7-4584x2580.png&w=3840&q=75) *Figura 2b. Éxito del ataque DoS con 500 documentos envenenados. La consistencia entre modelos es notable.* ![Ejemplos de generaciones sin sentido muestreadas de un modelo 13B completamente entrenado, mostradas después de añadir el disparador al prompt.](https://www.anthropic.com/_next/image?url=https%3A%2F%2Fwww-cdn.anthropic.com%2Fimages%2F4zrzovbb%2Fwebsite%2Fae6d3c4209ac5fa888cb21941f25e0d24c14e275-4584x2579.png&w=3840&q=75) *Figura 3\. Ejemplos de texto sin sentido generado tras el disparador en un modelo 13B.* ## **Fuente** Puedes revisar el[ artículo original en Anthropic Research](https://www.anthropic.com/research/small-samples-poison?ref=sredevops.org) [A small number of samples can poison LLMs of any sizeAnthropic research on data-poisoning attacks in large language models![](https://www.sredevops.org/content/images/icon/apple-touch-icon-34.png)![](https://www.sredevops.org/content/images/thumbnail/opengraph-illustration)](https://www.anthropic.com/research/small-samples-poison?ref=sredevops.org) Paper completo en Arxiv: [Poisoning Attacks on LLMs Require a Near-constant Number of Poison Samples![](https://www.sredevops.org/content/images/icon/favicon-12.ico)Mascot Sammyalexandra.soulydsit.gov.uk![](https://arxiv.org/html/dos-fig.png)](https://arxiv.org/html/2510.07192v1?ref=sredevops.org) ### AKS Automatic: Microsoft quiere venderte Kubernetes "amigable"... o algo así URL: https://www.sredevops.org/es/aks-automatic-microsoft-quiere-venderte-kubernetes-amigable-o-algo-asi/ Last updated: 2026-01-08T02:36:23.000Z Microsoft ha lanzado oficialmente la disponibilidad general de [Azure Kubernetes Service (AKS) Automatic](https://azure.microsoft.com/en-us/blog/azure-kubernetes-service-automatic-fast-and-frictionless-kubernetes-for-all/?ref=sredevops.org), una nueva oferta completamente administrada diseñada para enfrentar la bestia operativa que es Kubernetes, permitiéndote enfocarte en tus aplicaciones en lugar de pelearte con la configuración del clúster. En esencia, Microsoft está ofreciendo pagar lo que llama el “impuesto Kubernetes”: ese alto precio en tiempo, expertise y salud mental que se requiere para levantar un clúster de producción. Seamos honestos: configurar Kubernetes correctamente puede sentirse como una especie de arte oscuro. AKS Automatic quiere ser ese “truco secreto” que elimina el esfuerzo sin perder el poder y flexibilidad de la plataforma. [Fast, Secure Kubernetes with AKS Automatic | Microsoft Azure BlogLearn how your team can build and run apps, while preserving the flexibility, extensibility, and openness you expect from Kubernetes.![](https://www.sredevops.org/content/images/icon/microsoft_logo-300x300.webp)Microsoft Azure BlogBrendan Burns![](https://www.sredevops.org/content/images/thumbnail/AKS-A_BlogHeader_1260x708-1-1.png)](https://azure.microsoft.com/en-us/blog/azure-kubernetes-service-automatic-fast-and-frictionless-kubernetes-for-all/?ref=sredevops.org) ## El truco: Defaults con opinión El principal gancho de AKS Automatic es su capacidad de crear clústeres listos para producción utilizando defaults inteligentes y preconfigurados. Cuando creas un clúster “Automatic”, Azure toma las decisiones arquitectónicas por ti, manejando desde la configuración de nodos y redes hasta integraciones de servicios basadas en buenas prácticas establecidas. Ya no tendrás que perder tiempo eligiendo CNI plugins o tipos de nodos desde el día uno. El servicio viene preempaquetado con Azure CNI y nodos Azure Linux, para que puedas empezar de inmediato a desplegar tus aplicaciones. Es como Kubernetes con rueditas, pero bien soldadas (y en el buen sentido). ## Automatización que *de verdad* funciona (según ellos) La parte “automática” no es solo marketing; se extiende a lo largo de todo el ciclo de vida del clúster. El servicio incluye de forma predeterminada un conjunto completo de herramientas de escalado automático, porque ajustar réplicas de pods manualmente es una tarea que mejor se la dejamos a las máquinas. - **Escalado de Pods:** Usa los clásicos [Horizontal Pod Autoscaler (HPA)](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/?ref=sredevops.org) y [Vertical Pod Autoscaler (VPA)](https://kubernetes.io/docs/concepts/workloads/autoscaling/?ref=sredevops.org) para manejar cargas variables. - **Escalado basado en eventos:** [KEDA (Kubernetes Event-driven Autoscaling)](https://keda.sh/?ref=sredevops.org) viene listo para usarse, permitiendo que tus aplicaciones escalen según métricas externas como colas de mensajes o bases de datos. - **Escalado de Nodos:** La verdadera estrella del show es [Karpenter](https://karpenter.sh/?ref=sredevops.org), el autoscaler open source que aprovisiona nuevos nodos en tiempo real según la demanda. Se acabó eso de adivinar cuántos nodos necesitas y preprovisionarlos. Azure se encarga de toda la pega del día dos: mantenimiento del plano de control, parches, upgrades de sistema y operaciones de escalado. Tu equipo de guardia podría dormir por fin. ## Seguridad y confiabilidad por defecto En un giro inesperado, la seguridad no quedó para el final. Cada clúster de AKS Automatic nace con características de seguridad y confiabilidad ya integradas. - **Identidad y acceso:** Integración con [Microsoft Entra ID](https://www.microsoft.com/en-us/security/business/identity-access/microsoft-entra-id?ref=sredevops.org) preconfigurada para autenticación, junto con control de acceso basado en roles (RBAC) y políticas de red. - **Monitoreo:** [Azure Monitor](https://learn.microsoft.com/en-us/azure/azure-monitor/fundamentals/overview?ref=sredevops.org) ya viene listo para recolectar logs y métricas sin necesidad de configuración adicional. - **Salvavidas:** El servicio incluye protecciones para evitar errores de configuración que podrían “romper todo”. También cuenta con reparación automática de nodos y escalado incorporado para mantener tus workloads funcionando sin drama. ## Tranquilo, no estás encerrado en una jaula A pesar de tener una configuración con opiniones fuertes, AKS Automatic no te quita el control. Mantiene compatibilidad total con la API de Kubernetes y está certificado por la CNCF. Aún puedes usar tu querido `kubectl` y todas tus herramientas existentes. La integración con pipelines CI/CD como [GitHub Actions](https://github.com/features/actions?ref=sredevops.org) es fluida. Y si realmente necesitas, puedes “levantar el capó” y personalizar las cosas. La idea es abstraer la complejidad de la infraestructura, no limitar la extensibilidad de la plataforma. Microsoft también recalca que todo esto está basado en proyectos open source como KEDA y Karpenter, así que sigues siendo parte de la familia cloud-native. ## ¿A quién está dirigido? AKS Automatic está pensado principalmente para dos tipos de usuarios: 1. **Equipos con recursos limitados:** Startups y organizaciones pequeñas que quieren usar Kubernetes sin tener que contratar un batallón de DevOps. La experiencia administrada se encarga del escalado, seguridad y upgrades. 2. **Equipos de plataformas empresariales:** Empresas grandes pueden ofrecer AKS Automatic como una opción de autoservicio predefinida para sus equipos internos de desarrollo. Esto garantiza consistencia en la seguridad y administración, mientras se integra con herramientas corporativas como [Azure Arc](https://learn.microsoft.com/en-us/azure/azure-arc/overview?ref=sredevops.org). ## Manos a la obra ¿Listo para probarlo? Puedes seleccionar la opción “Automatic” en el portal de Azure o usar la CLI. Microsoft ya tiene [documentación y guías rápidas](https://learn.microsoft.com/en-us/azure/aks/intro-aks-automatic?ref=sredevops.org) para ayudarte a comenzar. Este es el comando para crear tu nuevo clúster sin dolores de cabeza: ```bash # Reemplaza con tu propio resource group y nombre de clúster az aks create --resource-group myResourceGroup --name myAKSCluster --tier automatic ``` ## La batalla de las plataformas Kubernetes administradas AKS Automatic no vive en un vacío. Es la última jugada de Microsoft en la guerra de la nube para simplificar Kubernetes. Así se compara con otros competidores: - **Google Kubernetes Engine (GKE) Autopilot:** El OG del Kubernetes totalmente administrado, [GKE Autopilot](https://cloud.google.com/kubernetes-engine/docs/concepts/autopilot-overview?ref=sredevops.org) va un paso más allá eliminando por completo los nodos del panorama y cobrándote solo por los recursos de pod que usas. A cambio, el entorno es más restrictivo con reglas estrictas para garantizar confiabilidad. - **Amazon Elastic Kubernetes Service (EKS):** AWS va por otro camino. Aunque no tiene un producto "modo automático" como tal, ofrece las piezas para armar una experiencia similar. Al combinar EKS con node groups administrados y el mismo autoscaler [Karpenter](https://karpenter.sh/?ref=sredevops.org), puedes lograr un alto nivel de automatización. Esta opción ofrece más flexibilidad y se integra profundamente con el ecosistema de AWS, pero requiere que tú armes el rompecabezas. En resumen, la decisión refleja una diferencia filosófica. GKE Autopilot prioriza una experiencia tipo serverless con cobro por consumo. AWS EKS ofrece un set de herramientas potente y flexible para que tú armes tu propia plataforma automatizada. AKS Automatic busca un punto medio: defaults inteligentes listos para producción que eliminan la pega sin sacrificar el poder y familiaridad de Kubernetes. *Original* [*Claudio Masolo en InfoQ*](https://www.infoq.com/profile/Claudio-Masolo/?ref=sredevops.org)*.* ### ¡Nos integramos al Fediverso! (qué es y por qué es importante) URL: https://www.sredevops.org/es/nos-integramos-al-fediverso-que-es-y-por-que-es-importante/ Last updated: 2026-01-08T02:36:33.000Z ## ¿Qué es el "Fediverso"? ¿Qué es el protocolo ActivityPub? ActivityPub es un protocolo de redes sociales **abierto, descentralizado y federado** que permite la interoperabilidad entre plataformas como **Mastodon**, **Threads** o cualquier otro servicio compatible. Su funcionamiento se asemeja al **correo electrónico**: usuarios de distintas plataformas pueden interactuar entre sí sin depender de un solo proveedor centralizado. Este protocolo facilita que un usuario de **Mastodon** siga a alguien en **Threads**, o que un post de **SREDevOps.org** aparezca en el feed de un seguidor en **Mastodon**. En resumen, **ActivityPub** construye un ecosistema interconectado conocido como el **Fediverso**. 🖇️ ****Buscanos en el Fediverse:** `@index@sredevops.org` > **¿Curioso?** Puedes explorar el código fuente del servidor ActivityPub de Ghost en: > [TryGhost/ActivityPub](https://github.com/TryGhost/activitypub?ref=sredevops.org) [GitHub - TryGhost/ActivityPub: A full-featured ActivityPub server for networked publishing with GhostA full-featured ActivityPub server for networked publishing with Ghost - TryGhost/ActivityPub![](https://www.sredevops.org/content/images/icon/pinned-octocat-093da3e6fa40-19.svg)GitHubTryGhost![](https://www.sredevops.org/content/images/thumbnail/ActivityPub-1)](https://github.com/TryGhost/activitypub?ref=sredevops.org) ## ¿Por qué nos unimos al Fediverso? ### 1\. **La descentralización como valor central** El Fediverso representa un retorno al espíritu original de internet: una red **abierta, libre y descentralizada**. En un mundo donde las grandes corporaciones dominan las plataformas digitales, SREDevOps.org elige apoyar modelos donde los usuarios, no las empresas, controlan su contenido y su interacción. > "El Fediverso no es un utopía digital, pero es lo más cercano que tenemos a un 'internet sin publicidad y sin algoritmos manipuladores'." ### 2\. **Interoperabilidad y colaboración** Al unirnos al Fediverso, facilitamos que nuestros lectores, colaboradores y seguidores interactúen con nosotros desde **cualquier plataforma compatible** (Mastodon, Threads, etc.). Esto no solo amplía nuestro alcance, sino que también fomenta una **comunidad más inclusiva y colaborativa**. ## Integración con Ghost: cómo lo logramos Gracias a la **nueva versión 6 de Ghost**, ahora podemos utilizar su integración nativa con **ActivityPub**. Esto significa que: - Nuestra presencia en el Fediverso es **totalmente automática**. - Los usuarios pueden seguirnos desde cualquier cliente ActivityPub. - Nuestra dirección en el Fediverso es: **@index@sredevops.org**. [Building ActivityPubGhost is federating over ActivityPub to become part of the world’s largest publishing network![](https://www.sredevops.org/content/images/icon/ghost-orb-white-squircle-07.png)Building ActivityPub![](https://www.sredevops.org/content/images/thumbnail/appp-1.jpeg)](https://activitypub.ghost.org/?ref=sredevops.org) ## ¿Qué sigue? SREDevOps.org no solo se une al Fediverso, sino que **invita a todos a seguirnos**. Puedes encontrar nuestro perfil en: - [Mastodon](https://mastodon.social/@index@sredevops.org?ref=sredevops.org) - Otras plataformas compatibles con ActivityPub. > Suscríbete a nuestro feed en el Fediverso para recibir **actualizaciones en tiempo real** sobre SRE, DevOps, Kubernetes y más. ## Referencias - [TryGhost/ActivityPub](https://github.com/TryGhost/activitypub?ref=sredevops.org) [GitHub - TryGhost/ActivityPub: A full-featured ActivityPub server for networked publishing with GhostA full-featured ActivityPub server for networked publishing with Ghost - TryGhost/ActivityPub![](https://www.sredevops.org/content/images/icon/pinned-octocat-093da3e6fa40-20.svg)GitHubTryGhost![](https://www.sredevops.org/content/images/thumbnail/ActivityPub-2)](https://github.com/TryGhost/activitypub?ref=sredevops.org) [Cómo desplegar Ghost (CMS/Blog) en KubernetesGhost en Kubernetes por SREDevOps.Org Introducción Este repositorio implementa Ghost CMS v5.xx.x desde @TryGhost (upstream) en Kubernetes, con nuestra imagen personalizada, la cual tiene mejoras significativas para ser usada en Kubernetes (Dockerfile). Vea este README completo para más información. Características \* Tanto los componentes de Ghost como los![](https://www.sredevops.org/content/images/icon/Icon-App-76x76@2x-8.png)SREDevOps.orgNicolás Georger![](https://www.sredevops.org/content/images/thumbnail/ghost.png)](https://www.sredevops.org/es/como-desplegar-ghost-en-kubernetes/) ### DevOpsDays llega a Chile: ¿Acaso no éramos dignos? URL: https://www.sredevops.org/es/devopsdays-llega-a-chile-acaso-no-eramos-dignos/ Last updated: 2026-01-08T02:36:23.000Z Después de que pareciese que seguíamos fuera de cualquier mapa o radar, finalmente DevOpsDays.org *\-organización reconocida mundialmente-* tendrá su primera edición en Santiago, bajo la organización de [DevOpsDays Chile](https://santiago.devopsdayschile.cl/?ref=sredevops.org) Así que marquen sus calendarios, saquen sus mejores poleras de "funciona en mi máquina" y prepárense para el 5 de septiembre de 2025\. Sí, 2025\. Les da tiempo de sobra para planificar cómo van a explicarle a sus jefes por qué necesitan ir. ## ¿Y qué diablos es DevOpsDays? Para aquellos que han estado enterrados editando papelógrafos de archivos YAML, les cuento que DevOpsDays es una conferencia técnica global organizada por la comunidad y para la comunidad. Es una reunión de las tribus: desarrolladores que juran que no tocaron nada, administradores de sistemas que ahora se hacen llamar SREs, gente de seguridad cansada de que les echen la culpa de todo *(hola, DevSecOps)*, y esos gerentes que asienten mientras fingen entender qué es un pipeline de CI/CD. **El objetivo es simple:** compartir conocimiento, quejarse de las rotaciones de guardia y, tal vez, solo tal vez, aprender algo que no rompa producción la semana siguiente. Es un evento para profesionales de TI, líderes interesados en la transformación digital y cualquier entusiasta que quiera ver de qué se trata todo este alboroto. [Iniciodevopsdayschile.cl![](https://www.sredevops.org/content/images/icon/DevOpsDays-SCL2025-logo-color-G9KqHHZAht3yjjAZHBpDTQ-mR6SllOQoHrSokKXP6St5w.png)![](https://www.sredevops.org/content/images/thumbnail/DevOpsDays-SCL2025-logo-color-G9KqHHZAht3yjjAZHBpDTQ.png)](https://santiago.devopsdayschile.cl/?ref=sredevops.org) ## ¿Qué puedo esperar de este evento? Un día completo de charlas, actividades y, por supuesto, suficientes stickers para cubrir sus laptops por los próximos cinco años. Estamos hablando de: - 3 Keynotes de ponentes de renombre en el universo DevOps. - \~14 Charlas y talleres de gente que, como tú, envió una propuesta y cruzó los dedos, además de presentaciones de nuestros patrocinadores. - Open Spaces para discutir temas propuestos por los propios asistentes. ¿Quieres hablar de por qué Kubernetes es demasiado complejo? ¿O por qué tu empresa aún usa FTP? Este es tu momento. - Networking, también conocido como terapia de grupo para ñoños. ## ¿Por qué debería molestarme en ir? Miren, podrían quedarse en la oficina, viendo cómo su pipeline de CI/CD falla por decimoséptima vez. O podrían venir a DevOpsDays. Aquí, pueden quejarse de ese mismo pipeline con gente que realmente entiende su dolor. Conectarán con colegas, aprenderán sobre herramientas que podrían resolver sus problemas (o crear otros nuevos) y se pondrán al día con las últimas tendencias que probablemente serán obsoletas en seis meses. Se llama desarrollo profesional, búsquenlo. Además, es una excusa perfecta para salir de la oficina. ## Patrocinio y voluntariado ¿Tienen una empresa con los bolsillos llenos? ¡Conviértanse en patrocinadores! Es una forma fantástica de poner su marca frente a las mentes más brillantes (y más privadas de sueño) de la tecnología chilena, latinoamericana y global. ¿Prefieren dar su tiempo en lugar de su dinero? *~~(Ejem, como nosotros acá en SREDevOps.org, tacaños como AWS)~~* También necesitan voluntarios. La recompensa es la satisfacción de ayudar... y probablemente una estrellita en la manito. ## Resumen: Para que quede claro! 💡 ****\- Evento:** DevOpsDays Santiago 2025 ****\- Cuándo:** 5 de septiembre de 2025 \- ****Dónde:** Universidad INACAP, sede Santiago Sur, Metro Camino Agrícola. \- ****Entradas:** Disponibles exclusivamente en TicketPlus ([https://ticketplus.cl/events/devopsdays-santiago-2025](https://ticketplus.cl/events/devopsdays-santiago-2025/?ref=sredevops.org)). Es el primero de su tipo en Chile, así que ***"estamos todos, sólo faltas tu!"***. No sean los que se enteren al día siguiente y se los coma el tiburón. Consigan sus entradas antes de que se agoten y hagamos de este un evento para recordar. **O al menos, un día productivo fuera de la oficina.** [Entradas para DevOpsDays Santiago 2025 - TicketplusDevOpsDays Santiago 2025![](https://www.sredevops.org/content/images/icon/favicon-2bf150de56e638b5289625318bacc557c7050639.png)Ticketplus![](https://www.sredevops.org/content/images/thumbnail/1fea2ef9f3c4d92ab16aeebadf4981d4690044a3.png)](https://ticketplus.cl/events/devopsdays-santiago-2025?ref=sredevops.org) ### sudo's latest "trick": when chroot and nsswitch conspire against you (cve-2025-32462) URL: https://www.sredevops.org/en/sudos-latest-trick-when-chroot-and-nsswitch-conspire-against-you-cve-2025-32462/ Last updated: 2025-07-10T14:41:20.000Z Ah, `sudo`. The trusty command that grants mere mortals the power of a deity (root, that is) on a Linux system. It's the gatekeeper, the bouncer, the one program we all implicitly trust to elevate our privileges without turning our beloved machine into a digital wasteland. And precisely because of this immense power, `sudo` has, shall we say, a rather extensive rap sheet when it comes to security vulnerabilities. It seems every now and then, another flaw is unearthed, reminding us that even the most fundamental tools can harbor the deepest secrets. And guess what? They found another one. ## what is `sudo` and why is it a perennial target? For those living under a rock, or perhaps just starting their journey into the glorious world of Linux, `sudo` (short for "superuser do" or "substitute user do") allows a permitted user to execute commands as another user, typically the superuser (root). It's not just a fancy prefix; it's a critical component for managing system-level tasks without constantly logging in as root, which, let's be honest, is about as secure as leaving your front door wide open with a "Welcome, Burglars!" sign. The magic behind `sudo` lies in its `setuid` bit. When a binary like `/usr/bin/sudo` has this bit set, the kernel executes it with the effective user ID of the file's owner, which in `sudo`'s case, is `root`. This means that even if you, a humble `devops_apprentice`, run `sudo`, the `sudo` process itself is running with root privileges. This design, while essential for its function, also makes `sudo` an irresistible target for privilege escalation vulnerabilities. A single logical misstep, a parsing error, or a misinterpretation of trust boundaries within `sudo`'s vast codebase can be weaponized to execute arbitrary code as root. It's like finding a secret back door in the bouncer's office that leads directly to the vault. ## the anatomy of a logic bomb: cve-2025-32462 explained The latest addition to `sudo`'s hall of fame of vulnerabilities is [CVE-2025-32462](https://nvd.nist.gov/vuln/detail/CVE-2025-32462?ref=sredevops.org). This particular gem allows a local attacker to escalate privileges by tricking `sudo` into loading an arbitrary shared library. The trickery involves two key features: `sudo`'s `-r` (chroot) option and the Linux Name Service Switch (NSS). ### chroot: your cozy file system jail Let's talk `chroot`. Imagine you're a child, and your parents tell you, "Your room is now the entire house." That's `chroot` in a nutshell. It changes the root directory for the current running process and its children. So, if you `chroot` into `/opt/myjail`, any process running within that `chroot` environment will perceive `/opt/myjail` as `/`. It's a file system jail, designed to isolate processes. However, for a `chroot` environment to be truly functional, it needs more than just a new root. It needs all the necessary libraries (like `libc`, `libm`, etc.), binaries, and configuration files that a typical Linux environment expects. Without them, most commands will simply fail because they can't find their dependencies. ### `nsswitch.conf` and shared libraries: the identity crisis Enter `nsswitch.conf`, or the Name Service Switch configuration file, usually found at `/etc/nsswitch.conf`. This file dictates how a system resolves various types of information, such as user accounts, groups, hostnames, and network services. For instance, when you try to log in, the system consults `nsswitch.conf` to figure out where to look for your username and password – typically in `/etc/passwd` and `/etc/shadow` files, but potentially also in network services like LDAP or NIS. The magic behind `nsswitch` lies in its use of shared libraries. For each "service" (e.g., `passwd`, `group`, `hosts`), `nsswitch` can be configured to use specific modules, which are implemented as shared objects (e.g., `libnss_files.so.2` for local files, `libnss_ldap.so.2` for LDAP). When `sudo` or any other program needs to resolve user or group information, it calls functions that, based on `nsswitch.conf`, load and execute code from these shared libraries. ### the ingenious exploit: putting it all together The brilliance (and danger) of CVE-2025-32462 lies in the combination of these two features. A local attacker can craft a malicious `chroot` environment containing a custom `etc/nsswitch.conf` file and a custom, malicious shared library. ## Here's the simplified breakdown of the attack chain: 1. **Craft a malicious `chroot` environment:** The attacker creates a directory, let's call it `woot_jail`, and inside it, they set up a minimal file system structure. Crucially, they place their own `nsswitch.conf` file at `woot_jail/etc/nsswitch.conf`. 2. **Point to a custom shared library:** This custom `nsswitch.conf` is configured to look for user/group information using a non-existent or custom "service" name, say, `woot1337`. This implies that `sudo` will eventually try to load a shared library named `libnss_woot1337.so.2`. 3. **Create the malicious shared library:** The attacker creates `woot_jail/usr/lib/libnss_woot1337.so.2` (or a similar path) containing their exploit code. This shared library includes a constructor function (a function that runs automatically when the library is loaded) that sets the effective user ID and group ID of the current process to `0` (root) and then executes arbitrary commands, like spawning a root shell. 4. **Privilege Escalation:** When `sudo` starts up within this `chroot` jail and attempts to resolve any user or group information (which it inevitably does), it will read the attacker's `nsswitch.conf`. This configuration will direct `sudo` to load the `libnss_woot1337.so.2` shared library from within the `woot_jail`. Because `sudo` is running with `setuid` root privileges, when it loads and executes the malicious shared library, the constructor within that library runs *as root*, granting the attacker a root shell or allowing them to execute any command with full system privileges. **Execute `sudo` with `chroot`:** The attacker then runs a `sudo` command using the `-r` option, pointing to their `woot_jail`: ```bash sudo -r /path/to/woot_jail ``` The `` doesn't matter; it's just a placeholder to get `sudo` to execute. This elegant (from an attacker's perspective) exploit was demonstrated by researcher Rich Merch. You can find a proof of concept (PoC) for a similar logic bug (CVE-2025-32463) on GitHub, which highlights the mechanism: [pr0v3rbs/CVE-2025-32463\_chwoot](https://github.com/pr0v3rbs/CVE-2025-32463%5Fchwoot?ref=sredevops.org). [GitHub - pr0v3rbs/CVE-2025-32463\_chwoot: Escalation of Privilege to the root through sudo binary with chroot option. CVE-2025-32463Escalation of Privilege to the root through sudo binary with chroot option. CVE-2025-32463 - pr0v3rbs/CVE-2025-32463\_chwoot![](https://www.sredevops.org/content/images/icon/pinned-octocat-093da3e6fa40-16.svg)GitHubpr0v3rbs![](https://www.sredevops.org/content/images/thumbnail/CVE-2025-32463_chwoot)](https://github.com/pr0v3rbs/CVE-2025-32463%5Fchwoot?ref=sredevops.org) ## `sudo-rs`: the rust paradox In the ongoing quest for more secure systems, there's been a significant buzz around `sudo-rs`, a re-implementation of `sudo` in the Rust programming language. Rust is celebrated for its memory safety guarantees, which theoretically prevent entire classes of vulnerabilities like buffer overflows, use-after-free errors, and other memory corruption bugs that plague C/C++ applications. Ubuntu, for instance, is even considering making `sudo-rs` the default in future releases (e.g., 25.10). One might assume that moving `sudo` to a memory-safe language like Rust would magically eradicate its security woes. However, CVE-2025-32462 serves as a stark reminder that security is a multi-faceted beast. This vulnerability is *not* a memory corruption bug. It's a **logic bug**, a flaw in how `sudo` processes and trusts external configuration (the `chroot` path and `nsswitch.conf`). Even if `sudo` were entirely rewritten in Rust, this specific vulnerability could still exist, as Rust's memory safety features wouldn't prevent the underlying logical flaw in handling `chroot` and `nsswitch` interactions. It's a classic case of "garbage in, garbage out" – if the logic allows for trusted inputs to be maliciously manipulated, the language itself won't save you. This doesn't diminish Rust's value in security-critical applications; it merely highlights that comprehensive security requires more than just memory safety. It demands rigorous logical design, robust input validation, and a healthy dose of paranoia about what an attacker might try to feed your program. ## mitigation and staying safe So, what's a humble sysadmin or developer to do? - **Patch, patch, patch:** The most crucial step is to keep your `sudo` package updated. Distributions will release patched versions that address this and other vulnerabilities. This is non-negotiable for any system exposed to local users. - **Principle of Least Privilege:** Always apply the principle of least privilege. Users should only have `sudo` access to the commands they absolutely need, and nothing more. Restrict `sudoers` configurations. - **Monitor and Audit:** Implement robust logging and auditing for `sudo` usage. Anomalous `sudo` commands or repeated failed attempts can be indicators of compromise or malicious activity. - **Isolate Environments:** For critical services, consider containerization or virtualization with strict resource and network isolation to limit the blast radius of any successful exploit. The never-ending cat-and-mouse game between security researchers and attackers continues. `sudo` remains a critical piece of the Linux puzzle, and its security is paramount. While this latest vulnerability reminds us that no software is infallible, it also underscores the importance of continuous auditing, patching, and a healthy dose of skepticism towards anything that promises too much power. --- **Author/Source:** This article is based on the analysis and explanation provided by [@LowLevel](https://www.youtube.com/@LowLevelTV?ref=sredevops.org) ### Multipass, la forma fácil y rápida para crear máquinas virtuales Ubuntu, compatible con macOS y Windows, ahora es completamente Open Source URL: https://www.sredevops.org/es/multipass-la-forma-facil-y-rapida-para-crear-maquinas-virtuales-ubuntu-compatible-con-macos-y-windows-ahora-es-completamente-open-source/ Last updated: 2026-01-19T16:40:23.000Z En un movimiento que, sin duda, hará vibrar las fibras más sensibles de los amantes del código abierto, Canonical, la empresa detrás del omnipresente Ubuntu, ha decidido que su **ligero pero potente gestor de máquinas virtuales (VMs), Multipass**, ahora es **totalmente open source**. Con el lanzamiento del Multipass 1.16 Release Candidate, esta herramienta que simplifica la vida al ejecutar entornos Ubuntu en Linux, Windows y macOS, ha cortado las últimas cadenas propietarias en las licencias de su código fuente. ## ¿Qué Diablos es Multipass? Para los que aún no se desenchufan del Atari, Multipass es esa joyita que te permite levantar instancias de Ubuntu, casi tan tan fácil como abrir una pestaña más, ~~aparte de todas esas otras que sigues acumulando en tu navegador~~. Olvídate de las complejidades de la virtualización; con un solo comando, tienes una VM Ubuntu lista para la acción, ya sea que estés en tu Linux, tu Windows o tu Mac. Es como tener un patio de juegos Ubuntu desechable, pero sin el desorden ni preocuparte de destrozar tu equipo de trabajo. Bajo el capó, Multipass no se anda con chicas y usa las tecnologías de virtualización nativas para que todo vuele bajo y sin dramas: - **Linux**: Se apoya en el robusto KVM. - **Windows**: Utiliza el mismísimo Microsoft Hyper-V. - **macOS**: Se la juega con QEMU. Esta versatilidad multiplataforma y su obsesión por la simplicidad han catapultado a Multipass al estrellato, convirtiéndolo en una opción confiable para probar software, desarrollar en un ambiente aislado o simplemente *cachurear* con Ubuntu sin tener que instalarlo completo. ## La Odisea Hacia el Código Abierto Total Aunque Multipass ya venía con la licencia GNU GPLv3, la verdad es que no todo su código era tan "abierto" como uno quisiera. Había unas cuantas porciones específicas para las versiones de Windows y macOS que se mantenían en el lado oscuro, el propietario. Una situación que, si bien es común en proyectos que intentan balancear el desarrollo open source con el soporte a múltiples plataformas, siempre generaba un ruido en la comunidad. Pero la buena nueva es que, con el Multipass 1.16 RC, esa dualidad se fue al carajo. Canonical ha integrado esas partes que antes eran "secretas" directamente en la base de código open source de Multipass. Como lo gritaron a los cuatro vientos en el anuncio de lanzamiento: > *"¡toda la base de código se volvió completamente open source! ... Anteriormente, los bits propietarios para Windows y macOS ahora son parte de este repositorio."* > *\- Alguien en Canonical, ~~creo...~~* Este hito no es casualidad; es el resultado de un esfuerzo titánico de refactorización y unificación, encapsulado en esa pull request épica en GitHub llamada "One Repo To Rule Them All" (PR #4058). Este movimiento no solo reafirma el compromiso de Canonical con el open source, sino que también abre las puertas de par en par a una colaboración comunitaria en serio y confiable *(hola terraform)* , permitiendo que cualquier desarrollador meta mano en todas las entrañas del proyecto sin desconfiar que cambien la licencia y el uso de tus potenciales aportes al código. [One Repo To Rule Them All by ricab · Pull Request #4058 · canonical/multipass![](https://www.sredevops.org/content/images/icon/pinned-octocat-093da3e6fa40-15.svg)GitHubcanonical![](https://www.sredevops.org/content/images/thumbnail/4058)](https://github.com/canonical/multipass/pull/4058?ref=sredevops.org) ## Multipass y Kubernetes: Tu cluster para jugar y desechar Aquí es donde la cosa se pone realmente interesante para los que vivimos en el mundo de DevOps y la ingeniería de plataformas. Multipass es la herramienta perfecta para levantar clústeres de Kubernetes locales y desechables. ¿Necesitas probar algo rápido? ¿Una demo? ¿O simplemente quieres *cachurear* sin ensuciar tu máquina principal? Multipass es tu mejor amigo. Vamos a ver un ejemplo de cómo puedes levantar un clúster de MicroK8s (la versión ligera de Kubernetes de Canonical) modo express: ## Levantando un Clúster MicroK8s con Multipass ### **Espera a que MicroK8s esté listo**: Kubernetes necesita un momento para arrancar todos sus componentes. Este comando esperará hasta que todo esté en su lugar. ```bash multipass exec k8s-dev -- sudo microk8s status --wait-ready ``` ### **Instala MicroK8s dentro de la VM**: Una vez que la VM esté lista, nos conectamos a ella y le instalamos MicroK8s. El `--classic` es importante para que Snap lo instale correctamente. ```bash multipass exec k8s-dev -- sudo snap install microk8s --classic ``` ### **Lanza una VM Ubuntu con Multipass**: Primero, necesitamos una máquina virtual donde instalar nuestro Kubernetes. Le daremos 4GB de RAM y 20GB de disco, que es suficiente para empezar. ```bash multipass launch --name k8s-dev --memory 4G --disk 20G ``` ```log % multipass exec k8s-dev -- sudo microk8s status --wait-ready microk8s is running high-availability: no datastore master nodes: 127.0.0.1:19001 datastore standby nodes: none addons: enabled: dns # (core) CoreDNS ha-cluster # (core) Configure high availability on the current node helm # (core) Helm - the package manager for Kubernetes helm3 # (core) Helm 3 - the package manager for Kubernetes disabled: cert-manager # (core) Cloud native certificate management cis-hardening # (core) Apply CIS K8s hardening community # (core) The community addons repository dashboard # (core) The Kubernetes dashboard host-access # (core) Allow Pods connecting to Host services smoothly hostpath-storage # (core) Storage class; allocates storage from host directory ingress # (core) Ingress controller for external access kube-ovn # (core) An advanced network fabric for Kubernetes mayastor # (core) OpenEBS MayaStor metallb # (core) Loadbalancer for your Kubernetes cluster metrics-server # (core) K8s Metrics Server for API access to service metrics minio # (core) MinIO object storage observability # (core) A lightweight observability stack for logs, traces and metrics prometheus # (core) Prometheus operator for monitoring and logging rbac # (core) Role-Based Access Control for authorisation registry # (core) Private image registry exposed on localhost:32000 rook-ceph # (core) Distributed Ceph storage using Rook storage # (core) Alias to hostpath-storage add-on, deprecated ``` ### **Copia la configuración de Kubeconfig a tu máquina local**: Para interactuar con tu nuevo clúster desde tu terminal local (usando `kubectl`), necesitas el archivo de configuración. ```bash multipass exec k8s-dev -- sudo microk8s config > ~/.kube/k8s-dev.yaml ``` ```log % cat ~/.kube/k8s-dev.yaml apiVersion: v1 clusters: - cluster: certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSWlJMnMKbjQ5QXh5T1RBeHFaZnRPbVZVb0xrSDN0SXc9PQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg== server: https://192.168.64.2:16443 name: microk8s-cluster contexts: - context: cluster: microk8s-cluster user: admin name: microk8s current-context: microk8s kind: Config preferences: {} users: - name: admin user: client-certificate-data: blablable client-key-data: bñlablabla ``` 💡 ****Ojo**: Esto NO sobrescribirá tu `kubeconfig` actual. De todos modos, si ya tienes otros clústeres configurados, te recomiendo que hagas un respaldo. ### **Verifica tu clúster desde tu máquina local**: ¡Listo! Ahora puedes usar `kubectl` para ver los nodos de tu clúster. ```bash kubectl --kubeconfig ~/.kube/k8s-dev.yaml get nodes ``` ```log NAME STATUS ROLES AGE VERSION k8s-dev Ready 10m v1.32.3 ``` ### Limpiando el Desorden Cuando termines de jugar, la belleza de los clústeres desechables es que los puedes borrar sin remordimientos: ```bash multipass delete k8s-dev --purge && multipass ls ``` ```log No instances found. ``` Este comando no solo borra la VM, sino que también la purga, liberando todo el espacio en disco. ¡Magia! ## Novedades en Multipass 1.16 La movida hacia un modelo totalmente open source no es la única joya que trae Multipass 1.16\. Esta versión candidata viene cargada de otras mejoras y arreglos que te harán la vida más fácil: - **GUI Mejorada**: La interfaz gráfica del usuario recibió un cariño, prometiendo una experiencia más fluida y menos dolorosa. - **Correcciones en el Daemon/Servicio**: Mejoras en la estabilidad y confiabilidad del servicio de fondo de Multipass. ¡Menos crasheos, más productividad! - **Mejoras de Seguridad**: Refuerzos en la seguridad para que tus entornos virtuales estén más blindados que nunca. - **Documentación Aumentada**: Una documentación más clara y completa para que no te pierdas en el camino y le saques el jugo a la herramienta. Para más detalles sobre el Multipass 1.16 Release Candidate, puedes echarle un ojo al [anuncio oficial en GitHub](https://github.com/canonical/multipass/releases/tag/v1.16.0-rc3?ref=sredevops.org). [Release 1.16.0 RC · canonical/multipassMultipass version 1.16.0 We’re pleased to announce Multipass 1.16.0, where the entire code base became fully open source! This is a consolidation release, bringing a ton of improvements to our GUI,…![](https://www.sredevops.org/content/images/icon/pinned-octocat-093da3e6fa40-14.svg)GitHubcanonical![](https://www.sredevops.org/content/images/thumbnail/v1.16.0-rc3)](https://github.com/canonical/multipass/releases/tag/v1.16.0-rc3?ref=sredevops.org) La decisión de Canonical de liberar Multipass por completo es un golazo para toda la comunidad de desarrollo. No solo aumenta la transparencia y la confianza en el proyecto, sino que también es un empujón gigante a la innovación y la colaboración, asegurando que Multipass siga siendo una herramienta indispensable para la gestión de VMs ligeras. ¡A celebrar con un buen terremoto! Fuente: [Phoronix - Canonical Makes Multipass VM Manager Fully Open-Source](https://www.phoronix.com/news/Multipass-Fully-Open-Source?ref=sredevops.org) por Michael Larabel. ### KServe: La Plataforma de Inferencia de IA Basada en Kubernetes Que Realmente Funciona (Más o Menos) URL: https://www.sredevops.org/es/kserve-la-plataforma-de-inferencia-de-ia-basada-en-kubernetes-que-realmente-funciona-mas-o-menos/ Last updated: 2026-01-08T02:36:24.000Z Seamos sinceros: desplegar modelos de IA a escala es un dolor de cabeza. KServe llega para simplificarlo. ## ¿Qué es KServe? KServe es una plataforma de inferencia de modelos de machine learning construida sobre Kubernetes. Permite desplegar modelos de manera eficiente, escalable y reproducible. ### ¿Por qué elegir KServe? (Porque lo tienes que hacer, obviamente) - **Protocolo de Inferencia Estandarizado:** Funciona a través de diferentes frameworks de ML. - *Ya no tendrás que reescribir código solo para que funcione con un nuevo framework.* - **Serverless y Optimizado para GPU:** Gestión eficiente de recursos. - *Tu GPU debería estar trabajando, no viendo Netflix.* - **Flexible y Extensible:** Soporta runtimes personalizados y patrones de despliegue avanzados. - *Si no estás usando runtimes personalizados, probablemente no estés haciendo nada interesante.* - **Características para Producción:** Monitoreo, *explicabilidad* y despliegues canarios. - *“Enterprise-grade” significa que tus modelos no pueden fallar, ni siquiera por unos segundos.* - **Adoptado por Líderes de la Industria:** Confiado por **Bloomberg, NVIDIA, IBM, Cisco, AMD, Gojek**, y más. - *Si hasta Bloomberg lo usa, debe ser mejor que la última vez que intentaste desplegar un modelo.* ![](https://raw.githubusercontent.com/kserve/kserve/refs/heads/master/docs/diagrams/kserve_new.png) ### Características Clave: - **ModelMesh:** Un componente central que gestiona el despliegue y el escalado de modelos. - **vLLM:** Un runtime de Hugging Face optimizado para inferencia rápida de modelos de lenguaje. - **API Compatible con OpenAI:** Permite usar modelos de lenguaje con la misma API que OpenAI. - **Despliegues Canary:** Permiten probar nuevas versiones de modelos en un entorno controlado antes de lanzarlas a producción. - ***Explicabilidad* de Modelos:** Permite entender cómo toman decisiones los modelos de IA. ## ¿Qué puedes hacer con KServe? - **Inferencia de Modelos de Lenguaje:** Despliega y sirve modelos de lenguaje como GPT-3 o Llama 2. - **Análisis Predictivo:** Implementa modelos de machine learning para predecir resultados y tomar decisiones. - **Automatización de Procesos:** Integra modelos de IA en flujos de trabajo automatizados. [KServeKServe is a highly scalable and standards based Model Inference Platform on Kubernetes for Trusted AI. It is hosted in Incubation in LF AI & Data Foundation. - KServe![](https://www.sredevops.org/content/images/icon/pinned-octocat-093da3e6fa40-13.svg)GitHub![](https://www.sredevops.org/content/images/thumbnail/83512434)](https://github.com/kserve?ref=sredevops.org) ## Comenzando: Para configurar y usar KServe, consulta la [documentación de KServe](https://kserve.github.io/website/master/get%5Fstarted/?ref=sredevops.org). *Nota: Si estás leyendo esto y pensando, “no tengo idea de lo que estoy haciendo”, no estás solo. Pero con KServe, al menos parecerás que sabes lo que estás haciendo.* ### API OpenAI Compatible: KServe soporta endpoints tipo **OpenAI `/v1/completions` y `/v1/chat/completions`** . - **API Endpoints:** Supports text generation, text2text generation, and embeddings. - Docs: [https://kserve.github.io/website/master/modelserving/v1beta1/llm/huggingface/text\_generation/](https://kserve.github.io/website/master/modelserving/v1beta1/llm/huggingface/text%5Fgeneration/?ref=sredevops.org) - *Si no estás usando APIs compatibles con OpenAI, probablemente no estés en el club de los cool kids.* ## Ecosistema y Comunidad: - **GitHub:** [KServe Community](https://github.com/kserve?ref=sredevops.org) - *Si no estás contribuyendo a GitHub, probablemente no seas un desarrollador de verdad – o tal vez sí, pero estás demasiado ocupado.* - **Adopters:** [Lista de empresas que usan KServe](https://kserve.github.io/website/master/community/adopters/?ref=sredevops.org) - *Si tu empresa no está en esta lista, probablemente no estés haciendo nada importante – o tal vez sí, pero eres demasiado cool para la lista.* - **Contribuciones:** Abierto a la entrada de la comunidad. Guías sobre [cómo contribuir](https://kserve.github.io/website/master/developer/developer/?ref=sredevops.org). - *El código abierto se trata de dar algo a cambio – incluso si son solo unas pocas líneas de código que nadie verá nunca.* **KServe** es una herramienta poderosa para empresas y desarrolladores que buscan operacionalizar la IA a escala, respaldada por un ecosistema en crecimiento y adopción de la industria. ## En resumen, KServe te ayuda a: - Desplegar modelos de IA de forma más rápida y sencilla. - Escalar tus modelos para manejar grandes volúmenes de tráfico. - Mejorar la confiabilidad y la disponibilidad de tus modelos. - Reducir los costos de operación de tus modelos. - Acelerar la innovación en IA. [GitHub - kserve/kserve: Standardized Serverless ML Inference Platform on KubernetesStandardized Serverless ML Inference Platform on Kubernetes - kserve/kserve![](https://www.sredevops.org/content/images/icon/pinned-octocat-093da3e6fa40-12.svg)GitHubkserve![](https://www.sredevops.org/content/images/thumbnail/kserve)](https://github.com/kserve/kserve?ref=sredevops.org) ### ¿Apple está tratando de matar a Docker? Los Contenedores Linux Nativos están llegando a macOS URL: https://www.sredevops.org/es/apple-esta-tratando-de-matar-a-docker-los-contenedores-linux-nativos-estan-llegando-a-macos/ Last updated: 2026-01-08T02:36:05.000Z ## Introducción Apple, la compañía que alguna vez hizo de "Piensa Diferente" un mantra, ahora ha decidido "Pensar en Contenedores". La presentación principal de este año en WWDC, que de alguna manera logró eclipsar el tan esperado (y probablemente exagerado) iPhone 16, reveló una característica que podría cambiarlo todo: la integración de contenedores Linux nativos. Esto podría significar el fin de Docker tal como lo conocemos. ## ¿Una amenaza para Docker? Apple está introduciendo una nueva forma de ejecutar contenedores Linux directamente en macOS, sin la necesidad de una máquina virtual o Docker. Esto podría simplificar el desarrollo y la implementación de aplicaciones, pero también plantea preguntas sobre el futuro de Docker. ## Impacto en Desarrolladores y Profesionales de SRE/DevOps Para los desarrolladores, esto podría significar: - **Mayor eficiencia:** Adiós a las máquinas virtuales engorrosas o a los "Docker resource hogs". Finalmente, una solución que no haga sentir a tu Mac como si estuviera ejecutando un reactor nuclear. - **Integración ligera:** Una solución optimizada para la duración de la batería. Porque, ¿quién quiere trabajar en un Mac que constantemente está pidiendo un enchufe? - **Potencial para el backend en Swift:** Abriendo nuevas posibilidades para construir y desplegar aplicaciones usando Swift. Porque, ¿por qué usar Python cuando puedes usar Swift? Para los profesionales de SRE y DevOps, esto podría significar: - **Mejoras en la eficiencia:** Adiós a las máquinas virtuales engorrosas o a los "Docker resource hogs". Finalmente, una solución que no haga sentir a tu Mac como si estuviera ejecutando un reactor nuclear. - **Integración ligera:** Una solución optimizada para la duración de la batería. Porque, ¿quién quiere trabajar en un Mac que constantemente está pidiendo un enchufe? - **Potencial para el backend en Swift:** Abriendo nuevas posibilidades para construir y desplegar aplicaciones usando Swift. Porque, ¿por qué usar Python cuando puedes usar Swift? ## Posibles Problemas Sin embargo, existen preocupaciones: - **Apertura y Flexibilidad:** ¿El framework de Apple soportará una amplia gama de imágenes de contenedores y herramientas de orquestación? ¿O será un jardín cerrado donde solo se permitirán las herramientas aprobadas por Apple? - **Seguridad:** ¿Puede proporcionar el mismo nivel de aislamiento que las soluciones de contenedorización tradicionales? ¿O será una pesadilla de seguridad que hará que incluso los SRE más paranoicos rompan en sudor frío? - **Lock-in de proveedor:** ¿Apple forzará a los usuarios a usar sus propias herramientas y servicios, o mantendrá la compatibilidad con el resto del ecosistema? Porque nada dice "open source" como una herramienta propietaria. ## La herramienta CLI `container` La herramienta `container` es una herramienta escrita en Swift, optimizada para Apple silicon, para crear y ejecutar contenedores Linux en macOS. Consume y produce imágenes de contenedores OCI-compatibles, lo que permite a los usuarios descargar y ejecutar imágenes desde registros estándar. ![Introductory movie](https://raw.githubusercontent.com/apple/container/refs/heads/main/docs/assets/landing-movie.gif) ### Empezando - **Requisitos:** Mac con Apple silicon, Swift (para construir). - **Compatibilidad:** macOS 26 Beta 1 y posteriores; limitaciones significativas de red en macOS 15. ### Instalación y Siguientes Pasos 1. Descarga el instalador firmado más reciente desde la [página de lanzamientos de GitHub](https://github.com/apple/container/releases?ref=sredevops.org). 2. Realiza una [visita guiada](https://github.com/apple/container/blob/main/docs/tutorial.md?ref=sredevops.org) para construir, ejecutar y publicar una imagen de servidor web simple. 3. Explora [varias características de container](https://github.com/apple/container/blob/main/docs/how-to.md?ref=sredevops.org). 4. Lee la [visión general técnica](https://github.com/apple/container/blob/main/docs/technical-overview.md?ref=sredevops.org) y [documentación de la API](https://apple.github.io/container/documentation/?ref=sredevops.org). [Releases · apple/containerA tool for creating and running Linux containers using lightweight virtual machines on a Mac. It’s written in Swift, and optimized for Apple silicon. - apple/container![](https://www.sredevops.org/content/images/icon/pinned-octocat-093da3e6fa40-11.svg)GitHubapple![](https://www.sredevops.org/content/images/thumbnail/123bf50d-9ae2-48d9-94f7-7a345bf82c15-1)](https://github.com/apple/container/releases?ref=sredevops.org) ## Proyecto Apple Containers en GitHub El código fuente del framework de contenedorización de Apple está disponible en GitHub: - [Framework de Contenedorización](https://github.com/apple/containerization/?ref=sredevops.org) - [Paquete de Contenedorización](https://github.com/apple/containerization/tree/main/Sources/Containerization?ref=sredevops.org) Este proyecto incluye la gestión de imágenes OCI, la interacción con registros remotos, la creación y gestión del sistema de archivos, las interacciones de sockets Netlink, la optimización del kernel para tiempos de arranque rápidos, el inicio ligero de máquinas virtuales, la interacción de contenedores Linux, el inicio de sesión en el registro de contenedores y más. ## Reflexiones Finales La nueva funcionalidad de Apple podría revolucionar la forma en que los desarrolladores trabajan con contenedores. Sin embargo, también plantea preguntas sobre el futuro de Docker y el panorama de la contenerización en general. El tiempo dirá si esta innovación de Apple será una bendición o una amenaza para la industria. [Releases · apple/containerA tool for creating and running Linux containers using lightweight virtual machines on a Mac. It’s written in Swift, and optimized for Apple silicon. - apple/container![](https://www.sredevops.org/content/images/icon/pinned-octocat-093da3e6fa40-10.svg)GitHubapple![](https://www.sredevops.org/content/images/thumbnail/123bf50d-9ae2-48d9-94f7-7a345bf82c15)](https://github.com/apple/container/releases?ref=sredevops.org) ## Más contenido similar [Alternativas a Docker Desktop en macOS: OrbStack, Lima, Podman y másLos usuarios de macOS tienen varias opciones sólidas para ejecutar contenedores (containers), cada una con sus propias fortalezas. Revisamos OrbStack, Lima (Linux Machines) y Docker Desktop, comparando sus características, rendimiento y facilidad de uso para ayudarte a elegir la que mejor se adapte a tu flujo de trabajo de desarrollo.![](https://www.sredevops.org/content/images/icon/Icon-App-76x76@2x-6.png)SREDevOps.orgNicolás Georger![](https://www.sredevops.org/content/images/thumbnail/orbstack.webp)](https://www.sredevops.org/es/alternativas-a-docker-desktop-en-macos-orbstack-lima-podman-y-mas/) [Lima: La forma más fácil de ejecutar cualquier distribución de Linux, Kubernetes, k3s e incluso Docker en macOS y Linux, compatible con Apple Silicon (M1/ARM64)Qué es Lima: Una herramienta de línea de comandos (CLI) versátil y fácil de usar para ejecutar máquinas virtuales (VM) de Linux en tu sistema macOS o Linux Lima es compatible con cualquier procesador Apple Silicon (M1, M2, etc.) y procesadores Intel x86\_64, y te permite ejecutar VMs de![](https://www.sredevops.org/content/images/icon/Icon-App-76x76@2x-7.png)SREDevOps.orgNicolás Georger![](https://www.sredevops.org/content/images/thumbnail/lima-linux-apple-1.jpeg)](https://www.sredevops.org/es/lima-la-forma-mas-facil-de-ejecutar-cualquier-distribucion-de-linux-kubernetes-k3s-e-incluso-docker-en-macos-y-linux-compatible-con-apple-silicon-m1-arm64/) ### Flux vs ArgoCD: ¿Por qué deberías usar GitOps KRM-Native? URL: https://www.sredevops.org/es/flux-vs-argocd-por-que-deberias-usar-gitops-krm-native/ Last updated: 2026-01-08T02:36:05.000Z *Basado en el artículo original publicado por* [*Pierre-Gilles Mialon*](https://www.linkedin.com/pulse/krm-native-gitops-yes-without-flux-fluxcd-nothing-mialon-wsmue/?ref=sredevops.org)*.* ## Gitops: FluxCD o Nada Este artículo es con opinión, y muy marcada. Está forjada a través de la experiencia con despliegues de Kubernetes a gran escala, impulsada por debates con colegas, conversaciones con mantenedores de OSS, cientos de estudiantes de CKA/CKAD entrenados... y más de una que otra caída de servicio (outage). 🙃 En una sesión reciente en KubeCon Paris 2024, los oradores intentaron argumentar que KRM no era un modelo viable para la ingeniería de plataforma. Pero quizás no entendieron el punto. **Con lo que realmente estaban luchando... era con ArgoCD.** ## Sign up for SREDevOps.org SRE, DevOps, Linux, Ethical Hacking, AI, ML, Open Source, Cloud Native, Platform Engineering en Español, Portugués (Brasil) and English Registrate gratis Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. ### 🧠 ¿Qué es GitOps KRM-Native? GitOps KRM-Native es más que una palabra de moda — es un patrón de arquitectura. Uno que finalmente aporta verdadera simplicidad a la ingeniería de plataforma. > Es GitOps, impulsado por el Kubernetes Resource Model (KRM), gestionando todo: desde deployments hasta IAM, DNS, bases de datos SQL gestionadas y reglas de firewall — con una única API, un único modelo y una única fuente de verdad en Git. Con herramientas como [Config Connector (GCP)](https://cloud.google.com/config-connector/docs?ref=sredevops.org), Crossplane, ACK (AWS) o la salida KRM de Pulumi, toda tu infraestructura se convierte en un conjunto de recursos de Kubernetes. 🧱 Todo se declara en YAML. - ¿Tu Deployment? YAML. - ¿Tu VPC? YAML. - ¿Tu Service Account? YAML. - ¿Tu instancia de CloudSQL? YAML. - ¿Tu Política de Alerta? YAML. 🎯 Todo es declarativo, inmutable, componible — y versionado en Git. 🌍 Por Qué GitOps KRM-Native Es el Futuro ### Un contrato de despliegue para gobernarlos a todos Como ingeniero de plataforma, estás construyendo un sistema para alojar muchas aplicaciones y servicios, posiblemente desarrolladas por docenas de equipos. Quieres: - 🔒 Una forma segura y auditable de definir y provisionar infraestructura. - 🧠 Un modelo entendible por humanos y máquinas. - 🚀 Una base para habilitar la automatización, la IA y flujos de trabajo inteligentes. - 🔄 Reducir la complejidad y el trabajo pesado (toil). KRM cumple con todo esto — porque es: - 🌐 API-first — Todo es impulsado por controladores de Kubernetes. - ✍️ Declarativo — Sin scripts, sin desorden imperativo. - 🔁 Reconciliador — Kubernetes asegura la convergencia al estado deseado. - 🤖 AI-friendly — Todos los recursos son legibles por máquina en el mismo formato. ### Ejemplo: la Aplicación Full-Stack GitOps Supongamos que estás desplegando un microservicio que necesita: - Un Deployment de Kubernetes. - Un Service de GKE con LoadBalancer. - Una base de datos PostgreSQL en CloudSQL. - Bindings de IAM para la workload identity. - Una regla de firewall para el tráfico backend-a-base de datos. - Alertas y dashboards de monitoreo. Tradicionalmente, esto significaría: - Un repo de Terraform. - Un Helm chart. - Un ticket al equipo de cloud. - Un script de devops. - Y un pobre ingeniero intentando pegar todo (glue everything together). Con GitOps KRM-Native, todo eso va a un único repo de Git, bajo una estructura de carpetas clara, completamente declarativo. La plataforma reconcilia el resto. ### Beneficios: - 🧩 Modelo unificado: Gestionas todos los recursos de la misma manera. - 🔍 Visibilidad completa: El grafo de dependencias se vuelve observable. - 🚨 Listo para AI-OPS: Los servidores MCP pueden razonar sobre tu plataforma. - 📜 Control de versiones: Cada cambio es rastreado. - 🛠️ Consistencia operacional: El error humano se reduce. La automatización prospera. Si alguna vez tuviste que rastrear una caída de producción (outage) hasta un permiso de IAM faltante o una regla de firewall olvidada — verás el valor inmediatamente. ## ⚖️ Flux vs ArgoCD — O Por Qué Uno Abraza Kubernetes y el Otro Lo Reinventa Probablemente estás aquí porque has probado GitOps. Quizás ya estás ejecutando ArgoCD en producción. Quizás simplemente lo viste en una demo en una conferencia y pensaste: "¡Wow, esa UI es genial!". Y sí — lo es. Pero aquí está el giro: esa interfaz brillante viene con equipaje arquitectónico. ### 🎭 UX vs Verdad: La División Filosófica Hagámoslo simple: - Flux: opinionado, minimalista, nativo de Kubernetes. - ArgoCD: flexible, rico en UI, compatible con Kubernetes. No es que uno sea mejor en todos los contextos — pero si tu objetivo es GitOps KRM-Native, una de estas herramientas se alinea más profundamente con la filosofía de diseño de Kubernetes. Y no es el que tiene pestañas y gráficos. ### 🔐 Permisos: Confía en la API, No en la Aplicación Empecemos con RBAC. - Flux delega todo al RBAC de Kubernetes. → Sin puertas traseras raras. Sin modelo de permisos duplicado. → Usas `kubectl auth can-i` y listo. - ArgoCD introduce su propio modelo de acceso, superpuesto a Kubernetes, permitiendo a los usuarios realizar acciones a través de la UI independientemente de sus permisos dentro del cluster. ¿Suena conveniente? Lo es — hasta que falla. Pregúntale a cualquiera que haya visto a un desarrollador borrar accidentalmente cargas de trabajo de producción a través de la UI de ArgoCD un viernes por la noche. ### Historia real: > Un equipo subió un cambio a ArgoCD, editó algo en vivo a través de la UI web (en contra de las mejores prácticas), y rompió la mitad de la plataforma — con un retraso de 24 horas debido a la reconciliación de drift. ¿Adivina en qué día cayó ese período de 24 horas? Sí, domingo. ### 🔄 Pull vs Push: ¿Quién Posee la Verdad? El corazón de GitOps es que Git es la fuente de verdad. No un usuario, no un dashboard, no una UI — Git. - Flux opera en modo pull. Vigila Git, reconcilia continuamente y aplica cambios. Es silencioso, humilde, pero sólido como una roca. - ArgoCD por defecto usa push. Si bien el pull es técnicamente soportado, la mayoría de las implementaciones usan push por flexibilidad — y velocidad. ¿El riesgo? > Ahora tienes un plano de control mutable, accesible para humanos (y posiblemente sistemas de CI), con permisos amplios y mutación en tiempo real del estado del cluster. Déjame preguntarte: - ¿Confías en que una aplicación web accesible tenga las llaves de todos tus entornos? - ¿Has oído hablar de las vulnerabilidades Zero-Day? - ¿Puedes probar que ArgoCD no tiene una ahora mismo? Si tu controlador de GitOps tiene un CVE, quieres que esté aislado y de solo lectura, no sentado frente a tu cluster con modo dios habilitado. ### 🖥️ UX y Adopción: El Arma Secreta de Argo Seamos honestos: ArgoCD está ganando corazones con su UI. Se ve genial, funciona bien en demos, y los equipos se sienten productivos. - ✅ Diff visual - ✅ Sincronización con un click - ✅ Indicadores de salud - ✅ Dashboards de estado Pero esa conveniencia tiene un costo: - Aleja la toma de decisiones de Git. - Fomenta el click-ops (que no es GitOps). - Rompe los rastros de auditoría a menos que seas extremadamente disciplinado. Mientras tanto, Flux es... bueno, una herramienta principalmente de CLI. Se integra maravillosamente en GitHub Actions, GitLab CI y pipelines. Se ejecuta como controladores nativos de Kubernetes. Emite eventos. Se integra con SOPS, Kustomize, OCI, Helm, multi-tenancy y modelos de operator. Flux no se ve bien. Flux funciona bien. 🛠️ Tip: ¿Quieres una UI para Flux? Usa [Headlamp](https://headlamp.dev/?ref=sredevops.org) — es limpia, respeta el RBAC y es componible. ### ⚡ Event-Driven vs Polling Otra diferencia clave: Flux es event-driven. ArgoCD hace polling. Esto significa: - En ArgoCD, configuras un intervalo de sincronización (por ejemplo, 3 minutos) y esperas. - En Flux, un nuevo commit en Git dispara un evento, y todo se reconcilia instantáneamente. ¿Resultado? Flux es más rápido, más reactivo y más nativo de Kubernetes. Recuerda, Kubernetes no se trata de programar cron jobs — se trata de convergencia reactiva. ### 🔐 Gestión de Secretos: Flux Es Simplemente Más Inteligente Gestionar secretos en GitOps es doloroso. Flux abraza esto integrándose con SOPS de forma nativa (out-of-the-box). - Tus secretos están encriptados en reposo (YAML + PGP/AES/GCP KMS). - Se commitean a Git — pero de forma segura. - Se desencriptan solo dentro del cluster. - Es determinístico, a prueba de auditorías y funciona en CI. ¿El enfoque de ArgoCD? > "GitOps no es para secretos." — [Literalmente en la documentación](https://argo-cd.readthedocs.io/en/stable/operator-manual/secret-management/?ref=sredevops.org) En cambio, ArgoCD pasa el problema a vaults, sincronizaciones externas o herramientas de side-channel. Buena suerte uniendo eso en un modelo de despliegue unificado. ## 🆚 GitOps vs Gitless GitOps — O Cómo OCI y la Seguridad Están Dando Forma a la Próxima Frontera Ah, GitOps. Nos encanta. - 🧠 Git como la única fuente de verdad. - 🛠️ CI construye el artefacto. - 🤖 Las herramientas de CD (como Flux o ArgoCD) sincronizan el estado declarado en Kubernetes. Pero recientemente, ha surgido un nuevo sabor de las sombras de KubeCon EU 2025 — algo a la vez familiar y radical: Gitless GitOps. Vamos a desempacarlo. ### 🛢️ Gitless GitOps: ¿Qué Es? En resumen, Gitless GitOps reemplaza los repositorios de Git con artefactos OCI (Open Container Initiative) almacenados en registros de contenedores. En lugar de sincronizar YAMLs desde Git: - CI construye tus manifests (por ejemplo, con Kustomize o Helm). - El resultado se empaqueta como un artefacto OCI. - Ese artefacto se almacena en un registro como ghcr.io, gcr.io, harbor, ArtifactRegistry, etc. - Las herramientas de CD extraen (pull) y aplican esos bundles OCI directamente. > La fuente de verdad ahora es un artefacto firmado e inmutable, no una rama de Git. ### 🔒 ¿Por Qué Cambiar Lo Que Funciona? Porque Git — con toda su grandeza — tiene algunas desventajas en cadenas de suministro de grado de producción: ### 🔐 1\. Seguridad de la Cadena de Suministro de Software Los flujos de trabajo basados en OCI permiten: - Firmado de artefactos con [cosign](https://github.com/sigstore/cosign?ref=sredevops.org). - Escaneo de vulnerabilidades. - Publicación de SBOM (Software Bill of Materials). - Seguimiento de procedencia con niveles [SLSA](https://slsa.dev/?ref=sredevops.org). Esto hace que Gitless GitOps sea ideal para entornos de alta conformidad: finanzas, salud, defensa. Con Git, validar que un YAML no fue manipulado es difícil. Con OCI, es criptográficamente verificable. ### 🧱 2\. Replicación de Registros y Resiliencia en el Edge A diferencia de los servidores de Git, los registros OCI se replican fácilmente entre regiones y zonas. Esta es una gran ventaja para: - 🌍 Entornos de edge. - 🛰️ Sistemas air-gapped. - 🧪 Disaster recovery. ¿Necesitas desplegar el mismo manifest en 50 clusters de edge? La replicación OCI es tu amigo. ### 🔐 3\. No Se Necesita Acceso a Git en CD En GitOps tradicional: - Tu controlador extrae (pull) de Git. - Gestionas claves SSH, PATs, tokens OAuth. - Esperas que nadie las secuestre. En Gitless GitOps: - Las herramientas de CD extraen (pull) artefactos de solo lectura, preconstruidos, desde tu registro. - No se necesitan credenciales de Git. - El acceso se gestiona a través de scopes OCI y tokens de corta duración. Tu superficie de ataque acaba de reducirse. 🎯 ### 🚀 Mejoras de Rendimiento Gitless GitOps elimina la sobrecarga del `git pull`. No más hacer checkout de repos completos. No más parsear cientos de YAMLs en cada sincronización. Obtienes un único artefacto, firmado, validado y listo para usar. Eso hace que Gitless sea rápido. Y en CD, velocidad = seguridad. ### 🔁 ¿Pero Sigue Siendo GitOps? Sí... y no. Todavía: - Mantienes un estado deseado declarado. - Confías en los controladores para aplicarlo. - Esperas que la reconciliación asegure la convergencia. Pero ya no necesitas acceso directo a Git. Entonces, ¿sigue siendo "GitOps"? - 👉 Filosóficamente: sí. - 👉 Técnicamente: Git ya no es un requisito estricto. ### 🛠️ Flux Abraza Gitless ¿Una razón más por la que FluxCD brilla? Flux tiene soporte de primera clase para artefactos OCI: - Puedes definir recursos `OCIRepository`. - Referenciarlos en `Kustomization`. - Integrar firmado, verificación, promoción. ¿ArgoCD? No tanto. El soporte es experimental, fragmentado y mayormente impulsado por la comunidad. Si hablas en serio sobre GitOps basado en OCI, Flux está millas por delante. ### 😬 Consecuencias en el Mundo Real Los equipos aman ArgoCD... hasta que algo sale mal: - Un override clickeado en la UI se desvía de Git → se reconcilia tarde → rompe producción. - Una política mal configurada permite acceso demasiado amplio. - Una plantilla se edita sin control de versiones. - Alguien piensa "es solo un campo" — y de repente tus logs desaparecen. Lo he visto. Probablemente ustedes también. ## 🛠️ Helm vs Kustomize — O Por Qué Las Plantillas Son El Tipo Incorrecto De Magia Si la batalla entre ArgoCD y Flux es sobre filosofía, entonces Helm vs Kustomize es sobre artesanía. Helm es popular. Extremadamente popular. Da a los equipos la ilusión de velocidad, reusabilidad y estructura. Pero bajo el capó... a menudo es un campo minado basado en plantillas que explota bajo presión. ¿Kustomize? Es más silencioso, más opinionado, y a veces frustrante al principio. Pero una vez que lo dominas, nunca miras atrás. Vamos a desglosarlo. ### 🧙♂️ Helm: La Ilusión de Simplicidad Helm es como los frameworks de JavaScript: Lo resuelve todo a la vez — hasta que no lo hace. - ¿Go templating en YAML? ✔️ - ¿Variables globales pasadas a través de archivos values? ✔️ - ¿Lógica condicional? ✔️ - ¿Rutas de renderizado complejas? ✔️ - ¿Debugging de YAML usando `--dry-run` y `--debug` mientras rezas? ✔️ Sí, Helm te da superpoderes. Pero vienen con un precio alto: complejidad a largo plazo. ### 🚨 Dolor en el mundo real: - Intentas añadir un flag simple a un chart. - Ese flag rompe la configuración de otro equipo. - Introduces sentencias `if` para manejar casos de uso. - De repente tienes 20 condicionales. - Alguien intenta "arreglarlo" con un subchart. - Ahora tu CI está rota y nadie sabe por qué. Y cuando falla, ¿adivina quién recibe el pager a las 2 AM? ### 🪜 Kustomize: Exigente, Pero Honesto Kustomize adopta un enfoque diferente. En lugar de renderizar plantillas, compone recursos. - Sin lógica. - Sin if/else. - Solo overlays, patches y transformers. Es declarativo de principio a fin. Esto lo hace un poco más difícil al principio — tienes que entender el modelo, planificar tu estructura, escribir tu base correctamente. ¿Pero una vez que eso está hecho? - ✨ Nunca falla de formas sorprendentes. - ✨ Puedes leerlo. - ✨ Tu sucesor puede leerlo. - ✨ Incluso un robot puede leerlo. ### 🧩 Composición vs Templating Aquí está la clave: > Las plantillas requieren interpretación. Las composiciones son solo configuración. En escenarios de respuesta a incidentes, la simplicidad salva vidas. Si alguna vez tuviste que solucionar problemas en un Helm chart con cinco condicionales anidados mientras tu SLO arde... sabes a lo que me refiero. Kustomize reduce la carga cognitiva. Puedes ejecutar `kustomize build` y ver el estado real. No hay proyección mental. Lo que ves es lo que Kubernetes obtiene. ### 😴 La Trampa de Helm: La Pereza Disfrazada de Velocidad Seamos honestos: Helm se usa en todas partes no porque sea bueno — sino porque es fácil de empezar. La mayoría de las empresas: - Crean un Helm chart "compartido" para gobernarlos a todos. - Añaden cientos de condicionales para diferentes apps. - Lo usan en todas partes hasta que se vuelve inmanejable. Luego el equipo de SRE pasa los siguientes 6 meses intentando refactorizarlo. 🧨 Pregúntate: - ¿Cuántos incidentes vinieron de cambios en Helm charts? - ¿Cuántos secretos se filtraron debido al renderizado de plantillas? - ¿Cuántos desarrolladores culparon a "Kubernetes" cuando Helm era el verdadero villano? He visto docenas de plataformas caídas por la complejidad de los Helm charts. ### 😬 YAML Ya Es Suficientemente Difícil Seamos honestos: YAML no es la idea de nadie de un formato agradable. Ahora añade Go templating, lógica sensible a la indentación y anidamiento. 🔁 ¿El resultado? Escribes YAML dentro de strings dentro de Go templates dentro de YAML. ¿Qué podría salir mal? Kustomize evita todo esto. No es sexy. Pero es limpio. ¿Y no es eso lo que todos queremos cuando estamos solucionando problemas en prod? ### ⚠️ Cuando Tienes Que Usar Helm Hay un caso de uso legítimo para Helm: cuando el vendor te da un chart y no puedes evitarlo. A veces está certificado. A veces es la única instalación soportada. A veces está tan fuertemente acoplado que escribir tus propios manifests sería una locura. Eso está bien. Pero incluso aquí, Flux vuelve a ganar. ¿Por qué? - Flux usa la librería oficial de Helm. - Flux gestiona releases de Helm de forma nativa. - Flux soporta el seguimiento adecuado de dependencias con `HelmRelease` y `HelmChart`. Mientras tanto, ArgoCD... renderiza el chart a través de `helm template` y aplica la salida. Así es: Argo en realidad no respeta la API de Helm. La simula. ### 🎻 ¿Helm Como Orquestador? No Tan Rápido… Aquí hay otro patrón peligroso: > Los equipos usan Helm no solo como un motor de plantillas — sino como un orquestador. Definen el orden de instalación, dependencias, reintentos, hooks, todo dentro de Helm. Pero aquí está el problema: - Kubernetes ya es un orquestador. - Helm ahora está orquestando recursos que también están siendo orquestados. - Terminas con reconciliación de reconciliación. Esta es una receta para drift, duplicación y confusión. ### 🤖 Orquestación GitOps Real = Operators Si necesitas orquestación — orquestación real, inteligente y consciente de dependencias — deberías estar usando operators. Los operators son ciudadanos de primera clase de Kubernetes. Exponen CRDs. Siguen el patrón controller. Respetan la lógica de convergencia. ¿Y la mejor parte? Se integran limpiamente con GitOps. Puedes declarar operator, CRDs en Git, reconciliarlos con Flux, y todo se comporta como debería. No luches contra el modelo. Abrázalo. ### 💡 Construir Operators Es Más Fácil De Lo Que Piensas ¿Tienes miedo de escribir operators? No lo tengas. Ni siquiera necesitas Go — a menos que quieras. - Prueba [Shell Operator](https://flant.github.io/shell-operator/?ref=sredevops.org) para prototipos rápidos. - Usa [Operator SDK](https://operatorframework.io/?ref=sredevops.org) para lógica de grado de producción. Un operator bien construido te permite encapsular la lógica una vez y reutilizarla de forma segura. No más hacks de Helm. No más pegamento de CLI. No más "simplemente vuelve a ejecutar el job." ## 🔐 Los Ingenieros de Plataforma Son Solo Profesionales del Pegamento — Así Que Usa Menos Pegamento Si has estado en ingeniería de plataforma por más de cinco minutos, probablemente te has dado cuenta de esto: > Nuestro verdadero trabajo no es escribir código — es eliminar el caos con estructura. Y hacemos eso pegando herramientas juntas. CI con CD. Git con infra. Secretos con apps. DNS con servicios. Pero aquí está la trampa: Cuanto más pegamento usas, más frágil se vuelve tu plataforma. ### 🧪 Cuanto Menos Pegamento, Mejor 🧠 Regla general: > El mejor pegamento es el que no necesitas. En una plataforma GitOps robusta, quieres minimizar la superposición de herramientas: - ✅ Un repositorio de Git por propósito (infra, apps, etc.) - ✅ Una CI (por ejemplo, GitHub Actions, GitLab CI) - ✅ Una CD (Flux 🤓) - ✅ Un modelo (KRM) - ✅ Una fuente de estado (Git o OCI) Cada vez que añades "solo una herramienta más" para llenar un vacío — estás introduciendo: - Una interfaz que mantener. - Una superficie de seguridad. - Un costo cognitivo. - Una nueva fuente de verdad (también conocida como un nuevo lugar para que se escondan los bugs). La ingeniería de plataforma no se trata de construir máquinas de Rube Goldberg. Se trata de componer herramientas simples de la forma más simple posible. ### 🗂️ Nombres de Namespace: Tu Primera UX Kubernetes usa namespaces. Eso no es opcional — es fundamental. Malos nombres = mala UX. Y no solo para humanos. Veamos este comportamiento de DNS: - `foo` → resuelve `foo` en el namespace actual. - `foo.bar` → resuelve `foo` en el namespace `bar`. - 👉 Eso es determinístico. - 👉 Eso es predecible. - 👉 Eso es tu amigo. Ahora, esto es lo que no debes hacer: - 🚫 `mynamespace-dev-staging-prod` - 🚫 `namespace-team1-infra-env8` ¿Por qué? - Rompe patrones estándar. - Confunde el descubrimiento. - Dificulta la automatización. - Señala que estás sobrecargando un cluster con múltiples entornos 😬. ### ☠️ Los Peligros de los Clusters Multi-Entorno Algunos equipos piensan que están ahorrando dinero poniendo dev, staging y prod en el mismo cluster. No lo están. En cambio, están pagando con: - 💥 Incidentes de seguridad. - 🔥 Despliegues accidentales. - 👻 Errores fantasma de recursos compartidos. - 🤯 Lógica de pipeline compleja. Los clusters son baratos. Los ingenieros no. Los incidentes son caros. También lo son las demandas. Usa clusters separados por entorno. Quieres: - Cluster: `prod-eu-west1` - Namespace: `payment` - App: `api-gateway` 🧭 Entonces tu ruta en Git se convierte en: `clusters/prod-eu-west1/payment/api-gateway/` Y tu KRM se aplica limpiamente: - Namespace: `payment` - Kustomization: `api-gateway` - GitPath: `clusters/prod-eu-west1/payment/api-gateway` 🧩 Es sistemático, determinístico, CI-friendly y legible para humanos. ### 🧠 Propaga las Rutas de Git a Kubernetes ¿La mejor estrategia de GitOps? > Deja que tu estructura de Git defina la estructura de tu cluster. De esa manera: - Reduces la complejidad. - Reduces los errores. - Haces imposible enrutar mal un despliegue. ¿Quieres que tu CI construya el artefacto correcto, lo suba al cluster correcto y lo aplique en el namespace correcto? - 👉 No necesitas archivos de configuración. - 👉 Necesitas rutas consistentes. Esto también habilita: - ✅ Lógica de despliegue predecible. - ✅ Observabilidad más fácil. - ✅ Mejor control de acceso. - ✅ Límites de permisos más limpios. ### 📦 El Contexto Es Rey Evita repetirte — especialmente en YAML. Usa ConfigMaps para definir primitivas base como: - `projectId` - `environment` - `region` - `sharedVPC` - `dnsZone` Deja que se propaguen a través de overlays. 📌 Decláralo una vez. Refiérelo en todas partes. De esa manera, ¿cuando tu proyecto de GCP cambia? Actualizas una línea — no 400 archivos YAML. También es tu boleto dorado para despliegues multi-región. O tu estrategia de Disaster Recovery (DR). A veces, sin darte cuenta, estás escribiendo tu Plan de Continuidad del Negocio... en YAML. De nada, CIO. 😎 ### 🧬 DRY + GitOps = Poder Si tus YAMLs están bien estructurados, con valores base comunes y overlays de entorno: - Solo defines secretos, políticas, labels, límites de recursos una vez. - Eliminas la repetición. - Eliminas la ambigüedad. - Ganas auditabilidad. Esto hace que tu plataforma sea fácil de replicar, fácil de probar y fácil de escalar. Ya sea que estés desplegando a dev, staging, prod, o eu-west2, es solo cuestión de cambiar variables de contexto. ✨ El contexto lo es todo. Trátalo como oro. ## ⚖️ Drift: El Asesino Silencioso — Por Qué La Precisión Es Un Superpoder De Ops Seamos realistas por un segundo. 🧑💻 A los desarrolladores les encanta la libertad. 🧑🔧 A los operators les encanta la predictibilidad. Ambos son válidos. Pero cuando eres responsable de ejecutar producción — la precisión lo es todo. Porque si tu definición no coincide con lo que se está ejecutando en tu cluster... 💥 Ocurre el drift. ### 💥 ¿Qué Es Drift? Drift es la diferencia entre: - Lo que crees que has desplegado (tu estado en Git), y - Lo que realmente se está ejecutando en Kubernetes. Es el duende invisible que causa: - 🔍 Pesadillas de debugging. - 🧪 Tests rotos. - 📉 Mentiras de observabilidad. - 🔄 Comportamiento inesperado después de reinicios. - 😤 Momentos de "¡Pero funcionaba ayer!". Drift es la antítesis de GitOps. Y la mayoría de los equipos ni siquiera se dan cuenta de cuánto drift tienen — hasta que es demasiado tarde. ### 🔄 ¿Por Qué Ocurre el Drift? El drift se cuela cuando: - Alguien edita un recurso en vivo a través de `kubectl` o una UI. - Un secreto se actualiza fuera de banda (out-of-band). - Un pipeline de CI aplica algo pero olvida hacer commit. - Se hacen parches manuales durante incidentes y nunca se reconcilian. - Los recursos son generados por herramientas que no hacen el viaje de vuelta (round-trip) a Git. ¿El resultado? Tu fuente de verdad ya no es... verdadera. ### 🛠️ Herramientas GitOps: Cómo Manejan el Drift Hablemos de las herramientas GitOps y su actitud hacia el drift: | **Herramienta** | **Política de Drift** | **Tipo de Reconciliación** | | --------------- | ---------------------------- | ---------------------------------------- | | Flux | ❌ No se permite drift | Event-driven, sincronización completa | | Kustomize | ❌ Sin plantillas = Sin drift | Solo declarativo | | ArgoCD | ✅ Acepta drift | Polling, detección lenta | | Helm | ✅ Tolera drift | Renderiza plantillas, no hay enforcement | | Config Sync | ❌ Previene ediciones | Enforzado con admission controller | Si valoras la confianza en tu sistema, quieres el primer grupo. Si disfrutas persiguiendo fantasmas, ve con el segundo. ### 🧠 Operators Piensan en Sistemas Aquí está la cosa: > Para los devs, el fallo suele ser sobre bugs de lógica. > Para los ops, el fallo suele ser sobre desajuste de estado (state mismatch). Los devs piensan: - "¿Por qué esta función no devuelve lo correcto?" Los ops piensan: - "¿Por qué este recurso existe en staging, pero no en prod?" - "¿Por qué este secreto es diferente de lo que está en Git?" - "¿Por qué este config map sigue aquí cuando fue eliminado hace 2 semanas?" Estos no son bugs en el código. Son bugs en la realidad de la infraestructura. ### 🎯 Precisión = Confianza En Ops, la precisión es supervivencia. - Un RoleBinding incorrecto → tu app no puede hablar con la DB. - Una regla de firewall faltante → el tráfico cae silenciosamente. - Un typo en una env var → la app crashea. - Un volumen sobrante → los costos se disparan. - Un secreto desajustado → el login falla en producción. Por eso herramientas como Flux y Kustomize importan tanto. Te dan fuertes garantías: - ✅ Lo que está en Git es lo que está en el cluster. - ✅ Sin drift. Sin sorpresas. - ✅ Sin estado misterioso. ### 🔒 Config Sync: El Martillo del Drift ¿Quieres ser aún más estricto? 🛡️ Config Sync de Google incluye un admission controller que: - Rechaza ediciones manuales a recursos declarados. - Enforza Git como la única entrada permitida. - Bloquea `kubectl apply` si no viene de Git. Este es el enfoque sin concesiones para la prevención del drift. Puede sonar rígido — pero en entornos regulados, es una bendición. ### 🎵 You Can’t Always Get What You Want… Como dirían los Rolling Stones: > “You can’t always get what you want, But if you try sometimes, you just might find... You get what you need.” Kustomize + Flux = exactamente eso. Sin ruido de templating. Sin adivinar. Sin lógica secreta de `--dry-run`. Solo infraestructura pura, declarativa — que se mantiene declarada. Eso es lo que necesitas. ## 🔗 Links y recursos útiles [Get Started with FluxGet Started with Flux.![](https://www.sredevops.org/content/images/icon/apple-touch-icon-32.png)flux-iconCreated with Sketch.Flux![](https://www.sredevops.org/content/images/thumbnail/flux-social.png)](https://fluxcd.io/flux/get-started/?ref=sredevops.org) [GitHub - fluxcd/flux2-kustomize-helm-example: A GitOps workflow example for multi-env deployments with Flux, Kustomize and Helm.A GitOps workflow example for multi-env deployments with Flux, Kustomize and Helm. - fluxcd/flux2-kustomize-helm-example![](https://www.sredevops.org/content/images/icon/pinned-octocat-093da3e6fa40-9.svg)GitHubfluxcd![](https://www.sredevops.org/content/images/thumbnail/flux2-kustomize-helm-example)](https://github.com/fluxcd/flux2-kustomize-helm-example?ref=sredevops.org) ### Cómo utilizar GitOps en modo fácil? FluxCD Operator + MCP + IA URL: https://www.sredevops.org/es/como-utilizar-gitops-en-modo-facil-fluxcd-operator-mcp-ia/ Last updated: 2026-01-08T02:36:25.000Z ¿Quieres ayuda para depurar, administrar, monitorear u obtener una comprensión más profunda de tus clústeres de Kubernetes con la ayuda de la IA y el nuevo *hype* del protocolo MCP? Basándonos en la publicación original de [Stefan Prodan @ FluxCD.io](https://fluxcd.io/blog/2025/05/ai-assisted-gitops/?ref=sredevops.org), nos sumergimos en el Servidor MCP de Flux, la más reciente creación del proyecto [Flux Operator](https://github.com/controlplaneio-fluxcd/flux-operator?ref=sredevops.org). Esto no es sólo otra herramienta; es un puente que conecta asistentes de IA (Claude, Cursor, Windsurf, GitHub Copilot, etc) directamente a tus clústeres de Kubernetes, permitiendo una interacción fluida a través de la "*magia del lenguaje natural"*. Sí, ahora puedes ~~pelear~~ interactuar con tu clúster y, sorprendentemente, lograr que las cosas se hagan. ## Llevando la IA a GitOps ¿Recuerdas los buenos tiempos de 2016 cuando la comunidad de Flux dio el puntapié inicial al movimiento GitOps? Tiempos más simples, ¿verdad? No, no me acuerdo porque no sabía mucho sobre GitOps, pero desde entonces, GitOps ha explotado en popularidad dentro del ecosistema de Kubernetes, convirtiéndose en el método preferido para administrar la infraestructura y las implementaciones de aplicaciones de forma declarativa. Pero seamos honestos, a medida que las *pipelines* de GitOps se vuelven más complejas, la gimnasia mental necesaria para solucionar problemas, descifrar las relaciones de los recursos y realizar operaciones rutinarias puede ser agotadora. Aquí entra el Servidor MCP de Flux al escenario. Al vincular los asistentes de IA tanto a tus clústeres de Kubernetes como al estado deseado que está tranquilamente en Git, empodera a los operadores para: - Depurar *pipelines* de GitOps de principio a fin, rastreando desde los recursos de Flux hasta los registros de la aplicación. - Identificar la causa raíz exacta de las implementaciones fallidas con una precisión *inquietante*. - Comparar las configuraciones de Flux y los recursos de Kubernetes entre clústeres, porque ¿quién tiene tiempo de sobra? - Visualizar las dependencias de Flux con diagramas generados directamente desde el estado del clúster. Porque una imagen vale más que mil comandos `kubectl`. - Instruir a Flux para que realice operaciones utilizando indicaciones conversacionales. Perfecto para cuando estás demasiado cansado para escribir. - Obtener la información y las recomendaciones más recientes, extraídas directamente de la documentación oficial más reciente de Flux. ## Cómo Funciona El **Servidor MCP de Flux** habla el lenguaje del **Model Context Protocol (MCP)**, ofreciendo a los asistentes de IA las herramientas que necesitan para trabajar en tus clústeres de manera efectiva. Cuando haces una pregunta ~~o ladras una orden~~, el modelo de IA utiliza estas herramientas para recopilar información, analizar configuraciones e incluso ejecutar operaciones basadas en tus caprichos. Los asistentes de IA, complementados con el Servidor MCP de Flux pueden rastrear problemas desde recursos de GitOps de alto nivel como ResourceSets, HelmReleases y Kustomizations hasta los detalles más minuciosos de las implementaciones de Kubernetes y los registros de los pods. ![Image 2: AI-Assisted GitOps with Flux](https://fluxcd.io/blog/2025/05/ai-assisted-gitops/fluxcd-ai-assisted-gitops.png) Además, el Servidor MCP permite que la IA revise la documentación de Flux, **proporcionando orientación basada en las últimas características y mejores prácticas.** ## Empezando Configurar el Servidor MCP de Flux es sorprendentemente sencillo. Escrito en Go y compilado como un único binario sin dependencias externas, está diseñado para una implementación fácil. Si eres un *aficionado* a Homebrew, puedes instalarlo con: ```zsh brew install controlplaneio-fluxcd/tap/flux-operator-mcp ``` Para aquellos que prefieren la ruta manual, pueden obtener binarios precompilados para Linux, macOS y Windows. Se pueden encontrar más detalles en la [guía de instalación](https://fluxcd.control-plane.io/mcp/install/?ref=sredevops.org). Una vez instalado, ajusta tu asistente de IA para que se lleve bien con el Servidor MCP de Flux. Para Claude, Cursor, Windsurf o GitHub Copilot, agrega este fragmento a tu configuración de MCP: ```json { "flux-operator-mcp":{ "command":"flux-operator-mcp", "args":["serve"], "env":{ "KUBECONFIG":"/path/to/.kube/config" } } } ``` No olvides cambiar `/path/to/.kube/config` con la ruta real a tu archivo kubeconfig. ## Configurando las Instrucciones de la IA Para aprovechar al máximo el Servidor MCP de Flux, debes instruir a tu asistente de IA sobre cómo interactuar con los clústeres de Kubernetes y los recursos de Flux. Estas instrucciones le dan a la IA el contexto que necesita para tomar decisiones informadas. El Servidor MCP de Flux incluye un conjunto de instrucciones predefinidas, que puedes *robar* del archivo [instructions.md](https://raw.githubusercontent.com/controlplaneio-fluxcd/distribution/refs/heads/main/docs/mcp/instructions.md?ref=sredevops.org). Es aconsejable mejorar estas instrucciones con detalles específicos de tus clústeres, tales como: - Detalles de la distribución de Kubernetes (EKS, GKE, AKS, etc.) - Servicios específicos de la nube integrados con tus clústeres - Tipos de aplicaciones implementadas - Enfoques de gestión de secretos Para obtener un tutorial detallado sobre cómo configurar estas instrucciones con diferentes asistentes de IA, consulta la sección [AI Instructions](https://fluxcd.control-plane.io/mcp/prompt-engineering/?ref=sredevops.org#ai-instructions) de la documentación. ## Aplicaciones Prácticas Exploremos algunos escenarios del mundo real donde el Servidor MCP de Flux puede hacer tu vida de GitOps más fácil: ### 1\. Evaluación Rápida del Estado Sáltate el desfile interminable de comandos `kubectl` y `flux` y simplemente pregunta: > Analiza la instalación de Flux en mi clúster actual e informa el estado de todos los componentes y ResourceSets. ![Image 3](https://fluxcd.io/blog/2025/05/ai-assisted-gitops/flux-mcp-cluster-state.png) Tu asistente de IA recopilará la información necesaria sobre tu instalación del Operador de Flux, los controladores y los recursos administrados, entregando un informe de estado completo. ### 2\. Visualización de la *Pipeline* de GitOps Comprender las laberínticas relaciones entre los recursos de GitOps puede ser una pesadilla. El Servidor MCP de Flux simplifica esto: > Enumera los Kustomizations de Flux y dibuja un diagrama de Mermaid para la relación "depends on". ![Image 4](https://fluxcd.io/blog/2025/05/ai-assisted-gitops/flux-mcp-diagram.png) La IA creará una representación visual de tu *pipeline* de GitOps, destacando las relaciones de dependencia entre los Kustomizations de Flux, ayudándote a comprender el orden de implementación y los posibles cuellos de botella. ### 3\. Comparaciones Entre Clústeres Comparar las configuraciones entre múltiples entornos suele ser una tarea tediosa. Pero con el Servidor MCP de Flux: > Compara el HelmRelease de podinfo entre los clústeres de producción y *staging*. ![Image 5](https://fluxcd.io/blog/2025/05/ai-assisted-gitops/flux-mcp-diff.png) La IA cambiará de contexto, recopilará los datos y destacará las diferencias entre los dos entornos. ### 4\. Análisis de la Causa Raíz (root cause) Cuando las implementaciones fracasan, encontrar al culpable puede sentirse como encontrar a Wally: > Realiza un análisis de la causa raíz de la última Helm release fallida en el *namespace* frontend. El asistente de IA rastreará las dependencias, verificará el estado de los recursos, analizará los registros y entregará un *post-mortem* detallado explicando qué salió mal y cómo solucionarlo. ### 5\. Operaciones de GitOps Incluso puedes ejecutar operaciones de GitOps usando *lenguaje natural*: > Reanuda todos los recursos de Flux suspendidos en el clúster actual y verifica su estado. La IA identificará los recursos suspendidos, los revivirá e informará sobre los resultados. ### 6\. Operaciones de Kubernetes El Servidor MCP de Flux permite operaciones complejas de Kubernetes con instrucciones simples: > Crea un *namespace* llamado test, luego copia el Helm release de podinfo y su fuente. Cambia los valores de Helm para que el *ingress* sea test.podinfo.com La IA generará y aplicará los recursos de Kubernetes necesarios, gestionando las complejidades de crear *namespaces*, clonar Helm releases y ajustar los valores de configuración, todo desde una única solicitud conversacional. ## Consideraciones de Seguridad ☢️ Dado que esta herramienta interactúa con tus clústeres, la seguridad debe ser una preocupación importante. El Servidor MCP de Flux tiene los siguientes riesgos a considerar: - Opera con tus permisos existentes de kubeconfig. - Admite la suplantación de cuentas de servicio para un acceso limitado. - Enmascara la información confidencial en los valores de Kubernetes Secret. - Proporciona un modo de solo lectura para la observación sin afectar el estado del clúster. Para una inmersión más profunda en la configuración de seguridad, consulta la [guía de configuración](https://fluxcd.control-plane.io/mcp/config/?ref=sredevops.org). ## El Futuro de GitOps Asistido por IA El Servidor MCP de Flux todavía está en su fase experimental, y se está refinando activamente en función de los comentarios de los usuarios y las aplicaciones del mundo real. Las mejoras futuras incluyen: - Integración con Kubernetes metrics-server y otras herramientas de observabilidad - Capacidades de búsqueda de documentación mejoradas - Capacidades de resolución de problemas más avanzadas - Soporte para el lanzamiento/retroceso escalonado de aplicaciones en todos los clústeres Tus comentarios son invaluables, así que comparte tus ideas en [GitHub Discussions](https://github.com/fluxcd/flux2/discussions/5352?ref=sredevops.org). [AI-Assisted GitOps with Flux Operator MCP ServerBridging the gap between AI assistants and GitOps pipelines![](https://www.sredevops.org/content/images/icon/apple-touch-icon-31.png)flux-iconCreated with Sketch.Flux![](https://www.sredevops.org/content/images/thumbnail/featured-image.png)](https://fluxcd.io/blog/2025/05/ai-assisted-gitops/?ref=sredevops.org) ### Amazon Apuesta Fuerte por Chile: Una Inversión de $4 Mil Millones en Infraestructura Cloud URL: https://www.sredevops.org/es/amazon-apuesta-fuerte-por-chile-una-inversion-de-4-mil-millones-en-infraestructura-cloud/ Last updated: 2026-01-08T02:36:25.000Z Amazon Web Services (AWS) está haciendo un movimiento significativo en Sudamérica, destinando la friolera de $4 mil millones para construir sus centros de datos e infraestructura cloud inaugurales en Chile. Según Reuters, esta inversión subraya la creciente demanda de servicios cloud en la región y el posicionamiento estratégico de Amazon para capitalizarla. ## AWS Expande su Presencia en Latinoamérica La decisión de AWS de establecer una región cloud en Chile marca su tercera incursión en Latinoamérica, siguiendo los pasos de Brasil y México. Juan Pablo Estevez, el jefe local de AWS, reveló en una entrevista que se han asegurado todos los permisos necesarios, allanando el camino para que el proyecto entregue una potencia informática sustancial, particularmente para aplicaciones de IA generativa. - Se espera que esté operativo en la segunda mitad de 2026. - Tiene como objetivo proporcionar una potencia informática significativa para servicios como la IA generativa. - Se une a Brasil y México como la tercera región cloud de AWS en Latinoamérica. ## Centros de Datos, Sequías y Equilibrios Delicados La proliferación de centros de datos en todo el mundo ha desatado un debate considerable sobre su consumo de energía y agua, cuestiones que son particularmente sensibles en Chile, una nación que lidia con una sequía prolongada que abarca más de 15 años. Consideraciones ambientales obligaron previamente a Google a revisar sus planes para un centro de datos de $200 millones en Chile después de que un tribunal ambiental local revocara parcialmente su permiso. Esto establece un escenario desafiante para AWS, enfatizando la necesidad de prácticas sostenibles. Microsoft anticipa que su centro de computación cloud Azure en Chile estará operativo este año. Esto significa un panorama competitivo donde la responsabilidad ambiental y el avance tecnológico deben coexistir. - Aborda las preocupaciones sobre el uso de energía y agua en Chile, afectado por la sequía. - Destaca la importancia de las prácticas sostenibles en las operaciones de los centros de datos. - Sigue los planes revisados del centro de datos de Google debido a preocupaciones ambientales. ## Las Promesas Verdes de Amazon Estevez aseguró que la región cloud de Amazon limitaría su uso de agua para enfriar los servidores a solo el 4% del año, empleando tecnologías de aire y evaporación para el resto. Se dice que esto es equivalente al consumo de agua de aproximadamente ocho hogares durante un período de 15 años. Además, Amazon afirma haber igualado el 100% de su consumo de energía con energía renovable desde 2023, mostrando un compromiso con la sostenibilidad. - Promete un uso limitado de agua, confiando en tecnologías de aire y evaporación. - Se compromete a igualar el 100% de su consumo de energía con energía renovable desde 2023. - Tiene como objetivo aliviar las preocupaciones ambientales asociadas con las operaciones de los centros de datos. ## Alcance Global e Impacto Local Amazon opera actualmente 36 regiones y 114 availability zones en todo el mundo, atendiendo a una clientela diversa, incluyendo Netflix, General Electric y Sony, para necesidades de almacenamiento, networking y seguridad remota. En Chile, importantes actores como Cencosud, MercadoLibre y varias empresas mineras ya aprovechan los servicios regionales de Amazon. Esta adopción local subraya el potencial para un mayor crecimiento e innovación en la región. A pesar de que las previsiones de ingresos e ingresos cloud de Amazon en el primer trimestre no cumplieron con las expectativas, Estevez se mantiene optimista sobre el fuerte crecimiento en Chile y en toda la región. - Expande la red global de Amazon de 36 regiones y 114 availability zones. - Tiene como objetivo servir a clientes existentes como Netflix, General Electric y Sony. - Se dirige a empresas chilenas locales como Cencosud, MercadoLibre y empresas mineras. ## El Futuro es Cloud, Con una Posibilidad de Crecimiento Estevez proyecta un robusto crecimiento del mercado del 20.3% año tras año en Chile desde ahora hasta 2028, estimando que el mercado se expandirá de $1.5 mil millones el año pasado a $1.0\. Si bien parece haber un error tipográfico en la estimación (probablemente $1.0 mil millones este año y creciendo), la perspectiva general sigue siendo positiva. La inversión de $4 mil millones de Amazon en Chile significa una fuerte creencia en el potencial de la región y un compromiso para impulsar los avances tecnológicos al tiempo que se abordan las preocupaciones ambientales. Queda por ver si pueden cumplir esas promesas, pero por ahora, el panorama cloud de Chile se ve mucho más interesante. Artículo original de Fabián Andrés Cambero - [Reuters](https://www.reuters.com/?ref=sredevops.org) [https://finance.yahoo.com/news/amazon-spend-4-billion-cloud-131253222.html](https://finance.yahoo.com/news/amazon-spend-4-billion-cloud-131253222.html?ref=sredevops.org) ### Universal blue es Linux en tu escritorio pero evolucionado con patrones cloud-native y con una comunidad activa URL: https://www.sredevops.org/es/universal-blue-es-linux-en-tu-escritorio-pero-evolucionado-con-patrones-cloud-native-y-con-una-comunidad-activa/ Last updated: 2026-01-16T02:21:31.000Z > ¿La idea central? Tomar los patrones probados en batalla del mundo *cloud-native* – específicamente, imágenes base inmutables del SO construidas como contenedores – y aplicarlos al escritorio. Es ospechosamente como alguien intentando arreglar el escritorio Linux... otra vez. Pero esperen, esta vez involucra contenedores, palabras de moda *cloud-native*, y una dosis saludable de "¿y si realmente aprendiéramos algo del lado del servidor?" Estamos hablando de [Universal Blue](https://universal-blue.org/?ref=sredevops.org), un proyecto liderado por el siempre apasionado Jorge Castro (quizás lo conozcan por su pega diaria gestionando comunidades en la [CNCF/Linux Foundation](https://www.cncf.io/?ref=sredevops.org)). Recientemente, se sentó a conversar con Alan Pope de [Anchore](https://anchore.com/?ref=sredevops.org) (sí, la gente detrás de esas geniales herramientas de escaneo de seguridad, [Syft](https://github.com/anchore/syft?ref=sredevops.org) y [Gripe](https://github.com/anchore/grype?ref=sredevops.org)) para una charla que desentrañó las capas de esta ambiciosa iniciativa. Y créanme, es más que solo otro fondo de pantalla bonito sobre Fedora. *(Basado en la entrevista de Anchore Community Spotlight:* [*Universal Blue revolutionizes the Linux desktop experience*](https://www.youtube.com/watch?v=XpKFcLqbd-A&ref=sredevops.org)*)* ## Tantos Nombres, Tan Poco Tiempo: ¿Qué Cresta es Universal Blue? Primero, los nombres. Universal Blue, Bluefin, Bazzite, Kite... suena como una bandada de pájaros de colores extraños que escaparon de una conferencia tecnológica. Jorge admite, con las mejores intenciones, que comenzó de forma algo... egoísta. Al migrar desde Ubuntu después de años en Canonical, quería construir *su* escritorio ideal, Bluefin (el de los dinosaurios – más sobre eso después). Piensen en "Ubuntu, pero si hubiera seguido el camino que *yo* quería". Ah, el eterno sueño del desarrollador. Pero construir el castillo de escritorio perfecto requiere cimientos. Esto llevó a descomponer la idea en imágenes base – el "caldo base" – que se convirtió en Universal Blue (Ublue). El nombre en sí es un guiño a Fedora Silverblue y quizás un juego de palabras descarado ("You Blue It!"). ¿La idea central? Tomar los patrones probados en batalla del mundo *cloud-native* – específicamente, imágenes base inmutables del SO construidas como contenedores – y aplicarlos al escritorio. ## Abandonando la Edad de Piedra: ¿Patrones Cloud-Native en tu Laptop? ¿Recuerdan los viejos tiempos? Instalar una distro, `apt update && apt upgrade`, rezar para que nada se rompa, instalar manualmente software de fuentes cuestionables, ajustar archivos de configuración hasta que salga humo, y llamar al desastre resultante "mi configuración". En el lado del servidor, (mayormente) superamos ese caos con contenedores, configuraciones declarativas y automatización. Sin embargo, el escritorio a menudo se sentía atascado en 1999. Universal Blue aprovecha [bootc](https://github.com/osbuild/bootc?ref=sredevops.org), permitiéndote construir imágenes de SO booteables usando herramientas de contenedores como Docker o Podman. 1. **Imagen Base:** Comienza con una base sólida, como Fedora. 2. **Magia Dockerfile:** Agrega tus personalizaciones, paquetes, fondos de pantalla, lo que sea, usando instrucciones estándar de `Dockerfile` (`RUN dnf install ...`, `COPY ./mi-wallpaper.png /usr/share/wallpapers/`, etc.). 3. **Construcción (Build):** Ejecuta `podman build` o `docker build`. 4. **Resultado:** Una imagen compatible con OCI que contiene un SO completo, kernel y todo, lista para ser desplegada y booteada en *bare metal* (fierro). Es como construir cualquier otro contenedor, excepto que este *es* tu sistema operativo. ## Inmutabilidad: "¡No Puedes Tocar Esto!" (Mayormente) Aquí viene la parte donde los usuarios tradicionales de Linux podrían empezar a ponerse nerviosos. Las imágenes Ublue, siguiendo el modelo de Fedora Kinoite/Silverblue, tienen un `/usr` inmutable. Los archivos centrales del SO son de solo lectura. "¡Pero mi libertad!" te escucho gritar. "¡*Necesito* editar `/usr/share/systemd/system/mi-precioso.service` directamente como root!" Para el carro, Stallman. - **/etc es Escribible:** Tus archivos de configuración están sanos y salvos, listos para tus ajustes expertos (o no tan expertos). - **Separación de Responsabilidades:** El SO es un artefacto. Tu configuración está separada. Tus datos (¡y aplicaciones!) están separados. Al igual que en la nube, las actualizaciones del SO base no pisotean tu entorno cuidadosamente diseñado (generalmente). Las aplicaciones se instalan típicamente a través de Flatpaks, contenedores Distrobox u otros medios, manteniéndolas desacopladas del sistema base. **Hay una Forma Correcta™:** ¿Recuerdas `systemd`? En realidad, tiene mecanismos para sobrescribir archivos de unidad (*unit files*) sin tocar los originales. En lugar de `sudo nano /usr/lib/systemd/system/apache2.service`, usarías: ```bash sudo systemctl edit apache2.service ``` BashEste comando copia la unidad original a `/etc/systemd/system`, abre tu editor, te permite hacer cambios, los guarda de forma segura en la parte escribible del sistema de archivos y recarga el servicio. El archivo original permanece intacto. Resulta que, a veces, las herramientas *sí* proporcionan un camino menos destructivo, incluso si lo ignoramos durante años. No se trata de bloquearte; se trata de crear un sistema más confiable, predecible y recuperable. Las actualizaciones se convierten en reemplazos atómicos de imágenes, no en una delicada danza de dependencias de paquetes. ¿Rollbacks? Pan comido. ## Desktop DevOps: Gestionando Flotas de Uno (o Muchos) ¿Recuerdan cómo las distros tradicionales a menudo definen "comunidad" como "las pobres almas que brindan soporte técnico gratuito en los foros"? Universal Blue le da la vuelta a esto adoptando lo que Jorge llama el patrón "Desktop DevOps". La comunidad Ublue no son solo usuarios; incluye contribuidores que gestionan los *pipelines* de construcción, prueban actualizaciones y aseguran que el "despliegue" (la imagen del SO que ejecutan los usuarios) sea estable. Las actualizaciones se prueban en el *pipeline* (a menudo *builds* diarios que incorporan las últimas actualizaciones de Fedora) antes de ser enviadas a los usuarios, frecuentemente con una cadencia semanal. ![ ```mermaid graph LR A[Actualizaciones Fedora] --> B(GitHub Actions: Build Imagen Base); B --> C{Imagen Base Ublue}; C --> D(GitHub Actions: Build Bluefin); C --> E(GitHub Actions: Build Bazzite); C --> F(GitHub Actions: Otros Spins...); D --> G[Usuarios Bluefin]; E --> H[Usuarios Bazzite]; F --> I[Otros Usuarios]; ```](https://www.sredevops.org/content/images/2025/05/universal-blue-mermaid.png) Es como gestionar un despliegue de Kubernetes, pero para escritorios. Cuando Fedora 41 necesita convertirse en Fedora 42 para los usuarios, el equipo de Ublue maneja esa transición en segundo plano a través de GitHub Actions, entregando un producto terminado y probado. No más "Ok, 10.000 usuarios, ejecuten `dnf system-upgrade` simultáneamente... ¡buena suerte!" ## Más Allá de la Base: Spins para Todos (Especialmente Gamers y Devs) La belleza del enfoque de imagen base es su extensibilidad. Cualquiera puede tomar una imagen base Ublue y construir su propia experiencia encima. - [**Bluefin**](https://universal-blue.org/images/bluefin/?ref=sredevops.org)**:** La visión original de Jorge, adaptada para desarrolladores (especialmente los *cloud-native*). Busca proporcionar un entorno familiar y productivo, incluyendo incluso herramientas como [Homebrew](https://brew.sh/?ref=sredevops.org) (sí, de verdad) para facilitar la transición a los usuarios de Mac. Más sobre la experiencia del desarrollador a continuación. - [**Bazzite**](https://universal-blue.org/images/bazzite/?ref=sredevops.org)**:** La estrella revelación, enfocada completamente en el *gaming*. Creada por Kyle (`ky` en Discord), integra parches y drivers (como los del Steam Deck), optimizaciones y utilidades de juego útiles listas para usar (*out-of-the-box*). ¿El objetivo? Instalarlo y jugar Halo, no pasar horas ajustando cosas. Proporciona una experiencia de juego consistente en escritorios, laptops y consolas portátiles. - [**Blues TWENTY-FIVE**](https://github.com/ublue-os/blues-twenty-five?ref=sredevops.org)**:** La prueba de que los nerds siempre serán nerds. Alguien tomó XFCE, le puso una *skin* para que se viera *exactamente* como Windows 95 (¿o era 2000?), y lo empaquetó como un *spin* de Ublue. ¿Porque por qué no? Este modelo hace que la creación de "spins" especializados sea significativamente más fácil que convertirse en una variante oficial de una distro tradicional, fomentando la innovación y atendiendo a comunidades de nicho. ## La Experiencia del Desarrollador: ¿Puedo Tener Mis Herramientas? Ok, los desarrolladores somos mañosos. Tenemos nuestros flujos de trabajo, nuestras herramientas sagradas, nuestros `dotfiles` cuidadosamente construidos. ¿Cómo satisface Ublue a esta multitud exigente, especialmente a aquellos acostumbrados a macOS o configuraciones tradicionales de Linux? - **Prioridad Cloud-Native:** El objetivo son a menudo desarrolladores ya familiarizados con contenedores y patrones de nube. Ellos *cachan* la inmutabilidad y la contenerización. Muchos son usuarios de Mac que son expertos en Linux bajo el capó pero evitan la experiencia tradicional del escritorio Linux. - **Docker & Podman:** Ambos están disponibles *out-of-the-box*. Sin tener que dar saltos mortales. Copia y pega ese comando del `README.md`, y probablemente funcione. - **Homebrew:** ¿Controversial? Quizás. ¿Útil? Absolutamente. Proporciona acceso a un vasto ecosistema de herramientas familiares para los desarrolladores de Mac. Se trata de encontrarse con los desarrolladores donde están. - [**Distrobox**](https://github.com/89luca89/distrobox?ref=sredevops.org)**:** Tu vía de escape. ¿Necesitas un entorno Ubuntu para probar algo o ejecutar una herramienta específica? `distrobox-create -n miubuntu -i ubuntu:22.04` y `distrobox enter myubuntu`. Boom, tienes un entorno de contenedor Ubuntu integrado, completo con acceso a tu directorio home y aplicaciones gráficas. ¿Necesitas Arch? ¿Debian? Fácil. - **Dev Containers:** El enfoque recomendado. Define el entorno de desarrollo de tu proyecto dentro del repositorio Git del proyecto (`.devcontainer/devcontainer.json`). Cualquiera, en cualquier SO (Ublue, Mac, Windows), puede clonar el repo, abrirlo en un editor compatible (como VS Code), y obtener exactamente el mismo entorno consistente. - **Herramientas Modernas:** Ublue a menudo incluye herramientas de vanguardia como `uv` (el instalador/resolvedor rápido de Python) o `pixi` porque los mantenedores están inmersos en estas comunidades y saben lo que está de moda. La filosofía es menos sobre forzar una única forma verdadera y más sobre proporcionar cimientos robustos (base immutable, contenedores) y herramientas flexibles (Homebrew, Distrobox, Dev Containers) para permitir que los desarrolladores construyan *su* flujo de trabajo preferido encima. ## Seguridad: SBOMs, Escáneres y Cadenas de Automatización Con imágenes construidas diariamente y desplegadas automáticamente, la seguridad es primordial. Aquí es donde la conexión con Anchore se vuelve crucial. - **La Automatización es Clave:** Ublue depende en gran medida de [GitHub Actions](https://github.com/features/actions?ref=sredevops.org) para construir, probar y desplegar imágenes. El bot Renovate vigila los lanzamientos *upstream* de Fedora, desencadenando reconstrucciones que se propagan en cascada a través de las imágenes dependientes. - **Generación de SBOM:** Usan [Syft](https://github.com/anchore/syft?ref=sredevops.org) de Anchore para generar Listas de Materiales de Software (SBOMs) para sus imágenes durante el proceso de construcción. Inicialmente, esto añadía un tiempo significativo, por lo que lo optimizaron para ejecutarse solo en el *merge/push* final, no en cada *build* de PR. ¡La velocidad del desarrollador importa! - **Escaneo de Vulnerabilidades:** El siguiente paso lógico, que Alan demostró durante la charla, es usar [Gripe](https://github.com/anchore/grype?ref=sredevops.org) para escanear el SBOM (o la imagen directamente) en busca de vulnerabilidades conocidas. Gripe puede generar un informe SARIF. - **El Problema del "¿Y Ahora Qué?":** Jorge señala cándidamente el desafío de la industria: Ok, tienes un SBOM. ¿Y ahora qué? ¿Cómo correlacionas esa lista de componentes con información de CVE en tiempo real y perspectivas accionables? Herramientas como Gripe y *dashboards* integrados son pasos en la dirección correcta, pero todavía queda trabajo por hacer. Ublue aspira a ser transparente, eventualmente mostrando estas métricas públicamente. **Integración con GitHub:** Este informe SARIF se puede subir de nuevo a GitHub, poblando la pestaña "Security" -> "Code scanning" en el repositorio. Esto hace que las vulnerabilidades sean visibles directamente dentro de la interfaz de usuario de GitHub, en lugar de estar enterradas en logs o archivos JSON. ```yaml # Pasos de ejemplo en un workflow de GitHub Action - name: Generar SBOM uses: anchore/syft-action@v0 with: image: ${{ steps.build-image.outputs.image }} # Tu imagen construida format: spdx-json output: image.spdx.json - name: Escanear Vulnerabilidades uses: anchore/grype-action@v3 with: sbom: ./image.spdx.json # O usar 'image: ${{ steps.build-image.outputs.image }}' fail-build: false # No fallar el build, solo reportar output-format: sarif output-file: results.sarif - name: Subir informe SARIF uses: github/codeql-action/upload-sarif@v2 with: sarif_file: results.sarif ``` YAML ## Dinosaurios, Ecosistemas y la Próxima Generación ¿Por qué los dinosaurios en Bluefin? Jorge adopta una visión casi antropológica del *open source*. Es un ecosistema, muy parecido a la Tierra prehistórica. - **Los Proyectos Evolucionan:** Algunos proyectos prosperan, algunos compiten, algunos colaboran, algunos se extinguen (son archivados). - **La Gente Importa:** Se trata de computación distribuida *y* gente distribuida. La salud no se trata solo de código; se trata del *burnout* de los contribuidores, las dinámicas comunitarias y la sostenibilidad. Los dinosaurios son una metáfora visual de este ecosistema complejo, a veces brutal, pero finalmente interconectado. - **Una Mazmorra para Principiantes (*Starter Dungeon*):** Ublue aspira a ser un punto de entrada accesible, una "mazmorra para principiantes" para la gente que aprende sobre Linux, contenedores y contribución al *open source*. Se mantiene intencionalmente simple (Bash, un poco de Python) para bajar la barrera de entrada. - **Atrayendo Sangre Nueva:** El proyecto ha atraído con éxito a un grupo demográfico más joven, particularmente a través de Bazzite. Estos recién llegados están aprendiendo, experimentando (a veces yéndose por tangentes salvajes, lo que Jorge ve como parte del proceso), e incluso siendo contratados por empresas como Chainguard basándose en sus contribuciones. Se trata de fomentar la *próxima* generación de contribuidores de *open source*. ## La Conclusión Universal Blue no es solo otra distribución de Linux. Es un *enfoque* con opinión para construir, entregar y gestionar un escritorio Linux, tomando prestado fuertemente de las mejores prácticas *cloud-native*. Prioriza la confiabilidad, la automatización y la seguridad a través de patrones de inmutabilidad y contenedores, al tiempo que ofrece flexibilidad para los desarrolladores y experiencias especializadas para usuarios como los *gamers*. Adopta el modelo "Desktop DevOps", tratando el SO como un producto desplegado continuamente gestionado por una comunidad enfocada en el *pipeline* de entrega. Al integrar herramientas como Syft y Gripe, están abordando la seguridad de la cadena de suministro de software (*software supply chain*) de frente, apuntando a la transparencia y la gestión proactiva de vulnerabilidades. ¿Es para el tradicionalista acérrimo que insiste en compilar todo desde el código fuente y editar `/usr` a mano? Probablemente no. ¿Es una forma potencialmente más robusta, manejable y segura de ejecutar Linux en el escritorio para desarrolladores, *gamers*, y quizás incluso tus padres? Ciertamente lo parece. ¿Quieres aprender más o involucrarte? - **Sitio Web de Universal Blue:** [https://universal-blue.org/](https://universal-blue.org/?ref=sredevops.org) - **GitHub:** [https://github.com/ublue-os](https://github.com/ublue-os?ref=sredevops.org) - **Discord:** (Enlace disponible en su sitio web) Siempre están buscando ayuda, especialmente con cosas como mejorar la documentación, las pruebas y la integración de herramientas de seguridad (como esa genial acción de CVE que mostró Alan). Anda a echarle un vistazo. Podrías encontrar tu próximo hogar en Linux, o al menos una visión fascinante del futuro del escritorio. ### kgateway: An amazing tool to simplify traffic management using Kubernetes API Gateway URL: https://www.sredevops.org/en/kgateway-an-amazing-tool-to-simplify-traffic-management-using-kubernetes-api-gateway/ Last updated: 2025-12-10T01:05:29.000Z Kgateway is a feature-rich, fast, and flexible Kubernetes-native ingress controller and next-generation API gateway. Built on top of the robust [Envoy proxy](https://www.envoyproxy.io/?ref=sredevops.org) and the Kubernetes Gateway API, Kgateway acts as a reverse proxy, providing a crucial security barrier between your clients and the microservices that constitute your application. ## Kgateway's Superpowers Kgateway isn't just another API gateway; it's fully compliant with the Kubernetes Gateway API and extends its functionality with custom Gateway APIs like `RoutePolicies`, `ListenerPolicies`, and `Backends`. These resources allow for centralized configuration of advanced traffic management, security, and resiliency rules for an `HTTPRoute` or Gateway listener. In simpler terms, Kgateway gives you more control and flexibility over how traffic flows through your Kubernetes cluster. ![](https://www.sredevops.org/content/images/2025/03/image.png) ## Extensions and integrations The kgateway project offers a range of extensions on top of the Kubernetes Gateway API, enabling advanced routing, security, and resiliency capabilities. Some of these extensions include: - [Access logging Security](https://kgateway.dev/docs/security/access-logging/?ref=sredevops.org): Keep tabs on who's accessing what. - [AWS ALB and NLB Traffic](https://kgateway.dev/docs/setup/customize/aws-elb/?ref=sredevops.org): Seamlessly integrate with AWS load balancers. - [AWS Lambda Traffic](https://kgateway.dev/docs/traffic-management/destination-types/backends/lambda?ref=sredevops.org): Route traffic to serverless functions. - [Buffering Traffic](https://kgateway.dev/docs/traffic-management/buffering/?ref=sredevops.org): Manage traffic spikes like a pro. - [Delegation Traffic](https://kgateway.dev/docs/traffic-management/route-delegation/?ref=sredevops.org): Delegate routing decisions for more granular control. - [Direct responses Traffic](https://kgateway.dev/docs/traffic-management/direct-response/?ref=sredevops.org): Send direct responses without hitting a backend. - [Gateway customization Setup](https://kgateway.dev/docs/setup/customize/?ref=sredevops.org): Tailor the gateway to your specific needs. - [Integrations Setup](https://kgateway.dev/docs/integrations/?ref=sredevops.org): Integrate with other tools and services. - [Mirroring Resiliency](https://kgateway.dev/docs/resiliency/mirroring/?ref=sredevops.org): Mirror traffic for testing and debugging. - [Transformations Traffic](https://kgateway.dev/docs/traffic-management/transformations/?ref=sredevops.org): Modify requests and responses on the fly. ## Default Gateway Proxy Setup: The Magic Behind the Scenes When you create a Kubernetes Gateway resource, Kgateway automatically spins up, bootstraps, and manages gateway proxy deployments. This magic is achieved through a combination of Kgateway and Kubernetes resources, including `GatewayClass`, `GatewayParameters`, and a gateway proxy template that includes the Envoy configuration for each proxy. For a deeper dive into the default setup and how these resources interact, check out the [Default gateway proxy setup](https://kgateway.dev/docs/setup/default/?ref=sredevops.org). **Example of a `GatewayClass`:** ```yaml apiVersion: gateway.networking.k8s.io/v1 kind: GatewayClass metadata: name: kgateway spec: controllerName: kgateway.dev/kgateway description: KGateway Controller parametersRef: group: gateway.kgateway.dev kind: GatewayParameters name: kgateway namespace: kgateway-system ``` ## Deployment Patterns: Choose how to route your traffic Kgateway's flexibility allows you to deploy it in a way that best suits your environment. Here are some recommended deployment patterns: ### Simple Ingress: The Classic Approach ![Kgateway as a simple ingress](https://kgateway.dev/img/pattern-simple-ingress.svg) In this setup, a single Kgateway proxy serves as the ingress API gateway for all workloads in a Kubernetes cluster. It's centrally managed by the Kgateway control plane and configured to match and forward traffic based on your defined rules. This is a great starting point for smaller environments where all workloads run in a single cluster. ### Sharded Gateway: Divide and Conquer ![Kgateway as a sharded gateway](https://kgateway.dev/img/pattern-sharded-gateway.svg) For larger environments or those with both high and low traffic services, a sharded gateway can help isolate services and protect against noisy neighbors. Multiple gateway proxies split the traffic for different services, providing better load balancing and isolation. ### Sharded Gateway with Central Ingress: The Best of Both Worlds ![Sharded gateway with central ingress](https://kgateway.dev/img/pattern-central-ingress-gloo.svg) This pattern combines a central ingress gateway proxy with a second layer of sharded gateway proxies. The central gateway applies common traffic management, resiliency, and security rules, while the second layer handles traffic for specific apps, teams, or namespaces. This is ideal if you need a central IP address and DNS name for the gateway that serves all your traffic. Kgateway can also be paired with other proxy types, such as HAProxy or AWS NLB/ALB, as your central ingress endpoint. ![Central ingress with any proxy](https://kgateway.dev/img/pattern-central-ingress-any.svg) ### API Gateway for a Service Mesh: Istio Ambient Mesh Integration ![API gateway for Istio ambient mesh](https://kgateway.dev/img/ambient-ingress.svg) Kgateway can be deployed as an ingress, egress, or waypoint proxy gateway for workloads in an Istio ambient mesh. This allows you to leverage Kgateway's features within your service mesh environment. For more details, refer to the guides for using Kgateway as an [ingress](https://kgateway.dev/docs/integrations/istio/ambient/ambient-ingress/?ref=sredevops.org) or [waypoint proxy](https://kgateway.dev/docs/integrations/istio/ambient/waypoint/?ref=sredevops.org) for your ambient mesh. ## Kubernetes Gateway API Success with kgateway Kgateway is a powerful and versatile tool for managing traffic in your Kubernetes environment. Whether you're running a small cluster or a large, complex infrastructure, Kgateway provides the features and flexibility you need to ensure secure, reliable, and efficient communication between your services. So, go ahead and give Kgateway a try – your microservices will thank you! ## Learn more [kgatewayKgateway is a feature-rich, fast, and flexible API gateway that is built on top of Envoy proxy and the Kubernetes Gateway API. It excels in function-level routing, supports legacy apps, microservices and serverless, offers robust discovery capabilities, integrates seamlessly with open-source projects, and is designed to support hybrid applications with various technologies, architectures, protocols, and clouds.![](https://www.sredevops.org/content/images/icon/apple-touch-icon-29.png)![](https://www.sredevops.org/content/images/thumbnail/use-case-security.svg)](https://kgateway.dev/?ref=sredevops.org) [WelcomeKgateway is a feature-rich, fast, and flexible API gateway that is built on top of Envoy proxy and the Kubernetes Gateway API. It excels in function-level routing, supports legacy apps, microservices and serverless, offers robust discovery capabilities, integrates seamlessly with open-source projects, and is designed to support hybrid applications with various technologies, architectures, protocols, and clouds.![](https://www.sredevops.org/content/images/icon/apple-touch-icon-30.png)![](https://www.sredevops.org/content/images/thumbnail/logo.svg)](https://kgateway.dev/docs/?ref=sredevops.org) ### Kiss Goodbye to QEMU: Unleash the Power of Native GitHub Runners for Multi-Arch Docker Images URL: https://www.sredevops.org/en/kiss-goodbye-to-qemu-unleash-the-power-of-native-github-runners-for-multi-arch-docker-images/ Last updated: 2025-09-02T03:55:51.000Z In the cutthroat world of DevOps, where speed and efficiency are the holy grail, building multi-architecture Docker images used to be a pain in the neck. But hold on tight! With the advent of native GitHub runners, you can finally ditch the quirky QEMU emulation and embrace the lightning speed of native builds. This guide will take you by the hand and lead you through the dark arts of setting up a multi-architecture build process using GitHub Actions. [GitHub - sredevopsorg/multi-arch-docker-github-workflow: How to build a Multi-Architecture Docker Image in Github Actions using multiple runners without QEMUHow to build a Multi-Architecture Docker Image in Github Actions using multiple runners without QEMU - sredevopsorg/multi-arch-docker-github-workflow![](https://www.sredevops.org/content/images/icon/pinned-octocat-093da3e6fa40-6.svg)GitHubsredevopsorg![](https://opengraph.githubassets.com/996c34e08b586b609dd111813a8f11643d2566f95dfdb1c182e7f92fce70c372/sredevopsorg/multi-arch-docker-github-workflow)](https://github.com/sredevopsorg/multi-arch-docker-github-workflow?ref=sredevops.org) ## Overview: The Two-Headed Beast This workflow is like a two-headed beast, split into two main jobs: ### Build Job: The Workhorse - **Matrix Strategy:** This bad boy builds images for each platform separately, like a well-oiled machine. - **Docker Context and Buildx Setup:** Configures the native builds, so you don't have to mess with QEMU. - **GHCR Login and Push:** Uploads the image by its unique digest, keeping things tidy. - **Artifact Export:** Saves the digest for later use, because we're smart like that. ### Merge Job: The Brain - **Digest Download:** Retrieves the digests from the build job, like a detective gathering clues. - **Metadata Generation:** Ensures consistency with the built images, because we like things neat. - **Multi-Arch Manifest Creation:** Combines the images into a single, powerful manifest. - **Manifest Push:** Uploads everything to GHCR, enabling Docker to magically select the correct image based on architecture. This two-step process results in a "fat" image – a monstrous creation that delivers the right binary for any user's architecture, no questions asked. ## Features: The Cool Stuff - **Native Builds:** We're using GitHub's native runners, so say adios to QEMU and its shenanigans. - **Multi-Arch Manifest:** Merges per-architecture images into one, because we're efficient like that. - **Build Caching:** Speeds up subsequent builds, because who has time to wait? - **OCI Metadata:** Enhances image provenance with labels and annotations, making your images look professional. - **Concurrency Control:** Cancels outdated builds using GitHub Actions concurrency, keeping things clean and tidy. ## Getting Started: Let's Roll Up Our Sleeves ### Prerequisites: What You Need - A GitHub public repository (because the arm64 runners are picky and only work with public repos). - A valid Dockerfile in the repository root, ready to be built. ### Setup: The Nitty-Gritty 1. Fork the Repository and edit the [multi-build.yaml](https://github.com/sredevopsorg/multi-arch-docker-github-workflow/blob/main/.github/workflows/multi-build.yaml?ref=sredevops.org) file. 2. **Review and Customize:** - **Dockerfile:** Tweak it to suit your application's dark desires. - **Workflow File:** Adjust the parameters in `.github/workflows/multi-build.yaml` as needed. ## A Step-by-Step Detailed Explanation: The Gory Details ### File: [multi-build.yaml](https://github.com/sredevopsorg/multi-arch-docker-github-workflow/blob/main/.github/workflows/multi-build.yaml?ref=sredevops.org) Let's dissect this beast, shall we? ```yaml name: Build multi arch Docker Image with separate Github Runners on: workflow_dispatch: push: branches: - main paths: - 'Dockerfile' - '.github/workflows/multi-build.yaml' env: GHCR_IMAGE: ghcr.io/${{ github.repository }} #(...) ``` - This workflow is a masterpiece that builds a multi-arch Docker image using GitHub Actions. It leverages separated GitHub Runners with native support for ARM64 and AMD64 architectures, completely avoiding the dreaded QEMU emulation. - It uses Docker Buildx, a powerful tool, to build and push the image to the GitHub Container Registry (GHCR). - `GHCR_IMAGE`: Defines the name of the Docker image to be built and pushed to GHCR. The image name is cleverly derived from the GitHub repository name and the GHCR URL, resulting in a format like `ghcr.io/owner/repo`. ```yaml # (...) permissions: contents: read concurrency: group: ${{ github.workflow }}-${{ github.ref }} cancel-in-progress: true #(...) ``` - `permissions`: Sets global permissions for the workflow. These can be overridden at the job level if needed. - `concurrency`: This ensures that only one job in the group runs at a time. If a new job is triggered, the previous one is mercilessly canceled. ```yaml # (...) jobs: build: strategy: fail-fast: false matrix: platform: - linux/amd64 - linux/arm64 permissions: attestations: write actions: read checks: write contents: write deployments: none id-token: write issues: read discussions: read packages: write pages: none pull-requests: read repository-projects: read security-events: read statuses: read #(...) ``` - `build`: This job is the workhorse, building the Docker image for each platform specified in the matrix. - `matrix`: Defines the platforms: `linux/amd64` and `linux/arm64`. The build job will run for each of these platforms. - `permissions`: Sets specific permissions for the build job, allowing it to write to GHCR and read from the repository. ```yaml # (...) runs-on: ${{ matrix.platform == 'linux/amd64' && 'ubuntu-latest' || matrix.platform == 'linux/arm64' && 'ubuntu-24.04-arm' }} #(...) ``` - `runs-on`: This cleverly selects the appropriate runner based on the platform: - For `linux/amd64`, it uses the latest Ubuntu runner. - For `linux/arm64`, it uses an Ubuntu 24.04 ARM runner. ```yaml # (...) name: Build Docker image for ${{ matrix.platform }} steps: - name: Prepare environment for current platform id: prepare run: | platform=${{ matrix.platform }} echo "PLATFORM_PAIR=${platform//\//-}" >> $GITHUB_ENV - name: Checkout uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2 - name: Docker meta default id: meta uses: docker/metadata-action@902fa8ec7d6ecbf8d84d538b9b233a880e428804 # v5.7.0 with: images: ${{ env.GHCR_IMAGE }} #(...) ``` - The `prepare` step sets up the environment for the current platform. It replaces '/' in the platform name with '-' and sets it as an environment variable (`PLATFORM_PAIR`). This is useful for naming artifacts and other resources that can't handle '/'. - `Checkout`: This step uses `actions/checkout@v4.2.2` to clone the repository into the runner's workspace. - `Docker meta default`: This step uses `docker/metadata-action@v5.7.0` to generate metadata for the Docker image, including the image name, tags, and labels. This metadata will be used later for building and pushing the image. ```yaml # (...) - name: Set up Docker Context for Buildx id: buildx-context run: | docker context create builders - name: Set up Docker Buildx uses: docker/setup-buildx-action@b5ca514318bd6ebac0fb2aedd5d36ec1b5c232a2 # v3.10.0 with: endpoint: builders platforms: ${{ matrix.platform }} - name: Login to GitHub Container Registry # This step logs in to the GitHub Container Registry (GHCR) using the docker/login-action. # It uses the GitHub actor's username and the GITHUB_TOKEN secret for authentication. uses: docker/login-action@74a5d142397b4f367a81961eba4e8cd7edddf772 # v3.4.0 with: registry: ghcr.io username: ${{ github.actor }} password: ${{ secrets.GITHUB_TOKEN }} #(...) ``` - `Set up Docker Context for Buildx`: Creates a new context named "builders" for Buildx, allowing it to use the Docker daemon for building images. - `Set up Docker Buildx`: Configures Buildx (`docker/setup-buildx-action@v3.10.0`) with the specified context and platforms. - `Login to GitHub Container Registry`: Logs in to GHCR using `docker/login-action@v3.4.0` with the GitHub actor's username and the `GITHUB_TOKEN` secret. ```yaml # (...) - name: Build and push by digest id: build uses: docker/build-push-action@471d1dc4e07e5cdedd4c2171150001c434f0b7a4 # v6.15.0 env: DOCKER_BUILDKIT: 1 with: context: . platforms: ${{ matrix.platform }} labels: ${{ steps.meta.outputs.labels }} annotations: ${{ steps.meta.outputs.annotations }} outputs: type=image,name=${{ env.GHCR_IMAGE }},push-by-digest=true,name-canonical=true,push=true,oci-mediatypes=true cache-from: type=gha,scope=${{ github.repository }}-${{ github.ref_name }}-${{ matrix.platform }} cache-to: type=gha,scope=${{ github.repository }}-${{ github.ref_name }}-${{ matrix.platform }} #(...) ``` - `Build and push by digest`: This is where the magic happens. It uses `docker/build-push-action@v6.15.0` to build the image with the specified context and platforms. The image is built with the labels and annotations generated earlier. - `outputs`: Configures the action to push the image by digest, enabling better caching and versioning. - `cache-from` and `cache-to`: Enable caching for the build process, storing the cache in GitHub Actions cache and scoping it to the repository, branch, and platform. ```yaml # (...) - name: Export digest run: | mkdir -p /tmp/digests digest="${{ steps.build.outputs.digest }}" touch "/tmp/digests/${digest#sha256:}" - name: Upload digest uses: actions/upload-artifact@4cec3d8aa04e39d1a68397de0c4cd6fb9dce8ec1 # v4.6.1 with: name: digests-${{ env.PLATFORM_PAIR }} path: /tmp/digests/* if-no-files-found: error retention-days: 1 #(...) ``` - `Export digest`: Creates a directory `/tmp/digests` and saves the digest of the built image to a file. The digest uniquely identifies the built image. - `Upload digest`: Uploads the digest file to GitHub Actions artifact storage using `actions/upload-artifact@v4.6.1`. The artifact is named `digests-${{ env.PLATFORM_PAIR }}` and is retained for 1 day. ```yaml # (...) merge: name: Merge Docker manifests runs-on: ubuntu-latest permissions: attestations: write actions: read checks: read contents: read deployments: none id-token: write issues: read discussions: read packages: write pages: none pull-requests: read repository-projects: read security-events: read statuses: read needs: - build steps: - name: Download digests uses: actions/download-artifact@cc203385981b70ca67e1cc392babf9cc229d5806 # v4.1.9 with: path: /tmp/digests pattern: digests-* merge-multiple: true ``` - `merge`: This job merges the Docker manifests for the different platforms built in the previous job. - `needs: - build`: Ensures that the `build` job completes successfully before starting. - `Download digests`: Downloads the digest files uploaded in the `build` job using `actions/download-artifact@v4.1.9`. The files are merged into the `/tmp/digests` directory. ```yaml - name: Docker meta id: meta uses: docker/metadata-action@902fa8ec7d6ecbf8d84d538b9b233a880e428804 # v5.7.0 with: images: ${{ env.GHCR_IMAGE }} annotations: | type=org.opencontainers.image.description,value=${{ github.event.repository.description || 'No description provided' }} tags: | type=raw,value=main,enable=${{ github.ref_name == 'main' }} type=raw,value=latest,enable=${{ github.ref_name == 'main' }} - name: Set up Docker Buildx uses: docker/setup-buildx-action@b5ca514318bd6ebac0fb2aedd5d36ec1b5c232a2 # v3.10.0 with: driver-opts: | network=host - name: Login to GitHub Container Registry uses: docker/login-action@74a5d142397b4f367a81961eba4e8cd7edddf772 # v3.4.0 with: registry: ghcr.io username: ${{ github.actor }} password: ${{ secrets.GITHUB_TOKEN }} - name: Get execution timestamp with RFC3339 format id: timestamp run: | echo "timestamp=$(date -u +"%Y-%m-%dT%H:%M:%SZ")" >> $GITHUB_OUTPUT ``` - `Docker meta`: Generates metadata for the Docker image using `docker/metadata-action@v5.7.0`. - `Set up Docker Buildx`: Sets up Buildx again (`docker/setup-buildx-action@v3.10.0`). - `Login to GitHub Container Registry`: Logs in to GHCR (`docker/login-action@v3.4.0`). - `Get execution timestamp with RFC3339 format`: Gets the current UTC time in RFC3339 format for annotating the Docker manifest list. ```yaml - name: Create manifest list and pushs working-directory: /tmp/digests id: manifest-annotate continue-on-error: true run: | docker buildx imagetools create \ $(jq -cr '.tags | map("-t " + .) | join(" ")' <<< "$DOCKER_METADATA_OUTPUT_JSON") \ --annotation='index:org.opencontainers.image.description=${{ github.event.repository.description }}' \ --annotation='index:org.opencontainers.image.created=${{ steps.timestamp.outputs.timestamp }}' \ --annotation='index:org.opencontainers.image.url=${{ github.event.repository.url }}' \ --annotation='index:org.opencontainers.image.source=${{ github.event.repository.url }}' \ $(printf '${{ env.GHCR_IMAGE }}@sha256:%s ' *) - name: Create manifest list and push without annotations if: steps.manifest-annotate.outcome == 'failure' working-directory: /tmp/digests run: | docker buildx imagetools create $(jq -cr '.tags | map("-t " + .) | join(" ")' <<< "$DOCKER_METADATA_OUTPUT_JSON") \ $(printf '${{ env.GHCR_IMAGE }}@sha256:%s ' *) - name: Inspect image id: inspect run: | docker buildx imagetools inspect '${{ env.GHCR_IMAGE }}:${{ steps.meta.outputs.version }}' ``` - `Create manifest list and push`: Creates a manifest list for the Docker images built for different platforms using `docker buildx imagetools create`. The manifest list is annotated with metadata and pushed to GHCR. - `Create manifest list and push without annotations`: If the previous step fails, this step creates the manifest list without annotations and pushes it to GHCR. - `Inspect image`: Inspects the created manifest list using `docker buildx imagetools inspect` to verify its contents. There you have it! A complete, step-by-step guide to building multi-arch Docker images like a pro, using native GitHub Runners and leaving QEMU in the dust. Now go forth and conquer the world of multi-architecture deployments! [GitHub - sredevopsorg/multi-arch-docker-github-workflow: How to build a Multi-Architecture Docker Image in Github Actions using multiple runners without QEMUHow to build a Multi-Architecture Docker Image in Github Actions using multiple runners without QEMU - sredevopsorg/multi-arch-docker-github-workflow![](https://www.sredevops.org/content/images/icon/pinned-octocat-093da3e6fa40-7.svg)GitHubsredevopsorg![](https://www.sredevops.org/content/images/thumbnail/multi-arch-docker-github-workflow)](https://github.com/sredevopsorg/multi-arch-docker-github-workflow?ref=sredevops.org) ### SkyPilot: How to run AI models and workloads easily on any infra and save money too URL: https://www.sredevops.org/en/skypilot-how-to-run-ai-models-and-workloads-easily-on-any-infra-and-save-money-too/ Last updated: 2025-03-12T20:37:17.000Z ## What the Heck is SkyPilot? SkyPilot is like a universal remote control, but instead of flipping through channels of reality TV garbage, it manages your cloud infrastructure. Think Kubernetes clusters, cloud VMs, and even that dusty old server in your closet – all working together in a beautiful, chaotic symphony orchestrated for your AI workloads. It's designed to make your life easier, especially if you're dealing with the ever-growing demands of Artificial Intelligence. Because, let's face it, AI is hungry, and it needs a *lot* of compute power. ![](https://github.com/skypilot-org/skypilot/blob/eda46ed6a0ce715853e46f415c91822d4142d6e0/docs/source/images/skypilot-abstractions-long-2.png?raw=true) SkyPilot offers a simplified interface using three core concepts: - **Clusters**: The basic building blocks. Think of them as groups of VMs or Kubernetes pods. - **Jobs**: The actual programs you want to run. Like "train this ridiculously large language model." - **Services**: For serving your AI models, because what's the point of having a fancy AI if no one can use it? These abstractions cover the entire AI lifecycle, from initial development and training to finetuning, hyperparameter optimization, and serving. Basically, everything but making the coffee (though, with enough GPUs, you could probably train an AI to do that too). ## Why Bother with SkyPilot? (Besides Avoiding Cloud-Induced Headaches) SkyPilot has some sweet benefits that might just make you reconsider your current, probably overly complicated, setup: ### Unified Execution (Because Juggling Clouds is for Clowns, Not Engineers) No matter how many clouds, regions, or clusters you're dealing with, SkyPilot provides a single, unified interface. You tell it what you want to run, and it figures out the messy details of where and how. It's like having a really efficient, slightly sarcastic, personal assistant for your cloud infrastructure. ### Cost and Capacity Optimization (Save Money, Buy More GPUs... or Pizza) SkyPilot automatically picks the cheapest and most available infrastructure for your workload. It's like a bargain hunter for compute resources, constantly sniffing out the best deals. So you can spend less time worrying about your cloud bill and more time, you know, actually doing science (or whatever it is you do). ### Auto-Failover (Because Stuff Happens, Especially in the Cloud) You can give SkyPilot a list of infrastructure options, from "anywhere in the world" to "that specific server rack in Antarctica." If one option is unavailable (because, let's face it, cloud providers aren't perfect), SkyPilot automatically tries the next best choice. It's like having a backup plan for your backup plan, but without all the manual configuration. ### No Cloud Lock-in (Freedom! ... Sort Of) Adding new clouds, regions, or clusters later on? No problem. Your existing workloads can easily run on them without any major code changes or existential dread. SkyPilot embraces the [Sky Computing](https://docs.skypilot.co/en/latest/sky-computing.html?ref=sredevops.org#concept-sky-computing) vision, which basically means "play nice with all the clouds." ## Digging Deeper: Clusters, Jobs, and Services Let's break down those core concepts a bit further: ### Clusters: Your Virtual Compute Playground A *cluster* is SkyPilot's fundamental resource unit. It can be one or more VMs or Kubernetes pods, all hanging out in the same location. Think of it as your dedicated workspace for a particular task. You launch a cluster using the `sky launch` command. Yes, it's that simple. ```shell $ sky launch $ sky launch --gpus L4:8 $ sky launch --num-nodes 10 --cpus 32+ $ sky launch --down cluster.yaml $ sky launch --help # See all the glorious options. ``` Or, if you prefer Python: ```python import sky task = sky.Task().set_resources(sky.Resources(accelerators='L4:8')) sky.launch(task, cluster_name='my-cluster') ``` With a cluster, you can: - SSH into any node (because sometimes you just need to get your hands dirty). - Connect your favorite IDE (VSCode or whatever floats your boat). - Submit and queue a bunch of jobs. - Set it to automatically shut down to save those precious cloud dollars. - Launch and manage many ephemeral clusters (because who needs permanence anyway?). You can even bring your own Docker or VM image, or use SkyPilot's defaults, which are surprisingly sensible and handle things like CUDA versions for you. Remember, a SkyPilot cluster is *virtual*. It's a collection of resources carved out from the *physical* clusters you provide (either Kubernetes clusters or your own machines). For more info, check out the [quickstart](https://skypilot.readthedocs.io/en/latest/getting-started/quickstart.html?ref=sredevops.org) and [dev-cluster](https://docs.skypilot.co/en/latest/examples/interactive-development.html?ref=sredevops.org#start-a-development-cluster) documentation. ### Jobs: Getting Stuff Done (Without the Manual Labor) A *job* is simply the program you want to run. SkyPilot supports two main types: - **Jobs on Clusters**: Use `sky exec`. These jobs run on an existing cluster and reuse its setup. Good for interactive development and debugging. - **Managed Jobs**: Use `sky jobs launch`. These jobs get their own temporary cluster and have auto-recovery. Perfect for those long-running, fault-tolerant tasks, especially on spot instances (which are like the clearance rack of cloud computing). A job can contain one or [more](https://docs.skypilot.co/en/latest/examples/managed-jobs.html?ref=sredevops.org#managed-pipelines) *tasks*, but usually, it's just one. #### Jobs on Clusters: The Interactive Approach `sky exec` is your friend for running jobs on an existing cluster. ```bash sky exec my-cluster --gpus L4:1 --workdir=. -- python train.py sky exec my-cluster train.yaml # YAML is your friend. # Fractional GPUs? No problem! sky exec my-cluster --gpus L4:0.5 -- python eval.py # Multi-node? Sure, why not? sky exec my-cluster --num-nodes 2 -- hostname ``` Or, in Python: ```python # Assuming 'my-cluster' is already up and running. # Queue a job with 1 GPU. train = sky.Task(run='python train.py').set_resources( sky.Resources(accelerators='L4:1')) train = sky.Task.from_yaml('train.yaml') # Load from YAML, because typing is hard. sky.exec(train, cluster_name='my-cluster') # Queue a job with half a GPU. eval = sky.Task(run='python eval.py').set_resources( sky.Resources(accelerators='L4:0.5')) sky.exec(eval, cluster_name='my-cluster') ``` Check out the [job-queue](https://docs.skypilot.co/en/latest/reference/cli.html?ref=sredevops.org#sky-queue) documentation for more details. #### Managed Jobs: Set It and Forget It (Mostly) *Managed jobs* handle the messy details of provisioning a temporary cluster and recovering from failures. They use a lightweight jobs controller for monitoring and recovery. `sky jobs launch` is the command you need. These are great for running jobs on spot instances (save up to 6x on costs!), or for scaling to many parallel jobs. The recommended workflow: develop and debug interactively with clusters, then use managed jobs for large-scale runs. ### Services: Sharing Your AI Genius with the World A *service* is for serving your AI models. It can have multiple replicas, spread across different locations, pricing models, or even GPU types. Because redundancy is good, and options are even better. Check out [sky-serve](https://skypilot.readthedocs.io/en/latest/serving/sky-serve.html?ref=sredevops.org) to get started. ## Bringing Your Own Infrastructure (BYOI... Almost) SkyPilot plays nicely with your existing infrastructure: clouds, Kubernetes clusters, or even those on-premise machines you've been meaning to clean. It uses each infrastructure's native authentication (cloud credentials, kubeconfig, SSH). ### Cloud VMs: The Usual Suspects SkyPilot can launch VMs on most major cloud providers. Run `sky check` to see if you're good to go. ![SkyPilot Supported Clouds](https://github.com/skypilot-org/skypilot/blob/eda46ed6a0ce715853e46f415c91822d4142d6e0/docs/source/images/cloud-logos-dark.png?raw=true) See [cloud-account-setup](https://docs.skypilot.co/en/latest/cloud-setup/cloud-permissions/index.html?ref=sredevops.org#minimal-cloud-permissions) for details. You can even set up specific roles and permissions for SkyPilot, if you're into that sort of thing. ### Kubernetes Clusters: Container Orchestration Goodness Bring your existing Kubernetes clusters (managed or on-prem) into the SkyPilot fold. Auto-failover between multiple clusters is supported, because who needs single points of failure? ![](https://github.com/skypilot-org/skypilot/blob/eda46ed6a0ce715853e46f415c91822d4142d6e0/docs/source/images/k8s-skypilot-architecture-light.png?raw=true) ![](https://github.com/skypilot-org/skypilot/blob/eda46ed6a0ce715853e46f415c91822d4142d6e0/docs/source/images/k8s-skypilot-architecture-dark.png?raw=true) See [kubernetes-overview](https://docs.skypilot.co/en/latest/reference/kubernetes/index.html?ref=sredevops.org#using-kubernetes). ### Existing Machines: Dust Off Those Old Servers Got a bunch of machines with IP addresses you can SSH into? Bring them into SkyPilot! ![](https://github.com/skypilot-org/skypilot/blob/eda46ed6a0ce715853e46f415c91822d4142d6e0/docs/source/images/sky-existing-infra-workflow-light.png?raw=true) ![](https://github.com/skypilot-org/skypilot/blob/eda46ed6a0ce715853e46f415c91822d4142d6e0/docs/source/images/sky-existing-infra-workflow-dark.png?raw=true) See [Using Existing Machines](https://docs.skypilot.co/en/latest/reservations/existing-machines.html?ref=sredevops.org). ## SkyPilot's Secret Sauce: Cost and Capacity Optimization Whenever SkyPilot needs to provision resources, it automatically optimizes for cost and capacity. It's like a built-in accountant that's always looking for the best deal. For example, if you need a cluster with 8 A100 GPUs, SkyPilot will try all the options in your specified search space, starting with the cheapest and most available, and automatically failing over if needed: ![](https://blog.skypilot.co/ai-on-kubernetes/images/failover.png) This means no more worrying about specific infrastructure details, manual retries, or complicated setups. You get more GPU capacity and save money. It's a win-win! You can define the search space for each workload, making it as broad or specific as you like. Examples: - "Use the cheapest GPU from this set: `{A10g:8, A10:8, L4:8, A100:8}`" - "Use my Kubernetes cluster or any cloud I have access to" - "Give me a spot or on-demand H100 GPU" - "Only use AWS's European regions" - "Use this specific zone, region, or cloud" See [auto-failover](https://docs.skypilot.co/en/latest/examples/auto-failover.html?ref=sredevops.org#cross-cloud-failover) for the nitty-gritty details. ## Local or Team Deployment: Choose Your Adventure SkyPilot can be used locally or deployed as a centralized API server for your team. Team deployment lets you share and manage resources across multiple users: - **Deploy Once, Use Anywhere**: Deploy the SkyPilot API server in Kubernetes or on a cloud VM and access it from anywhere. - **Resource Sharing**: Team members can share resources, because sharing is caring (and efficient). - **Easy Onboarding**: New members can run SkyPilot commands without setting up their own cloud credentials. - **Global View and Control**: Admins get a single dashboard to monitor all the team's resources. This article is an enhanced version of the original documentation, which can be found at [SkyPilot Documentation](https://docs.skypilot.co/en/latest/docs/index.html?ref=sredevops.org). [Welcome to SkyPilot! — SkyPilot documentation![](https://www.sredevops.org/content/images/icon/favicon-9.ico).st0{clip-path:url(#SVGID\_2\_);} .st1{fill:#372F8A;} .st2{fill:#195D7F;} .st3{fill:#39A4DD;} .st4{fill:var(--logo-text-color);}![](https://www.sredevops.org/content/images/thumbnail/SkyPilot_wide_dark.svg)](https://docs.skypilot.co/en/latest/docs/index.html?ref=sredevops.org) ### Kubernetes v1.32.3 is alive!: A brief lookup over the changelog and new features URL: https://www.sredevops.org/en/kubernetes-v1-32-3-is-alive-a-brief-lookup-over-the-changelog-and-new-features/ Last updated: 2025-03-12T14:40:29.000Z So, Kubernetes v1.32.3 is out. It's not a *major* release, more like a "patch release" or a collection of bug fixes and minor improvements. For the average user, it's the equivalent of cleaning up your desk - necessary, but not exactly thrilling. But for those of us who live and breathe Kubernetes, even the smallest changes can be, dare I say, *interesting*? Let's dive into this digital janitorial work. ## API Changes: The Cost of (Mis)Estimation - **DRA and CEL Shenanigans:** Dynamic Resource Allocation (DRA) had a bit of a hiccup. Common Expression Language (CEL) expressions using attribute strings were exceeding their cost limits. Why? Because the cost estimation was, to put it mildly, *incomplete*. They also unnecessarily computed this in the scheduler. Think of it like ordering a pizza, assuming it'll cost $10, and then being hit with a $50 bill because they forgot to factor in the cost of, I don't know, *cheese*. This has now been fixed. - **Reference:** [#129690](https://github.com/kubernetes/kubernetes/pull/129690?ref=sredevops.org) - **Author:** [@pohly](https://github.com/pohly?ref=sredevops.org) - **SIG:** Node ## Bug Fixes and Regressions: The "Oops, We Broke It" Section This release is mostly about fixing things that were unintentionally broken in previous versions (regressions). It's like Kubernetes developers are playing a game of whack-a-mole with bugs. - **Ordered Namespace Deletion:** A new feature gate, `OrderedNamespaceDeletion`, has been added. When enabled, it ensures that pods are deleted *before* other resources during namespace deletion. This improves workload security. You know, because deleting things in the wrong order can lead to... chaos. - **Reference:** [#130508](https://github.com/kubernetes/kubernetes/pull/130508?ref=sredevops.org) - **Author:** [@cici37](https://github.com/cici37?ref=sredevops.org) - **SIG:** API Machinery, Apps, and Testing - **`register-gen` Import Issues:** A minor, but crucial fix. Some necessary imports for `k8s.io/apimachinery/pkg/runtime` and `k8s.io/apimachinery/pkg/runtime/schema` were missing in `register-gen`. It's like forgetting to include the flour when baking a cake. - **Reference:** [#130392](https://github.com/kubernetes/kubernetes/pull/130392?ref=sredevops.org) - **Author:** [@mrIncompetent](https://github.com/mrIncompetent?ref=sredevops.org) - **SIG:** API Machinery - **Websocket Connection Stability (1.30+ Regression):** If you were using websockets for `exec`, `attach`, or `portforward` requests and experienced connection instability since v1.30, this release fixes that. Because dropping connections mid-operation is *never* fun. - **Reference:** [#130253](https://github.com/kubernetes/kubernetes/pull/130253?ref=sredevops.org) - **Author:** [@fuweid](https://github.com/fuweid?ref=sredevops.org) - **SIG:** API Machinery, CLI, and Testing - **`postStart` Hook Regression (1.32 Regression):** Pods with `postStart` hooks were having trouble starting in v1.32\. This is now fixed. It's like a car that refuses to start *after* you've already turned the key. - **Reference:** [#130496](https://github.com/kubernetes/kubernetes/pull/130496?ref=sredevops.org) - **Author:** [@sreeram-venkitesh](https://github.com/sreeram-venkitesh?ref=sredevops.org) - **SIG:** Node - **Node Status and Certificate Renewal Regression (1.32 Regression):** Nodes were sometimes failing to report their status and renew serving certificates after a kubelet restart in v1.32\. This has been addressed. Imagine a worker who stops reporting to work and lets their ID badge expire. Not ideal. - **Reference:** [#130356](https://github.com/kubernetes/kubernetes/pull/130356?ref=sredevops.org) - **Author:** [@aojea](https://github.com/aojea?ref=sredevops.org) - **SIG:** Node - **`kube-apiserver` Authentication Flag Regression (1.32+ Regression):** `kube-apiserver` had an issue validating that OIDC and anonymous authentication flags were mutually exclusive. Also, the `/flagz` endpoint wasn't responding correctly. This release fixes both problems. - **Reference:** [#130332](https://github.com/kubernetes/kubernetes/pull/130332?ref=sredevops.org) - **Author:** [@richabanker](https://github.com/richabanker?ref=sredevops.org) - **SIG:** API Machinery and Testing - **`kube-proxy` UDP CPU Consumption:** `kube-proxy`, when dealing with UDP services and External or LoadBalancer IPs, was consuming excessive CPU. It was like a bouncer checking the ID of *everyone* entering a club, even those who weren't going to the VIP section (the specific service port). It's now more selective. - **Reference:** [#130505](https://github.com/kubernetes/kubernetes/pull/130505?ref=sredevops.org) - **Author:** [@aojea](https://github.com/aojea?ref=sredevops.org) - **SIG:** Network - **`kube-proxy` UDP Memory Leak (1.32 Regression):** Clusters with lots of UDP traffic were potentially experiencing a memory leak in `kube-proxy` in v1.32\. This has been plugged. - **Reference:** [#130034](https://github.com/kubernetes/kubernetes/pull/130034?ref=sredevops.org) - **Author:** [@aroradaman](https://github.com/aroradaman?ref=sredevops.org) - **SIG:** Network - **`kubeadm` Panic Fix:** `kubeadm` would panic if no `UpgradeConfiguration` was found in the config file. Now it handles this situation more gracefully. Because panicking is rarely the best solution. - **Reference:** [#130313](https://github.com/kubernetes/kubernetes/pull/130313?ref=sredevops.org) - **Author:** [@neolit123](https://github.com/neolit123?ref=sredevops.org) - **SIG:** Cluster Lifecycle - **Consistent List Performance Regression (1.31+ Regression):** Rapid create/update API requests across different namespaces were experiencing increased latency due to the `ConsistentListFromCache` feature. This performance regression has been addressed. - **Reference:** [#130136](https://github.com/kubernetes/kubernetes/pull/130136?ref=sredevops.org) - **Author:** [@AwesomePatrol](https://github.com/AwesomePatrol?ref=sredevops.org) - **SIG:** API Machinery - **RBAC `Watch` Permissions Added:** Several core Kubernetes controllers have had the `Watch` permission added to their respective roles. This is a security enhancement, ensuring controllers have the necessary permissions to monitor resources. - **Controllers:** `cronjob-controller`, `endpoint-controller`, `endpointslice-controller`, `endpointslicemirroring-controller`, `horizontal-pod-autoscaler`, `node-controller`, `pod-garbage-collector`, `storage-version-migrator-controller` - **Reference:** [#130461](https://github.com/kubernetes/kubernetes/pull/130461?ref=sredevops.org) - **Author:** [@kariya-mitsuru](https://github.com/kariya-mitsuru?ref=sredevops.org) - **SIG:** Auth ## Dependency Changes: The Under-the-Hood Stuff - **`github.com/vishvananda/netlink` Updated:** The `netlink` library has been updated. This is a low-level networking library, so most users won't directly notice this change. But it's crucial for the underlying plumbing of Kubernetes. - **Old Version:** b1ce50c - **New Version:** 62fb240 - **Reference:** [https://github.com/vishvananda/netlink/compare/b1ce50c...62fb240](https://github.com/vishvananda/netlink/compare/b1ce50c...62fb240?ref=sredevops.org) ## Conclusion: Keep Calm and `kubectl apply` Kubernetes v1.32.3 is a maintenance release, focusing on stability and fixing regressions. While not as flashy as a major feature release, it's essential for keeping your clusters running smoothly. So, update your clusters, and rest easy knowing that the Kubernetes community is constantly working to squash bugs and improve performance. Or, you know, just keep doing what you're doing. It's your cluster. This changelog analysis was brought to you by the Kubernetes project, with the help of tireless open-source contributors. Original changelog available at [GitHub](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.32.md?ref=sredevops.org). [kubernetes/CHANGELOG/CHANGELOG-1.32.md at master · kubernetes/kubernetesProduction-Grade Container Scheduling and Management - kubernetes/kubernetes![](https://www.sredevops.org/content/images/icon/pinned-octocat-093da3e6fa40-5.svg)GitHubkubernetes![](https://www.sredevops.org/content/images/thumbnail/kubernetes)](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.32.md?ref=sredevops.org#downloads-for-v1323) ### Coder: Low cost, self hosted Cloud Development Environments URL: https://www.sredevops.org/en/coder-low-cost-self-hosted-cloud-development-environments/ Last updated: 2025-03-11T18:33:13.000Z Coder is an open-source platform that allows organizations to define and manage development environments within their own public or private cloud infrastructure. Think of it as a way to create standardized, reproducible, and scalable development workspaces in the cloud. Instead of developers painstakingly setting up their local machines (and inevitably running into "it works on my machine" issues), Coder provisions consistent environments using Infrastructure-as-Code (IaC). It's like having a well-stocked, perfectly organized workshop for each developer, accessible from anywhere. If your current development environment setup feels like a chaotic, untamed junkyard, Coder might just be the Marie Kondo of your workflow. ## Quickstart The fastest way to get your hands dirty with Coder is to install it locally and play around with Docker-based development environments. This works across Linux, macOS, and even Windows (yes, even Windows developers deserve nice things). ```bash # First, install Coder. It's like magic, but with more typing. curl -L https://coder.com/install.sh | sh # Start the Coder server. This is where the fun begins. coder server # Open your browser and go to http://localhost:3000. # Create a user, a Docker template, and provision a workspace. # You're basically a cloud wizard now. ``` ## Installation The recommended installation method is the install script (for Linux and macOS). Windows users can grab the latest `..._installer.exe` from the GitHub Releases page. ```shell # This one-liner is all you need for Linux and macOS. curl -L https://coder.com/install.sh | sh ``` If you're the cautious type (or just curious), use `--dry-run` to see what the script *would* do without actually doing it. Use `--help` for even more options. > See [install](https://coder.com/docs/install?ref=sredevops.org) for alternative installation methods, because we all love options. For a production deployment, a single command gets you started: ```bash # This sets up an external access URL on *.try.coder.app. Easy peasy. coder server # If you're feeling fancy and have a PostgreSQL database (v13+), use this: coder server --postgres-url --access-url ``` `coder --help` is your friend for a full list of flags and environment variables. The [install guides](https://coder.com/docs/install?ref=sredevops.org) provide detailed, step-by-step instructions, because sometimes we all need a little hand-holding. ## Documentation The Coder documentation is your bible, your guiding light, your source of truth. Find it [here](https://coder.com/docs?ref=sredevops.org). Here's a quick rundown of the key sections: ### Templates [Templates](https://coder.com/docs/templates?ref=sredevops.org) are the blueprints for your workspaces. They're written in Terraform (so you can version control them, collaborate on them, and generally feel like a responsible adult). These templates describe the infrastructure, like EC2 instances, Kubernetes Pods, or Docker containers. Think of it as defining the recipe for your perfect development environment. ### Workspaces [Workspaces](https://coder.com/docs/workspaces?ref=sredevops.org) are the actual instances of your development environments. They contain the IDEs, dependencies, and all the configuration details a developer needs to start coding. No more "dependency hell," just a clean, consistent environment. ### IDEs [IDEs](https://coder.com/docs/ides?ref=sredevops.org) You can connect your favorite editor to a Coder workspace. Whether you're a VS Code aficionado, a JetBrains devotee, or still clinging to Vim (we respect that), Coder has you covered. ### Administration [Administration](https://coder.com/docs/admin?ref=sredevops.org) This section is for the folks who keep the lights on. Learn how to manage and operate Coder, because with great power comes great responsibility (and the occasional troubleshooting session). ### Premium [Premium](https://coder.com/pricing?ref=sredevops.org#compare-plans): For larger teams, Coder offers paid features. Think of it as the enterprise-grade version, with extra bells and whistles. ## Support Stuck? Found a bug? Have a brilliant feature idea? [Open an issue](https://github.com/coder/coder/issues/new?ref=sredevops.org). The Coder team is there to help (and they're surprisingly friendly). [Join the Coder Discord](https://discord.gg/coder?ref=sredevops.org) to chat with the community, share your experiences, and provide feedback on upcoming features. It's like a virtual water cooler for Coder users. ## Integrations Coder plays well with others. New integrations are constantly being developed, and contributions are always welcome. ### Official Integrations These are the integrations maintained by the Coder team: - [**VS Code Extension**](https://marketplace.visualstudio.com/items?itemName=coder.coder-remote&ref=sredevops.org): Seamlessly open Coder workspaces in VS Code. - [**JetBrains Gateway Extension**](https://plugins.jetbrains.com/plugin/19620-coder?ref=sredevops.org): Do the same, but for JetBrains IDEs. - [**Dev Container Builder**](https://github.com/coder/envbuilder?ref=sredevops.org): Build environments using `devcontainer.json` on Docker, Kubernetes, and OpenShift. Because standards are important. - [**Module Registry**](https://registry.coder.com/?ref=sredevops.org): Extend your environments with pre-built modules for common use cases. Less boilerplate, more coding. - [**Kubernetes Log Stream**](https://github.com/coder/coder-logstream-kube?ref=sredevops.org): Stream Kubernetes Pod events to the Coder startup logs. Because debugging shouldn't be a guessing game. - [**Self-Hosted VS Code Extension Marketplace**](https://github.com/coder/code-marketplace?ref=sredevops.org): A private extension marketplace for air-gapped or restricted networks. Integrates with [code-server](https://github.com/coder/code-server?ref=sredevops.org). - [**Setup Coder**](https://github.com/marketplace/actions/setup-coder?ref=sredevops.org): A GitHub Action to set up the Coder CLI in your workflows. Automate all the things! ### Community Integrations These are integrations built by the awesome Coder community: - [**Provision Coder with Terraform**](https://github.com/ElliotG/coder-oss-tf?ref=sredevops.org): Deploy Coder on various Kubernetes platforms (GKE, AKS, EKS, DOKS, etc.) using Terraform. Infrastructure-as-Code for your Infrastructure-as-Code platform. Meta! - [**Coder Template GitHub Action**](https://github.com/marketplace/actions/update-coder-template?ref=sredevops.org): A GitHub Action to automatically update Coder templates. ## Contributing Want to contribute to Coder? That's fantastic! Check out the [contribution guide](https://coder.com/docs/CONTRIBUTING?ref=sredevops.org) to get started. New contributors are always welcome. ## Hiring Interested in joining the Coder team? Apply [here](https://jobs.ashbyhq.com/coder?utm%5Fsource=github&utm%5Fmedium=readme&utm%5Fcampaign=unknown). They're building cool stuff, and you could be a part of it. ## Source This article is based on the README file from the official Coder repository: [Coder GitHub Repository](https://github.com/coder/coder?ref=sredevops.org). [GitHub - coder/coder: Provision remote development environments via TerraformProvision remote development environments via Terraform - coder/coder![](https://www.sredevops.org/content/images/icon/pinned-octocat-093da3e6fa40-4.svg)GitHubcoder![](https://opengraph.githubassets.com/544218dea89af1f7a0e26b845ba41db9b76439fc90fdfbffac126543b65c5d69/coder/coder)](https://github.com/coder/coder?ref=sredevops.org) ### Why I trust Kubernetes: The Built-In Zero-Trust Model with Mutual TLS (mTLS) URL: https://www.sredevops.org/en/why-i-trust-kubernetes-the-built-in-zero-trust-model-with-mutual-tls-mtls/ Last updated: 2025-02-14T23:07:26.000Z Kubernetes is often celebrated for its scalability, reliability, and portability. However, one feature that often goes under the radar is its **built-in zero-trust model** enforced through **Mutual TLS (mTLS)**. In this article, we'll explore how Kubernetes enforces mTLS to ensure secure communication between services and clients. ## What is Mutual TLS (mTLS)? Mutual TLS, or mTLS, is a security mechanism where both the client and server authenticate each other using digital certificates. Unlike traditional TLS, where the server is trusted by default, in mTLS, **no一方 is implicitly trusted**. This creates a strict "zero-trust" environment. ## How Does mTLS Work in Kubernetes? In a Kubernetes cluster, every service (including the API server, scheduler, and etcd) communicates via mTLS. Here's how it works: 1. **Client Authentication**: When a client (e.g., `kubectl`, a pod, or another service) wants to communicate with the Kubernetes API server, it must present a valid client certificate. 2. **Server Authentication**: The API server also presents its own certificate to prove its identity to the client. 3. **Certificate Management**: All certificates are managed by the Kubernetes control plane and stored in the `kubernetes_directory/ssl` directory (typically `/etc/kubernetes`). This process happens **for every request**, regardless of whether it's from a human, machine, or another service. ## The Role of the Kubeconfig File The `kubeconfig` file is central to mTLS in Kubernetes. It contains three critical fields: - `clusters.certificate-authority-data`: The server's CA certificate used to validate server identity. - `users.client-certificate-data`: The client's public key, used to verify the client's identity. - `users.client-key-data`: The client's private key, required for signing requests. These fields ensure that both the client and server can establish trust by verifying that their certificates are signed by the same CA (Certificate Authority). ## Why is mTLS Important in Kubernetes? 1. **Zero-Trust Architecture**: No internal or external entity is trusted by default. 2. **Secure Service-to-Service Communication**: Every service must authenticate itself to communicate with others. 3. **Comprehensive Security**: Even internal services like the scheduler and etcd use mTLS, ensuring that no component can act maliciously without proper authentication. ## Closing ideas Kubernetes' implementation of mTLS is a cornerstone of its security model. By enforcing mutual authentication at every level, Kubernetes ensures a robust zero-trust environment, making it harder for attackers to compromise the cluster ### Nginx vs. Traefik: Cuál es el mejor reverse proxy? URL: https://www.sredevops.org/es/nginx-vs-traefik-cual-es-el-mejor-reverse-proxy/ Last updated: 2026-01-08T02:36:06.000Z ### Introducción Este artículo profundiza en un análisis comparativo de Nginx y Traefik como proxies inversos (reverse proxies) . Examinaremos los indicadores clave de rendimiento, incluyendo la latencia (p99), el rendimiento (peticiones por segundo), la disponibilidad (tasa de error) y la utilización de recursos (CPU, memoria y tráfico de red). El análisis también considera el impacto en el rendimiento de las aplicaciones backend. Inspirados por [este video](https://www.youtube.com/watch?v=42RNqGdpELE&ref=sredevops.org), nuestro objetivo es proporcionar una comprensión integral de qué proxy podría ser el más adecuado para tus necesidades. ## ¿Qué es un Proxy Inverso? Antes de entrar en detalles, definamos qué es un proxy inverso. Es un servidor que se sitúa delante de tu aplicación, enrutando las peticiones entrantes a las instancias de la aplicación backend. Piénsalo como un guardián, protegiendo tus valiosos servidores de aplicaciones del salvaje oeste de internet. Aquí te explicamos por qué son esenciales: - **Balanceo de Carga (Load Balancing):** Los proxies inversos (reverse proxies) distribuyen el tráfico entre múltiples instancias de la aplicación, permitiendo un escalado dinámico y una alta disponibilidad. ¿Necesitas escalar verticalmente durante las horas pico y reducir la escala durante las horas de menor actividad? Un proxy inverso te cubre las espaldas (y la billetera). - **Actualizaciones Sin Tiempo de Inactividad (Zero-Downtime Upgrades):** Actualiza tu aplicación una instancia a la vez sin interrumpir el servicio. Tus usuarios ni se darán cuenta, y podrás desplegar con un poco menos de miedo (solo un poco). - **Terminación TLS (TLS Termination):** Gestiona el cifrado TLS a nivel del proxy, liberando a tus servidores de aplicaciones de esta tarea que consume muchos recursos. Además, gestionas los certificados en un solo lugar, lo que evita a tu equipo de DevOps las interminables pesadillas de renovación de certificados. - **Seguridad:** Al proteger tus servidores de aplicaciones de la exposición directa a internet, los proxies inversos (reverse proxies) reducen tu superficie de ataque. Menos puntos de entrada expuestos significan menos oportunidades para esos molestos hackers. - **Caché y Compresión (Caching and Compression):** Almacena en caché el contenido estático (HTML, CSS, JavaScript) y comprime las respuestas para minimizar la latencia y mejorar el rendimiento. Cada milisegundo cuenta en el vertiginoso mundo de internet. ## Comparación Nginx vs. Traefik Comparemos Nginx y Traefik en varios aspectos clave: ### Configuración - **Nginx:** Se basa principalmente en archivos de configuración estáticos. Si bien es potente y probado, requiere una curva de aprendizaje para dominarlo. - **Traefik:** Ofrece opciones de configuración tanto estáticas como dinámicas. Sus mecanismos de descubrimiento de servicios incorporados pueden detectar y configurar automáticamente las rutas para las aplicaciones desplegadas en entornos como Docker. ### Gestión de Certificados TLS (TLS Certificate Management) - **Nginx:** Requiere una herramienta externa como Certbot para obtener y gestionar los certificados TLS. Si bien Certbot automatiza el proceso, es un componente adicional para instalar y configurar. - **Traefik:** Tiene soporte integrado para Let's Encrypt, lo que simplifica la adquisición y renovación de certificados. ¡Una cosa menos de qué preocuparse! ### Métricas - **Nginx (Código Abierto):** Carece de métricas granulares para aplicaciones individuales. Si bien existen soluciones alternativas, la ausencia de métricas integradas es un inconveniente notable. La versión de pago Nginx Plus sí ofrece métricas más completas. - **Traefik:** Proporciona métricas en formato Prometheus, lo que facilita la monitorización del rendimiento y la resolución de problemas. ### Contenido Estático (Static Content) - **Nginx:** Puede servir contenido estático, lo que lo convierte en una opción versátil para servidores web y proxies inversos (reverse proxies) . - **Traefik:** Se centra únicamente en el proxy inverso y no admite el servicio de contenido estático. ## Configuración y Diseño de las Pruebas Las pruebas se realizaron en AWS, utilizando instancias m7a.large para cada proxy e instancias EC2 medianas para las aplicaciones backend. Se utilizó un clúster EKS con instancias Graviton para la monitorización (Prometheus y Grafana) y la generación de carga. La versión de Nginx utilizada fue la 1.27.2 y la versión de Traefik la 3.2.0\. Todos los archivos de configuración y scripts de Terraform están disponibles en [GitHub](https://github.com/antonputra/tutorials/tree/224/lessons/224?ref=sredevops.org). [tutorials/lessons/224 at 224 · antonputra/tutorialsDevOps Tutorials. Contribute to antonputra/tutorials development by creating an account on GitHub.![](https://www.sredevops.org/content/images/icon/pinned-octocat-093da3e6fa40-3.svg)GitHubantonputra![](https://www.sredevops.org/content/images/thumbnail/tutorials)](https://github.com/antonputra/tutorials/tree/224/lessons/224?ref=sredevops.org) ## Resultados de las Pruebas ### Latencia Nginx demostró consistentemente una latencia menor durante toda la prueba, lo que indica una mejor experiencia de usuario. La latencia de Traefik aumentó a medida que se intensificaba la carga. ### Rendimiento (Throughput) Nginx logró un rendimiento significativamente mayor, alcanzando las 40.000 peticiones por segundo en comparación con las 17.000 de Traefik. Esto se traduce en posibles ahorros de costos en infraestructura. ### Uso de CPU (CPU Usage) El uso de CPU de Traefik alcanzó rápidamente el 100%, mientras que Nginx tenía más margen. Esto se alinea con los resultados de rendimiento, lo que sugiere que Traefik alcanzó su límite de rendimiento antes. ### Uso de Memoria (Memory Usage) El uso de memoria de Traefik aumentó con el tiempo, posiblemente debido al almacenamiento en caché. El uso de memoria de Nginx se mantuvo relativamente estable. ### Tasa de Error (Error Rate) Traefik intentó procesar cada petición, lo que afectó la latencia. Nginx, por otro lado, descartó un pequeño porcentaje de peticiones bajo carga extrema, priorizando la baja latencia para la mayoría de los usuarios. ### Keep-Alive: El Factor Decisivo de Nginx Un factor crucial en el rendimiento de Nginx es la configuración `keep-alive`. De forma predeterminada, Nginx no utiliza keep-alive para las conexiones backend, lo que genera una mayor carga en los servidores de aplicaciones. Habilitar keep-alive mejora drásticamente el rendimiento de Nginx al reutilizar las conexiones. ```nginx upstream backend { server backend1:8080; server backend2:8080; keepalive 16; # Habilitar keep-alive con 16 conexiones } server { # ... otras configuraciones location / { proxy_pass http://backend; proxy_http_version 1.1; proxy_set_header Connection ""; # Importante para keep-alive } } ``` ## Conclusión Nginx superó a Traefik en este benchmark, particularmente en rendimiento y latencia. Sin embargo, la facilidad de configuración de Traefik y el soporte integrado de Let's Encrypt son características atractivas. La elección entre los dos depende de tus necesidades y prioridades específicas. Si el rendimiento puro es primordial, Nginx, especialmente con keep-alive habilitado, parece ser el ganador. Si la facilidad de uso y la configuración dinámica son más importantes, Traefik podría ser una mejor opción. ## Fuente [****Anton Putra en Youtube**](https://www.youtube.com/@AntonPutra?ref=sredevops.org) [El nuevo Traefik Proxy v3.5 te permite migrar desde ingress-nginx sin modificar tus actuales recursos e incluye soporte Post-Quantum-Secure TLSTraefik Proxy v3.5 te permite equilibrar la innovación con el pragmatismo y la estabilidad, ya sea que estés migrando de sistemas legados, adoptando los nuevos standards en Kubernetes como API Gateway o preparándote para usar Post-Quantum-Secure TLS.![](https://www.sredevops.org/content/images/icon/Icon-App-76x76@2x-9.png)SREDevOps.orgNicolás Georger![](https://www.sredevops.org/content/images/thumbnail/traefik-v3.5.jpg)](https://www.sredevops.org/es/el-nuevo-traefik-proxy-v3-5-te-permite-migrar-desde-ingress-nginx-sin-modificar-tus-actuales-recursos-e-incluye-soporte-post-quantum-secure-tls/) ### A Candid Conversation with Linus Torvalds URL: https://www.sredevops.org/en/a-candid-conversation-with-linus-torvalds/ Last updated: 2024-12-07T06:00:03.000Z ## The Evolution of the Linux Kernel and its Ecosystem In this fascinating interview from the Open Source Summit in Vienna, Austria, Swapnil Bhartiya sits down with Linus Torvalds, the creator of Linux, for a candid conversation about the evolution of the kernel, the open-source community, and the ever-changing tech landscape. Years have passed since their last encounter, and much has changed in the world of technology. Linus, in his characteristically straightforward manner, discusses his current role in kernel development, which he describes as primarily a "connection point" and occasional "bad guy" who rejects poorly written code. He emphasizes the smooth operation of kernel development, attributing it to the maturity of the ecosystem and the community's proficiency in problem-solving. When asked about the widespread adoption of Linux, Linus reiterates his long-held stance of not being concerned with market share numbers. He values widespread use primarily for its ability to uncover bugs and reveal new use cases that drive further development. He humorously acknowledges his "big enough ego" without needing external validation. ## The Changing Landscape of Kernel Development The conversation shifts to the changing dynamics of the kernel community. Linus observes a shift from individual contributors to large organizations with specific needs. While this has led to more professional and well-defined requirements, he admits a slight nostalgia for the "wild west" days of early Linux development. Linus acknowledges the growth of the kernel community, from tens of core developers to hundreds, and thousands of contributors. This expansion has necessitated a more structured approach, with a hierarchy of trust and responsibility. He expresses a desire for more maintainers to alleviate the workload and stress associated with the role. ## The Future of the Kernel and Open Source Linus addresses concerns about the aging kernel community and the need for fresh talent. He believes the inherent technical challenge and career opportunities associated with kernel development continue to attract new maintainers. He also touches on specific areas of concern, such as the microcontroller world, where Linux faces challenges due to its size. He predicts that any successor in this niche will likely be open source. The discussion delves into the prevalence of open source and the challenge of fostering good open-source citizenship. Linus acknowledges the existence of "free riders" but doesn't view them as a significant threat. He emphasizes the trade-off: those who don't contribute miss out on influencing the project's direction. ## Linus's Personal Perspective and Work-Life Balance Linus shares his personal preferences for email-based communication over synchronous meetings, citing his aversion to interruptions and the asynchronous nature of kernel development. He humorously mentions his preference for bathrobes, but the underlying reason is his focus on maintaining a productive workflow. When asked about new projects, Linus expresses contentment with his current tools and focuses on Git and Subsurface. He highlights the transformative role of web browsers in making the Linux desktop more relevant. Linus discusses his approach to emerging technologies like AI, expressing interest while simultaneously criticizing the hype cycle. He prefers to focus on long-term value over short-lived trends. He cites the Raspberry Pi as an example of a technology that, while not revolutionary in itself, democratized access to hardware and empowered a new generation of makers. Finally, Linus touches on his appreciation for electric vehicles (EVs), driven by his dislike of combustion engines and the instant torque of electric motors. He views cars as appliances, prioritizing comfort and convenience. He concludes by mentioning his enduring hobbies of reading (mostly "disgusting crap") and scuba diving. This insightful interview provides a glimpse into the mind of Linus Torvalds, his pragmatic approach to technology, and his unwavering commitment to the Linux kernel. His candidness and dry humor make for a compelling read, offering valuable perspectives on the past, present, and future of open source and the tech industry. ### Source ### The Slow, Grinding Halt of Intel: A Board-Level Post-Mortem URL: https://www.sredevops.org/en/the-slow-grinding-halt-of-intel-a-board-level-post-mortem/ Last updated: 2024-12-05T22:35:49.000Z ## The Unceremonious Departure of Pat Gelsinger Let's be honest, Pat Gelsinger's "retirement" from Intel smells more like a forced ejection from a crashing airliner. His 1386-day tenure as CEO was surprisingly short, especially considering he was arguably the most technically competent CEO Intel has seen in recent years. He wasn't perfect, his optimistic outlook at times bordering on delusional, as evidenced by his ambitious wafer goals for Intel Foundry Services (IFS) during a UBS conference. He seemed to channel the ghost of Andy Grove, aiming for the moon while struggling to get off the ground. But, crucially, he *wanted* the job. He was playing for the home team, tackling one of the most challenging roles in the tech world. His predecessors, who arguably steered Intel into this mess, lasted longer and achieved considerably less. ## The Board: A Masterclass in Incompetence? Which brings us to the real villains of this story: the Intel board. This group deserves a special place in the Corporate Hall of Shame. Let's break down their "qualifications": - **Semiconductor experience:** Scarce. A few academics, a handful of recent additions with actual industry experience, and a whole lot of nothing. - **Other company/work experience:** A mixed bag, ranging from successful companies to those embroiled in their own disasters (Boeing, anyone?). A concerning number seem to be "professional board members," collecting checks and offering little in the way of actual expertise. - **Tenure at Intel:** Many have been around for the entirety of Intel's decline, silently observing the train wreck in slow motion. This isn't a board; it's a collection of well-dressed bystanders. The very people responsible for Intel's current predicament are still holding the reins, making decisions that will shape the company's future. It's like letting the arsonist design the fire escape. Here's a quick rundown of some of the key players: - **Frank Yeary (Chairman):** M&A expert, long tenure, oversaw the disaster, now likely looking to sell off the pieces. - **Omar Ishrak (Former Chairman):** No semiconductor experience, presided over the decline, *still on the board*. - **Gregory Smith:** Boeing's former CFO, also oversaw a major corporate disaster. Because one wasn't enough, apparently. The lack of relevant experience is staggering. It's as if Intel decided to hire a team of podiatrists to perform brain surgery. ## The Activist Investor Paradox The sad irony is that even activist investors, those corporate raiders of Wall Street, are hesitant to get involved. Turning around Intel is a herculean task, with little promise of a quick return. It's easier to just move on to the next shiny object. ## The Autopilot Board The board's dysfunction is compounded by the influence of proxy advisory firms like Glass Lewis and ISS. Passive investors often blindly follow their recommendations, which typically align with the board's proposals. This creates a self-perpetuating cycle of mediocrity, where the board can act with impunity, knowing that their decisions will likely be rubber-stamped. ## The Future of Intel: A Bleak Prognosis So, what's next for Intel? The most likely scenario is a fire sale. The board, under the leadership of an M&A specialist, will likely carve up the company and sell off the profitable bits. This might be good for short-term shareholder value, but it's a disaster for the long-term health of the company, the semiconductor industry, and arguably, American technological competitiveness. It's like selling your kidneys to pay off your credit card debt. The appointment of two new board members with actual semiconductor experience is a glimmer of hope, but it might be too little, too late. It's like bringing in a trauma surgeon after the patient has already bled out. Pat Gelsinger's ouster is a symptom of a much larger disease. The Intel board, operating on autopilot and lacking relevant expertise, has driven the company into the ground. It's a cautionary tale of corporate governance gone wrong, a reminder that even the mightiest can fall victim to their own internal rot. ### Source: [The Death of Intel: When Boards FailPat lost his seat because of an incompetent board. Let’s meet them.![](https://www.sredevops.org/content/images/icon/https-3A-2F-2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com-2Fpublic-2Fimages-2F0a321451-9d55-4042-9d3b-7ab4980aa2d0-2Fapple-touch-icon-180x180.png)Fabricated KnowledgeDoug O’Laughlin![](https://www.sredevops.org/content/images/thumbnail/https-3A-2F-2Fsubstack-post-media.s3.amazonaws.com-2Fpublic-2Fimages-2Fd4636feb-ef51-493a-9589-0af0d94a63fc_600x490.webp)](https://www.fabricatedknowledge.com/p/the-death-of-intel-when-boards-fail?ref=sredevops.org) ### ¿Cómo ejecutar un escritorio Linux en tu navegador? ¡WebVM 2.0 (WebAssembly) es la respuesta! URL: https://www.sredevops.org/es/como-ejecutar-un-escritorio-linux-en-tu-navegador-webvm-2-0-webassembly-es-la-respuesta/ Last updated: 2026-01-08T02:36:33.000Z ## ¡¿Espera, QUÉ?! ¿Recuerdas los días en que ejecutar un escritorio Linux completo significaba particionar discos duros, configurar gestores de arranque y sacrificar tu preciado fin de semana a los dioses de la administración de sistemas? Bueno, amigos, esos días se acabaron (más o menos). WebVM 2.0 te permite ejecutar un entorno Linux completo, incluyendo un escritorio, completamente dentro de tu navegador. Sí, leíste bien. Tu navegador. Gracias a la magia de WebAssembly, HTML5 y un toque de magia negra (o tal vez solo ingeniería inteligente), WebVM trae una máquina virtual Linux completa, almacenamiento persistente, redes e incluso Xorg a tu navegador, todo del lado del cliente. No más arranque dual, no más máquinas virtuales consumiendo tu RAM, solo Linux puro y sin adulterar en una pestaña. Echa un vistazo al [entorno Alpine Linux / Xorg / i3](https://webvm.io/alpine.html?ref=sredevops.org) para verlo en acción. [WebVM - Linux virtualization in WebAssemblyLinux virtual machine, running in the browser via HTML5/WebAssembly. Networking and graphics supported.![](https://www.sredevops.org/content/images/icon/tower.ico)WebVM![](https://www.sredevops.org/content/images/thumbnail/social_2024.png)](https://webvm.io/alpine.html?ref=sredevops.org) ## ¿Cómo funciona esta *brujería*? WebVM se basa en cuatro pilares de la tecnología web moderna: - **Motor de virtualización CheerpX:** Este motor basado en WebAssembly es el corazón de WebVM. Es un compilador JIT que traduce instrucciones x86 a WebAssembly, junto con una capa de emulación para las llamadas al sistema Linux. Esto le permite ejecutar binarios x86 de Linux sin modificar directamente en tu navegador. - **Backend de disco en streaming:** Arrancar una distribución Linux completa requiere un sistema de archivos considerable. WebVM evita inteligentemente descargar la imagen completa por adelantado mediante el uso de un backend de disco en streaming. Descarga bloques de 128kb bajo demanda desde un Cloudflare Worker, lo que garantiza una baja latencia y una experiencia fluida. Los cambios se guardan en el IndexedDB de tu navegador, lo que proporciona persistencia. - **Capa de red:** Las redes en un navegador son complicadas. WebVM utiliza Tailscale para crear una VPN privada, lo que permite que la máquina virtual acceda a Internet (y a otras WebVM) de forma segura. - **Dispositivo gráfico emulado:** WebVM admite Xorg utilizando la API KMS (Kernel Modesetting) de Linux, lo que habilita las aplicaciones gráficas y los entornos de escritorio. Actualmente, se incluye el administrador de ventanas ligero i3, pero se planea la compatibilidad con entornos más pesados como XFCE. ![Overview of Architecture](https://labs.leaningtech.com/_astro/webvm_architecture_1.BdNLQjNU_ZTSk2.webp) ## CheerpX: virtualización x86 sin los muñecos vudú CheerpX es la tecnología central detrás de WebVM. Es un motor de virtualización x86 seguro, robusto y de alto rendimiento construido completamente sobre WebAssembly y las API del navegador. Se ejecuta dentro del sandbox del navegador, aislando las aplicaciones virtualizadas de tu sistema local. Piensa en ello como un pequeño universo autónomo de Linux que se ejecuta en la pestaña de tu navegador. CheerpX no es solo para WebVM. También impulsa [CheerpX para Flash](https://leaningtech.com/cheerpx-for-flash/?ref=sredevops.org) (porque alguien tiene que mantener vivas esas antiguas aplicaciones Flash), el [CheerpX Games Runner](https://chromewebstore.google.com/detail/cheerpx-games-runner-beta/kpjhccfibjgklihcmaddjecaenppaahg?ref=sredevops.org) (para jugar juegos de GOG en tu navegador), y está disponible como un [paquete NPM](https://www.npmjs.com/package/@leaningtech/cheerpx?ref=sredevops.org). ![CheerpX Architecture](https://labs.leaningtech.com/_astro/webvm_architecture_engine.D5hm6TYo_1Rsm0.webp) ## Gestión de discos: porque a nadie le gusta un disco lleno El backend de disco en streaming de WebVM es una innovación clave. Utiliza WebSockets y Cloudflare Workers para descargar bloques de disco bajo demanda, minimizando la latencia y el uso de ancho de banda. La compatibilidad con lectura y escritura y la persistencia local se gestionan mediante IndexedDB, por lo que tus cambios se guardan incluso si cierras el navegador. ![Streaming Disk Backend Architecture](https://labs.leaningtech.com/_astro/webvm_architecture_disk.Bzrju7qv_ZwPHX9.webp) ## Redes: ya no es solo para videos de gatos Las redes en un entorno de navegador son un desafío. WebVM aborda esto integrándose con Tailscale, creando una VPN privada que permite que la máquina virtual se conecte a Internet y a otras WebVM. Este enfoque evita los problemas de escalabilidad, privacidad y abuso asociados con las soluciones tradicionales basadas en proxy. ![Networking Architecture](https://labs.leaningtech.com/_astro/webvm_architecture_network.sysEm417_2r0xcv.webp) ## Gráficos: Xorg y la API KMS (suena menos aterrador de lo que parece) WebVM admite aplicaciones gráficas y entornos de escritorio a través de Xorg y la API KMS (Kernel Modesetting) de Linux. Esto permite una transición fluida de los mensajes del kernel a la animación de arranque a Xorg sin el temido parpadeo de la pantalla. Actualmente, WebVM cuenta con el administrador de ventanas i3, pero el soporte para entornos más pesados como XFCE está en la hoja de ruta. El soporte para Wayland también está planeado, pero tomará algún tiempo. ![](https://www.sredevops.org/content/images/2024/11/image.png) ## ¿Por qué alguien haría esto? WebVM es un escaparate para CheerpX y una herramienta útil por derecho propio. Proporciona una forma conveniente de acceder a herramientas de línea de comandos, ejecutar fragmentos de código e incluso administrar repositorios de git sobre la marcha. También es un potencial cambio de juego para la educación, que ofrece acceso sin mantenimiento y sin costo a entornos de desarrollo. ***Y seamos honestos, ejecutar un escritorio Linux completo en tu navegador es simplemente genial.*** ## El futuro es brillante (y probablemente se ejecute en un navegador) El lanzamiento de WebVM 2.0 y CheerpX 1.0 es solo el comienzo. Los planes futuros incluyen un rendimiento mejorado, compatibilidad con contenedores Docker y mejoras en la experiencia de usuario de WebVM. Las posibilidades son tan vastas como el propio Internet (o al menos tan vastas como la memoria de tu navegador). ## ¡No tienes excusas para probar Linux! WebVM es un proyecto fascinante que amplía los límites de lo que es posible en un navegador web. Es gratuito, de código abierto y está disponible para que cualquiera lo use, modifique y mejore. Si encuentras algún error, infórmalo en [GitHub](https://github.com/leaningtech/webvm/issues?ref=sredevops.org). Y si tienes alguna pregunta, únete a la comunidad de Leaning Technologies en [Discord](https://discord.leaningtech.com/?ref=sredevops.org). > *Artículo original de Alessandro Pignotti en* [*Leaning Technologies Labs*](https://labs.leaningtech.com/blog/webvm-20?ref=sredevops.org) [WebVM 2.0: A complete Linux Desktop Environment in the browser via WebAssemblyWebVM is a full Linux environment running in the browser, client-side. It is a complete virtual machine, with support for persistent data storage, networking and, as of today’s release, Xorg and complete desktop environments. This article will explain the WebVM architecture, how the main components work, and what you can build with this technology.![](https://www.sredevops.org/content/images/icon/tower.NQ93itT2.svg)Leaning Technologies Developer Hub![](https://www.sredevops.org/content/images/thumbnail/Webvm2.DV0NK_a8.png)](https://labs.leaningtech.com/blog/webvm-20?ref=sredevops.org) [Web Assembly - SREDevOps.orgSRE, DevOps, Linux, Ethical Hacking, AI, ML, Open Source, Cloud Native, Platform Engineering en Español, Portugués (Brasil) and English![](https://www.sredevops.org/content/images/icon/Icon-App-76x76@2x-5.png)SREDevOps.orgNicolás Georger![](https://www.sredevops.org/content/images/thumbnail/card-1.png)](https://www.sredevops.org/tag/web-assembly/) ### How to run a Linux Desktop in your browser? WebVM 2.0 (WebAssembly) is the answer! URL: https://www.sredevops.org/en/how-to-run-a-linux-desktop-in-your-browser-webvm-2-0-webassembly-is-the-answer/ Last updated: 2024-11-20T03:03:07.000Z ## Wait, WHAT!? Remember the days when running a full Linux desktop meant partitioning hard drives, configuring bootloaders, and sacrificing your precious weekend to the gods of system administration? Well, friends, those days are over (sort of). WebVM 2.0 lets you run a complete Linux environment, including a desktop, entirely within your browser. Yes, you read that right. Your browser. Thanks to the magic of WebAssembly, HTML5, and a touch of dark sorcery (or maybe just clever engineering), WebVM brings a full Linux VM, persistent storage, networking, and even Xorg to your browser, all client-side. No more dual-booting, no more VMs eating your RAM, just pure, unadulterated Linux in a tab. Check out the [Alpine Linux / Xorg / i3 environment](https://webvm.io/alpine.html?ref=sredevops.org) to see it in action. [WebVM - Linux virtualization in WebAssemblyLinux virtual machine, running in the browser via HTML5/WebAssembly. Networking and graphics supported.![](https://www.sredevops.org/content/images/icon/tower.ico)WebVM![](https://www.sredevops.org/content/images/thumbnail/social_2024.png)](https://webvm.io/alpine.html?ref=sredevops.org) ## How Does This *Witchcraft* Work? WebVM is built on four pillars of modern web technology: - **CheerpX Virtualization Engine:** This WebAssembly-based engine is the heart of WebVM. It's a JIT compiler that translates x86 instructions into WebAssembly, coupled with an emulation layer for Linux system calls. This allows it to run unmodified Linux x86 binaries directly in your browser. - **Streaming Disk Backend:** Booting a full Linux distro requires a hefty file system. WebVM cleverly avoids downloading the entire image upfront by using a streaming disk backend. It downloads 128kb blocks on demand from a Cloudflare Worker, ensuring low latency and a smooth experience. Changes are saved to your browser's IndexedDB, providing persistence. - **Networking Layer:** Networking in a browser is tricky. WebVM uses Tailscale to create a private VPN, allowing the VM to access the internet (and other WebVMs) securely. - **Emulated Graphical Device:** WebVM supports Xorg using the Linux KMS (Kernel Modesetting) API, enabling graphical applications and desktop environments. Currently, the lightweight i3 window manager is featured, but support for heavier environments like XFCE is planned. ![Overview of Architecture](https://labs.leaningtech.com/_astro/webvm_architecture_1.BdNLQjNU_ZTSk2.webp) ## CheerpX: x86 Virtualization Without the Voodoo Dolls CheerpX is the core technology behind WebVM. It's a secure, robust, and performant x86 virtualization engine built entirely on WebAssembly and browser APIs. It runs within the browser sandbox, isolating the virtualized applications from your local system. Think of it as a tiny, self-contained universe of Linux running in your browser tab. CheerpX is not just for WebVM. It also powers [CheerpX for Flash](https://leaningtech.com/cheerpx-for-flash/?ref=sredevops.org) (because someone has to keep those ancient Flash apps alive), the [CheerpX Games Runner](https://chromewebstore.google.com/detail/cheerpx-games-runner-beta/kpjhccfibjgklihcmaddjecaenppaahg?ref=sredevops.org) (for playing GOG games in your browser), and is available as an [NPM package](https://www.npmjs.com/package/@leaningtech/cheerpx?ref=sredevops.org). ![CheerpX Architecture](https://labs.leaningtech.com/_astro/webvm_architecture_engine.D5hm6TYo_1Rsm0.webp) ## Disk Management: Because Nobody Likes a Full Disk WebVM's streaming disk backend is a key innovation. It uses WebSockets and Cloudflare Workers to download disk blocks on demand, minimizing latency and bandwidth usage. Read-write support and local persistence are handled by IndexedDB, so your changes are saved even if you close your browser. ![Streaming Disk Backend Architecture](https://labs.leaningtech.com/_astro/webvm_architecture_disk.Bzrju7qv_ZwPHX9.webp) ## Networking: It's Not Just for Cat Videos Anymore Networking in a browser environment is a challenge. WebVM tackles this by integrating with Tailscale, creating a private VPN that allows the VM to connect to the internet and other WebVMs. This approach avoids the scaling, privacy, and abuse issues associated with traditional proxy-based solutions. ![Networking Architecture](https://labs.leaningtech.com/_astro/webvm_architecture_network.sysEm417_2r0xcv.webp) ## Graphics: Xorg and the KMS API (It's Less Scary Than It Sounds) WebVM supports graphical applications and desktop environments through Xorg and the Linux KMS (Kernel Modesetting) API. This allows for a smooth transition from kernel messages to boot animation to Xorg without the dreaded screen flicker. Currently, WebVM features the i3 window manager, but support for heavier environments like XFCE is on the roadmap. Wayland support is also planned, but it will take some time. ![](https://www.sredevops.org/content/images/2024/11/image.png) ## Why Would Anyone Do This? WebVM is a showcase for CheerpX and a useful tool in its own right. It provides a convenient way to access command-line tools, run code snippets, and even manage git repositories on the go. It's also a potential game-changer for education, offering zero-maintenance and zero-cost access to development environments. ***And let's be honest, running a full Linux desktop in your browser is just plain cool.*** ## The Future is Bright (and Probably Running in a Browser) The release of WebVM 2.0 and CheerpX 1.0 is just the beginning. Future plans include improved performance, support for Docker containers, and enhancements to the WebVM UX. The possibilities are as vast as the internet itself (or at least as vast as your browser's memory). ## You don't have any excuses to try Linux! WebVM is a fascinating project that pushes the boundaries of what's possible in a web browser. It's free, open-source, and available for anyone to use, modify, and improve. If you encounter any bugs, please report them on [GitHub](https://github.com/leaningtech/webvm/issues?ref=sredevops.org). And if you have any questions, join the Leaning Technologies community on [Discord](https://discord.leaningtech.com/?ref=sredevops.org). > *Original article by Alessandro Pignotti at* [*Leaning Technologies Labs*](https://labs.leaningtech.com/blog/webvm-20?ref=sredevops.org)*.* [WebVM 2.0: A complete Linux Desktop Environment in the browser via WebAssemblyWebVM is a full Linux environment running in the browser, client-side. It is a complete virtual machine, with support for persistent data storage, networking and, as of today’s release, Xorg and complete desktop environments. This article will explain the WebVM architecture, how the main components work, and what you can build with this technology.![](https://www.sredevops.org/content/images/icon/tower.NQ93itT2.svg)Leaning Technologies Developer Hub![](https://www.sredevops.org/content/images/thumbnail/Webvm2.DV0NK_a8.png)](https://labs.leaningtech.com/blog/webvm-20?ref=sredevops.org) ### Researchers at Apple concludes that LLMs are basically glorified parrots: "It may resemble sophisticated pattern matching more than true logical reasoning" URL: https://www.sredevops.org/en/researchers-at-apple-concludes-that-llms-are-basically-glorified-parrots-it-may-resemble-sophisticated-pattern-matching-more-than-true-logical-reasoning/ Last updated: 2024-11-16T08:33:12.000Z The AI community is in a frenzy *\-as usual-*, and no, it's not about the latest sentient toaster meme. Apple, in its *infinite wisdom* (and let's be honest, occasional need to stir the pot), has been working with dropped a research paper that has everyone questioning the very nature of Large Language Models (LLMs). Have we all been duped into believing these models are more intelligent than they actually are? **Buckle up, because things are about to get statistically significant.** [GSM-Symbolic: Understanding the Limitations of Mathematical Reasoning in Large Language Models![](https://www.sredevops.org/content/images/icon/favicon-8.ico)Mascot Sammy2024![](https://arxiv.org/html/x1.png)](https://arxiv.org/html/2410.05229v1?ref=sredevops.org) ## The Illusion of Intelligence: Pattern Recognition vs. Reasoning The paper, titled ["GSM Symbolic: Understanding the Limitations of Mathematical Reasoning in Large Language Models,"](https://arxiv.org/pdf/2410.05229v1?ref=sredevops.org) throws some serious shade at the current state of LLMs. The gist? These models might not be the reasoning geniuses we thought they were. Instead, Apple's researchers suggests they're more like highly sophisticated parrots, mimicking patterns they've observed in their training data rather than genuinely understanding the concepts. Remember those standardized tests we all "loved" in school? Apple researchers used a similar approach, focusing on the GSM8K benchmark, a collection of 8,000 grade school math problems. They noticed a dramatic improvement in scores over time, with even smaller, less complex models achieving impressive results. But here's the kicker: when they tweaked the GSM8K problems ever so slightly, simply changing names and values while keeping the underlying mathematical concepts intact, the models' performance plummeted. Imagine acing a math test, only to fail miserably when the teacher changes "John has 4 apples" to "Jane has 5 oranges." That's essentially what happened to the LLMs. This "fragility" in their reasoning abilities, as the researchers call it, raises serious concerns about their actual understanding and ability to generalize. ![](https://www.sredevops.org/content/images/2024/10/Screenshot-2024-10-15-at-05.49.15.png) ## The "No-Op" Bombshell: LLMs Can't Ignore Irrelevant Information To further drive their point home, the researchers introduced a particularly devious trick: irrelevant information. They added clauses to the math problems that, while seemingly related, had absolutely no bearing on the actual solution. For example: > **Original problem:** "John has 4 apples. He buys 2 more. How many apples does John have now?" > **Modified problem:** "John has 4 apples. His favorite color is blue. He buys 2 more apples. How many apples does John have now?" A human would easily recognize the irrelevance of John's favorite color and solve the problem without a hitch. LLMs, however, stumbled like a drunk robot trying to solve a captcha. The performance drop was significant, with even the mighty GPT-4 showing a concerning dip in accuracy. This inability to filter out noise and focus on the core problem highlights a fundamental flaw in current LLM architectures. It suggests that these models are blindly processing information without truly understanding its relevance or context. ## The Implications: A Reality Check for AI This research is a wake-up call for the AI community. It challenges the **prevailing narrative of ever-larger, ever-more-powerful LLMs as the inevitable path to Artificial General Intelligence (AGI)**. If these models can be so easily tripped up by irrelevant information and minor variations in problem presentation, how can we trust them with complex, real-world tasks? The researchers argue that simply throwing more data and compute power at the problem won't cut it. What's needed is a fundamental shift in how we approach LLM design, focusing on developing models that can genuinely reason and generalize, not just parrot patterns. ## The Future of Reasoning: A Fork in the Road So, where do we go from here? The good news is that by identifying this limitation, we can start exploring solutions. Researchers are already investigating new architectures and training methods that prioritize reasoning and logical thinking. This might involve incorporating symbolic AI, which focuses on manipulating symbols and logical rules, or developing hybrid models that combine the strengths of both symbolic and statistical AI. The road to AGI is paved with both hype and hard truths. Apple's research, while potentially a setback, is a valuable reminder that true intelligence goes beyond impressive benchmarks and witty chatbot responses. **It's about understanding, reasoning, and adapting to the complexities of the real world, something that current LLMs, for all their sophistication, are still struggling to master.** [The Vision of Generative AI’s Future, Its Relationship with Kubernetes, and Basically, All of Humanity, According to What Nvidia “Promises” Us“Reading between the lines, there is a clear omission of how those who currently work in said industry would benefit, or in general, all workers and their disadvantages compared to the proprietary giants who -at least for now- are the only ones who truly benefit from this inevitable historical paradigm![](https://www.sredevops.org/content/images/icon/Icon-App-76x76@2x-3.png)SREDevOps.orgNicolás Georger![](https://www.sredevops.org/content/images/thumbnail/nim-microservices-image.png)](https://www.sredevops.org/en/the-vision-of-generative-ais-future-its-relationship-with-kubernetes-and-basically-all-of-humanity-according-to-what-nvidia-promises-us/) ### Whonix: An Operating System for DevSecOps, Researchers and Paranoids like you and me URL: https://www.sredevops.org/en/whonix-an-operating-system-for-devsecops-researchers-and-paranoids-like-you-and-me/ Last updated: 2024-10-10T09:34:57.000Z Ah, privacy. That mythical beast we all chase in this digital jungle. You think incognito mode is enough? ***Honey, please***. Your ISP knows what you had for breakfast, and they're judging. But fear not, my friend, for there's a solution for the truly paranoid: **Whonix**. Whonix is not your average OS. It's like that friend who wears a tinfoil hat, but in a good way ~~(maybe?)~~. It's built on the idea that **security by isolation** is the only way to truly protect yourself online. Think of it as a fortress within a fortress, all wrapped up in a nice, Debian-based package. ## Whonix Architecture: Two VMs are Better Than One Whonix doesn't mess around. It uses not one, but **two virtual machines**: - **Whonix-Gateway:** This bad boy handles all your Tor shenanigans. It's the gatekeeper, ensuring all your traffic goes through the onion network. - **Whonix-Workstation:** This is where you do your thing. Browse the web, write your manifesto, whatever. But remember, this VM is completely isolated and has no clue about your real IP address. This separation is what makes Whonix so damn secure. Even if malware somehow manages to infiltrate your Workstation, it won't be able to sniff out your real IP. It's like trying to find a needle in a haystack, but the haystack is on fire and guarded by ninjas. ## Features: More Than Just a Pretty (Paranoid) Face Whonix is packed with features that would make even the most skeptical security expert nod in approval: - **Full Spectrum Anti-Tracking Protection:** Forget about IP tracking, browser fingerprinting, and all that jazz. Whonix has you covered. It even randomizes your boot clock, because why not? - **Based on Debian:** This means you get all the stability and compatibility of Debian, but with an extra layer of security hardening. It's like Debian, but with a black belt in karate. - **Security by Isolation:** We've already talked about this, but it's worth repeating. This is the core of Whonix's security philosophy, and it's what makes it so effective. - **Online Anonymity via Tor:** All your traffic goes through Tor, period. No ifs, ands, or buts. It's like having a permanent invisibility cloak, but for your internet activity. ## Whonix: Not for the Faint of Heart **Whonix is not a magic bullet.** It won't make you completely anonymous, and it requires some effort to learn and use properly. But if you're serious about protecting your privacy, it's the closest thing you'll find to a digital safe house. So, if you're tired of Big Brother watching your every move, and you're ready to take your privacy into your own hands, give Whonix a try. Just be prepared to **embrace your inner paranoid, we recommend to use with Black Sabbath or Radiohead**. [Whonix - OverviewPrivacy protection. Anonymity online. Anonymous Operating System. Whonix routes all Internet traffic through the Tor anonymity network. Security by Isolation. Based on Debian. Whonix Architecture.![](https://static.ghost.org/v5.0.0/images/link-icon.svg)WhonixWhonix![](https://www.whonix.org/w/images/8/8b/Whonix-homepage-main.png?version=c7f7be436201f8f9b6604bb22b1bf90b)](https://www.whonix.org/wiki/About?ref=sredevops.org) ### DevOps Paradox: OpenTelemetry meets Mobile URL: https://www.sredevops.org/en/devops-paradox-opentelemetry-meets-mobile/ Last updated: 2024-10-04T00:45:07.000Z > OpenTelemetry is transforming the landscape of mobile app observability, providing developers with powerful tools to monitor, understand, and optimize their applications. Embrace, with its open-source SDKs and commitment to community involvement, is at the forefront of this exciting evolution. This episode of [DevOps Paradox](https://www.devopsparadox.com/?ref=sredevops.org) features Austin Alexander from Embrace ([https://embrace.io/](https://embrace.io/?ref=sredevops.org)), a mobile app observability platform. The discussion delves into the fascinating world of OpenTelemetry for mobile development, exploring its challenges, benefits, and future potential. [Podcast DevOps Paradox](https://www.devopsparadox.com/?ref=sredevops.org) ## OpenTelemetry: Beyond the Server OpenTelemetry, the rising star of observability, has revolutionized how backend systems are monitored and understood. However, as Austin highlights, its reach extends beyond servers. OpenTelemetry offers a standardized approach to instrumenting mobile apps. ## **Embrace: Bridging the Gap** Embrace ([https://embrace.io/](https://embrace.io/?ref=sredevops.org)) provides open-source SDKs that empower mobile developers to leverage OpenTelemetry. These SDKs, available for iOS, Android, React Native, Flutter, and Unity, simplify the process of instrumenting mobile apps and exporting telemetry data to various backends. ## **Challenges of Mobile Observability** Mobile app observability presents unique challenges compared to traditional server-side monitoring. Here's a look at some of these hurdles: - **Limited Control Over Hardware and Network Conditions:** Mobile devices operate in unpredictable environments with varying network connectivity, battery life, and hardware capabilities. - **App Store Review Processes:** Releasing updates for mobile apps involves a review process, which can delay the deployment of bug fixes and new features. - **Diverse Device Ecosystem:** The mobile landscape comprises a wide array of devices with different screen sizes, operating system versions, and hardware specifications. ## **Benefits of OpenTelemetry for Mobile** Despite the challenges, OpenTelemetry brings significant advantages to mobile development: - **Standardized Instrumentation:** OpenTelemetry provides a consistent and vendor-agnostic approach to instrumenting mobile apps, reducing reliance on proprietary SDKs. - **Flexibility in Data Export:** Developers can choose from various OpenTelemetry-compatible backends, such as Grafana, DataDog, and Prometheus, to store and analyze telemetry data. - **Improved Debugging and Performance Monitoring:** OpenTelemetry enables developers to gain deeper insights into app behavior, identify bottlenecks, and resolve issues more effectively. ## **Metrics: A Work in Progress** While Embrace currently supports logs and traces, metrics collection is still under development. The interview explains that attributing metrics to specific user actions and device capabilities in a meaningful way requires careful consideration. ## **Importance of Community Involvement** The interview emphasizes the significance of active participation in the OpenTelemetry community, particularly the client-side and Swift SIGs. By collaborating with other developers and contributing to the project, Embrace ensures its SDKs remain aligned with the evolving OpenTelemetry standards. ### **Get Involved** - Embrace SDKs: [https://github.com/embrace-io](https://github.com/embrace-io?ref=sredevops.org) [EmbraceEmbrace has 70 repositories available. Follow their code on GitHub.![](https://www.sredevops.org/content/images/icon/pinned-octocat-093da3e6fa40-2.svg)GitHub![](https://www.sredevops.org/content/images/thumbnail/8295703)](https://github.com/embrace-io?ref=sredevops.org) - OpenTelemetry Community: [https://opentelemetry.io/community/](https://opentelemetry.io/community/?ref=sredevops.org) [CommunityOpenTelemetry is an open source project that anyone in the community can use, improve, and enjoy. We’d love you to join us! Learn and Connect Using or want to use OpenTelemetry? Find out more here: Mailing Lists: List of mailing lists that the project uses. Mastodon: Follow us on Mastodon to get the latest news! X: Follow us on X, previously known as Twitter, to get the latest news! Stack Overflow: Practical questions and curated answers OTel logos: Official OpenTelemetry logos Meeting Recordings: Watch our meeting recordings on Zoom Cloud Site analytics: Google analytics for opentelemetry.![](https://www.sredevops.org/content/images/icon/apple-touch-icon-21.png)OpenTelemetryCC BY 4.0![](https://www.sredevops.org/content/images/thumbnail/logo-wordmark-001.png)](https://opentelemetry.io/community/?ref=sredevops.org) - DevOps Paradox: [https://www.devopsparadox.com/](https://www.devopsparadox.com/?ref=sredevops.org) [DevOps ParadoxDevOps Paradox![](https://www.sredevops.org/content/images/icon/apple-touch-icon-22.png)DevOps ParadoxDarin Pope and Viktor Farcic![](https://www.sredevops.org/content/images/thumbnail/283-social.jpg)](https://www.devopsparadox.com/?ref=sredevops.org) ### How to fix the Critical 9.9 CVE Linux Vulnerability in CUPS: A Step-by-Step Guide URL: https://www.sredevops.org/en/how-to-fix-the-critical-9-9-cve-linux-vulnerability-in-cups-a-step-by-step-guide/ Last updated: 2024-09-29T09:47:44.000Z ***Oh No! Not My Printers! Exploiting CUPS on Linux: A How-to Guide (Just Kidding, Please Patch Your Systems)*** Remember those carefree days when the most terrifying thing about printers was running out of ink at 3 AM just before a big deadline? **Yeah, me neither.** But hold onto your coffee mugs because we're diving headfirst into a pool of vulnerabilities in CUPS, the ubiquitous print server that's about as secure as a screen door on a submarine, apparently. [Linux could be facing a critical RCE vulnerability, scoring 9.9 (CVE): Let’s separate hype, security, facts, and developer dramaThe Linux community is abuzz with news of a potential Remote Code Execution (RCE) vulnerability, sending chills down the spines of sysadmins and prompting frantic security checks. But hold on to your penguins, because things are a bit more complicated than they appear. A Mysterious Vulnerability Emerges The story begins![](https://www.sredevops.org/content/images/icon/Icon-App-76x76@2x-1.png)SREDevOps.orgNicolás Georger![](https://www.sredevops.org/content/images/thumbnail/Gemini_Generated_Image_sb53dhsb53dhsb53.jpeg)](https://www.sredevops.org/en/linux-could-be-facing-a-critical-rce-vulnerability-scoring-9-9-cve-lets-separate-hype-security-facts-and-developer-drama/) ## CUPS: Conveniently Unsecure Printing System? Simone Margaritelli, the cybersecurity Gandalf, has unearthed a treasure trove of vulnerabilities in CUPS. We're talking CVEs like **CVE-2024-47176**, **CVE-2024-47076**, **CVE-2024-47175**, and **CVE-2024-47177**. These aren't your grandma's paper jams, folks. These bad boys could let a remote attacker waltz right into your system and take over *faster than you can say "Ctrl+P."* ## The Exploit: It's Like Printing Malware, But Worse Here's the lowdown on how this digital dumpster fire unfolds: 1. **`cups-browsed`**, a service that's supposed to make your life easier by browsing for printers, is actually making life easier for attackers. If it's running, you're basically waving a neon sign that says, "Hack me!" 2. Our attacker buddy, armed with more exploits than a dark web starter pack, only needs access to your network. This could be through the internet (if you're feeling adventurous and left port 631 open) or your local network (because trust is overrated, right?). 3. They set up a fake printer, slicker than a used car salesman, just waiting for you to take the bait. 4. You, being the diligent worker bee that you are, send a print job to the new "printer." 5. Surprise! Instead of your TPS report, you've just given the attacker the keys to the kingdom. They can now execute code on your machine and wreak havoc like a toddler in a china shop. ## The Fallout: More Than Just a Papercut We're talking remote code execution, folks. That means stolen data, compromised systems, and enough potential damage to make your head spin. And the worst part? You don't even need to click a suspicious link or download a dodgy file. Just printing a document is enough to trigger this digital landmine. ## Patching Your System: Less Fun Than a Root Canal, But Way More Important Alright, enough doom and gloom. Let's talk about how to slam the door shut on this vulnerability before it slams shut on you. Those instructions are meant for `systemd` based distros, AKA Debian, Ubuntu and friends. For other distros, check the links at the bottom. ### Step 1: Channel Your Inner Detective First, check if you're running **cups-browsed**: ```bash sudo systemctl status cups-browsed ``` If you see **"Active: inactive (dead),"** you can breathe a sigh of relief. If not, it's time to roll up your sleeves. ### Step 2: Stop the Bleeding Disable **cups-browsed** immediately: ```bash sudo systemctl stop cups-browsed ``` ### Step 3: Prevention is Key (and Less Stressful) Make sure **cups-browsed** stays down for the count: ```bash sudo systemctl disable cups-browsed ``` ### Step 4: Build a Firewall (No, Not the Windows Kind) If you absolutely can't disable **cups-browsed**, at least block traffic to UDP port 631: ```bash sudo iptables -A INPUT -p tcp --dport 631 -j DROP sudo iptables -A INPUT -p udp --dport 631 -j DROP ``` ### Step 5: Stay Updated (It's Not Just for Your Phone's OS) Keep your CUPS installation updated. Think of it like showering—do it regularly to avoid becoming a breeding ground for digital parasites. ## The Wrap-up: Back to Regularly Scheduled Printer Frustration So there you have it, folks. The CUPS vulnerability is a stark reminder that even the most mundane technologies can be weaponized. Stay vigilant, keep your systems patched, and maybe consider investing in a carrier pigeon for your printing needs. Just kidding (or am I?). ## References and Resources: - [https://www.evilsocket.net/2024/09/26/Attacking-UNIX-systems-via-CUPS-Part-I/](https://www.evilsocket.net/2024/09/26/Attacking-UNIX-systems-via-CUPS-Part-I/?ref=sredevops.org) - [https://www.redhat.com/en/blog/red-hat-response-openprinting-cups-vulnerabilities](https://www.redhat.com/en/blog/red-hat-response-openprinting-cups-vulnerabilities?ref=sredevops.org) - [https://github.com/OpenPrinting/cups-browsed/security/advisories/GHSA-rj88-6mr5-rcw8](https://github.com/OpenPrinting/cups-browsed/security/advisories/GHSA-rj88-6mr5-rcw8?ref=sredevops.org) - [https://github.com/RickdeJager/cupshax/tree/main](https://github.com/RickdeJager/cupshax/tree/main?ref=sredevops.org) - [https://ubuntu.com/blog/cups-remote-code-execution-vulnerability-fix-available](https://ubuntu.com/blog/cups-remote-code-execution-vulnerability-fix-available?ref=sredevops.org) ### Linux could be facing a critical RCE vulnerability, scoring 9.9 (CVE): Let's separate hype, security, facts, and developer drama URL: https://www.sredevops.org/en/linux-could-be-facing-a-critical-rce-vulnerability-scoring-9-9-cve-lets-separate-hype-security-facts-and-developer-drama/ Last updated: 2024-09-29T09:49:20.000Z The Linux community is abuzz with news of a potential Remote Code Execution (RCE) vulnerability, sending chills down the spines of sysadmins and prompting frantic security checks. But hold on to your penguins, because things are a bit more complicated than they appear. ## *UPDATE 29-09-2024:* [How to fix the Critical 9.9 CVE Linux Vulnerability in CUPS: A Step-by-Step GuideOh No! Not My Printers! Exploiting CUPS on Linux: A How-to Guide (Just Kidding, Please Patch Your Systems) Remember those carefree days when the most terrifying thing about printers was running out of ink at 3 AM just before a big deadline? Yeah, me neither. But hold onto your coffee![](https://www.sredevops.org/content/images/icon/Icon-App-76x76@2x-2.png)SREDevOps.orgNicolás Georger![](https://www.sredevops.org/content/images/thumbnail/Gemini_Generated_Image_6lv7ve6lv7ve6lv7.jpeg)](https://www.sredevops.org/en/how-to-fix-the-critical-9-9-cve-linux-vulnerability-in-cups-a-step-by-step-guide/) **UPDATE 29-09-2024 How to fix* ## A Mysterious Vulnerability Emerges The story begins with renowned security researcher, Simone Margaritelli, who claims to have discovered a critical RCE vulnerability affecting all GNU/Linux systems, potentially extending its reach to other operating systems as well. While details remain shrouded in secrecy, the severity score, reportedly confirmed by industry giants like Canonical and Red Hat, stands at a jaw-dropping 9.9 out of 10\. To put that into perspective, Heartbleed, the infamous bug that sent shockwaves through the internet, scored a 7.5. ## The Plot Thickens: A Researcher's Frustration Adding fuel to the fire, Margaritelli took to X (formerly Twitter) to express his frustration over the handling of the disclosure. He alleges that despite providing proof-of-concept exploits, developers have been dismissive, debating the vulnerability's impact instead of working towards a fix. His posts, now protected, paint a picture of a security researcher caught in a battle against corporate bureaucracy and developer pride. ## A Timeline for Disclosure: What We Know So Far While the specifics of the vulnerability remain under wraps, a disclosure timeline has been agreed upon: - **September 30th:** Initial disclosure to the Openwall security mailing list. - **October 6th:** Full public disclosure of the vulnerability details. ## Separating Fact from Fiction: A Healthy Dose of Skepticism The lack of concrete information has led to rampant speculation, with rumors swirling about the affected subsystems, ranging from CUPS to the networking stack. However, it's crucial to approach the situation with a healthy dose of skepticism. While the severity score and Margaritelli's reputation lend credibility to the claims, independent confirmation from the vendors involved is still pending. ## The Bigger Picture: Complexity Breeds Vulnerability Regardless of the specifics, this incident highlights a fundamental truth in the world of software: complexity breeds vulnerability. Modern operating systems, with their intricate interconnected components and constant online connectivity, present an ever-expanding attack surface. As systems become more complex, the possibility of undiscovered vulnerabilities increases exponentially. ## The Waiting Game: What Can You Do? Until more information comes to light, the best course of action is to stay informed and exercise caution. Keep an eye out for updates from official sources, and be prepared to patch your systems as soon as possible. ## Key Takeaways: - A potential RCE vulnerability in Linux has been reported, with a severity score of 9.9/10. - Details are scarce, and independent confirmation from vendors is pending. - The disclosure timeline suggests more information will be available by September 30th and October 6th. - This incident underscores the inherent vulnerability of complex systems. - It's crucial to stay informed and prepared to patch systems promptly. [Unauthenticated RCE vs. all GNU/Linux systems, CVSS 9.9 | Hacker News![](https://www.sredevops.org/content/images/icon/y18.svg)Hacker News![](https://www.sredevops.org/content/images/thumbnail/y18.svg)](https://news.ycombinator.com/item?id=41636796&ref=sredevops.org) [Severe Unauthenticated RCE Flaw (CVSS 9.9) in GNU/Linux Systems Awaiting Full DisclosureStay up to date with the latest news on a critical Linux vulnerability. Learn about its severity, impact, and ongoing efforts to find a fix.![](https://www.sredevops.org/content/images/icon/cropped-white-hat-icon-9-1-300x300.png)Cybersecurity Newsdo son![](https://www.sredevops.org/content/images/thumbnail/background-1900329_640.jpg)](https://securityonline.info/severe-unauthenticated-rce-flaw-cvss-9-9-in-gnu-linux-systems-awaiting-full-disclosure/?ref=sredevops.org) ### How to install a Data Science Stack? Easy as 3 commands with Canonical's DSS URL: https://www.sredevops.org/en/how-to-install-a-data-science-stack-easy-as-3-commands-with-canonicals-dss/ Last updated: 2024-11-19T04:32:17.000Z ### Data Science Stack: Your Out-of-the-Box Solution for ML Environments Canonical, the company behind Ubuntu, has released Data Science Stack (DSS), a ready-to-use solution designed to simplify the setup of machine learning (ML) environments. This open-source tool is available on various platforms, including Linux distributions, Windows Subsystem for Linux (WSL), and macOS with Multipass. [Multipass orchestrates virtual Ubuntu instancesMultipass is a CLI to launch and manage VMs on Windows, Mac and Linux that simulates a cloud environment with support for cloud-init. Get Ubuntu on-demand with clean integration to your IDE and version control on your native platform.![](https://www.sredevops.org/content/images/icon/65139c26-Multipass_rgb_apple-touch-icon.png)![](https://www.sredevops.org/content/images/thumbnail/7b658b39-Favicon---Multipass.svg)](https://multipass.run/?ref=sredevops.org) ## The Need for Speed in AI Development The adoption of AI is rapidly increasing, but so are the challenges associated with its implementation. [Deloitte's statistics reveal that:](https://www2.deloitte.com/us/en/pages/consulting/articles/challenges-of-using-artificial-intelligence.html?ref=sredevops.org) - **51%* of organizations using AI consider cybersecurity to be their highest risk.* - **36%* cite regulatory compliance as a major concern.* These challenges highlight the need for efficient and secure ML development environments. ## Data Science Stack: A Three-Command Solution DSS addresses these challenges by enabling quick setup with just three commands: 1. Set up your container orchestration layer *(microk8s)* 2. Install the DSS CLI *(with snap)* 3. Initialize the Data Science Stack. This streamlined process can be completed in 10-30 minutes, depending on your experience level. ## Features and Benefits DSS comes pre-loaded with essential tools for ML development: - **Jupyter Notebook:** For model development and experimentation. - **MLflow:** For experiment tracking and model registry. - **Popular ML Frameworks:** PyTorch and TensorFlow are included by default, allowing users to choose the most suitable framework for their needs. Furthermore, DSS is highly customizable, enabling users to add new libraries based on their specific use cases. ## Hardware Optimization DSS is designed to work seamlessly with any hardware type, ensuring optimal performance regardless of your setup. It leverages optimized ML frameworks from various vendors and integrates advanced extensions like AVX, VNNI, and AMX for accelerated model training and experimentation. ## Security and Support Canonical's commitment to security extends to DSS through Ubuntu Pro, which offers enterprise-grade support and security maintenance for your ML solution. This ensures timely issue resolution and adherence to Canonical's Service Level Agreements (SLAs). ## Now what? [Data science tools on Ubuntu: how can you quickly get started? | UbuntuLearn how Data Science Stack will accelerate your learning curve![](https://www.sredevops.org/content/images/icon/f38b9c7e-COF-20apple-touch-icon.png)Ubuntu![](https://www.sredevops.org/content/images/thumbnail/933f7ac1-Data-20Science-20Stack-20webinar.png)](https://ubuntu.com/engage/data-science-tools?ref=sredevops.org) Data Science Stack provides a comprehensive and user-friendly solution for setting up efficient and secure ML environments. Its three-command setup, pre-installed tools, hardware optimization, and enterprise support make it an ideal choice for both individual developers and organizations looking to accelerate their AI initiatives. ## Further Reading [GitHub - canonical/data-science-stack: Stack with machine learning tools needed for local development.Stack with machine learning tools needed for local development. - canonical/data-science-stack![](https://www.sredevops.org/content/images/icon/pinned-octocat-093da3e6fa40.svg)GitHubcanonical![](https://www.sredevops.org/content/images/thumbnail/data-science-stack)](https://github.com/canonical/data-science-stack?ref=sredevops.org) ### Cyclops: A Kubernetes UI to easily create YAML templates URL: https://www.sredevops.org/en/cyclops-a-kubernetes-ui-to-easily-create-yaml-templates/ Last updated: 2024-09-21T05:50:40.000Z ### *Cyclops: Your Friendly Kubernetes UI* Ah, Kubernetes. The container orchestration platform that everyone *claims* to understand. If you're tired of wrestling with YAML files and deciphering cryptic kubectl commands, then buckle up, because Cyclops is here to save the day, and your sanity, so you don't have to become Odysseus, let the Cyclops do ir for you. Cyclops is more than just a pretty UI for Kubernetes. It's a testament to the idea that powerful tools don't have to be intimidating. Whether you're a seasoned Kubernetes veteran or just starting your journey, Cyclops provides an accessible and enjoyable way to interact with the complexities of container orchestration. ![](https://www.sredevops.org/content/images/2024/09/image-7.png) Source: [https://github.com/cyclops-ui/cyclops](https://github.com/cyclops-ui/cyclops?ref=sredevops.org) ## What is Cyclops? Cyclops is an open-source developer tool that wraps a shiny, user-friendly UI around the complexities of Kubernetes. Think of it as the benevolent intermediary between you and the YAML gods. With Cyclops, you can: - **Kiss YAML goodbye (almost):** Configure and deploy applications through an intuitive interface, leaving YAML where it belongs – in the depths of configuration hell. - **Embrace the power of templates:** Cyclops's template system lets you define configurations with ease, turning what would normally be a multi-day YAML-wrangling marathon into a few satisfying clicks. - **Empower your team:** Cyclops isn't just for seasoned Kubernetes veterans. It empowers developers of all skill levels to interact with Kubernetes without needing to become YAML whisperers. ## How Does Cyclops Work Its Magic? Cyclops achieves its developer-friendly magic through the use of Helm charts. This means you can leverage your existing Helm charts or tap into the vast library of public Helm charts available. Think of Cyclops as a Helm chart wizard, guiding you through the process of deploying and managing applications without the usual headaches. ## Getting Started with Cyclops Before you embark on your Cyclops adventure, make sure you have the necessary prerequisites in place. You can find a handy checklist on the [official Cyclops documentation](https://cyclops-ui.com/docs/installation/prerequisites?ref=sredevops.org). Once you're all set, you can install Cyclops using kubectl: ```bash kubectl apply -f https://raw.githubusercontent.com/cyclops-ui/cyclops/v0.12.0/install/cyclops-install.yaml && kubectl apply -f https://raw.githubusercontent.com/cyclops-ui/cyclops/v0.12.0/install/demo-templates.yaml ``` This will spin up a dedicated namespace called `cyclops` and deploy all the essential Cyclops components. To access your shiny new Cyclops instance, you'll need to expose the server: ```bash kubectl port-forward svc/cyclops-ui 3000:3000 -n cyclops ``` Now, point your browser to [http://localhost:3000](http://localhost:3000/?ref=sredevops.org), and behold the beauty of Cyclops! ## Unleash the Power of Templates Cyclops comes pre-loaded with a collection of handy templates to get you started. These templates provide a framework for deploying common applications and services, saving you from reinventing the wheel (or the YAML file). For those who like to get their hands dirty (or just really love customization), Cyclops allows you to create your own templates. You can explore the existing templates in the [Cyclops templates repository](https://github.com/cyclops-ui/templates?ref=sredevops.org) for inspiration and guidance. ## Meet cyctl: The Cyclops CLI No self-respecting Kubernetes tool would be complete without a command-line interface, and Cyclops is no exception. Enter `cyctl`, the Cyclops CLI, ready to streamline your Cyclops experience. You can install `cyctl` using Homebrew: ```bash brew install cyctl ``` `cyctl` empowers you to: - **Manage modules and templates:** Retrieve lists of available modules and templates. - **Automate Cyclops workflows:** Integrate `cyctl` with GitHub Actions to automate tasks like deploying new templates. ## Contributing to the Cyclops Community Cyclops is a shining example of the power of open source. If you're feeling generous (or just want to show off your mad coding skills), there are plenty of ways to contribute: - **Code contributions:** Dive into the codebase and help squash bugs, implement new features, or improve existing ones. - **Feedback and suggestions:** Share your thoughts, ideas, and pain points with the Cyclops team. - **Content creation:** Spread the Cyclops love by writing blog posts, tutorials, or documentation. - **GitHub stars:** Show your appreciation by giving the Cyclops repository a star. Every star counts! ## The Road Ahead for Cyclops The Cyclops team has an ambitious roadmap for the future, with plans for: - **Enhanced security:** Authentication and role-based access control to keep your Kubernetes clusters safe and sound. - **GitOps integration:** Seamless integration with GitOps tools for streamlined workflows. - **Kustomize support:** Expanding template creation beyond Helm to include Kustomize. - **Windows support for cyctl:** Bringing the power of `cyctl` to Windows users. So, ditch the YAML files, embrace the UI, and join the Cyclops revolution! [GitHub - cyclops-ui/cyclops: Developer Friendly Kubernetes 👁️Developer Friendly Kubernetes 👁️. Contribute to cyclops-ui/cyclops development by creating an account on GitHub.![](https://www.sredevops.org/content/images/icon/pinned-octocat-093da3e6fa40.svg)GitHubcyclops-ui![](https://www.sredevops.org/content/images/thumbnail/cyclops)](https://github.com/cyclops-ui/cyclops?ref=sredevops.org) ### Vulnerabilidad crítica en un repo de Stripe: ¿Cómo asegurar los Workflows de GitHub Actions? Entendiendo "Pwn Request" URL: https://www.sredevops.org/es/vulnerabilidad-critica-en-un-repo-de-stripe-como-asegurar-los-workflows-de-github-actions-entendiendo-pwn-request/ Last updated: 2026-01-08T02:36:00.000Z Una vulnerabilidad grave en el GitHub Actions Workflow de Stripe permitió a un investigador obtener acceso al token de GitHub del repositorio. Esta vulnerabilidad, conocida como "Pwn Request", explotó la confianza depositada en los pull requests para obtener acceso no autorizado a información confidencial y realizar acciones como fusionar commits no autorizados en la rama principal (main branch). Este incidente sirve como un claro recordatorio de la importancia de comprender y asegurar los workflows de GitHub Actions y los riesgos potenciales que representan el código no confiable y los actores maliciosos. ## Entendiendo el exploit y la vulnerabilidad ¿Recuerdas aquella vez que dejaste tus cuentas de redes sociales abiertas en el computador de un amigo? Esta brecha de seguridad es algo así, pero en lugar de ser trolleado por tu descuido, involucra código, credenciales y una gran cantidad de daños potenciales a todo tu código (codebase) e incluso entornos de producción (production environments). Un investigador de seguridad, *~~probablemente impulsado por la cafeína y la adrenalina~~*, encontró una vulnerabilidad *"pwn request"* en un repositorio público de Stripe. Esta vulnerabilidad les permitió hacer cosas que no deberían poder hacer, como fusionar commits no autorizados en la rama principal (main branch) y, lo que es peor, tener en sus manos el preciado token de GitHub del workflow. La vulnerabilidad en sí misma es un caso clásico de "Pwn Request", que, a pesar de sonar como algo que un hacker diría en una mala película de acción, es una falla de seguridad grave. En términos simples, aprovecha la confianza depositada en los pull requests. ## Así es como sucedió: - **Triggers riesgosos:** El workflow vulnerable usaba el trigger `pull_request_target`, que, en el mundo de GitHub Actions, es como darle las llaves de tu casa a cualquier desconocido que te las pida. Este trigger se ejecuta con privilegios elevados, lo que significa que tiene acceso a todo, incluidos los secretos como el token de GitHub. ![](https://www.sredevops.org/content/images/2024/09/image.png) **Fuente (Source): https://www.stepsecurity.io/blog/security-breach-in-stripe-repo-a-deep-dive-into-the-pwn-request-vulnerability* - **Sacando código de forks que no son de confianza:** Para empeorar las cosas, el workflow extraía código de una referencia (ref) explícita que se originó en un fork que no era de confianza. Esto es como invitar a un extraño a tu casa y dejar que revise tus objetos de valor. ![](https://www.sredevops.org/content/images/2024/09/image-1.png) **Fuente (Source): https://www.stepsecurity.io/blog/security-breach-in-stripe-repo-a-deep-dive-into-the-pwn-request-vulnerability* Esta combinación de un trigger riesgoso y una extracción de código (checkout) sin verificar creó la tormenta perfecta para que el investigador la explotara. ## El ataque paso a paso: Ahora, vamos a desglosar el ataque como si fuera un montaje de película de atracos, con música dramática y tomas en cámara lenta: - **Bifurcando (forking) y enviando un pull request malicioso:** El investigador, como cualquier buen hacker que se precie, comenzó bifurcando (forking) el repositorio de Stripe y enviando un pull request (PR) que contenía código malicioso. Cual caballo de madera atravesando las puertas de Troya. ![](https://www.sredevops.org/content/images/2024/09/image-2.png) **Fuente (Source): https://www.stepsecurity.io/blog/security-breach-in-stripe-repo-a-deep-dive-into-the-pwn-request-vulnerability* - **Explotando el workflow:** El workflow de GitHub Actions del repositorio, sin saberlo y activado por el evento `pull_request_target`, ejecutó alegremente el código malicioso del investigador. Esto le dio al atacante acceso al token de GitHub del repositorio, las joyas de la corona de esta operación. ![](https://www.sredevops.org/content/images/2024/09/image-3.png) **Fuente (Source): https://www.stepsecurity.io/blog/security-breach-in-stripe-repo-a-deep-dive-into-the-pwn-request-vulnerability* - **Fusionando el PR y extrayendo el token:** Con el token de GitHub en su poder, el investigador pudo fusionar automáticamente su PR en la rama principal (main branch), sin pasar por ningún proceso de revisión. Es como entrar directamente a la bóveda porque engañaste a alguien para que te regale la llave. En un PR posterior, el investigador decidió presumir un poco y extrajo el token de GitHub a un servidor remoto usando `wget`. ![](https://www.sredevops.org/content/images/2024/09/image-4.png) **Fuente (Source): https://www.stepsecurity.io/blog/security-breach-in-stripe-repo-a-deep-dive-into-the-pwn-request-vulnerability* ![](https://www.sredevops.org/content/images/2024/09/image-5.png) **Fuente (Source): https://www.stepsecurity.io/blog/security-breach-in-stripe-repo-a-deep-dive-into-the-pwn-request-vulnerability* ![](https://www.sredevops.org/content/images/2024/09/image-6.png) **Fuente (Source): https://www.stepsecurity.io/blog/security-breach-in-stripe-repo-a-deep-dive-into-the-pwn-request-vulnerability* ## La evidencia del exploit: - El pull request del investigador: [https://github.com/stripe-samples/accept-a-payment/pull/2719](https://github.com/stripe-samples/accept-a-payment/pull/2719?ref=sredevops.org) - El pull request del exploit que extrajo el token de GitHub: [https://github.com/stripe-samples/accept-a-payment/pull/2723/files](https://github.com/stripe-samples/accept-a-payment/pull/2723/files?ref=sredevops.org) ## Implicaciones y riesgos Este incidente es un claro recordatorio de que incluso los gigantes tecnológicos como Stripe no son inmunes a las vulnerabilidades de seguridad. He aquí por qué esta brecha debería poner a todos nerviosos: - **Ejecución de código no autorizada:** Imagina que alguien entra a tu casa y reorganiza tus muebles. Ahora imagina que entran en tu repositorio de código e inyectan código malicioso. Eso es precisamente lo que permite la ejecución de código no autorizada, lo que podría dar lugar a puertas traseras (backdoors), software comprometido y un montón de dolores de cabeza. - **Robo de credenciales de CI/CD:** Robar credenciales de CI/CD, como los tokens de GitHub, es como entregar la llave maestra de toda tu infraestructura digital. Los atacantes pueden acceder a los registros de packages, a los entornos de cloud e incluso a repositorios de código más confidenciales. - **Fusiones no autorizadas:** Al automatizar la fusión de PR con tokens robados, los atacantes pueden eludir esos molestos procesos de revisión manual que están ahí por una razón. Esto puede dar lugar a graves riesgos de seguridad, como los compromisos de la cadena de suministro (supply chain), en los que el código malicioso se cuela en el software de uso generalizado. ## Prevención de futuros ataques Entonces, ¿cómo podemos prevenir estos ataques y evitar convertirnos en la próxima historia con moraleja en el mundo de la ciberseguridad? Aquí tienes algunas ideas: - **Trata tus workflows de GitHub Actions como si fueran de la realeza:** No te limites a configurarlos y olvidarte de ellos. Revisa y actualiza periódicamente tus workflows, prestando especial atención a los triggers utilizados y a los permisos concedidos. - **Adopta el principio de mínimo privilegio:** Concede a tus workflows el mínimo acceso indispensable para que hagan su trabajo. Limitar el alcance de los tokens es como guardar bajo llave tus objetos de valor: dificulta mucho más que los atacantes se lleven todo si consiguen burlar tus defensas. - **Implementa reglas estrictas de protección de ramas:** Dificulta que se cuelen cambios no autorizados aplicando reglas de protección de ramas, como exigir varias aprobaciones para las fusiones de PR. Es como tener un sistema de seguridad para tu base de código (codebase). - **Utiliza un runner reforzado:** El Harden-Runner de StepSecurity ([https://github.com/step-security/harden-runner](https://github.com/step-security/harden-runner?ref=sredevops.org)) es un salvavidas (o mejor dicho, un salvavidas de código). Añade una capa extra de seguridad al evitar que los datos sensibles, como esos jugosos tokens de GitHub, sean extraídos por código malicioso. Piensa en él como el equivalente en ciberseguridad a una bóveda para tus activos más valiosos. [GitHub - step-security/harden-runner: Network egress filtering and runtime security for GitHub-hosted and self-hosted runnersNetwork egress filtering and runtime security for GitHub-hosted and self-hosted runners - step-security/harden-runner![](https://www.sredevops.org/content/images/icon/pinned-octocat-093da3e6fa40.svg)GitHubstep-security![](https://www.sredevops.org/content/images/thumbnail/harden-runner)](https://github.com/step-security/harden-runner?ref=sredevops.org) ## Resumen Esta brecha de seguridad en el repositorio de Stripe es una llamada de atención para todos aquellos que piensan que "a mí no me puede pasar". Asegurar tus pipelines de CI/CD, especialmente aquellos que utilizan GitHub Actions, no es una sugerencia, es una necesidad. Implementando medidas de seguridad sólidas, podemos hacer la vida mucho más difícil a los atacantes y mantener nuestras bases de código (codebases), y nuestra cordura, intactas. ## Fuente [Security Breach in Stripe Repo: A Deep Dive into the “Pwn Request” VulnerabilityThe Vulnerability in Stripe’s GitHub Actions Workflow Shows Why Securing CI/CD Pipelines Is Essential![](https://www.sredevops.org/content/images/icon/62a6a0f06a31c86da9153bce_favicon_unbounce_32x32.png)![](https://www.sredevops.org/content/images/thumbnail/66d9c6eda0bd9467cd9622a2_BLOG_BANNER_1.jpg)](https://www.stepsecurity.io/blog/security-breach-in-stripe-repo-a-deep-dive-into-the-pwn-request-vulnerability?ref=sredevops.org) ### Security Breach in Stripe GitHub's Repo: How to Secure GitHub Actions Workflows? Understanding the Pwn Request Vulnerability URL: https://www.sredevops.org/en/security-breach-in-stripe-githubs-repo-how-to-secure-github-actions-workflows-understanding-the-pwn-request-vulnerability/ Last updated: 2024-09-12T01:53:59.000Z A severe vulnerability in Stripe’s GitHub Actions Workflow allowed a researcher to gain access to the repository's GitHub token. This vulnerability, known as "Pwn Request," exploited the trust placed in pull requests to gain unauthorized access to sensitive information and perform actions such as merging unauthorized commits into the main branch. This incident serves as a stark reminder of the importance of understanding and securing GitHub Actions workflows and the potential risks posed by untrusted code and malicious actors. [Un exploit en GitHub permitía inyectar archivos en -casi- cualquier repositorio y distribuir malware “legítimo”Una vulnerabilidad de seguridad en GitHub permitía a atacantes inyectar malware en repositorios legítimos. El atacante podría subir un archivo malicioso como comentario en un issue o pull request. Incluso si el comentario se eliminaba, el archivo malicioso seguía siendo accesible a través de una URL pública. Esto se debe![](https://www.sredevops.org/content/images/icon/Icon-App-76x76@2x.png)SREDevOps.orgNicolás Georger![](https://www.sredevops.org/content/images/thumbnail/0922_07_GitHub_Malware_Blog_1060x698.jpeg)](https://www.sredevops.org/es/un-exploit-en-github-permitia-inyectar-archivos-en-casi-cualquier-repositorio-y-distribuir-malware-legitimo/) Related content ## The Vulnerability Explained Remember that time you left your social media accounts logged in on a friend's computer? This security breach is kind of like that, but instead of being trolled by your friends, it involves code, credentials, and a whole lot of potential damage to your whole codebase and production deployments. A security researcher, probably fueled by caffeine and the thrill of the chase, found a 'pwn request' vulnerability in a public Stripe repository. This vulnerability allowed them to do things they shouldn't be able to do – like merging unauthorized commits into the main branch and, even worse, getting their hands on the workflow's precious GitHub token. The vulnerability itself is a classic case of "Pwn Request," which, despite sounding like something a hacker would scream in a bad action movie, is a serious security flaw. In simple terms, it takes advantage of the trust placed in pull requests. ## Here's how it went down: - **Risky Business with Triggers:** The vulnerable workflow used the `pull_request_target` trigger, which, in the world of GitHub Actions, is like giving someone the keys to your kingdom. This trigger runs with elevated privileges, meaning it has access to all the good stuff, including secrets like the GitHub token. ![](https://www.sredevops.org/content/images/2024/09/image.png) **Source: https://www.stepsecurity.io/blog/security-breach-in-stripe-repo-a-deep-dive-into-the-pwn-request-vulnerability* - **Checking Out Code from Untrusted Forks:** To make matters worse, the workflow checked out code from an explicit ref that originated from an untrusted fork. This is like inviting a stranger into your home and letting them rummage through your valuables. ![](https://www.sredevops.org/content/images/2024/09/image-1.png) **Source: https://www.stepsecurity.io/blog/security-breach-in-stripe-repo-a-deep-dive-into-the-pwn-request-vulnerability* This combination of a risky trigger and unchecked code checkout created a perfect storm for the researcher to exploit. ## The Attack Breakdown Now, let's break down the attack like it's a heist movie montage, complete with dramatic music and slow-motion shots: - **Forking and Submitting a Malicious Pull Request:** The researcher, like any good hacker worth their salt, started by forking the Stripe repository and submitting a pull request (PR) containing malicious code. Think of it as sneaking a Trojan Horse past the guards. ![](https://www.sredevops.org/content/images/2024/09/image-2.png) **Source: https://www.stepsecurity.io/blog/security-breach-in-stripe-repo-a-deep-dive-into-the-pwn-request-vulnerability* - **Exploiting the Workflow:** The repository's GitHub Actions workflow, none the wiser and triggered by the `pull_request_target` event, happily ran the researcher's malicious code. This gave the attacker access to the repository's GitHub token – the crown jewels of this operation. ![](https://www.sredevops.org/content/images/2024/09/image-3.png) **Source: https://www.stepsecurity.io/blog/security-breach-in-stripe-repo-a-deep-dive-into-the-pwn-request-vulnerability* - **Merging the PR and Exfiltrating the Token:** With the GitHub token in their possession, the researcher could automatically merge their PR into the main branch, bypassing any pesky review processes. It's like walking straight into the vault because you tricked someone into giving you the code. In a subsequent PR, the researcher decided to show off a bit and exfiltrated the GitHub token to a remote server using `wget`. ![](https://www.sredevops.org/content/images/2024/09/image-4.png) **Source: https://www.stepsecurity.io/blog/security-breach-in-stripe-repo-a-deep-dive-into-the-pwn-request-vulnerability* ![](https://www.sredevops.org/content/images/2024/09/image-5.png) **Source: https://www.stepsecurity.io/blog/security-breach-in-stripe-repo-a-deep-dive-into-the-pwn-request-vulnerability* ![](https://www.sredevops.org/content/images/2024/09/image-6.png) **Source: https://www.stepsecurity.io/blog/security-breach-in-stripe-repo-a-deep-dive-into-the-pwn-request-vulnerability* ## Here are some receipts (evidence) of the hack: - The researcher's merged pull request: [https://github.com/stripe-samples/accept-a-payment/pull/2719](https://github.com/stripe-samples/accept-a-payment/pull/2719?ref=sredevops.org) [security test by ntk5 · Pull Request #2719 · stripe-samples/accept-a-payment![](https://www.sredevops.org/content/images/icon/pinned-octocat-093da3e6fa40.svg)GitHubstripe-samples![](https://www.sredevops.org/content/images/thumbnail/2719)](https://github.com/stripe-samples/accept-a-payment/pull/2719?ref=sredevops.org) - The exploit pull request that exfiltrated the GitHub token: [https://github.com/stripe-samples/accept-a-payment/pull/2723/files](https://github.com/stripe-samples/accept-a-payment/pull/2723/files?ref=sredevops.org) [Update gradlew by just-testing-stuff-thanks · Pull Request #2723 · stripe-samples/accept-a-paymentbug-bounty-test-not-malicious-hackerone![](https://www.sredevops.org/content/images/icon/pinned-octocat-093da3e6fa40.svg)GitHubstripe-samples![](https://www.sredevops.org/content/images/thumbnail/130579968)](https://github.com/stripe-samples/accept-a-payment/pull/2723/files?ref=sredevops.org) ## Implications and Risks This incident is a stark reminder that even tech giants like Stripe aren't immune to security vulnerabilities. Here's why this breach should make everyone nervous: - **Unauthorized Code Execution:** Imagine someone breaking into your house and rearranging your furniture. Now imagine them breaking into your code repository and injecting malicious code. That's precisely what unauthorized code execution allows, potentially leading to backdoors, compromised software, and a whole lot of headaches. - **CI/CD Credentials Theft:** Stealing CI/CD credentials, like GitHub tokens, is like handing over the master key to your entire digital infrastructure. Attackers can access package registries, cloud environments, and even more sensitive code repositories. - **Unauthorized Merges:** By automating the merging of PRs with stolen tokens, attackers can bypass those pesky manual review processes that are in place for a reason. This can lead to serious security risks, including supply chain compromises, where malicious code sneaks its way into widely used software. ## Preventing Future Attacks So, how do we prevent these attacks and avoid becoming the next cautionary tale in the cybersecurity world? Here are a few ideas: - **Treat Your GitHub Actions Workflows Like Royalty:** Don't just set them up and forget about them. Regularly review and update your workflows, paying close attention to the triggers used and the permissions granted. - **Embrace the Principle of Least Privilege:** Only give your workflows the bare minimum access they need to do their job. Limiting token scope is like locking up your valuables – it makes it much harder for attackers to make off with everything if they manage to breach your defenses. - **Implement Strict Branch Protection Rules:** Make it harder for unauthorized changes to slip through by enforcing branch protection rules, like requiring multiple approvals for PR merges. It's like having a security system for your codebase. - **Use a Harden Runner:** StepSecurity's Harden-Runner ([https://github.com/step-security/harden-runner](https://github.com/step-security/harden-runner?ref=sredevops.org)) is a lifesaver (or rather, a code-saver). It adds an extra layer of security by preventing sensitive data, like those juicy GitHub tokens, from being exfiltrated by malicious code. Think of it as the cybersecurity equivalent of a vault for your most valuable assets. [GitHub - step-security/harden-runner: Network egress filtering and runtime security for GitHub-hosted and self-hosted runnersNetwork egress filtering and runtime security for GitHub-hosted and self-hosted runners - step-security/harden-runner![](https://www.sredevops.org/content/images/icon/pinned-octocat-093da3e6fa40.svg)GitHubstep-security![](https://www.sredevops.org/content/images/thumbnail/harden-runner)](https://github.com/step-security/harden-runner?ref=sredevops.org) ## Summary This security breach in Stripe's repository is a wake-up call for everyone who thinks "it can't happen to me." Securing your CI/CD pipelines, especially those using GitHub Actions, is not a suggestion; it's a necessity. By implementing robust security measures, we can make life much more difficult for attackers and keep our codebases, and our sanity, intact. ## Source [Security Breach in Stripe Repo: A Deep Dive into the “Pwn Request” VulnerabilityThe Vulnerability in Stripe’s GitHub Actions Workflow Shows Why Securing CI/CD Pipelines Is Essential![](https://www.sredevops.org/content/images/icon/62a6a0f06a31c86da9153bce_favicon_unbounce_32x32.png)![](https://www.sredevops.org/content/images/thumbnail/66d9c6eda0bd9467cd9622a2_BLOG_BANNER_1.jpg)](https://www.stepsecurity.io/blog/security-breach-in-stripe-repo-a-deep-dive-into-the-pwn-request-vulnerability?ref=sredevops.org) ### Alternativas a Docker Desktop en macOS: OrbStack, Lima, Podman y más URL: https://www.sredevops.org/es/alternativas-a-docker-desktop-en-macos-orbstack-lima-podman-y-mas/ Last updated: 2026-01-08T02:35:58.000Z Los usuarios de macOS tienen varias opciones sólidas para ejecutar contenedores (*containers*), cada una con sus propias fortalezas. Revisamos OrbStack, Lima (Linux Machines) y Docker Desktop, comparando sus características, rendimiento y facilidad de uso para ayudarte a elegir la que mejor se adapte a tu flujo de trabajo de desarrollo. Tanto si eres un veterano experimentado en Kubernetes como si acabas de empezar a trabajar en contenedores, revisamos qué herramienta podría ser tu mejor complemento para trabajar usando containers en macOS. ## Contenedores: Por qué nos encantan? Los contenedores (*containers*) han tomado el mundo del desarrollo por asalto, y por una buena razón. Empaquetan las aplicaciones y sus dependencias en unidades ordenadas y portátiles, lo que facilita el traslado del software entre diferentes entornos sin pesadillas de compatibilidad. Esta portabilidad es un regalo del cielo para los desarrolladores, ya que les permite construir y probar aplicaciones en entornos consistentes que reflejan fielmente la producción. ## Docker Desktop: El standard de facto... bueno, más o menos Docker Desktop ha sido durante mucho tiempo la opción preferida para ejecutar (*running*) contenedores (*containers*) en macOS. Su interfaz fácil de usar y su estrecha integración con las herramientas de desarrollo más populares lo convirtieron en uno de los favoritos entre los desarrolladores. Sin embargo, los recientes cambios en las licencias de Docker Desktop, especialmente para las grandes organizaciones, han hecho que algunos usuarios busquen alternativas. ## Opciones?: OrbStack y Lima Han surgido dos contendientes, con el objetivo de destronar a Docker Desktop y capturar los corazones de los desarrolladores de macOS: ### **OrbStack** Este recién llegado se centra en la velocidad y la eficiencia. Construido sobre Rust, presume de un rendimiento impresionante y una huella ligera. OrbStack pretende proporcionar una experiencia de desarrollo fluida con características como un clúster (*cluster*) Kubernetes integrado y soporte para Docker Compose. 0:00 /0:45 1× ### **Lima (LInux MAchines)** Un veterano en el mundo del código abierto, Lima ofrece flexibilidad y personalización. Te permite crear máquinas virtuales Linux específicamente diseñadas para ejecutar contenedores (*containers*), lo que te da un control granular sobre tu entorno de desarrollo. Lima puede resultar atractiva para los desarrolladores que prefieren un enfoque más práctico y quieren jugar con su configuración. [Lima: La forma más fácil de ejecutar cualquier distribución de Linux, Kubernetes, k3s e incluso Docker en macOS y Linux, compatible con Apple Silicon (M1/ARM64)Qué es Lima: Una herramienta de línea de comandos (CLI) versátil y fácil de usar para ejecutar máquinas virtuales (VM) de Linux en tu sistema macOS o Linux Lima es compatible con cualquier procesador Apple Silicon (M1, M2, etc.) y procesadores Intel x86\_64, y te permite ejecutar VMs de![](https://www.sredevops.org/content/images/icon/Icon-App-76x76@2x.png)SREDevOps.orgNicolás Georger![](https://www.sredevops.org/content/images/thumbnail/lima-linux-apple.jpeg)](https://www.sredevops.org/es/lima-la-forma-mas-facil-de-ejecutar-cualquier-distribucion-de-linux-kubernetes-k3s-e-incluso-docker-en-macos-y-linux-compatible-con-apple-silicon-m1-arm64/) ## Comparando a los contendientes Vamos a desglosar las diferencias clave entre OrbStack, Lima y Docker Desktop: | | OrbStack | Lima | Docker Desktop | | ---------------- | -------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Rendimiento | Extremadamente rápido, gracias a su arquitectura basada en Rust | Buen rendimiento, pero puede variar dependiendo de la configuración de la máquina virtual | Buen rendimiento, pero puede consumir muchos recursos | | Facilidad de uso | Interfaz fácil de usar y configuración sencilla | Requiere algunos conocimientos de línea de comandos; se necesita más configuración | Interfaz fácil de usar y configuración sencilla | | Características | Kubernetes integrado, compatibilidad con Docker Compose, *port forwarding* | Altamente personalizable, soporta diferentes distribuciones de Linux | Características completas, incluyendo soporte para Kubernetes, creación de imágenes (*image building*) y análisis de vulnerabilidades (*vulnerability scanning*) | | Coste | Gratuito para uso personal; planes de pago para equipos | De código abierto y gratuito | Gratuito para uso personal y pequeños equipos; planes de pago para grandes organizaciones | ## Elegir tu campeón: ¿Cuál es el adecuado para ti? El mejor motor de contenedores (*container engine*) para tu flujo de trabajo de desarrollo en macOS depende de tus necesidades y prioridades específicas: - Si el rendimiento en bruto es tu prioridad, los tiempos de inicio de OrbStack podrían convertirlo en tu opción ideal. - Para los desarrolladores que anhelan la personalización y disfrutan ensuciándose las manos con la configuración, la flexibilidad de Lima podría ser una combinación perfecta. - Si prefieres una interfaz fácil de usar y una experiencia optimizada, Docker Desktop sigue siendo una opción sólida, especialmente para aquellos que ya están familiarizados con su ecosistema. ## Seamos prácticos: Instalar y ejecutar una aplicación sencilla Para que te hagas una idea de cada opción, vamos a ver cómo se instala una sencilla aplicación web utilizando OrbStack, Lima y Docker Desktop. ### OrbStack **Instalación:** Descarga el instalador de OrbStack o utiliza Homebrew y simplemente ejecuta: ```bash brew install orbstack ``` **Ejecutar un contenedor:** Una vez instalado, abre tu terminal y ejecuta el siguiente comando para iniciar un servidor web Nginx en un contenedor (*container*): ```bash orbstack run -d -p 80:80 nginx:latest ``` **Acceder a tu aplicación:** Abre tu navegador web y navega hasta [http://localhost](http://localhost/?ref=sredevops.org). Deberías ver la página de bienvenida predeterminada de Nginx. ```bash open http://localhost ``` ### Lima Instalar L¡ima es tan fácil como: ```bash brew install --require-sha lima ``` **Crear una instancia de Lima:** Crea una instancia de Lima con Docker preinstalado: ```bash limactl start --name=my-lima-instance template://docker ``` **Ejecutar un contenedor:** Ahora puedes ejecutar comandos de Docker como siempre: ```bash docker run -d -p 80:80 nginx:latest ``` **Acceder a tu aplicación:** Dado que Lima se ejecuta en una máquina virtual, tendrás que encontrar su dirección IP para acceder a tu aplicación. Para encontrar la dirección IP de `my-lima-instance` ```bash limactl list # y luego ábrela en tu navegador web open http://$my-lima-instance-ip ``` ### Docker Desktop **Instalación:** Descarga el instalador de Docker Desktop desde el sitio web de Docker y sigue las instrucciones de instalación. **Ejecutar un contenedor:** Abre tu terminal y ejecuta el siguiente comando: ```bash docker run -d -p 80:80 nginx:latest ``` **Acceder a tu aplicación:** Abre tu navegador web y navega hasta [http://localhost](http://localhost/?ref=sredevops.org). Deberías ver la página de bienvenida de Nginx. ## Ecosistema y comunidad El mundo de los contenedores (*containers*) está en constante evolución, con nuevas herramientas y tecnologías que surgen todo el tiempo. Aunque este artículo se ha centrado en OrbStack, Lima y Docker Desktop, merece la pena explorar otras opciones como Rancher Desktop y Podman para encontrar la que mejor se adapte a tus necesidades de desarrollo. La clave está en experimentar, probar diferentes herramientas y elegir la que te permita construir, enviar y ejecutar tus aplicaciones con facilidad y eficiencia. ## Mención especial: Podman Desktop Bueno, siempre hay otra opción, ¿verdad? Podman Desktop también funciona muy bien en macOS, lee más: [Podman Desktop: Your Gateway to Containers and KubernetesTL;DR 😴 Podman Desktop is an open-source, cross-platform graphical tool designed to make working with containers and Kubernetes on your local machine a breeze. It provides a user-friendly interface for building, running, managing, inspecting, and debugging containers, as well as interacting with Kubernetes deployments. Podman Desktop is a powerful yet![](https://www.sredevops.org/content/images/icon/Icon-App-76x76@2x.png)SREDevOps.orgNicolás Georger![](https://www.sredevops.org/content/images/thumbnail/banner-bb0f1ccb389f6bff5debba4110d76b9e.png)](https://www.sredevops.org/en/podman-desktop-your-gateway-to-containers-and-kubernetes/) ### Enlaces [OrbStack · Fast, light, simple Docker & Linux on macOSSay goodbye to slow, clunky containers and VMs. The fast, light, and easy way to run containers and Linux. Develop at lightspeed with our Docker Desktop alternative.![](https://orbstack.dev/img/icon128.png)OrbStack![](https://orbstack.dev/img/icon-square256.png)](https://orbstack.dev/?ref=sredevops.org) [Lima: The Easiest Way to Run any Linux Distro, Kubernetes, k3s and even Docker on macOS and Linux, Apple Silicon (M1/ARM64) compatibleLima is a versatile and user-friendly command line tool (CLI) that empowers you to seamlessly run Linux virtual machines (VMs) on your macOS or Linux system. It’s compatible with any Apple Silicon Mac (M1, M2, etc) ARM64 and Intel x86\_64 processors, vice versa, without anything else than a single![](https://www.sredevops.org/content/images/size/w256h256/2024/07/Icon-App-76x76@2x.png)SREDevOps.orgNicolás Georger![](https://www.sredevops.org/content/images/size/w1200/2024/06/lima-linux-apple.jpeg)](https://www.sredevops.org/en/lima-the-easiest-way-to-run-any-linux-distro-kubernetes-k3s-and-even-docker-on-macos-and-linux-apple-silicon-m1-arm64-compatible/) [Docker Desktop: The #1 Containerization Tool for Developers | DockerDocker Desktop is collaborative containerization software for developers. Get started and download Docker Desktop today on Mac, Windows, or Linux.![](https://www.docker.com/wp-content/uploads/2024/02/cropped-docker-logo-favicon-270x270.png)Docker![](https://www.docker.com/wp-content/uploads/2023/06/meta-image-download-docker-desktop-1110x580.png)](https://www.docker.com/products/docker-desktop/?ref=sredevops.org) ### ### Puedo migrar de Terraform a OpenTofu fácil? Hoy ya puedes gracias a su nueva búsqueda web + API URL: https://www.sredevops.org/es/puedo-migrar-de-terraform-a-opentofu-facil-hoy-ya-puedes-gracias-a-su-nueva-busqueda-web-api/ Last updated: 2026-01-08T02:36:07.000Z OpenTofu, la herramienta de código abierto de Infrastructure as Code (IaC), ha lanzado una interfaz fácil de usar para su registro de componentes (OpenTofu Registry). Esta interfaz web, desarrollada en colaboración con Spacelift, tiene como objetivo simplificar la adopción de OpenTofu al facilitar que cualquier persona pueda explorar y comprender los recursos de OpenTofu. Junto con la interfaz de usuario, OpenTofu presenta una API beta para el acceso programático al registro, alojada por Cloudflare. Estas mejoras están configuradas para capacitar tanto a los recién llegados como a los usuarios experimentados para aprovechar todo el potencial de OpenTofu para sus necesidades de automatización de infraestructura, con autonomía e independencia de Hashicorp/IBM. [IBM continúa devorando: Hashicorp (Terraform) será su próxima adquisiciónIBM lo confirma: Comprará HashiCorp En el mundo de la nube híbrida, se sabía que HashiCorp, creadores de la popular herramienta de infraestructura como código (IaC) Terraform, estaba buscando ser adquirida. También sabíamos que el cambio de la licencia Mozilla de código abierto de Terraform por la Business Source License![](https://www.sredevops.org/content/images/icon/Icon-App-76x76@2x.png)SREDevOps.orgNicolás Georger![](https://www.sredevops.org/content/images/thumbnail/1967_ibm_film14.webp)](https://www.sredevops.org/es/ibm-continua-devorando-hashicorp-terraform-sera-su-proxima-adquisicion/) **Leer mas sobre Hashicorp e IBM* ## El poder de un registry fácil de usar en el ecosistema OpenTofu La constante evolución de la Infraestructura como Código (IaC), tener un registro bien estructurado y fácil de navegar es primordial. El proyecto OpenTofu, reconociendo esta necesidad, ha dado un salto significativo al introducir una interfaz de usuario (UI) para su registro de componentes. Este movimiento aborda un punto crítico para muchos usuarios que anteriormente dependían únicamente de la documentación para descifrar las complejidades de IaC. La nueva interfaz de usuario actúa como un repositorio centralizado de conocimiento, proporcionando una forma visualmente atractiva e intuitiva de explorar las capacidades de OpenTofu. [OpenTofu RegistryA fast and easy-to-use UI for quickly browsing and viewing OpenTofu modules and providers.![](https://www.sredevops.org/content/images/icon/favicon.svg)![](https://www.sredevops.org/content/images/thumbnail/open-graph.png)](https://search.opentofu.org/?ref=sredevops.org) OpenTofu Registry Imagina esto: estás trabajando en un proyecto OpenTofu y necesitas integrar un recurso específico, pero la documentación parecía ser el [*Laberinto del Minotauro y tu, cual Teseo, ya se te acaba el hilo*](https://historia.nationalgeographic.com.es/a/la-leyenda-del-minotauro-el-terrorifico-monstruo-mitad-hombre-y-mitad-toro-%5F19205?ref=sredevops.org). Aquí es donde la interfaz de usuario viene al rescate. En lugar de examinar páginas de texto, ahora puede navegar visualmente a través de los recursos disponibles, sus funcionalidades y opciones de configuración. Este enfoque optimizado no solo ahorra tiempo, sino que también hace que la curva de aprendizaje sea menos desalentadora para los recién llegados. ## OpenTofu Registry: un impulso para la adopción de IaC La importancia de la interfaz de usuario de OpenTofu se extiende más allá de la mera conveniencia. Representa un paso estratégico hacia una adopción más amplia de IaC. Al reducir la barrera de entrada, la interfaz de usuario permite a una gama más amplia de usuarios, desde ingenieros DevOps experimentados hasta aquellos que recién comienzan su viaje de IaC, aprovechar el poder de OpenTofu. Esta inclusión es crucial para impulsar la adopción generalizada de los principios de IaC y fomentar un ecosistema más robusto y dinámico. El impacto de la interfaz de usuario va más allá de los usuarios individuales. Para las organizaciones, se traduce en una incorporación más rápida de nuevos miembros del equipo, ciclos de desarrollo reducidos y, en última instancia, un enfoque más eficiente y ágil para la gestión de la infraestructura. La capacidad de encontrar, comprender e implementar rápidamente los recursos de OpenTofu a través de una interfaz fácil de usar puede afectar significativamente los resultados de una organización al optimizar las operaciones y reducir el riesgo de errores. ## OpenTofu Registry API La interfaz de usuario en sí está construida sobre el Registro OpenTofu existente, que alberga una gran cantidad de información sobre proveedores y módulos OpenTofu. Cada entrada en el registro incluye documentación completa, ejemplos y opciones de configuración, lo que lo convierte en una ventanilla única para todo lo relacionado con OpenTofu. La API, actualmente en versión beta, proporciona la posibilidad programática de interactuar con el registro. Esto abre un mundo de posibilidades para los desarrolladores e ingenieros de DevOps que buscan automatizar sus flujos de trabajo. Por ejemplo, puede usar la API para buscar programáticamente recursos específicos, consultar su documentación o incluso integrar los datos del registro en sus propias herramientas y aplicaciones. Aquí hay una muestra de cómo puedes interactuar con la API del Registro OpenTofu utilizando `curl` y `jq`: ```bash curl -X GET https://api.opentofu.org/search?q=google | jq ``` Este comando retorna una lista de todos resultados asociados a Google en OpenTofu disponibles del registro. Puede refinar aún más sus consultas especificando parámetros de búsqueda o consultando a los endpoints específicos. [OpenTofu Registry UI API![](https://www.sredevops.org/content/images/icon/faviconV2)](https://api.opentofu.org/?ref=sredevops.org) ## El futuro de OpenTofu: colaboración y desarrollo impulsado por la comunidad El desarrollo de la interfaz de usuario y la API del Registro OpenTofu es un testimonio del poder de la colaboración de código abierto. Spacelift, un proveedor líder de plataformas IaC, jugó un papel fundamental en la creación de la interfaz de usuario, mientras que Cloudflare proporciona generosamente la infraestructura para alojar la API. Este espíritu de colaboración está en el corazón del proyecto OpenTofu, y es lo que lo distingue como una iniciativa verdaderamente impulsada por la comunidad, mientras que Linux Foundation garantiza su independencia en el largo plazo, sin cambios en sus licencias sólo motivados por intereses comerciales egoístas. [OpenTF ahora es OpenTofu y es parte de Linux Foundation, ¡ya puedes usar el primer alpha!Hace poco te contábamos por qué Terraform estaba muerto -al menos para la comunidad Open Source-, el por qué es importante la confianza y la responsabilidad de todos los actores en el ecosistema de código abierto. Aquí puedes ver nuestra publicación de la muerte de Terraform. Vamos al grano Ya![](https://www.sredevops.org/content/images/icon/Icon-App-76x76@2x.png)SREDevOps.orgNicolás Georger![](https://www.sredevops.org/content/images/thumbnail/tofu-insurance.png)](https://www.sredevops.org/es/opentf-ahora-es-opentofu-y-es-parte-de-linux-foundation-ya-puedes-usar-el-primer-alpha/) ### OpenTofu Registry Gets a User Interface and an API URL: https://www.sredevops.org/en/opentofu-registry-gets-a-user-interface-and-an-api/ Last updated: 2024-09-17T21:17:25.000Z OpenTofu, the open-source Infrastructure as Code (IaC) tool, has launched a user-friendly interface for its component registry. This visual interface, developed in collaboration with Spacelift, aims to simplify IaC adoption by providing a centralized hub for exploring and understanding OpenTofu resources. Alongside the UI, OpenTofu introduces a beta API for programmatic registry access, hosted by Cloudflare. These enhancements are set to empower both newcomers and experienced users in leveraging the full potential of OpenTofu for their infrastructure automation needs. [Terraform ha muerto, ¡Larga vida a OpenTF!(O del por qué es tan importante la comunidad Open Source) En este momento histórico, en que la tecnología está transformando rápidamente nuestro mundo, es fundamental que las personas y organizaciones se comprometan a promover prácticas éticas y sostenibles en su desarrollo y uso. Puedes ver klos detalles del roadmap![](https://www.sredevops.org/content/images/icon/Icon-App-76x76@2x.png)SREDevOps.orgNicolás Georger![](https://www.sredevops.org/content/images/thumbnail/on-dark.png)](https://www.sredevops.org/es/terraform-ha-muerto-larga-vida-a-opentf/) ## The Power of a User-Friendly Registry in the OpenTofu Ecosystem In the ever-evolving landscape of Infrastructure as Code (IaC), having a well-structured and easily navigable registry is paramount. The OpenTofu project, recognizing this need, has taken a significant leap forward by introducing a user interface (UI) for its component registry. This move addresses a critical pain point for many users who previously relied solely on documentation to decipher the intricacies of IaC. The new UI acts as a centralized repository of knowledge, providing a visually appealing and intuitive way to explore the capabilities of OpenTofu. Imagine this: you're working on an OpenTofu project and need to integrate a specific resource, but the documentation feels like navigating a labyrinth. This is where the UI comes to the rescue. Instead of sifting through pages of text, you can now visually browse through available resources, their functionalities, and configuration options. This streamlined approach not only saves time but also makes the learning curve less daunting for newcomers. ## OpenTofu Registry UI: A Game-Changer for IaC Adoption The significance of the OpenTofu Registry UI extends beyond mere convenience. It represents a strategic step towards broader IaC adoption. By lowering the barrier to entry, the UI empowers a wider range of users, from seasoned DevOps engineers to those just beginning their IaC journey, to harness the power of OpenTofu. This inclusivity is crucial for driving the widespread adoption of IaC principles and fostering a more robust and dynamic ecosystem. The UI's impact goes beyond individual users. For organizations, it translates to faster onboarding of new team members, reduced development cycles, and ultimately, a more efficient and agile approach to infrastructure management. The ability to quickly find, understand, and implement OpenTofu resources through a user-friendly interface can significantly impact an organization's bottom line by streamlining operations and reducing the risk of errors. ## A Deep Dive into the OpenTofu Registry UI and API Let's delve deeper into the technical aspects of the OpenTofu Registry UI and API. The UI itself is built on top of the existing OpenTofu Registry, which houses a wealth of information on OpenTofu providers and modules. Each entry in the registry includes comprehensive documentation, examples, and configuration options, making it a one-stop shop for all things OpenTofu. The API, currently in beta, provides a programmatic way to interact with the registry. This opens up a world of possibilities for developers and DevOps engineers looking to automate their workflows. For instance, you can use the API to programmatically search for specific resources, retrieve their documentation, or even integrate the registry data into your own tools and applications. Here's a glimpse of how you can interact with the OpenTofu Registry API using curl: ```bash curl -X GET https://api.opentofu.org/search?q=google | jq ``` This command will retrieve a list of all available OpenTofu providers from the registry. You can further refine your queries by specifying search parameters or targeting specific resources. ## The Future of OpenTofu: Collaboration and Community-Driven Development The development of the OpenTofu Registry UI and API is a testament to the power of open-source collaboration. Spacelift, a leading IaC platform provider, played a pivotal role in bringing the UI to life, while Cloudflare generously provides the infrastructure for hosting the API. This collaborative spirit is at the heart of the OpenTofu project, and it's what sets it apart as a truly community-driven initiative. As OpenTofu continues to evolve, we can expect to see even more exciting developments in the future. The project maintainers are committed to providing a robust and feature-rich IaC tool that meets the needs of a diverse user base. With its new UI and API, OpenTofu is well-positioned to become the go-to solution for organizations and individuals looking to embrace the power of IaC. [IBM continúa devorando: Hashicorp (Terraform) será su próxima adquisiciónIBM lo confirma: Comprará HashiCorp En el mundo de la nube híbrida, se sabía que HashiCorp, creadores de la popular herramienta de infraestructura como código (IaC) Terraform, estaba buscando ser adquirida. También sabíamos que el cambio de la licencia Mozilla de código abierto de Terraform por la Business Source License![](https://www.sredevops.org/content/images/icon/Icon-App-76x76@2x.png)SREDevOps.orgNicolás Georger![](https://www.sredevops.org/content/images/thumbnail/1967_ibm_film14.webp)](https://www.sredevops.org/es/ibm-continua-devorando-hashicorp-terraform-sera-su-proxima-adquisicion/) ### Elastic regresa al código abierto: ¿Qué hay detrás del sorprendente retorno? URL: https://www.sredevops.org/es/elastic-regresa-al-codigo-abierto-que-hay-detras-del-sorprendente-retorno/ Last updated: 2026-01-08T02:36:16.000Z ¿Recuerdas cuando Elastic decidió abandonar al open-source y volverse semi-propietario con sus licencias? Bueno, han vuelto. *¡TA-DA!*. Así es, Elasticsearch y Kibana están adoptando una vez más el "espíritu open-source", esta vez bajo la confiable GNU AGPL. Este giro inesperado se produce después de algunos años de drama con las licencias y un fork algo exitosa por parte de AWS. Si bien algunos son escépticos, este movimiento podría indicar una tendencia más amplia de empresas que regresan al código abierto. ## De Código Abierto a... No-Tan-Abierto... y de vuelta En el mundo de la tecnología en constante evolución, pocas cosas son tan constantes como el cambio mismo. Elastic, la empresa detrás de los populares Elasticsearch y Kibana, ciertamente se ha tomado esto muy en serio con su reciente montaña rusa de licencias. Tan solo tres años después de causar sensación al abandonar la licencia Apache 2.0 por su propia Server Side Public License (SSPL), han dado un giro sorprendente, devolviendo Elasticsearch y Kibana al redil del open-source. Este movimiento inesperado se produce después de que la decisión inicial de la empresa de volverse semi-propietaria provocara controversia y condujera a una bifurcación (fork) de Elasticsearch por parte de nada menos que Amazon Web Services (AWS). OpenSearch de AWS, resultado directo del cambio de licencia de Elastic, ganó una tracción significativa, lo que demuestra que, a veces, las bifurcaciones (forks) pueden ser bastante fructíferas. Entonces, ¿qué provocó el cambio de opinión de Elastic? Según Shay Banon, fundador y CTO de Elastic, la relación de la empresa con AWS ahora es "más fuerte que nunca". También citó la "confusión del mercado" como un factor que contribuyó, probablemente refiriéndose a la disputa de marca registrada sobre el uso de "Amazon Elasticsearch Service" por parte de AWS. Sin embargo, algunos observadores de la industria, como Simon Willison, no están convencidos de estas explicaciones. ## Licencia AGPL: ¿Una Nueva Esperanza para Elasticsearch? El regreso de Elastic al open-source viene con un giro: la adopción de la Licencia Pública General Affero de GNU (AGPL) como una tercera opción de licencia para Elasticsearch y Kibana, junto con su Licencia Elastic (ELv2) y SSPL existentes. La AGPL, a diferencia de sus contrapartes, ha sido reconocida durante mucho tiempo por la Open Source Initiative (OSI) como una verdadera licencia de open-source, lo que convierte a esto en un movimiento significativo para Elastic. La OSI, por su parte, está encantada de dar la bienvenida a Elastic de nuevo a la comunidad open-source. Stefano Maffulli, director ejecutivo de la OSI, destacó la importancia de la naturaleza (copyleft) de la AGPL, que garantiza las libertades de los usuarios y otorga a los desarrolladores un fuerte control sobre sus proyectos. ## ¿Una Señal de lo que viene? El regreso de Elastic al open-source podría indicar una tendencia más amplia de empresas que reconsideran sus estrategias de licencia. A medida que el panorama del open-source continúa evolucionando, las empresas pueden descubrir que los beneficios de la colaboración comunitaria y una adopción más amplia superan las ventajas percibidas de los modelos propietarios. Sin embargo, no todos están convencidos de que el compromiso de Elastic con el open-source esté escrito en piedra. Peter Zaitsev, fundador de Percona, si bien reconoció los aspectos positivos de la medida, cuestionó si Elastic puede recuperar plenamente la confianza de la comunidad open-source. ## El negocio del código abierto La serie de cambios de licencias de Elastic se desarrolló en el contexto de su desempeño financiero. Si bien la empresa reportó un fuerte crecimiento de ingresos, el precio de sus acciones se vio afectado debido a las preocupaciones sobre los compromisos futuros de los clientes. Esto destaca el delicado equilibrio al que se enfrentan las empresas dentro del ecosistema open-source y los negocios. Solo el tiempo dirá cómo el regreso de Elastic al open-source afectará a sus productos, su relación con la comunidad y sus resultados finales. Una cosa es segura: el mundo del open-source prospera con el cambio, y el viaje de Elastic es un testimonio de ello. ## Links - [What's Behind Elastic's Unexpected Return to Open Source?](https://thenewstack.io/whats-behind-elastics-unexpected-return-to-open-source/?ref=sredevops.org) - [Elasticsearch](https://www.elastic.co/elasticsearch?ref=sredevops.org) - [Kibana](https://www.elastic.co/kibana?ref=sredevops.org) - [GNU Affero General Public License (AGPL)](https://www.gnu.org/licenses/agpl-3.0.en.html?ref=sredevops.org) - [Open Source Initiative (OSI)](https://opensource.org/?ref=sredevops.org) ### Elastic Swims Back to Open Source: What's Behind the Unexpected Return? URL: https://www.sredevops.org/en/elastic-swims-back-to-open-source-whats-behind-the-unexpected-return/ Last updated: 2024-09-05T07:20:21.000Z Remember when Elastic decided to ditch the open-source life and go semi-proprietary with their licensing? Well, hold onto your hats, because they're back! That's right, Elasticsearch and Kibana are once again embracing the open-source ethos, this time under the trusty GNU AGPL. This unexpected U-turn comes after a few years of licensing drama and a somewhat successful fork by AWS. While some are skeptical, this move could signal a broader trend of companies returning to the open-source fold. ## From Open Source to... Not-So-Open Source... and Back Again In the ever-evolving world of technology, few things are as constant as change itself. Elastic, the company behind the wildly popular Elasticsearch and Kibana, has certainly taken this to heart with their recent licensing rollercoaster. Just three years after making waves by abandoning the Apache 2.0 license for their own Server Side Public License (SSPL), they've made a surprising U-turn, bringing Elasticsearch and Kibana back to the open-source fold. This unexpected move comes after the company's initial decision to go semi-proprietary sparked controversy and led to a fork of Elasticsearch by none other than Amazon Web Services (AWS). AWS's OpenSearch, a direct result of Elastic's licensing shift, gained significant traction, proving that sometimes, forks can be quite fruitful. So, what prompted Elastic's change of heart? According to Shay Banon, Elastic's founder and CTO, the company's relationship with AWS is now "stronger than ever." He also cited "market confusion" as a contributing factor, likely referring to the trademark dispute over AWS's use of "Amazon Elasticsearch Service." However, some industry observers, like Simon Willison, remain unconvinced by these explanations. ## The AGPL: A New Hope for Open Source Elasticsearch? Elastic's return to open source comes with a twist: the adoption of the GNU Affero General Public License (AGPL) as a third licensing option for Elasticsearch and Kibana, alongside their existing Elastic License (ELv2) and SSPL. The AGPL, unlike its counterparts, has long been recognized by the Open Source Initiative (OSI) as a true open-source license, making this a significant move for Elastic. The OSI, for its part, is thrilled to welcome Elastic back into the open-source community. Stefano Maffulli, the OSI's executive director, highlighted the importance of the AGPL's copyleft nature, which ensures user freedoms and grants developers strong control over their projects. ## A Sign of Things to Come? Elastic's return to open source could signal a broader trend of companies reconsidering their licensing strategies. As the open-source landscape continues to evolve, companies may find that the benefits of community collaboration and wider adoption outweigh the perceived advantages of proprietary models. However, not everyone is convinced that Elastic's commitment to open source is set in stone. Peter Zaitsev, founder of Percona, while acknowledging the positive aspects of the move, questioned whether Elastic can fully regain the trust of the open-source community. ## The Business of Open Source Elastic's licensing saga unfolded against the backdrop of its financial performance. While the company reported strong revenue growth, its stock price took a hit due to concerns about future customer commitments. This highlights the delicate balance that companies face when navigating the worlds of open source and business. Only time will tell how Elastic's return to open source will impact its products, its relationship with the community, and its bottom line. One thing is certain: the open-source world thrives on change, and Elastic's journey is a testament to that. ## Links and Resources - [What's Behind Elastic's Unexpected Return to Open Source?](https://thenewstack.io/whats-behind-elastics-unexpected-return-to-open-source/?ref=sredevops.org) - [Elasticsearch](https://www.elastic.co/elasticsearch?ref=sredevops.org) - [Kibana](https://www.elastic.co/kibana?ref=sredevops.org) - [GNU Affero General Public License (AGPL)](https://www.gnu.org/licenses/agpl-3.0.en.html?ref=sredevops.org) - [Open Source Initiative (OSI)](https://opensource.org/?ref=sredevops.org) ### Participa en el COBIT DAY 2024 organizado por ISACA Santiago Chapter y conoce cómo optimizar tus estrategias en TI URL: https://www.sredevops.org/es/participa-en-el-cobit-day-2024-organizado-por-isaca-santiago-chapter-y-conoce-como-optimizar-tus-estrategias-en-ti/ Last updated: 2026-01-08T02:36:16.000Z ¡Prepárate para el COBIT DAY 2024 organizado por ISACA Santiago Chapter! Este evento, que tendrá lugar el 26 de septiembre, ofrece una oportunidad única para conocer el mundo de COBIT y su relevancia en la gobernanza y gestión de las tecnologías de la información. **Entre sus principales expositores, se encuentra nuestro colaborador Rudy Pinochet, experto en ciberseguridad y gobernanza de TI.** Con opciones de asistencia presencial y en línea, este evento promete una experiencia enriquecedora para todos los interesados en fortalecer sus conocimientos en este importante marco de trabajo como también para optimizar tus estrategias de TI en tu negocio u organización. 0:00 /0:15 1× ## ¿Qué es COBIT y por qué debería importarte? COBIT, abreviatura de Control Objectives for Information and Related Technologies (Objetivos de Control para las Tecnologías de Información y relacionadas), es un marco de trabajo desarrollado por ISACA (Information Systems Audit and Control Association) que proporciona una guía completa para la gobernanza y gestión de las tecnologías de la información (TI). En un mundo cada vez más digitalizado, donde las empresas dependen en gran medida de la tecnología, COBIT se ha convertido en un estándar de facto para garantizar la seguridad, el cumplimiento y el valor empresarial de las TI. Podríamos entender COBIT como un GPS para tu estrategia de TI. Así como un GPS te ayuda a navegar por carreteras desconocidas, COBIT proporciona un conjunto de mejores prácticas, herramientas y guías para ayudarte a navegar por el complejo panorama de la gestión de TI. Ya sea que seas un CIO, un gerente de TI, un auditor o un profesional de seguridad, COBIT te proporciona un lenguaje común y un marco de referencia para alinear las TI con los objetivos empresariales, gestionar los riesgos y optimizar los recursos. ## Únete a la celebración del COBIT DAY 2024 El COBIT DAY 2024, organizado por ISACA Santiago Chapter, es una oportunidad única para sumergirse en el mundo de COBIT y conectarse con otros profesionales de la industria. El evento tendrá lugar el 26 de septiembre en Cerro El Plomo 5420, Zócalo -1, Las Condes, y también se transmitirá en línea para aquellos que prefieran asistir virtualmente. Durante el evento, podrás: - Profundizar en los principios y componentes de COBIT. - Conocer las últimas actualizaciones y tendencias en gobernanza y gestión de TI. - Participar en talleres prácticos y casos de estudio. - Conectar con expertos de la industria y ampliar tu red de contactos. Ya sea que seas un experto en COBIT o recién estés comenzando tu viaje en la gobernanza de TI, este evento te proporcionará información valiosa y te ayudará a mantenerte a la vanguardia en este campo en constante evolución. ¡No te pierdas esta oportunidad única de aprender, conectar y celebrar el poder de COBIT! ## Información del evento: - **Fecha:** 26 de septiembre - **Lugar:** Cerro El Plomo 5420, Zócalo -1, Las Condes (Exclusivo para miembros) - **Modalidad:** Presencial y online - **Sponsor:** Inside Security Para registrarte y obtener más información, visita el siguiente enlace: [CobitDay 2024 ISACA Santiago Chapter.![](https://cdn.evbstatic.com/s3-build/prod/1724745-rc2024-09-04_16.04-20fdfb4/django/images/favicons/safari-pinned-tab.svg)Eventbrite![](https://img.evbuc.com/https%3A%2F%2Fcdn.evbuc.com%2Fimages%2F792104559%2F1884343814693%2F1%2Foriginal.20240618-210356?w=1000&auto=format%2Ccompress&q=75&sharp=10&rect=0%2C0%2C1600%2C800&s=51eb37bb423110aaf89c4d8fb88a43c0)](https://www.eventbrite.cl/e/cobitday-2024-isaca-santiago-chapter-tickets-1002721395687?ref=sredevops.org) ¡No te pierdas esta oportunidad única de ser parte de la comunidad COBIT y llevar tu carrera al siguiente nivel! [ISACA Santiago Chapter on LinkedIn: #isacasantiago #audit #cobit¡🎉 Nos complace anunciar el COBIT DAY 2024 🎉 de ISACA Santiago Chapter! 🗓 Fecha: 26 de septiembre 📍 Locación: Cerro El Plomo 5420, Zócalo -1, Las Condes…![](https://static.licdn.com/aero-v1/sc/h/al2o9zrvru7aqj8e1x2rzsrca)LinkedInISACA Santiago Chapter![](https://media.licdn.com/dms/image/v2/D4E05AQGO8v17yIh7kg/videocover-high/videocover-high/0/1724772726834?e=2147483647&v=beta&t=Nfb-86tFMzmAUNxg00RDoI8z-5uTz3si6uzdWbf26zQ)](https://www.linkedin.com/posts/isacasantiagochapter%5Fisacasantiago-audit-cobit-ugcPost-7234221124404850688-mqUe?utm%5Fsource=share&utm%5Fmedium=member%5Fdesktop) ### New risks of WebAssembly (WASM): A Hidden Door for Malware? URL: https://www.sredevops.org/en/new-risks-of-webassembly-wasm-a-hidden-door-for-malware/ Last updated: 2024-08-30T04:35:55.000Z Secure Web Gateways (SWGs) are increasingly vulnerable to 'Last Mile Reassembly Attacks' that leverage WebAssembly (WASM) to deliver malware directly to user browsers. These attacks bypass traditional SWG defenses, highlighting the need for browser-native security solutions to protect against modern web threats. ## What is WebAssembly (WASM)? WebAssembly (WASM) is a binary instruction format that allows developers to compile code written in languages like C, C++, and Rust into a platform-agnostic, executable format that can be run in web browsers. This technology has revolutionized the way we build web applications, enabling faster execution, improved performance, and enhanced security. However, as we'll explore in this article, WASM's power can also be exploited by malicious actors. [What is Web Assembly (WASM) and what is it for?Have you heard of WebAssembly (Wasm)? In simple: It is a new way of where and how the source code is processed, moving the load from cloud instances (or servers, etc.) to the end user’s browser through “micro sandboxes” that will compile the app. Imagine Wasm is an actor that![](https://www.sredevops.org/content/images/2024/07/Icon-App-76x76@2x.png)SREDevOps.orgNicolás Georger![](https://www.sredevops.org/content/images/2023/08/wasm.webp)](https://www.sredevops.org/en/what-is-web-assembly-wasm-and-what-is-it-for/) ## What is a Secure Web Gateway (SWG)? A Secure Web Gateway (SWG) is a cybersecurity product that protects company data and enforces security policies. SWGs operate between company employees and the Internet, filtering unsafe content from web traffic to stop cyber threats and data breaches. They also block risky or unauthorized user behavior. All SWG products contain essential technologies like URL filtering, anti-malware detection and blocking, and application control. ## What is a Last Mile Reassembly Attack? A Last Mile Reassembly Attack is a type of cyber attack that targets the final leg of a data transmission process, also known as the "last mile." This type of attack is particularly dangerous because it occurs when data is being transmitted from a secure network to its final destination, such as a user's device. During a Last Mile Reassembly Attack, a hacker intercepts and alters the data as it is being transmitted over the last mile, allowing them to gain access to sensitive information, such as login credentials or financial data. ## The Rise of Last Mile Reassembly Attacks At DEF CON 32, SquareX Labs unveiled groundbreaking research exposing vulnerabilities in Secure Web Gateways (SWGs). These vulnerabilities allow attackers to execute 'Last Mile Reassembly Attacks,' bypassing traditional SWG defenses and delivering known malware directly to endpoints. This poses a significant threat to organizations that rely solely on SWGs for security. ## WebAssembly: A Double-Edged Sword One of the most concerning aspects of these attacks is the use of WebAssembly (WASM). While WASM offers numerous benefits, such as enhanced performance and efficiency in web applications, its power can also be exploited by malicious actors. Traditional SWGs primarily focus on inspecting network traffic at the HTML, CSS, and JavaScript layers, leaving them blind to the intricacies of WASM modules. ## SWGs vs. WebAssembly: A Mismatch The problem lies in the fact that SWGs lack the capability to perform dynamic analysis on WASM code. This means malicious payloads can be embedded within WASM modules and distributed through compromised or even legitimate websites, bypassing SWG detection mechanisms entirely. On the client-side, the malware is assembled and downloaded to the victim's endpoint. ## The Need for Browser-Native Security This vulnerability underscores the limitations of relying solely on network-layer defenses like SWGs in today's threat landscape. Enterprises need to adopt browser-native security solutions that operate directly within the browser, providing real-time analysis and control over WASM modules. These solutions offer a more effective approach to detecting and neutralizing threats before they can cause damage. ## Protecting Your Organization As WebAssembly continues to gain prominence in web development, organizations must recognize the evolving threat landscape and take proactive steps to protect their environments. This includes evaluating existing SWG capabilities and implementing browser-native security solutions designed to handle the complexities of modern web technologies. ## Sources: [WebAssembly diversification for malware evasionWebAssembly has become a crucial part of the modern web, offering a faster alternative to JavaScript in browsers. While boosting rich applications in …![](https://static.ghost.org/v5.0.0/images/link-icon.svg)ScienceDirectAuthor links open overlay panelJavier Cabrera-Arteaga, Martin Monperrus, Tim Toady, Benoit Baudry![](https://ars.els-cdn.com/content/image/1-s2.0-S0167404823X00066-cov150h.gif)](https://www.sciencedirect.com/science/article/pii/S0167404823002067?ref=sredevops.org) [https://www.cloudflare.com/learning/access-management/what-is-a-secure-web-gateway/](https://www.cloudflare.com/learning/access-management/what-is-a-secure-web-gateway/?ref=sredevops.org) [WebAssembly: The Fly on the Wall Delivering Malware Past Secure Web Gateways‘Last Mile Reassembly Attacks’ evade every Secure Web Gateway in the market and deliver known malware to the endpoint![](https://miro.medium.com/v2/resize:fill:304:304/10fd5c419ac61637245384e7099e131627900034828f4f386bdaa47a74eae156)SquareX LabsEngineering SquareX![](https://miro.medium.com/v2/resize:fit:1200/1*MPC7mQHpSLzSV8aTycgCbQ.jpeg)](https://labs.sqrx.com/webassembly-delivering-malware-past-secure-web-gateways-f047d1da252a?ref=sredevops.org) ### How to deploy Ghost CMS on Kubernetes URL: https://www.sredevops.org/en/how-to-deploy-ghost-cms-on-kubernetes/ Last updated: 2025-12-09T20:15:28.000Z ## Ghost on Kubernetes (v6.x) by SREDevOps.Org Deploy the leading open-source publishing platform, Ghost, on Kubernetes with maximum **security** and **efficiency** using a hardened, multi-arch container image. Maintained by [***SREDevOps.org***](https://www.sredevops.org/)*: SRE, DevOps, Linux, Ethical Hacking, AI, ML, Open Source, Cloud Native, Platform Engineering in English, Español, and Portugués (Brasil).* **Key Highlights: Security & Efficiency** This repository implements Ghost CMS v6.xx.x from [@TryGhost (Official)](https://github.com/TryGhost/Ghost?ref=sredevops.org) on Kubernetes with a custom built image, which delivers significant improvements for production use and security features in Kubernetes. [GitHub - sredevopsorg/ghost-on-kubernetes: Ghost on Kubernetes by SREDevOps.org - Deploy Ghost v6 on Kubernetes (k8s, k3s, etc) with our hardened distroless non root custom image.Ghost on Kubernetes by SREDevOps.org - Deploy Ghost v6 on Kubernetes (k8s, k3s, etc) with our hardened distroless non root custom image. - sredevopsorg/ghost-on-kubernetes![](https://www.sredevops.org/content/images/icon/pinned-octocat-093da3e6fa40-25.svg)GitHubsredevopsorg![](https://www.sredevops.org/content/images/thumbnail/395b82c9-df81-4aee-95a5-4269616a550f-3)](https://github.com/sredevopsorg/ghost-on-kubernetes?ref=sredevops.org) ### **Enhanced Security** - **Non-Root Execution:** Both the Ghost and MySQL components run exclusively as a non-root user (UID/GID 65532) in Kubernetes, preventing potential privilege escalation attacks. - **Distroless Runtime:** We utilize **Google Container Tools Distroless Debian 13 - NodeJS 22** as the final runtime environment. Distroless images contain only the required application and language dependencies, **excluding shells and package managers**, making them substantially more secure and reducing the attack surface. - **Vulnerability Reduction:** By replacing gosu with a native container execution flow and adopting Distroless, we removed several critical vulnerabilities reported in the original Ghost image: - **Result:** This change alone reduced **6 critical vulnerabilities** and **34 high vulnerabilities** reported by Docker Scout in the official image. **Example Security Reports:** | Ghost Official Image | Ghost on Kubernetes Image | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Example scan for the [Ghost Official Image](https://hub.docker.com/%5F/ghost/tags?ref=sredevops.org): ![Docker Scout Report - Ghost Official Image](https://raw.githubusercontent.com/sredevopsorg/ghost-on-kubernetes/main/docs/images/dockerhub-ghost.png) | Example of our [Ghost on Kubernetes Image on Docker Hub](https://hub.docker.com/r/ngeorger/ghost-on-kubernetes/tags?ref=sredevops.org): ![Docker Scout Report - Ghost on Kubernetes Image](https://raw.githubusercontent.com/sredevopsorg/ghost-on-kubernetes/main/docs/images/dockerhub-ngeorger.png) | ### **Performance & Architecture** - **Custom Build Artifacts:** We maintain two distinct Dockerfiles for production and development: - **Production Image:** The main image built using our hardened, multi-stage build process. See the [Dockerfile](https://github.com/sredevopsorg/ghost-on-kubernetes/blob/main/Dockerfile?ref=sredevops.org). - **Development Image:** A variant tailored for testing, which bundles SQLite support. See the [Dockerfile-dev](https://github.com/sredevopsorg/ghost-on-kubernetes/blob/main/Dockerfile-dev?ref=sredevops.org). - **Multi-Arch Support:** Images are built for both amd64 and arm64 architectures. - **Multi-Stage Build:** We use the official Node 22 Jod LTS image for building, which significantly reduces the final image size and improves security by removing unnecessary build components. - **Updated Ghost v6 & NodeJS 22 LTS:** Using the latest stable versions for security and performance. - **Robust Entrypoint (entrypoint.js):** A custom Node.js entrypoint script, executed by the unprivileged user, handles necessary runtime operations like updating default themes before starting the Ghost application. The script can be reviewed here: [entrypoint.js](https://github.com/sredevopsorg/ghost-on-kubernetes/blob/main/entrypoint.js?ref=sredevops.org). - **Dedicated Init Container:** The deployment includes an initContainer to handle directory creation, correct ownership (UID/GID 65532), and permission setting prior to the main Ghost container launch, ensuring seamless operation inside the Distroless container. ## **Deployment Architecture Overview** This project provides complete Kubernetes manifest files (deploy/) to run a production-ready Ghost instance backed by a MySQL database. | Resource | Components | Details | | -------------------------------- | -------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Namespace** | ghost-on-kubernetes | Provides logical isolation for all components. (File: [00-namespace.yaml](https://github.com/sredevopsorg/ghost-on-kubernetes/blob/main/deploy/00-namespace.yaml?ref=sredevops.org)) | | **StatefulSet** | ghost-on-kubernetes-mysql | Manages the MySQL 8 database, ensuring stable networking and persistent storage. (File: [05-mysql.yaml](https://github.com/sredevopsorg/ghost-on-kubernetes/blob/main/deploy/05-mysql.yaml?ref=sredevops.org)) | | **Deployment** | ghost-on-kubernetes | Manages the Ghost v6 application pods. (File: [06-ghost-deployment.yaml](https://github.com/sredevopsorg/ghost-on-kubernetes/blob/main/deploy/06-ghost-deployment.yaml?ref=sredevops.org)) | | **Services** | ghost-on-kubernetes-service, ghost-on-kubernetes-mysql-service | Exposes Ghost (2368) and MySQL (3306) internally within the cluster. (File: [03-service.yaml](https://github.com/sredevopsorg/ghost-on-kubernetes/blob/main/deploy/03-service.yaml?ref=sredevops.org)) | | **PersistentVolumeClaims (PVC)** | k8s-ghost-content, ghost-on-kubernetes-mysql-pvc | Requests persistent storage for Ghost content (themes, images) and MySQL data. (File: [02-pvc.yaml](https://github.com/sredevopsorg/ghost-on-kubernetes/blob/main/deploy/02-pvc.yaml?ref=sredevops.org)) | | **Secrets** | ghost-config-prod, ghost-on-kubernetes-mysql-env, tls-secret | Securely stores Ghost configuration, database credentials, and TLS certificates (optional). (Files: [01-mysql-config.yaml](https://github.com/sredevopsorg/ghost-on-kubernetes/blob/main/deploy/01-mysql-config.yaml?ref=sredevops.org), [04-ghost-config.yaml](https://github.com/sredevopsorg/ghost-on-kubernetes/blob/main/deploy/04-ghost-config.yaml?ref=sredevops.org), [01-tls.yaml](https://github.com/sredevopsorg/ghost-on-kubernetes/blob/main/deploy/01-tls.yaml?ref=sredevops.org)) | | **Ingress** | ghost-on-kubernetes-ingress | Exposes the Ghost application to the outside world via HTTP/HTTPS (requires a TLD). (File: [07-ingress.yaml](https://github.com/sredevopsorg/ghost-on-kubernetes/blob/main/deploy/07-ingress.yaml?ref=sredevops.org)) | *Note*: You can host multiple Ghost instances by replacing the Namespace specification in each manifest file. ## **Installation Instructions (Production)** Follow these steps to deploy Ghost on your Kubernetes cluster. ### **Prerequisites** 1. A functioning Kubernetes cluster (kubectl configured). 2. A provisioned StorageClass (required for PVCs). ### **0\. Clone (or fork) the Repository** ```bash ## Clone the repository git clone https://github.com/sredevopsorg/ghost-on-kubernetes.git --depth 1 --branch main --single-branch --no-tags ## Change directory cd ghost-on-kubernetes ``` ### **1\. Review and Configure** Review the example configuration files and modify the manifests in the deploy/ folder to suit your environment (e.g., storage class, domain name, secret values). - **Configurations:** Check the example configuration files in the [examples/](https://github.com/sredevopsorg/ghost-on-kubernetes/blob/main/examples/?ref=sredevops.org) directory: - config.production.sample.yaml: Recommended configuration using MySQL 8\. Requires a valid top-level domain (TLD) for the url field and Ingress configuration. - config.development.sample.yaml: Uses SQLite for testing environments. - **Official Ghost Docs:** Refer to the [official Ghost documentation](https://ghost.org/docs/config/?ref=sredevops.org#custom-configuration-files) for detailed configuration options. ### **2\. Deployment Sequence** It is **crucial** to apply the manifests in the correct order to ensure dependency resolution (especially the database components). **Expose Ghost with Ingress (Optional/Recommended):** ```bash # Routes external traffic to the Ghost Service kubectl apply -f deploy/07-ingress.yaml ``` **Deploy the Ghost Application (Deployment):** ```bash # Wait for MySQL to be ready before starting kubectl apply -f deploy/06-ghost-deployment.yaml ``` **Deploy MySQL Database (StatefulSet):** ```bash # Wait for the MySQL PVC to be bound kubectl apply -f deploy/05-mysql.yaml ``` **Create Persistent Storage and Services:** ```bash kubectl apply -f deploy/02-pvc.yaml kubectl apply -f deploy/03-service.yaml ``` **Create Secrets (Credentials and Config):** ```bash # IMPORTANT: Customize these secrets before applying kubectl apply -f deploy/01-mysql-config.yaml kubectl apply -f deploy/04-ghost-config.yaml kubectl apply -f deploy/01-tls.yaml ``` **Create the Namespace:** ```bash kubectl apply -f deploy/00-namespace.yaml ``` ## **Your Ghost Blog is Deployed!** Congratulations! You have deployed a highly secure and scalable Ghost v6 instance on Kubernetes. ### **Accessing Without a Domain Name (Testing)** To preview the website without configuring Ingress or a TLD, you can use port forwarding: 1. Temporarily configure both url and admin URLs in your config.production.json Secret to use `http://localhost:2368/`. 2. Restart the Ghost pod(s) after updating the Secret. 3. Run the port-forwarding command: ```bash kubectl port-forward -n ghost-on-kubernetes services ghost-on-kubernetes-service 2368:2368 ``` ## Contributing We welcome contributions from the community! Please check the [CONTRIBUTING.md](https://github.com/sredevopsorg/ghost-on-kubernetes/blob/main/CONTRIBUTING.md?ref=sredevops.org) file for more information on how to contribute to this project. ## License and Credits - This project is licensed under the MIT License. Please check the [LICENSE](https://github.com/sredevopsorg/ghost-on-kubernetes/blob/main/LICENSE?ref=sredevops.org) file for more information. - The Ghost CMS is licensed under the [MIT License](https://github.com/TryGhost/Ghost/blob/main/LICENSE?ref=sredevops.org). - The node image and the Distroless image are licensed by their respective owners. ## Star History ![Star History Chart](https://api.star-history.com/svg?repos=sredevopsorg/ghost-on-kubernetes&type=Date&theme=dark) ### Quantum Internet is Real and it's an Underground Network in NYC, USA URL: https://www.sredevops.org/en/quantum-internet-is-real-and-its-an-underground-network-in-nyc-usa/ Last updated: 2024-08-25T10:01:14.000Z Qunnect Inc., a Brooklyn-based company, has successfully operated a prototype quantum internet network under the streets of New York City for 15 continuous days. This achievement marks a significant step towards the development of a practical and stable quantum internet. The network, called GothamQ, utilizes polarization-entangled photons and features automated polarization compensation (APC) devices to mitigate the effects of fiber environment disturbances. The results, published in *PRX Quantum*, demonstrate the feasibility of long-term, stable entanglement distribution over metropolitan fiber networks. ![](https://www.sredevops.org/content/images/2024/08/image-2.png) **Schematic of the 34km loop within the GothamQ testbed used for the study. The inset diagrams show the experimental apparatus prior to photons entering and exiting the deployed fiber.. Source:* [https://www.prnewswire.com/news-releases/qunnect-achieves-record-breaking-performance-for-distributing-polarization-qubits-on-gothamq-network-in-nyc-302116594.html](https://www.prnewswire.com/news-releases/qunnect-achieves-record-breaking-performance-for-distributing-polarization-qubits-on-gothamq-network-in-nyc-302116594.html?ref=sredevops.org) ## The Challenge of Quantum Networks The development of quantum networks faces a major hurdle: the fragility of entangled states in fiber cables. Entanglement, a fundamental quantum phenomenon, is essential for secure communication and powerful computation. However, entangled photons are highly susceptible to disturbances caused by vibrations, bending, and temperature fluctuations within fiber cables. These disturbances can lead to rapid degradation of entanglement, making it difficult to maintain stable connections over long distances. ## Qunnect's GothamQ Network Qunnect's GothamQ network tackles this challenge head-on. The network utilizes a leased 34-kilometer-long fiber circuit, operating for 15 continuous days with an uptime of 99.84%. The network transmits polarization-entangled photon pairs at a rate of about 20,000 per second, achieving a compensation fidelity of 99%. This means that the entangled photons remain in their desired state with high accuracy, even after traveling through the fiber network. ## Automated Polarization Compensation To achieve this remarkable stability, Qunnect has developed automated polarization compensation (APC) devices. These devices continuously monitor and correct the polarization of the entangled photons as they travel through the fiber. By sending classical photon pairs with known polarizations, the APCs can measure and compensate for any polarization drift caused by environmental disturbances. ## Significance of the GothamQ Demonstration The GothamQ demonstration is significant for several reasons: - **Long-term stability:** The network's 15-day continuous operation with high uptime demonstrates the feasibility of long-term, stable entanglement distribution. - **Automated operation:** The use of APCs enables hands-off operation, reducing the need for frequent recalibrations. - **Metropolitan scale:** The network's operation over a 34-kilometer metropolitan fiber circuit showcases its potential for real-world applications. ## The Future of Quantum Internet Qunnect's GothamQ network represents a major step towards the realization of a practical and scalable quantum internet. The company's success in overcoming the challenges of entanglement distribution over long distances paves the way for future advancements in quantum communication, computation, and sensing. ## Code Example: Simulating Photon Polarization in Python While we can't quite simulate quantum entanglement with classical code, we can represent photon polarization and its manipulation using Python libraries like NumPy: ```python import numpy as np # Define a photon as a 2D vector representing its polarization state photon = np.array([1, 0]) # Horizontally polarized photon # Define a polarization rotation matrix (e.g., for a 45-degree rotation) rotation_angle = np.radians(45) rotation_matrix = np.array([[np.cos(rotation_angle), -np.sin(rotation_angle)], [np.sin(rotation_angle), np.cos(rotation_angle)]]) # Rotate the photon's polarization rotated_photon = np.dot(rotation_matrix, photon) print("Original photon polarization:", photon) print("Rotated photon polarization:", rotated_photon) ``` ```bash # Output: # Original photon polarization: [1 0] # Rotated photon polarization: [0.70710678 0.70710678] ``` > This code snippet provides a basic illustration of how photon polarization can be represented and manipulated mathematically. In a real-world quantum network, the principles of quantum mechanics govern the behavior of entangled photons, enabling secure communication and other groundbreaking applications. ## Links - [Research paper in *PRX Quantum*](https://link.aps.org/doi/10.1103/PRXQuantum.5.030330?ref=sredevops.org) [Automated Distribution of Polarization-Entangled Photons Using Deployed New York City FibersProgress toward practical, large-scale quantum networks is achieved via a demonstration of long-term, high-quality polarization-entanglement distribution.![](https://cdn.journals.aps.org/development/journals/images/favicon.ico)PRX QuantumAlexander N. Craddock![](https://cdn.journals.aps.org/journals/PRXQUANTUM/key_images/10.1103/PRXQuantum.5.030330.png)](https://link.aps.org/doi/10.1103/PRXQuantum.5.030330?ref=sredevops.org) ### Source: - Physics Magazine article [Test of a prototype quantum internet runs under New York City for half a monthTo introduce quantum networks into the marketplace, engineers must overcome the fragility of entangled states in a fiber cable and ensure the efficiency of signal delivery. Now, scientists at Qunnect Inc. in Brooklyn, New York, have taken a large step forward by operating just such a network under the streets of New York City.![](https://phys.b-cdn.net/favicon.ico)Phys.orgDavid Appell![](https://scx2.b-cdn.net/gfx/news/hires/2024/test-of-a-prototype-qu.jpg)](https://phys.org/news/2024-08-prototype-quantum-internet-york-city.html?ref=sredevops.org) ### OpenCTI: The Open-Source Cyber Threat Intelligence Platform URL: https://www.sredevops.org/en/opencti-the-open-source-cyber-threat-intelligence-platform/ Last updated: 2025-08-31T21:29:31.000Z ## TL/DR OpenCTI is an open-source platform designed to help organizations manage their cyber threat intelligence (CTI) data and observables. Developed by Filigran, it uses a knowledge schema built on the STIX2 standards and features a modern web application architecture with a GraphQL API and a user-friendly front end. OpenCTI integrates with other tools like MISP and TheHive, making it a central hub for cyber threat intelligence management. The platform ensures data traceability, interlinks data points, tracks first and last-seen dates, assesses confidence levels, and more. It is integrated with the MITRE ATT&CK framework and is available for free on GitHub. ## What is OpenCTI? In the ever-evolving landscape of cybersecurity, staying ahead of threats is crucial. OpenCTI, an open-source platform developed by Filigran, is designed to help organizations manage their cyber threat intelligence (CTI) data and observables effectively. This platform structures its data using a knowledge schema built on the STIX2 standards, ensuring that every piece of information is traceable back to its source. OpenCTI features a modern web application architecture with a GraphQL API and a user-friendly front end. This architecture not only makes the platform accessible but also ensures that it can handle complex queries and data interactions efficiently. The GraphQL API allows for flexible and efficient data retrieval, making it easier for users to interact with the platform. ## Integration and Capabilities One of the standout features of OpenCTI is its ability to integrate with other tools and applications, such as MISP and TheHive. This integration enhances its capability to serve as a central hub for cyber threat intelligence management. By connecting with these tools, OpenCTI can aggregate data from multiple sources, providing a comprehensive view of the threat landscape. The platform offers several key features that make it a powerful tool for cyber threat intelligence management. These include interlinking data points, tracking first and last-seen dates, assessing confidence levels, and more. The tool is also integrated with the MITRE ATT&CK framework via a dedicated connector, which assists in structuring the data. However, users can also incorporate their datasets, making the platform highly customizable. ## Data Processing and Visualization Once analysts within OpenCTI have processed and curated the data, the tool can infer new relationships from the existing ones. This capability enhances the understanding and visualization of the information, empowering users to extract valuable insights and leverage meaningful knowledge from the raw data. The platform's ability to visualize data and infer relationships makes it an invaluable tool for threat intelligence analysts. For example, if an analyst identifies a new threat, OpenCTI can help visualize how this threat relates to other known threats, providing a holistic view of the threat landscape. This visualization can help organizations prioritize their response efforts and allocate resources more effectively. ## Deployment and Availability OpenCTI is available for free on [GitHub](https://github.com/OpenCTI-Platform/?ref=sredevops.org). All components are shipped as Docker images and manual installation packages. For a production deployment, the developers recommend deploying all components in containers, including dependencies, using native cloud services or orchestration systems such as Kubernetes. This approach ensures that the platform is scalable, reliable, and easy to manage. Here is an example of how you can deploy OpenCTI using Docker Compose: [Installation - OpenCTI DocumentationDocumentation about OpenCTI, the next-generation Cyber Threat Intelligence platform.![](https://docs.opencti.io/latest/assets/images/favicon.png)logoFiligran![](https://avatars.githubusercontent.com/u/14978633?v=4&size=72)](https://docs.opencti.io/latest/deployment/installation/?ref=sredevops.org#using-docker) How to install OpenCTI > (It's basically `git clone https://github.com/OpenCTI-Platform/docker.git` and setting up your .env) [GitHub - OpenCTI-Platform/opencti: Open Cyber Threat Intelligence PlatformOpen Cyber Threat Intelligence Platform. Contribute to OpenCTI-Platform/opencti development by creating an account on GitHub.![](https://www.sredevops.org/content/images/icon/pinned-octocat-093da3e6fa40-21.svg)GitHubOpenCTI-Platform![](https://www.sredevops.org/content/images/thumbnail/opencti)](https://github.com/OpenCTI-Platform/opencti?ref=sredevops.org) ## Tooling for DevSecOps OpenCTI is a powerful open-source platform that helps organizations manage their cyber threat intelligence data effectively. With its modern architecture, integration capabilities, and advanced features, it serves as a central hub for cyber threat intelligence management. The platform's ability to visualize data and infer relationships makes it an invaluable tool for threat intelligence analysts. Available for free on GitHub, OpenCTI is a must-have for any organization looking to enhance its cybersecurity posture. [OpenCTI PlatformOpen Cyber Threat Intelligence Platform. OpenCTI Platform has 7 repositories available. Follow their code on GitHub.![](https://github.githubassets.com/assets/pinned-octocat-093da3e6fa40.svg)GitHub![](https://avatars.githubusercontent.com/u/51881218?s=280&v=4)](https://github.com/OpenCTI-Platform/?ref=sredevops.org) ## Links to Resources - [OpenCTI GitHub Repository](https://github.com/OpenCTI-Platform/?ref=sredevops.org) - [MITRE ATT&CK Framework](https://www.helpnetsecurity.com/2024/03/15/2023-attck-techniques/?ref=sredevops.org) - [MISP Project](https://www.misp-project.org/?ref=sredevops.org) - [TheHive Project](https://thehive-project.org/?ref=sredevops.org) Source: [OpenCTI: Open-source cyber threat intelligence platform - Help Net SecurityOpenCTI is an open-source platform designed to help organizations manage their cyber threat intelligence (CTI) data and observables.![](https://www.helpnetsecurity.com/wp-content/themes/hns24/icon.svg)Help Net SecurityHelp Net Security![](https://img.helpnetsecurity.com/wp-content/uploads/2024/08/12122255/opencti-1600.webp)](https://www.helpnetsecurity.com/2024/08/21/opencti-open-source-cyber-threat-intelligence-platform/?ref=sredevops.org) ### O Lado Obscuro do Open Source: Seríamos Todos Egoístas? Reflexões de Viktor Farcic e Por Que Ele Tem Razão. URL: https://www.sredevops.org/br/o-lado-obscuro-do-open-source-seriamos-todos-egoistas-reflexoes-de-viktor-farcic-e-por-que-ele-tem-razao/ Last updated: 2024-08-20T06:49:24.000Z Canal: [@DevOpsToolkit](https://www.youtube.com/@DevOpsToolkit?ref=sredevops.org) Analisamos as ideias de Viktor Farcic sobre o mundo do Open Source, frequentemente mal compreendido, desafiando a noção romântica do altruísmo puro. Ele explora as realidades econômicas por trás dos projetos Open Source, destacando como empresas e indivíduos os utilizam para benefício próprio. A conversa se aprofunda nas motivações por trás da criação e contribuição para projetos Open Source, que vão desde estratégias de penetração de mercado até o avanço profissional. Também analisa as controvérsias em torno das mudanças de licença, enfatizando o impacto dos interesses comerciais e o papel das fundações para mitigar possíveis conflitos. ## A Economia do Open Source: Não se trata de Software Livre, mas de Estratégia Sejamos realistas, o mundo do Open Source nem sempre é uma utopia de camaradagem digital. É fácil se deixar levar pelo idealismo, mas a realidade é que o Open Source é frequentemente um jogo estratégico jogado por empresas grandes e pequenas. Claro, existem aqueles pequenos projetos movidos pela paixão nos quais as pessoas contribuem em seu tempo livre por amor à arte. Mas quando se trata das grandes ligas, os Kubernetes, os Linux do mundo, há muito mais em jogo do que boa vontade. As empresas investem pesado em Open Source não pela bondade de seus corações, mas porque faz sentido comercial. É uma estratégia brilhante de entrada no mercado (**go-to-market strategy**). Lançar um software como Open Source reduz a barreira de entrada, atraindo usuários e criando uma comunidade em torno de um produto. Essa adoção generalizada é incrivelmente valiosa, especialmente no mercado de software atual. Pense nisso. O Kubernetes seria o gigante que é hoje se o Google o tivesse mantido trancado a sete chaves? Veríamos o mesmo nível de inovação e colaboração em torno do Linux se ele não fosse Open Source? Provavelmente não. O Open Source, de muitas maneiras, nivela o campo de jogo, permitindo que empresas menores compitam com os gigantes da tecnologia. Mas essa estratégia não é isenta de complexidades. O investimento em Open Source precisa ter retorno, e é aí que as coisas podem ficar um pouco complicadas. ## Mudanças de Licença: O Campo Minado do Open Source e os Interesses Comerciais Lembra do drama quando MongoDB, Elastic e HashiCorp mudaram suas licenças? A comunidade Open Source se revoltou, acusando essas empresas de trair a essência do Open Source. Mas foi realmente uma traição ou foi uma evolução natural em um mercado cada vez mais impulsionado por gigantes da nuvem como a AWS? A verdade é que, uma vez que uma empresa atinge um certo nível de sucesso com um projeto Open Source, ela se torna um alvo. Os provedores de nuvem podem começar a oferecer esse projeto como um serviço, o que pode prejudicar as fontes de receita da empresa original. Em resposta, as empresas geralmente se sentem pressionadas a modificar suas licenças para proteger seus investimentos e sua vantagem competitiva. Embora isso possa parecer uma traição para alguns, é essencial entender o delicado equilíbrio entre o Open Source e os interesses comerciais. O Open Source prospera com as contribuições, e essas contribuições geralmente vêm de empresas que precisam ver um retorno sobre o investimento. Quando esses retornos são ameaçados, isso pode desencadear manobras defensivas, como mudanças de licença. ## Encontrando o Equilíbrio: O Papel das Fundações e o Uso Responsável do Open Source Então, como navegamos por esse cenário complexo? Como aproveitamos os benefícios do Open Source sem cair nas suas possíveis armadilhas? Uma resposta está em apoiar projetos hospedados em fundações como a Cloud Native Computing Foundation (CNCF) ou a Apache Software Foundation. Essas fundações oferecem um nível de neutralidade e governança que pode ajudar a mitigar o risco de tomadas de decisão unilaterais por uma única empresa. Outro aspecto crucial é o uso responsável do Open Source. Se você está utilizando software Open Source para construir seu negócio, considere retribuir à comunidade. Contribua com código, patrocine projetos ou simplesmente ofereça sua experiência. Essa relação simbiótica é o que sustenta o ecossistema Open Source. O Open Source é uma força poderosa para a inovação, mas não é de graça. Compreender as motivações, os desafios e o delicado equilíbrio entre colaboração e interesses comerciais é crucial para sua saúde a longo prazo. Ao promover a transparência, fomentar uma cultura de contribuição e apoiar projetos com diversas partes interessadas, podemos garantir que o mundo do Open Source continue prosperando. ## Em Síntese... O Open Source é um panorama em constante evolução. Ao entender as motivações por trás dele, os desafios que as empresas e indivíduos enfrentam, e o papel das fundações para garantir sua sustentabilidade, todos podemos contribuir para um mundo Open Source mais dinâmico e equitativo. [DevOps ToolkitWe want to help you learn the tools and the processes that you should be using and applying in your day-to-day job. We want to help you make decisions. What works well, what doesn’t work, why you should choose one tool over the other, and how to get up-to-speed quickly. Which tool works the best for a given task? What should we explore in more depth, and what is a waste of time? This channel has DevOps in the name because we believe that the only way forward is to combine different types of expertise. Ultimately, we need to be able to develop, test, deploy, and operate our systems without friction caused by silos formed around distinct types of expertise. Hence, our focus is on bridging the gap by focusing on the topics that allow developers, operators, and everyone else works together by adopting tools and processes that are relevant today and foster collaboration. Viktor Farcic & Darin Pope![](https://www.youtube.com/s/desktop/4610dd25/img/favicon_144x144.png)YouTube![](https://yt3.googleusercontent.com/0YP74Y3JRONGGT-ceUZicHmukEFthR0VvUM0rFFEjUIIr2-EUp8ZZoixMh6l7bbcA0oh4Wpamg=s900-c-k-c0x00ffffff-no-rj)](https://www.youtube.com/@DevOpsToolkit?ref=sredevops.org) ### El lado oscuro del código abierto: ¿Somos todos egoístas? Reflexiones de Viktor Farcic y por qué tiene toda la razón. URL: https://www.sredevops.org/es/el-lado-oscuro-del-codigo-abierto-somos-todos-egoistas-reflexiones-de-viktor-farcic-y-por-que-tiene-toda-la-razon/ Last updated: 2026-01-08T02:35:53.000Z Canal: [@DevOpsToolkit](https://www.youtube.com/@DevOpsToolkit?ref=sredevops.org) Revisamos las ideas de [Viktor Farcic](https://www.linkedin.com/in/viktorfarcic/?ref=sredevops.org) con respecto al mundo del Open Source, a menudo malentendido, desafiando la noción romántica del altruismo puro. Analiza las realidades económicas detrás de los proyectos Open Source, destacando cómo las empresas y los individuos por igual lo aprovechan para beneficio personal. La conversación profundiza en las motivaciones detrás de iniciar y contribuir a proyectos Open Source, que van desde estrategias de penetración de mercado hasta el avance profesional. También analiza las controversias en torno a los cambios de licencia, enfatizando el impacto de los intereses comerciales y el papel de las fundaciones para mitigar posibles conflictos. ## La economía del código abierto: No se trata de software libre, sino de estrategia Seamos realistas, el mundo del Open Source no siempre es una utopía de camaradería digital. Es fácil dejarse llevar por el idealismo, pero la realidad es que el Open Source es a menudo un juego estratégico que juegan las empresas grandes y pequeñas. Claro, están esos pequeños proyectos impulsados por la pasión en los que la gente contribuye en su tiempo libre por amor al oficio. Pero cuando se trata de las grandes ligas, los Kubernetes, los Linux del mundo, hay mucho más en juego que la buena voluntad. Las empresas invierten mucho en Open Source, no por la bondad de sus corazones, sino porque tiene sentido comercial. Es una brillante estrategia de lanzamiento al mercado. Lanzar software como Open Source reduce la barrera de entrada, atrayendo usuarios y creando una comunidad alrededor de un producto. Esta adopción generalizada es increíblemente valiosa, especialmente en el mercado de software actual. Piénsalo. ¿Sería Kubernetes el gigante que es hoy si Google lo hubiera mantenido bajo llave? ¿Veríamos el mismo nivel de innovación y colaboración en torno a Linux si no fuera Open Source? Probablemente no. El Open Source, en muchos sentidos, nivela el campo de juego, lo que permite a las empresas más pequeñas competir con los gigantes tecnológicos. Pero esta estrategia no está exenta de complejidades. La inversión en Open Source necesita ver un retorno, y ahí es donde las cosas pueden volverse un poco complicadas. ## Los cambios de licencia: El campo minado del código abierto y los intereses comerciales ¿Recuerdas el drama cuando MongoDB, Elastic y HashiCorp cambiaron sus licencias? La comunidad Open Source se levantó en armas, acusando a estas empresas de traicionar la esencia misma del Open Source. Pero, ¿fue realmente una traición o fue una evolución natural en un mercado cada vez más impulsado por gigantes de la nube como AWS? La verdad es que una vez que una empresa alcanza cierto nivel de éxito con un proyecto Open Source, se convierte en un objetivo. Los proveedores de la nube pueden comenzar a ofrecer ese proyecto como un servicio, lo que podría socavar las fuentes de ingresos de la empresa original. En respuesta, las empresas a menudo se sienten presionadas para modificar sus licencias para proteger sus inversiones y su ventaja competitiva. Si bien esto puede parecer una traición para algunos, es esencial comprender el delicado equilibrio entre el Open Source y los intereses comerciales. El Open Source prospera con las contribuciones, y esas contribuciones a menudo provienen de empresas que necesitan ver un retorno de su inversión. Cuando esos retornos se ven amenazados, puede desencadenar maniobras defensivas como los cambios de licencia. ## Trabajar hacia el equilibrio: El papel de las fundaciones y el uso responsable de código abierto Entonces, ¿cómo afrontamos este complejo escenario? ¿Cómo aprovechamos los beneficios del Open Source y minimizamos sus posibles amenazas? Una respuesta está en apoyar proyectos alojados dentro de fundaciones como la Cloud Native Computing Foundation (CNCF) o la Apache Software Foundation. Estas fundaciones ofrecen un nivel de neutralidad y gobernanza que puede ayudar a mitigar el riesgo de la toma de decisiones unilateral por parte de una sola empresa. Otro aspecto crucial es el uso responsable Open Source. Si estás utilizando software Open Source para construir tu negocio, considera retribuir a la comunidad. Contribuye con código, patrocina proyectos o simplemente ofrece tu experiencia. Esta relación simbiótica es lo que sustenta el ecosistema Open Source. El Open Source es una fuerza poderosa para la innovación, pero no es un viaje gratis. Comprender las motivaciones, los desafíos y el delicado equilibrio entre la colaboración y los intereses comerciales es crucial para su salud a largo plazo. Al promover la transparencia, fomentar una cultura de contribución y apoyar proyectos con diversas partes interesadas, podemos garantizar que el mundo del Open Source continúe prosperando. ## En Síntesis... El Open Source está en constante evolución. Al comprender las motivaciones detrás de él, los desafíos que enfrentan las empresas y los individuos, y el papel de las fundaciones para garantizar su sostenibilidad, todos podemos contribuir a un mundo Open Source más dinámico y equitativo. [DevOps ToolkitWe want to help you learn the tools and the processes that you should be using and applying in your day-to-day job. We want to help you make decisions. What works well, what doesn’t work, why you should choose one tool over the other, and how to get up-to-speed quickly. Which tool works the best for a given task? What should we explore in more depth, and what is a waste of time? This channel has DevOps in the name because we believe that the only way forward is to combine different types of expertise. Ultimately, we need to be able to develop, test, deploy, and operate our systems without friction caused by silos formed around distinct types of expertise. Hence, our focus is on bridging the gap by focusing on the topics that allow developers, operators, and everyone else works together by adopting tools and processes that are relevant today and foster collaboration. Viktor Farcic & Darin Pope![](https://www.sredevops.org/content/images/icon/favicon_144x144-1.png)YouTube![](https://www.sredevops.org/content/images/thumbnail/jacVCU83XOS1K9ccASMnuesaaMyY33kWJm1_3TZ7ZsUsG1zJFq-j7pa1cg125_Z9yIlMjNzL-s900-c-k-c0x00ffffff-no-rj)](https://www.youtube.com/@DevOpsToolkit?ref=sredevops.org) ### The Dark Side of Open Source: Are we all just selfish? Viktor Farcic thoughts and why he is absolutely right. URL: https://www.sredevops.org/en/the-dark-side-of-open-source-are-we-all-just-selfish-viktor-farcic-thoughts-and-why-he-is-absolutely-right/ Last updated: 2024-08-20T06:30:01.000Z Channel: [@DevOpsToolkit](https://www.youtube.com/@DevOpsToolkit?ref=sredevops.org) We reviewed [Viktor Farcic' ](https://www.linkedin.com/in/viktorfarcic/?ref=sredevops.org)thoughts regarding the often-misunderstood world of open source, challenging the romantic notion of pure altruism. He explore the economic realities behind open source projects, highlighting how companies and individuals alike leverage it for personal gain. The conversation dives into the motivations behind starting and contributing to open source projects, ranging from market penetration strategies to career advancement. He also dissect the controversies surrounding license changes, emphasizing the impact of commercial interests and the role of foundations in mitigating potential conflicts. ## The Economics of Open Source: It's Not About Free Software, It's About Strategy Let's face it, the open-source world is not always a utopia of digital camaraderie. It's easy to get caught up in the idealism, but the reality is that open source is often a strategic game played by companies large and small. Sure, there are those small, passion-driven projects where folks contribute in their spare time for the love of the craft. But when it comes to the big leagues, the Kubernetes, the Linuxes of the world, there's a lot more at stake than goodwill. Companies invest heavily in open source, not out of the goodness of their hearts, but because it makes good business sense. It's a brilliant go-to-market strategy. Releasing software as open source lowers the barrier to entry, attracting users and building a community around a product. This widespread adoption is incredibly valuable, especially in today's software market. Think about it. Would Kubernetes be the behemoth it is today if Google had kept it under lock and key? Would we see the same level of innovation and collaboration around Linux if it wasn't open source? Probably not. Open source, in many ways, levels the playing field, allowing smaller companies to compete with tech giants. But this strategy isn't without its complexities. The investment in open source needs to see a return, and that's where things can get a bit sticky. ## The License to Change: The Minefield of Open Source and Commercial Interests Remember the drama when MongoDB, Elastic, and HashiCorp changed their licenses? The open-source community was up in arms, accusing these companies of betraying the very ethos of open source. But was it really a betrayal, or was it a natural evolution in a market increasingly driven by cloud giants like AWS? The truth is, once a company reaches a certain level of success with an open-source project, it becomes a target. Cloud providers might start offering that project as a service, potentially undercutting the original company's revenue streams. In response, companies often feel pressured to modify their licenses to protect their investments and competitive edge. While this might seem like a betrayal to some, it's essential to understand the delicate balance between open source and commercial interests. Open source thrives on contributions, and those contributions often come from companies that need to see a return on their investment. When those returns are threatened, it can trigger defensive maneuvers like license changes. ## Finding the Balance: The Role of Foundations and Responsible Open Source Consumption So, how do we navigate this complex landscape? How do we reap the benefits of open source without falling prey to its potential pitfalls? One answer lies in supporting projects housed within foundations like the Cloud Native Computing Foundation (CNCF) or the Apache Software Foundation. These foundations offer a level of neutrality and governance that can help mitigate the risk of unilateral decision-making by a single company. Another crucial aspect is responsible open source consumption. If you're using open-source software to build your business, consider giving back to the community. Contribute code, sponsor projects, or simply offer your expertise. This symbiotic relationship is what sustains the open-source ecosystem. Open source is a powerful force for innovation, but it's not a free ride. Understanding the motivations, the challenges, and the delicate balance between collaboration and commercial interests is crucial for its long-term health. By promoting transparency, fostering a culture of contribution, and supporting projects with diverse stakeholders, we can ensure that the open-source world continues to thrive. ## Final Thoughts Open source is a constantly evolving landscape. By understanding the motivations behind it, the challenges faced by companies and individuals, and the role of foundations in ensuring its sustainability, we can all contribute to a more vibrant and equitable open source world. [DevOps ToolkitWe want to help you learn the tools and the processes that you should be using and applying in your day-to-day job. We want to help you make decisions. What works well, what doesn’t work, why you should choose one tool over the other, and how to get up-to-speed quickly. Which tool works the best for a given task? What should we explore in more depth, and what is a waste of time? This channel has DevOps in the name because we believe that the only way forward is to combine different types of expertise. Ultimately, we need to be able to develop, test, deploy, and operate our systems without friction caused by silos formed around distinct types of expertise. Hence, our focus is on bridging the gap by focusing on the topics that allow developers, operators, and everyone else works together by adopting tools and processes that are relevant today and foster collaboration. Viktor Farcic & Darin Pope![](https://www.youtube.com/s/desktop/4610dd25/img/favicon_144x144.png)YouTube![](https://yt3.googleusercontent.com/0YP74Y3JRONGGT-ceUZicHmukEFthR0VvUM0rFFEjUIIr2-EUp8ZZoixMh6l7bbcA0oh4Wpamg=s900-c-k-c0x00ffffff-no-rj)](https://www.youtube.com/@DevOpsToolkit?ref=sredevops.org) ### Linux Foundation se une a la revolución de la IA Open-Source con OMI URL: https://www.sredevops.org/es/linux-foundation-se-une-a-la-revolucion-de-la-ia-de-open-source-con-omi/ Last updated: 2026-01-08T02:36:07.000Z Linux Foundation ha unido fuerzas con la Open Model Initiative (OMI) para impulsar el desarrollo de modelos de IA (Inteligencia Artificial) de código abierto. Esta colaboración busca crear un mundo donde la IA sea accesible, transparente e impulsada por la comunidad, no por las ganancias corporativas. Se están enfocando en construir una base sólida para la IA abierta, comenzando por una gobernanza clara, comprendiendo las necesidades de la comunidad y desarrollando modelos de IA robustos y éticamente sólidos. ## La IA abierta se vuelve Realidad: Linux Foundation apoya a OMI La Linux Foundation, la reconocida organización detrás de GNU/Linux, Cloud Native Computing Foundation y otros proyectos Open Source, ha unido fuerzas con la Open Model Initiative (OMI). Esta alianza busca revolucionar el mundo de la inteligencia artificial al defender el desarrollo y el uso de modelos de IA open-source (código abierto). OMI, la creación de los poderosos de la IA Invoke, Comfy Org y Civitai, tiene como objetivo garantizar que la tecnología de IA sea accesible para todos. Están comprometidos con un enfoque de open-source para modelos de generación de imágenes, vídeo y audio. [The Open Model InitiativeThe Open Model Initiative is a new community-driven effort to promote the development and adoption of openly licensed AI models for image, video and audio generation.![](https://cdn.prod.website-files.com/6569f44a2a0eba8a49bc11a1/6578a9c4371f2f23d221c95d_invoke-favicon.png)![](https://cdn.prod.website-files.com/6569f44a2a0eba8a49bc11a1/6596f930b8068a3300acd33b_open-graph-image.png)](https://www.invoke.com/the-open-model-initiative?ref=sredevops.org) No se trata solo de hacer que el código esté disponible; se trata de construir una comunidad. La OMI se regirá por un Comité Directivo elegido por la propia comunidad. Esto garantiza que las decisiones sobre la IA abierta se tomen con la participación de las personas que realmente la están construyendo y utilizando. ## Manteniendo la IA abierta y accesible Una de las cosas más interesantes de OMI es su dedicación a las licencias verdaderamente abiertas. Cualquier modelo de IA lanzado a través de esta iniciativa tendrá una licencia que no se puede revocar ni modificar por capricho. Esto significa que no más tácticas de "anzuelo y cambio" donde un modelo es inicialmente gratuito pero de repente requiere una tarifa de suscripción considerable. OMI tiene que ver con la transparencia y mantener la IA accesible para todos. ## Construyendo una base sólida para el futuro de la IA abierta La OMI tiene algunos objetivos ambiciosos, pero están comenzando con los fundamentos: - **Gobernanza primero:** Establecer directrices claras y grupos de trabajo para fomentar la colaboración y garantizar el buen funcionamiento de la iniciativa. - **Investigación impulsada por la comunidad:** Realización de encuestas para comprender qué quiere ver la comunidad de open-source en futuros modelos e investigación de IA. - **Desarrollo de IA ética:** Apoyar la creación de modelos de IA que no solo sean poderosos sino que también se desarrollen y utilicen de forma ética. - **La interoperabilidad es clave:** Desarrollar estándares compartidos para garantizar que diferentes modelos de IA puedan funcionar juntos sin problemas. - **Datos abiertos, capacitación abierta:** Creación de conjuntos de datos transparentes para entrenar modelos de IA e iniciar el proceso de subtitularlos para una mejor comprensión. - **La seguridad es lo primero: Red Teaming:** Introducción de un modelo de prueba alfa diseñado específicamente para "Red Teaming", una práctica de seguridad en la que los equipos simulan ataques para identificar vulnerabilidades en un sistema. La OMI ya está trabajando arduamente y planea lanzar una versión alfa de su modelo, completa con scripts de ajuste fino fáciles de usar, para fines de 2024\. Si bien su sitio web oficial aún está en proceso, puede consultar su repositorio de [GitHub](https://github.com/Open-Model-Initiative?ref=sredevops.org) o unirse a la conversación en su servidor de [Discord](https://discord.gg/KGpkjAPpTf?ref=sredevops.org). [Open Model InitiativeOpen Model Initiative has 3 repositories available. Follow their code on GitHub.![](https://github.githubassets.com/assets/pinned-octocat-093da3e6fa40.svg)GitHub![](https://avatars.githubusercontent.com/u/173907738?s=280&v=4)](https://github.com/Open-Model-Initiative?ref=sredevops.org) ## Por qué es importante la IA abierta: unas palabras de la Fundación Linux Jim Zemlin, director ejecutivo de la Fundación Linux, resumió perfectamente la importancia de esta iniciativa: > “La Fundación Linux está profundamente comprometida con el fomento de un desarrollo abierto y colaborativo en torno a la IA. Con la Iniciativa de Modelo Abierto, estamos dando un paso significativo para hacer que la IA sea accesible y beneficiosa para todos, construyendo un entorno donde la creatividad y el progreso en la IA puedan prosperar sin barreras”. En un mundo donde el desarrollo de la IA está cada vez más impulsado por las ganancias, la OMI, respaldada por la experiencia y el compromiso de la Fundación Linux con el código abierto, ofrece una alternativa refrescante. Esta asociación tiene el potencial de democratizar la IA, fomentando un futuro donde la innovación esté impulsada por la colaboración y el conocimiento compartido, no por los intereses corporativos. [Linux Foundation Welcomes the Open Model Initiative to Promote Openly Licensed AI ModelsNew initiative will foster the development of free to use, open and ethical AI models.![](https://www.linuxfoundation.org/favicon.ico)The Linux FoundationThe Linux Foundation![](https://www.linuxfoundation.org/hubfs/omi.png)](https://www.linuxfoundation.org/press/linux-foundation-welcomes-the-open-model-initiative-to-promote-openly-licensed-ai-models?ref=sredevops.org) [Ex-empleado de OpenAI habla sobre la AGI, la superinteligencia y la dinámica de poder globalEn un episodio reciente del podcast Dwarkesh Patel, el ex-empleado de OpenAI, Leopold Ashenbrenner, miembro del ahora disuelto equipo de superalineación, brindó una visión cautivadora y perspicaz del mundo de la AI avanzada, su trayectoria potencial y sus implicaciones para la humanidad. Analizando las ideas de Ashenbrenner: Ashenbrenner, conocido por![](https://www.sredevops.org/content/images/2024/07/Icon-App-76x76@2x.png)SREDevOps.orgNicolás Georger![](https://www.sredevops.org/content/images/2024/06/intelligence_explosion-1536x1184.webp)](https://www.sredevops.org/es/ex-empleado-de-openai-habla-sobre-la-agi-la-superinteligencia-y-la-dinamica-de-poder-global/) [Inteligencia Artificial - SREDevOps.org![](https://www.sredevops.org/content/images/2024/07/Icon-App-76x76@2x.png)SREDevOps.org![](https://www.sredevops.org/content/images/2023/11/bg-logo.png)](https://www.sredevops.org/tag/inteligencia-artificial/) ### Linux Foundation Embraces the Open-Source AI Revolution with OMI URL: https://www.sredevops.org/en/linux-foundation-embraces-the-open-source-ai-revolution-with-omi/ Last updated: 2024-08-20T05:18:42.000Z The Linux Foundation has teamed up with the Open Model Initiative (OMI) to champion the development of open-source AI models. This collaboration aims to create a world where AI is accessible, transparent, and driven by the community, not corporate profits. They're focusing on building a solid foundation for open AI, starting with clear governance, understanding community needs, and developing robust, ethically sound AI models. ## Open AI Gets Real: Linux Foundation Throws its Weight Behind OMI The Linux Foundation, the renowned guardian of all things open source, has joined forces with the Open Model Initiative (OMI). This dynamic duo is set to shake up the world of artificial intelligence by championing the development and use of open-source AI models. OMI, the brainchild of AI powerhouses Invoke, Comfy Org, and Civitai, is all about making sure AI technology is accessible to everyone. They're committed to an open-source approach for image, video, and audio generation models. This isn't just about making code available; it's about building a community. The OMI will be governed by a Steering Committee chosen by the community itself. This ensures that decisions about open AI are made with input from the people who are actually building and using it. ## No More Bait-and-Switch: Keeping AI Open and Accessible One of the coolest things about OMI is their dedication to truly open licenses. Any AI model released through this initiative will have a license that can't be revoked or modified on a whim. This means no more bait-and-switch tactics where a model is initially free to use but suddenly requires a hefty subscription fee. OMI is all about transparency and keeping AI accessible to everyone. ## Building a Solid Foundation for the Future of Open AI The OMI has some ambitious goals, but they're starting with the fundamentals: - **Governance First:** Establishing clear guidelines and working groups to foster collaboration and ensure the smooth running of the initiative. - **Community-Driven Research:** Conducting surveys to understand what the open-source community wants to see in future AI models and research. - **Ethical AI Development:** Supporting the creation of AI models that are not only powerful but also developed and used ethically. - **Interoperability is Key:** Developing shared standards to make sure different AI models can work together seamlessly. - **Open Data, Open Training:** Creating transparent datasets for training AI models and starting the process of captioning them for better understanding. - **Safety First: Red Teaming:** Introducing an alpha test model specifically designed for "Red Teaming," a security practice where teams simulate attacks to identify vulnerabilities in a system. The OMI is already hard at work and plans to release an alpha version of their model, complete with easy-to-use fine-tuning scripts, by the end of 2024\. While their official website is still in the works, you can check out their [GitHub](https://github.com/Open-Model-Initiative?ref=sredevops.org) repository or join the conversation on their [Discord](https://discord.gg/KGpkjAPpTf?ref=sredevops.org) server. [Open Model InitiativeOpen Model Initiative has 3 repositories available. Follow their code on GitHub.![](https://github.githubassets.com/assets/pinned-octocat-093da3e6fa40.svg)GitHub![](https://avatars.githubusercontent.com/u/173907738?s=280&v=4)](https://github.com/Open-Model-Initiative?ref=sredevops.org) ## Why Open AI Matters: A Word from the Linux Foundation Jim Zemlin, the Executive Director of The Linux Foundation, perfectly summed up the importance of this initiative: > “The Linux Foundation is deeply committed to fostering open and collaborative development around AI. With the Open Model Initiative, we are taking a significant step towards making AI accessible and beneficial for everyone, building an environment where creativity and progress in AI can thrive without barriers.” In a world where AI development is increasingly driven by profit, the OMI, backed by the Linux Foundation's experience and commitment to open source, offers a refreshing alternative. This partnership has the potential to democratize AI, fostering a future where innovation is driven by collaboration and shared knowledge, not corporate interests. [Linux Foundation Welcomes the Open Model Initiative to Promote Openly Licensed AI ModelsNew initiative will foster the development of free to use, open and ethical AI models.![](https://www.linuxfoundation.org/favicon.ico)The Linux FoundationThe Linux Foundation![](https://www.linuxfoundation.org/hubfs/omi.png)](https://www.linuxfoundation.org/press/linux-foundation-welcomes-the-open-model-initiative-to-promote-openly-licensed-ai-models?ref=sredevops.org) [Ex-empleado de OpenAI habla sobre la AGI, la superinteligencia y la dinámica de poder globalEn un episodio reciente del podcast Dwarkesh Patel, el ex-empleado de OpenAI, Leopold Ashenbrenner, miembro del ahora disuelto equipo de superalineación, brindó una visión cautivadora y perspicaz del mundo de la AI avanzada, su trayectoria potencial y sus implicaciones para la humanidad. Analizando las ideas de Ashenbrenner: Ashenbrenner, conocido por![](https://www.sredevops.org/content/images/2024/07/Icon-App-76x76@2x.png)SREDevOps.orgNicolás Georger![](https://www.sredevops.org/content/images/2024/06/intelligence_explosion-1536x1184.webp)](https://www.sredevops.org/es/ex-empleado-de-openai-habla-sobre-la-agi-la-superinteligencia-y-la-dinamica-de-poder-global/) [Artificial Intelligence - SREDevOps.org![](https://www.sredevops.org/content/images/2024/07/Icon-App-76x76@2x.png)SREDevOps.org![](https://www.sredevops.org/content/images/2023/11/bg-logo.png)](https://www.sredevops.org/tag/artificial-intelligence/) ### Kubernetes v1.31.0 ya está aquí: ¿Qué hay de nuevo y por qué debería importarme? URL: https://www.sredevops.org/es/kubernetes-v1-31-0-ya-esta-aqui-que-hay-de-nuevo-y-por-que-deberia-importarme/ Last updated: 2026-01-08T02:36:01.000Z Kubernetes v1.31 es más que solo una colección de nuevas características y mejoras; es un testimonio del compromiso del proyecto con la evolución constante, la mejora de la experiencia del usuario y la seguridad mejorada. Tanto si eres un veterano experimentado en Kubernetes como si acabas de empezar tu viaje, la versión v1.31 tiene algo que ofrecer a todo el mundo. Entonces, ¿a qué esperas? Sumérgete, explora y experimenta la potencia y flexibilidad de Kubernetes v1.31. ## Vale, suficiente bla, bla. Ve directo al grano. Cada lanzamiento de Kubernetes tiene sus estrellas, y la versión v1.31 no es una excepción. Vamos a centrarnos en algunos elementos que cambian las reglas del juego: ### ¿Proveedores de nube In-Tree? ¡Fuera de aquí! Este es el equivalente tecnológico de que esa banda a la que has estado siguiendo desde sus días en el garaje finalmente haya alcanzado el éxito. ¡Kubernetes se está volviendo agnóstico a la nube! La versión v1.31 se despide de todas las integraciones In-Tree con proveedores de nube. Este proceso de externalización es un gran paso hacia un Kubernetes verdaderamente neutral para los proveedores, liberándolo de las ataduras de entornos de nube específicos. ### Política de reclamación de PersistentVolume: ¡Ahora con garras y dientes! ¿Recuerdas cuando establecías una política de reclamación de PersistentVolume (PersistentVolume Reclaim Policy) y se sentía más como una sugerencia que como una regla? Esos días se acabaron. La versión v1.31 introduce finalizadores de protección contra eliminación para garantizar que tu política se aplique realmente. Por fin, puedes confiar en que tus valiosos datos se gestionarán de acuerdo con tus deseos. ### Kubectl Debug La depuración de imágenes base sin shell ahora es mucho más sencilla. La versión v1.31 introduce una opción de perfil personalizado para el comando `kubectl debug`, lo que te permite montar volúmenes de datos y otros recursos directamente en tu contenedor de depuración. Es como tener un pase entre bastidores para solucionar problemas de tus aplicaciones con facilidad. ## Apps (Deployments, StatefulSets, etc) Kubernetes no se trata solo de infraestructura; se trata de potenciar tus aplicaciones. Así es como la versión v1.31 sube de nivel tu juego de aplicaciones: ### PodDisruptionBudgets Despídete de esos momentos incómodos en los que los Pods no saludables acaparan recursos y estropean tu escalado. La versión v1.31 presenta `PodHealthyPolicy` para PodDisruptionBudgets (PDB), lo que te permite especificar si solo se deben tener en cuenta los Pods saludables al aplicar los límites de interrupción. Interesante.... ### StatefulSets: Maestros de su propio dominio (y numeración ordinal) La migración de StatefulSets ahora es mucho menos estresante. La versión v1.31 permite a los StatefulSets controlar su propia numeración ordinal de réplicas de inicio, allanando el camino para migraciones sin problemas entre namespaces y clusters sin el drama del tiempo de inactividad o las reprogramaciones manuales. *~~(Hola mySQL)~~* ### Política de éxito/ finalizaciones ¿Quién dice que Kubernetes debe dictar cómo es el éxito para tus trabajos? La versión v1.31 te pone al mando con la capacidad de definir políticas de éxito y finalización personalizadas para tus workloads. Esto es particularmente útil para cargas de trabajo por lotes donde el éxito podría no significar que todas las actividades se completen. ## kubectl y cli La CLI de Kubernetes es tu fiel compañero para administrar clústeres. La versión v1.31 le ofrece algunas actualizaciones ingeniosas: ### WebSockets para kubectl Kubernetes está adoptando el futuro de la comunicación web al cambiar de SPDY a WebSockets. La versión v1.31 introduce un WebSocketExecutor para `kubectl`, lo que permite una comunicación más rápida y eficiente con el servidor de API de Kubernetes. Es como actualizar tu conexión de acceso telefónico a fibra óptica. ### Kustomize: separado de kubectl (eventualmente) Aunque se aplazó por ahora, el plan para desacoplar `kustomize` de `kubectl` todavía está en el horizonte. Esta separación permite que cada herramienta evolucione a su propio ritmo, evitando desajustes de versión y simplificando la base de código de `kubectl`. Es como esa ruptura amistosa en la que todos están de acuerdo en que es lo mejor. ### Preferencias de Kubectl: La ansiedad por separación ya no existe Mezclar las preferencias del usuario con las configuraciones del clúster es cosa del pasado. La versión v1.31 introduce el archivo `kuberc`, un espacio dedicado para almacenar tus preferencias de `kubectl`. Ahora puedes mantener tus configuraciones personales separadas de las configuraciones específicas del clúster, evitando sobrescrituras accidentales y simplificando la administración de preferencias. ## Instrumentación de Kubernetes v1.31: Vigilando más de cerca las cosas La supervisión y las métricas son cruciales para mantener tu clúster funcionando sin problemas. La versión v1.31 trae algunas mejoras notables en esta área: ### Cardinalidad de métricas: Domesticando esas métricas descontroladas La cardinalidad de métricas no controlada puede convertirse rápidamente en una pesadilla de recursos. La versión v1.31 introduce la aplicación de la cardinalidad de métricas, lo que brinda a los administradores de clústeres el poder de definir límites y evitar que las métricas descontroladas consuman todos tus recursos. Es como ponerle un regulador a un demonio de la velocidad, asegurando que todo funcione dentro de límites seguros. ## Redes en Kubernetes 1.31: Conexiones más fluidas, más control Las redes son la columna vertebral de cualquier clúster de Kubernetes, y la versión v1.31 trae algunas mejoras significativas: ### Con conectividad Ingress: Kube-Proxy obtiene un aumento de confiabilidad La versión v1.31 introduce el drenaje de conexiones para los nodos de terminación y mejora las comprobaciones de estado para Kube-proxy, lo que lleva a una conectividad Ingress más confiable para tus aplicaciones. Es como tener un policía de tránsito dirigiendo el tráfico sin problemas, incluso durante las horas pico. ### Distribución del tráfico: Ajuste fino de su enrutamiento La versión v1.31 te brinda más control sobre cómo fluye el tráfico a través de tu clúster con la adición del campo `trafficDistribution` en la especificación del servicio. Esto te permite especificar preferencias para enrutar el tráfico, como preferir puntos finales topológicamente más cercanos. Es como tener un GPS para el tráfico de tu clúster, guiándolo por las rutas más eficientes. ### Múltiples CIDR de servicio: Abundancia de direcciones IP Quedarse sin IP de servicio es cosa del pasado. La versión v1.31 introduce los objetos `ServiceCIDR` e `IPAddress`, lo que te permite expandir dinámicamente tu espacio de direcciones IP de servicio disponible. Es como agregar carriles a una carretera, acomodando más tráfico sin esfuerzo. ## Nodos de Kubernetes v1.31: Soporte SWAP, Cgroups y AppArmor, Uf! En el corazón de cada clúster de Kubernetes están los worker nodes. La versión v1.31 introduce algunos cambios fundamentales en el funcionamiento de los nodos: ### Soporte de intercambio de memoria (SWAP) La memoria de intercambio finalmente obtiene el reconocimiento que merece en Kubernetes. La versión v1.31 introduce soporte swap a nivel de nodo, lo que te brinda la flexibilidad de utilizar el espacio de intercambio y potencialmente mejorar el rendimiento de tus cargas de trabajo. ### Cgroup v1: Se jubila Cgroup v1 nos ha servido bien, pero es hora de pasar la antorcha. La versión v1.31 hace la transición del soporte de cgroup v1 al modo de mantenimiento, allanando el camino para la adopción del cgroup v2 más potente y eficiente. [Chapter 1\. Introduction to Control Groups (Cgroups) | Red Hat Product DocumentationChapter 1\. Introduction to Control Groups (Cgroups) | Red Hat Documentation![](https://docs.redhat.com/favicon.ico)Red Hat Documentation![](https://docs.redhat.com/Logo-Red_Hat-Documentation-A-Reverse-RGB.svg)](https://docs.redhat.com/en/documentation/red%5Fhat%5Fenterprise%5Flinux/6/html/resource%5Fmanagement%5Fguide/ch01?ref=sredevops.org) ### Soporte para AppArmor Finalmente k8s da soporte nativo para AppArmor, lo que te permite definir perfiles de seguridad detallados para tus contenedores y Pods. Esto agrega una capa adicional de protección a tus apps, limitando sus capacidades y mitigando el impacto de posibles violaciones de seguridad. ```yaml apiVersion: v1 kind: Pod metadata: name: hello-apparmor spec: securityContext: appArmorProfile: type: Localhost localhostProfile: k8s-apparmor-example-deny-write containers: - name: hello image: busybox:1.28 command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ] ``` [Restrict a Container’s Access to Resources with AppArmorFEATURE STATE: Kubernetes v1.31 \[stable\] This page shows you how to load AppArmor profiles on your nodes and enforce those profiles in Pods. To learn more about how Kubernetes can confine Pods using AppArmor, see Linux kernel security constraints for Pods and containers. Objectives See an example of how to load a profile on a Node Learn how to enforce the profile on a Pod Learn how to check that the profile is loaded See what happens when a profile is violated See what happens when a profile cannot be loaded Before you begin AppArmor is an optional kernel module and Kubernetes feature, so verify it is supported on your Nodes before proceeding:![](https://kubernetes.io/icons/apple-touch-icon-256x256.png)Kubernetes![](https://kubernetes.io/images/kubernetes-horizontal-color.png)](https://kubernetes.io/docs/tutorials/security/apparmor/?ref=sredevops.org) ## Scheduling: la afinidad se refina La capacidad de "agendar" o "programar" (scheduling) es crucial para optimizar la utilización de recursos. La versión v1.31 trae algunas mejoras para PodAffinity: ### PodAffinity y PodAntiAffinity se vuelven más selectivos Despídete de los días de las reglas torpes de afinidad . La versión v1.31 introduce `MatchLabelKeys` y `MismatchLabelKeys` para `PodAffinityTerm`, lo que te brinda un control más granular sobre cómo los Pods se ubican conjuntamente o se distribuyen en tu clúster. ## Almacenamiento en Kubernetes: timestamps en PersistentVolume, VolumeAttributesClass y más El almacenamiento es un aspecto crítico de cualquier implementación de Kubernetes, y la versión v1.31 introduce algunas mejoras notables: ### Timestamps en PersistentVolume La administración de PersistentVolumes ahora es más fácil. La versión v1.31 agrega un nuevo campo de marca de tiempo a los PersistentVolumes, que registra cuándo hacen la transición entre diferentes fases. Esto te ayuda a comprender el ciclo de vida de tus volúmenes, simplifica las tareas de limpieza y obtiene información sobre tus patrones de uso del almacenamiento. Es como tener un libro de registro para tus volúmenes, rastreando sus viajes a través de los mares de Kubernetes. ### VolumeAttributesClass: Desacoplar atributos de la capacidad Atrás quedaron los días de administrar los atributos de almacenamiento y la capacidad como una entidad monolítica. La versión v1.31 introduce el recurso `VolumeAttributesClass`, lo que te permite definir y administrar atributos de volumen como IOPS y rendimiento independientemente de la capacidad. Este control detallado simplifica la administración del almacenamiento y facilita la adaptación de los recursos de almacenamiento a las necesidades específicas de tus cargas de trabajo. Es como tener una caja de herramientas llena de diferentes opciones de almacenamiento, lo que te permite elegir la que mejor se adapte a cada trabajo. ### CSI Differential Snapshot : Optimización y eficiencia incremental Las instantáneas (snapshots) son esenciales para la protección de datos, pero pueden consumir muchos recursos. Si bien se aplazó por ahora, la característica planificada de instantánea diferencial CSI tiene como objetivo optimizar este proceso al permitir la recuperación de metadatos solo para los bloques modificados entre instantáneas. Esto puede reducir significativamente el tiempo y los recursos necesarios para las operaciones de instantáneas. Es como tomar una instantánea solo de los cambios en un documento en lugar de todo el documento cada vez, ahorrando tiempo y espacio. ## Otras mejoras notables en Kubernetes 1.31 Kubernetes v1.31 está repleto de muchas otras mejoras y refinamientos. Aquí hay algunos puntos destacados: ### Mejoras en el token de cuenta de servicio Más seguridad y trazabilidad La versión v1.31 refuerza la seguridad al incrustar información del nodo en tokens de cuenta de servicio vinculados (bound service account tokens), lo que dificulta su uso indebido. Además, introduce UUID para tokens, mejorando la trazabilidad de las solicitudes del servidor API. Es como agregar sellos a prueba de manipulaciones y números de seguimiento a tus tokens, mejorando la seguridad y la responsabilidad. ### Políticas de admisión "*mutantes*" La versión v1.31 da un paso más hacia la simplificación del control de admisión con la introducción de políticas de admisión *mutantes* (mutating) utilizando CEL (lenguaje de expresión común/common expression language). Esto proporciona una alternativa más eficiente a la mutaciónde webhooks de admisión para tareas comunes como configurar etiquetas o inyectar contenedores sidecar. Es como tener un conjunto de reglas programables para modificar automáticamente los recursos a medida que ingresan a tu clúster. ### Elastic Indexed Jobs: Escalar con elegancia La versión v1.31 agrega más flexibilidad para administrar trabajos indexados al permitirte modificar dinámicamente el número deseado de finalizaciones (`spec.completions`). Esto facilita la escala de tus cargas de trabajo de procesamiento por lotes hacia arriba o hacia abajo sin interrumpir el progreso del trabajo. Es como tener un acordeón para tus trabajos indexados, expandiéndose o contrayéndose para adaptarse a diversas cargas de trabajo. ## Links y fuentes: [kubernetes/CHANGELOG/CHANGELOG-1.31.md at master · kubernetes/kubernetesProduction-Grade Container Scheduling and Management - kubernetes/kubernetes![](https://github.githubassets.com/assets/pinned-octocat-093da3e6fa40.svg)GitHubkubernetes![](https://opengraph.githubassets.com/d342c50894f0c8726ac0b7e403922846989fb4bd77158d240ed6c77ef5d64b42/kubernetes/kubernetes)](https://git.k8s.io/kubernetes/CHANGELOG/CHANGELOG-1.31.md?ref=sredevops.org) [Kubernetes 1.31 - What’s new?Kubernetes 1.31 is nearly here, and it’s full of exciting major changes to the project! So, what’s new in this upcoming release?![](https://sysdig.com/wp-content/uploads/favicon-350x350.png)SysdigNigel Douglas![](https://sysdig.com/wp-content/uploads/BlogImages-WhatsNewInKubernetes-1-31.png)](https://sysdig.com/blog/whats-new-kubernetes-1-31/?ref=sredevops.org) ### The new Kubernetes v1.31.0 is here: what's new, and why should I care? URL: https://www.sredevops.org/en/the-new-kubernetes-v1-31-0-is-here-whats-new-and-why-should-i-care/ Last updated: 2024-08-14T03:24:47.000Z Kubernetes v1.31 is more than just a collection of new features and improvements; it's a testament to the project's commitment to constant evolution, improved user experience, and enhanced security. Whether you're a seasoned Kubernetes veteran or just starting your journey, v1.31 has something to offer everyone. So, why wait? Dive in, explore, and experience the power and flexibility of Kubernetes v1.31 ## Ok, Enough blah-blah. Get straight to the point! Every Kubernetes release has its stars, and v1.31 is no exception. Let's shine the spotlight on a few game-changers: ### In-Tree Cloud Providers? Out the Window! This is the tech equivalent of that band you've been following since their garage days finally hitting it big. Kubernetes is going cloud-agnostic! v1.31 bids farewell to all in-tree integrations with cloud providers. This externalization process is a massive leap towards a truly vendor-neutral Kubernetes, freeing it from the shackles of specific cloud environments. ### PersistentVolume Reclaim Policy: Now With Teeth! Remember when you set a PersistentVolume Reclaim Policy and it felt more like a suggestion than a rule? Those days are gone. v1.31 introduces deletion protection finalizers to ensure your policy is actually enforced. Finally, you can trust that your precious data will be handled according to your wishes. ### Kubectl Debug Gets a Custom Profile Makeover Debugging shell-less base images just got a whole lot smoother. v1.31 introduces a custom profile option for the `kubectl debug` command, allowing you to mount data volumes and other resources directly into your debug container. It's like having a backstage pass to troubleshoot your applications with ease. ## Apps in Kubernetes 1.31: Feature Fiesta Kubernetes isn't just about infrastructure; it's about empowering your applications. Here's how v1.31 levels up your app game: ### PodDisruptionBudgets Get Healthy (Policy, That Is) Say goodbye to those awkward moments when unhealthy pods hog resources and mess with your scaling. v1.31 introduces the `PodHealthyPolicy` for PodDisruptionBudgets (PDB), allowing you to specify whether only healthy pods should be considered when enforcing disruption limits. It's like a bouncer for your cluster, ensuring only the healthy and ready get through. ### StatefulSets: Masters of Their Own Domain (and Ordinal Numbering) Migrating StatefulSets just got a whole lot less stressful. v1.31 empowers StatefulSets to control their own start replica ordinal numbering, paving the way for seamless migrations across namespaces and clusters without the drama of downtime or manual reschedules. It's like giving your StatefulSets a first-class ticket to their destination. ### Job Success/Completion Policy: Defining Your Own Victory Who says Kubernetes should dictate what success looks like for your jobs? v1.31 puts you in the driver's seat with the ability to define custom success and completion policies for Indexed Jobs. This is particularly handy for batch workloads where success might not mean all indexes completing. It's like having a custom finish line for your batch processing marathons. ## CLI in Kubernetes 1.31: Streamlining Your Command-Line Kung Fu The Kubernetes CLI is your trusty sidekick for managing clusters. v1.31 gives it some slick upgrades: ### SPDY Out, WebSockets In: A Networking Glow Up Kubernetes is embracing the future of web communication by shifting from SPDY to WebSockets. v1.31 introduces a WebSocketExecutor to `kubectl`, enabling faster and more efficient communication with the Kubernetes API server. It's like upgrading your dial-up connection to fiber optic. ### Kustomize: Flying Solo (Eventually) While deferred for now, the plan to decouple `kustomize` from `kubectl` is still on the horizon. This separation allows each tool to evolve at its own pace, preventing version mismatches and streamlining the `kubectl` codebase. It's like that amicable breakup where everyone agrees it's for the best. ### Kubectl Preferences: Separation Anxiety No More Mixing user preferences with cluster configs is so last release. v1.31 introduces the `kuberc` file, a dedicated space for storing your `kubectl` preferences. Now you can keep your personal settings separate from cluster-specific configurations, preventing accidental overwrites and simplifying preference management. It's like having a separate drawer for your socks and your shirts. ## Kubernetes v1.31 Instrumentation: Keeping a Closer Eye on Things Monitoring and metrics are crucial for keeping your cluster running smoothly. v1.31 brings some notable enhancements in this area: ### Metric Cardinality Enforcement: Taming Those Runaway Metrics Uncontrolled metric cardinality can quickly turn into a resource nightmare. v1.31 introduces metric cardinality enforcement, giving cluster administrators the power to define limits and prevent runaway metrics from consuming all your resources. It's like putting a governor on a speed demon, ensuring everything runs within safe limits. ## Networking in Kubernetes 1.31: Smoother Connections, More Control Networking is the backbone of any Kubernetes cluster, and v1.31 brings some significant improvements: ### Ingress Connectivity: Kube-Proxy Gets a Reliability Boost v1.31 introduces connection draining for terminating nodes and improves health checks for Kube-proxy, leading to more reliable ingress connectivity for your applications. It's like having a traffic cop directing traffic smoothly, even during rush hour. ### Traffic Distribution: Fine-Tuning Your Routing v1.31 gives you more control over how traffic flows through your cluster with the addition of the `trafficDistribution` field in the Service specification. This allows you to specify preferences for routing traffic, such as preferring topologically closer endpoints. It's like having a GPS for your cluster traffic, guiding it along the most efficient routes. ### Multiple Service CIDRs: IP Address Abundance Running out of Service IPs is a thing of the past. v1.31 introduces `ServiceCIDR` and `IPAddress` objects, allowing you to dynamically expand your available Service IP address space. It's like adding lanes to a highway, accommodating more traffic without breaking a sweat. ## Kubernetes v1.31 Nodes: Swap Support, Cgroups, and AppArmor, Oh My! At the heart of every Kubernetes cluster are the worker nodes. v1.31 introduces some fundamental changes to how nodes operate: ### Node Memory Swap Support: Breathing Room for Your Workloads Swap memory finally gets the recognition it deserves in Kubernetes. v1.31 introduces node-level swap support, giving you the flexibility to utilize swap space and potentially improve the performance of your workloads. It's like giving your nodes a shot of espresso, allowing them to handle bursts of activity with ease. ### Cgroup v1: Time for a Retirement Party Cgroup v1 has served us well, but it's time to pass the torch. v1.31 transitions cgroup v1 support into maintenance mode, paving the way for the adoption of the more powerful and efficient cgroup v2\. It's like upgrading from a rotary phone to a smartphone—a necessary evolution. ### AppArmor Support: Locking Down Your Containers Security-conscious Kubernetes users rejoice! v1.31 introduces native AppArmor support, allowing you to define fine-grained security profiles for your containers and pods. This adds an extra layer of protection to your workloads, limiting their capabilities and mitigating the impact of potential security breaches. It's like having a security detail for your containers, ensuring they play by the rules. ## Scheduling in Kubernetes: Affinity Gets Refined Efficient scheduling is crucial for optimizing resource utilization. v1.31 brings some welcome refinements to Pod affinity: ### PodAffinity and PodAntiAffinity Get More Selective Say goodbye to the days of clunky Pod affinity rules. v1.31 introduces `MatchLabelKeys` and `MismatchLabelKeys` for `PodAffinityTerm`, giving you more granular control over how Pods are co-located or spread across your cluster. It's like having a matchmaker for your Pods, ensuring they find their ideal neighbors (or avoid the ones they dislike). ## Kubernetes Storage: PersistentVolume Timestamps, VolumeAttributesClass, and More Storage is a critical aspect of any Kubernetes deployment, and v1.31 introduces some noteworthy enhancements: ### PersistentVolume Timestamps: Keeping Track of Time's Passage Managing PersistentVolumes just got easier. v1.31 adds a new timestamp field to PersistentVolumes, recording when they transition between different phases. This helps you understand the lifecycle of your volumes, simplify cleanup tasks, and gain insights into your storage usage patterns. It's like having a logbook for your volumes, tracking their journeys through the Kubernetes seas. ### VolumeAttributesClass: Decoupling Attributes from Capacity Gone are the days of managing storage attributes and capacity as a monolithic entity. v1.31 introduces the `VolumeAttributesClass` resource, allowing you to define and manage volume attributes like IOPS and throughput independently of capacity. This fine-grained control simplifies storage management and makes it easier to tailor storage resources to the specific needs of your workloads. It's like having a toolbox full of different storage options, allowing you to pick and choose the best fit for each job. ### CSI Differential Snapshot: Optimizing Snapshots for Efficiency Snapshots are essential for data protection, but they can be resource-intensive. While deferred for now, the planned CSI Differential Snapshot feature aims to optimize this process by allowing the retrieval of metadata for only the changed blocks between snapshots. This can significantly reduce the time and resources required for snapshot operations. It's like taking a snapshot of only the changes in a document instead of the entire document every time, saving time and space. ## Other Notable Enhancements in Kubernetes 1.31 Kubernetes v1.31 is packed with numerous other enhancements and refinements. Here are a few highlights: ### Bound Service Account Token Enhancements: Boosting Security and Traceability v1.31 strengthens security by embedding Node information into bound service account tokens, making them more difficult to misuse. Additionally, it introduces UUIDs for tokens, improving the traceability of API server requests. It's like adding tamper-proof seals and tracking numbers to your tokens, enhancing security and accountability. ### Mutating Admission Policies: CEL-ebrating Flexibility v1.31 takes another step towards simplifying admission control with the introduction of mutating admission policies using CEL (Common Expression Language). This provides a more efficient alternative to mutating admission webhooks for common tasks like setting labels or injecting sidecar containers. It's like having a set of programmable rules for automatically modifying resources as they enter your cluster. ### Elastic Indexed Jobs: Scaling with Grace v1.31 introduces more flexibility for managing Indexed Jobs by allowing you to modify the desired number of completions (`spec.completions`) dynamically. This makes it easier to scale your batch processing workloads up or down without disrupting the job's progress. It's like having an accordion for your Indexed Jobs, expanding or contracting to accommodate varying workloads. ## Links and sources: [kubernetes/CHANGELOG/CHANGELOG-1.31.md at master · kubernetes/kubernetesProduction-Grade Container Scheduling and Management - kubernetes/kubernetes![](https://github.githubassets.com/assets/pinned-octocat-093da3e6fa40.svg)GitHubkubernetes![](https://opengraph.githubassets.com/d342c50894f0c8726ac0b7e403922846989fb4bd77158d240ed6c77ef5d64b42/kubernetes/kubernetes)](https://git.k8s.io/kubernetes/CHANGELOG/CHANGELOG-1.31.md?ref=sredevops.org) [Kubernetes 1.31 - What’s new?Kubernetes 1.31 is nearly here, and it’s full of exciting major changes to the project! So, what’s new in this upcoming release?![](https://sysdig.com/wp-content/uploads/favicon-350x350.png)SysdigNigel Douglas![](https://sysdig.com/wp-content/uploads/BlogImages-WhatsNewInKubernetes-1-31.png)](https://sysdig.com/blog/whats-new-kubernetes-1-31/?ref=sredevops.org) ### Ingress, Gateway, Load Balancer, ClusterIP, NodePort... Qué carajo son? Cuál debo usar en mi app? Introducción en simple URL: https://www.sredevops.org/es/ingress-gateway-load-balancer-clusterip-nodeport-que-carajo-son-cual-debo-usar-en-mi-app-introduccion-en-simple/ Last updated: 2026-01-08T02:36:26.000Z ## TL;DR *(Too long; Didn't Read)* Las redes en Kubernetes pueden ser tan confusas como... *bueno, como el propio Kubernete*s. ¿Estás hasta las *~~pelotas u ovarios~~* de que los problemas de Kubernetes te distraigan de tu código? Aquí te ofrecemos una guía sencilla sobre los Servicios de Kubernetes, centrándonos en los protagonistas: Ingress, Gateway, Load Balancer, ClusterIP y NodePort. Desvelaremos sus propósitos, fortalezas y cuándo desplegar cada uno. ## Eliminando mitos de los Servicios de Kubernetes El escenario típico: has containerizado tu aplicación utilizando Docker, dividiéndola en microservicios repartidos por un clúster de Kubernetes. Pero, ¿cómo se comunican estos microservicios? ¿Cómo llega el tráfico externo a ellos? Aquí entran los Servicios de Kubernetes, los héroes olvidados del mundo de las redes de Kubernetes. Actúan como balanceadores de carga internos y proporcionan un endpoint estable para acceder a tus pods (esos contenedores que ejecutan tu aplicación). Imagínatelos como los amables directores de tráfico que garantizan una comunicación fluida entre los componentes de tu aplicación. Kubernetes ofrece varios tipos de Servicios, cada uno de los cuales satisface necesidades específicas: ## ClusterIP: La "sala privada" de tu aplicación El tipo más básico es el servicio ClusterIP. Proporciona una única dirección IP estable *dentro* de tu clúster, accesible sólo para otras aplicaciones que se ejecuten *dentro* del mismo clúster. Es como tener una fiesta privada en tu casa a la que sólo pueden asistir los que tienen invitación (otros pods del clúster). Utiliza ClusterIP cuando: - Necesitas comunicación interna entre los pods dentro de tu clúster. - No necesitas acceso externo al servicio. Aquí tienes un ejemplo sencillo: ```yaml apiVersion: v1 kind: Service metadata: name: my-internal-app spec: type: ClusterIP selector: app: my-app ports: - port: 80 targetPort: 8080 ``` En este ejemplo: - `type: ClusterIP` define explícitamente el tipo de servicio como ClusterIP. - `selector: app: my-app` le dice al servicio que seleccione los pods con la etiqueta `app: my-app`. - `ports:` define las asignaciones de puertos entre el servicio (puerto 80) y los pods (targetPort 8080). ## NodePort: Abriendo un hoyo en el firewall El siguiente es NodePort, que expone tu servicio en un puerto estático en *cada* nodo de tu clúster. Es como abrir una puerta designada en la fiesta de tu casa y dejar entrar a cualquiera que sepa el número de la puerta (el NodePort), tanto si está en la lista de invitados como si no. NodePort es útil para: - Exponer tu aplicación para acceso externo durante el desarrollo o la depuración. - Exponer un servicio en un puerto específico en todos los nodos, independientemente de la dirección IP del pod subyacente. Así es como se define un servicio NodePort: ```yaml apiVersion: v1 kind: Service metadata: name: my-nodeport-service spec: type: NodePort selector: app: my-app ports: - port: 80 targetPort: 8080 nodePort: 30080 ``` La diferencia clave aquí es `nodePort: 30080`. Esta línea expone el servicio en el puerto 30080 en cada nodo de tu clúster. ## LoadBalancer: El controlador de tráfico externo Mientras que NodePort abre una puerta, LoadBalancer despliega la alfombra roja, proporcionando una dirección IP externa dedicada que enruta el tráfico a tu servicio. Es como contratar a un portero profesional (a menudo proporcionado por tu proveedor de cloud) que gestiona de forma experta la lista de invitados y garantiza una entrada fluida a tu fiesta. Un servicio LoadBalancer es idóneo cuando quieres: - Exponer tu aplicación al mundo exterior en un entorno de producción. - Distribuir el tráfico entre múltiples pods para una alta disponibilidad y escalabilidad. Aquí tienes un ejemplo: ```yaml apiVersion: v1 kind: Service metadata: name: my-loadbalancer-service spec: type: LoadBalancer selector: app: my-app ports: - port: 80 targetPort: 8080 ``` Cuando creas un servicio LoadBalancer, Kubernetes (con la ayuda de tu proveedor de cloud) aprovisiona un balanceador de carga y le asigna una dirección IP externa, haciendo que tu aplicación sea accesible públicamente. ## Ingress: El enrutador de tráfico "*inteligente"* Piensa en los `LoadBalancers` como proveedores de un único punto de entrada a tu aplicación. Pero, ¿qué ocurre si quieres un control más preciso del tráfico entrante, como enrutar las peticiones a diferentes servicios en función de la URL solicitada? Aquí es donde entra Ingress, el sofisticado controlador de tráfico que actúa como un proxy inverso, dirigiendo el tráfico a diferentes servicios según las reglas que definas. Imagina Ingress como el organizador de la fiesta que recibe a los invitados en la puerta y los guía a diferentes salas (servicios) en función de sus intereses (URL de la solicitud). Ingress brilla cuando: - Necesitas enrutar el tráfico en función de atributos HTTP/HTTPS como nombres de host (`hostname`) , rutas o `headers`. - Quieres consolidar múltiples servicios bajo un único punto de entrada (como un único nombre de dominio). Aquí tienes una configuración básica de Ingress: ```yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-ingress spec: rules: - host: myapp.example.com http: paths: - path: / pathType: Prefix backend: service: name: my-service-1 port: number: 80 - path: /admin pathType: Prefix backend: service: name: my-service-2 port: number: 8080 ``` Esta configuración enruta las solicitudes a `myapp.example.com/` a `my-service-1` y las solicitudes a `myapp.example.com/admin` a `my-service-2`. ## Gateway API: El futuro de las redes de Kubernetes Aunque Ingress ha sido la solución preferida para el enrutamiento del tráfico HTTP, tiene sus limitaciones. Aquí es donde entra API Gateway, una forma más potente, expresiva y *extensible* de gestionar las redes de Kubernetes. Piensa en la API Gateway como la evolución del planificador de fiestas, ahora equipado con habilidades y herramientas avanzadas para gestionar incluso los eventos más complejos. Aquí tienes un ejemplo simplificado: ```yaml apiVersion: gateway.networking.k8s.io/v1alpha2 kind: Gateway metadata: name: my-gateway spec: gatewayClassName: istio listeners: - protocol: HTTP port: 80 --- apiVersion: gateway.networking.k8s.io/v1alpha2 kind: HTTPRoute metadata: name: my-route spec: parentRefs: - name: my-gateway hostnames: - "myapp.example.com" rules: - matches: - path: type: PathPrefix value: / backendRefs: - name: my-service-1 port: 80 ``` La API Gateway proporciona una forma más estructurada y flexible de definir puertas de enlace, listeners y rutas, lo que facilita la gestión de escenarios de red complejos. [Kubernetes Gateway API v1.1: Service mesh, GRPCRoute y mucho másDespués del lanzamiento GA de Gateway API el pasado octubre, Kubernetes SIG Network anuncia el lanzamiento de la versión v1.1 de Gateway API. En este lanzamiento, varias características pasan a formar parte del Canal Estándar (GA), incluyendo el soporte para service mesh y GRPCRoute. También introducen algunas características nuevas![](https://www.sredevops.org/content/images/size/w256h256/2024/07/Icon-App-76x76@2x.png)SREDevOps.orgNicolás Georger![](https://www.sredevops.org/content/images/2024/05/api-gateway-kubernetes.png)](https://www.sredevops.org/es/kubernetes-gateway-api-v1-1-service-mesh-grpcroute-y-mucho-mas/) ## Elegir el tipo de servicio adecuado - **Comunicación interna:** ClusterIP es tu opción preferida. - **Acceso externo durante el desarrollo:** NodePort ofrece una solución sencilla. - **Acceso externo listo para producción con balanceo de carga:** LoadBalancer es tu mejor opción. - **Enrutamiento de tráfico basado en atributos HTTP/HTTPS:** Ingress es la respuesta. - **Gestión avanzada del tráfico y extensibilidad:** Adopta la potencia de la API Gateway. Recuerda que comprender los Servicios de Kubernetes es clave para desbloquear todo el potencial de tus aplicaciones en contenedores. Elige sabiamente, y tus microservicios estarán comunicándose como esperas. ## Un paso adelante: Service Mesh Para una gestión avanzada de las redes y el tráfico, considera la posibilidad de explorar las *mallas de servicios (service mesh)* como Istio, Linkerd, Traefik Mesh, Kong o Kuma. Estas herramientas proporcionan funciones adicionales como el cifrado del tráfico, la observabilidad y un control preciso del tráfico, lo que lleva tu juego de redes de Kubernetes al siguiente nivel. [Traefik v3.0 ya está disponible e incluye soporte para Kubernetes Gateway API, WebAssembly y más. Aquí puedes ver cómo actualizar a v3.0Este año se cumple el noveno aniversario de Traefik y hoy se convirtió en uno de los gateways modernos más utilizados, con más de 3 mil millones de descargas y más de 750 colaboradores. Está en el Top 15 de DockerHub y tiene 47.000 estrellas en GitHub. Aquí en![](https://www.sredevops.org/content/images/size/w256h256/2024/07/Icon-App-76x76@2x.png)SREDevOps.orgNicolás Georger![](https://www.sredevops.org/content/images/2024/05/traefik-v3-announcement-image-1.png)](https://www.sredevops.org/es/traefik-v3-ya-esta-disponible-e-incluye-soporte-para-kubernetes-gateway-api-webassembly-y-mas-aqui-puedes-ver-como-actualizar-a-v3/) ## ### Ingress, Gateway, Load Balancer, ClusterIP, and NodePort... What the Heck Are They? A Simplified Guide to Kubernetes Services! URL: https://www.sredevops.org/en/ingress-gateway-load-balancer-clusterip-and-nodeport-what-the-heck-are-they-a-simplified-guide-to-kubernetes-services/ Last updated: 2024-08-12T22:41:11.000Z ## TL;DR Kubernetes networking can be as confusing as... well, Kubernetes itself. Are you tired of getting distracted from your coding spree by kubernetes mess-ups? Here we offer a simple guide to Kubernetes Services, focusing on the key players: Ingress, Gateway, Load Balancer, ClusterIP, and NodePort. We'll unravel their purposes, strengths, and when to deploy each one. ## Demystifying Kubernetes Services The typical scenario: you've containerized your application using Docker, breaking it down into microservices spread across a Kubernetes cluster. But how do these microservices communicate? How does external traffic reach them? Enter Kubernetes Services, the unsung heroes of the Kubernetes networking world. They act as internal load balancers and provide a stable endpoint to access your pods (those containers running your app). Think of them as the friendly traffic directors ensuring seamless communication between your application components. Kubernetes offers several types of Services, each catering to specific needs: ## ClusterIP: Your Application's Private Lounge The most basic type is the ClusterIP service. It provides a single, stable IP address *within* your cluster, accessible only by other applications running *inside* the same cluster. It's like having a private party in your house where only those with the invitation (other pods in the cluster) can join. Use ClusterIP when: - You need internal communication between pods within your cluster. - You don't need external access to the service. Here's a simple example: ```yaml apiVersion: v1 kind: Service metadata: name: my-internal-app spec: type: ClusterIP selector: app: my-app ports: - port: 80 targetPort: 8080 ``` In this example: - `type: ClusterIP` explicitly defines the service type as ClusterIP. - `selector: app: my-app` tells the service to select pods with the label `app: my-app`. - `ports:` define the port mappings between the service (port 80) and the pods (targetPort 8080). ## NodePort: Punching a Hole Through the Firewall Next up is NodePort, which exposes your service on a static port on *every* node in your cluster. It's like opening a designated door at your house party and letting anyone who knows the door number (the NodePort) in, whether they're on the guest list or not. NodePort is useful for: - Exposing your application for external access during development or debugging. - Exposing a service on a specific port on all nodes, regardless of the underlying pod's IP address. Here's how you'd define a NodePort service: ```yaml apiVersion: v1 kind: Service metadata: name: my-nodeport-service spec: type: NodePort selector: app: my-app ports: - port: 80 targetPort: 8080 nodePort: 30080 ``` The key difference here is `nodePort: 30080`. This line exposes the service on port 30080 on every node in your cluster. ## LoadBalancer: The External Traffic Controller While NodePort opens a door, LoadBalancer rolls out the red carpet, providing a dedicated external IP address that routes traffic to your service. It's like hiring a professional bouncer (often provided by your cloud provider) who expertly manages the guest list and ensures smooth entry to your party. LoadBalancer services are ideal for: - Exposing your application to the outside world in a production environment. - Distributing traffic across multiple pods for high availability and scalability. Here's an example: ```yaml apiVersion: v1 kind: Service metadata: name: my-loadbalancer-service spec: type: LoadBalancer selector: app: my-app ports: - port: 80 targetPort: 8080 ``` When you create a LoadBalancer service, Kubernetes (with the help of your cloud provider) provisions a load balancer and assigns it an external IP address, making your application publicly accessible. ## Ingress: The Intelligent Traffic Router Think of LoadBalancers as providing a single entry point to your application. But what if you want more fine-grained control over incoming traffic, like routing requests to different services based on the requested URL? Enter Ingress, the sophisticated traffic controller that acts as a reverse proxy, directing traffic to different services based on rules you define. Imagine Ingress as the party planner who greets guests at the door and guides them to different rooms (services) based on their interests (request URL). Ingress shines when: - You need to route traffic based on HTTP/HTTPS attributes like hostnames, paths, or headers. - You want to consolidate multiple services under a single entry point (like a single domain name). Here's a basic Ingress configuration: ```yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-ingress spec: rules: - host: myapp.example.com http: paths: - path: / pathType: Prefix backend: service: name: my-service-1 port: number: 80 - path: /admin pathType: Prefix backend: service: name: my-service-2 port: number: 8080 ``` This configuration routes requests to `myapp.example.com/` to `my-service-1` and requests to `myapp.example.com/admin` to `my-service-2`. ## Gateway API: The Future of Kubernetes Networking While Ingress has been the go-to for HTTP traffic routing, it has its limitations. Enter the Gateway API, a more powerful, expressive, and extensible way to manage Kubernetes networking. Think of Gateway API as the evolution of the party planner, now equipped with advanced skills and tools to handle even the most complex events. Here's a simplified example: ```yaml apiVersion: gateway.networking.k8s.io/v1alpha2 kind: Gateway metadata: name: my-gateway spec: gatewayClassName: istio listeners: - protocol: HTTP port: 80 --- apiVersion: gateway.networking.k8s.io/v1alpha2 kind: HTTPRoute metadata: name: my-route spec: parentRefs: - name: my-gateway hostnames: - "myapp.example.com" rules: - matches: - path: type: PathPrefix value: / backendRefs: - name: my-service-1 port: 80 ``` The Gateway API provides a more structured and flexible way to define gateways, listeners, and routes, making it easier to manage complex networking scenarios. [Traefik v3.0 ya está disponible e incluye soporte para Kubernetes Gateway API, WebAssembly y más. Aquí puedes ver cómo actualizar a v3.0Este año se cumple el noveno aniversario de Traefik y hoy se convirtió en uno de los gateways modernos más utilizados, con más de 3 mil millones de descargas y más de 750 colaboradores. Está en el Top 15 de DockerHub y tiene 47.000 estrellas en GitHub. Aquí en![](https://www.sredevops.org/content/images/size/w256h256/2024/07/Icon-App-76x76@2x.png)SREDevOps.orgNicolás Georger![](https://www.sredevops.org/content/images/2024/05/traefik-v3-announcement-image-1.png)](https://www.sredevops.org/es/traefik-v3-ya-esta-disponible-e-incluye-soporte-para-kubernetes-gateway-api-webassembly-y-mas-aqui-puedes-ver-como-actualizar-a-v3/) ## Choosing the Right Service Type - **Internal communication:** ClusterIP is your go-to. - **External access during development:** NodePort offers a simple solution. - **Production-ready external access with load balancing:** LoadBalancer is your best bet. - **Traffic routing based on HTTP/HTTPS attributes:** Ingress is the answer. - **Advanced traffic management and extensibility:** Embrace the power of Gateway API. Remember, understanding Kubernetes Services is key to unlocking the full potential of your containerized applications. Choose wisely, and your microservices will be chatting like old friends in no time! ## Going Beyond the Basics: Service Meshes For advanced networking and traffic management, consider exploring Service Meshes like Istio, Linkerd, Traefik Mesh, Kong or Kuma. These tools provide additional features like traffic encryption, observability, and fine-grained traffic control, taking your Kubernetes networking game to the next level. [Kubernetes Gateway API v1.1: Service mesh, GRPCRoute y mucho másDespués del lanzamiento GA de Gateway API el pasado octubre, Kubernetes SIG Network anuncia el lanzamiento de la versión v1.1 de Gateway API. En este lanzamiento, varias características pasan a formar parte del Canal Estándar (GA), incluyendo el soporte para service mesh y GRPCRoute. También introducen algunas características nuevas![](https://www.sredevops.org/content/images/size/w256h256/2024/07/Icon-App-76x76@2x.png)SREDevOps.orgNicolás Georger![](https://www.sredevops.org/content/images/2024/05/api-gateway-kubernetes.png)](https://www.sredevops.org/es/kubernetes-gateway-api-v1-1-service-mesh-grpcroute-y-mucho-mas/) ### Python poderia ter desencadeado o apocalipse global por engano URL: https://www.sredevops.org/br/python-poderia-ter-desencadeado-o-apocalipse-global-por-engano/ Last updated: 2024-08-05T08:07:27.000Z **Em resumo:** Imagine um mundo onde suas plataformas de redes sociais favoritas saem do ar, os sistemas financeiros entram em colapso e até mesmo a exploração espacial é interrompida. Este cenário distópico quase se tornou realidade graças a um único *access token* vazado que poderia ter dado a agentes mal-intencionados as chaves do reino, sendo o reino todo o ecossistema Python. Felizmente, o desastre foi evitado, mas o fato de ter chegado tão perto serve como um lembrete severo da fragilidade do nosso mundo dependente de software e da importância de ter fortes medidas de segurança em vigor. ## Um problema de software que (quase) se espalhou pelo mundo Você se lembra daqueles filmes de desastre em que o mundo mergulha no caos devido a um evento catastrófico? Agora imagine que, em vez de um asteroide ou uma invasão alienígena, o culpado fosse um simples erro de codificação. Esse é o cenário assustador que se desenrolou quando pesquisadores de segurança da JFrog descobriram uma vulnerabilidade que poderia ter colocado o mundo digital de joelhos. [Incident Report: Leaked GitHub Personal Access Token - The Python Package Index BlogWe responded to an incident related to a leaked GitHub Personal Access Token for a PyPI administrator.![](https://blog.pypi.org/assets/favicon.ico)logoEe Durbin PyPI Admin, Director of Infrastructure (PSF)![](https://blog.pypi.org/assets/images/social/posts/2024-07-08-incident-report-leaked-admin-personal-access-token.png)](https://blog.pypi.org/posts/2024-07-08-incident-report-leaked-admin-personal-access-token/?ref=sredevops.org) No coração deste quase fracasso apocalíptico estava o Python, a linguagem de programação onipresente que alimenta tudo, de serviços web a aplicações de IA. Um *GitHub Personal Access Token*, que foi inadvertidamente deixado exposto em um contêiner Docker público, poderia ter dado a agentes mal-intencionados acesso irrestrito à infraestrutura do Python, potencialmente permitindo que injetassem código malicioso nos inúmeros sistemas que dependem dele. ## Python: O motor silencioso da era digital Para compreender a devastação potencial de um ataque como esse, é crucial entender a influência generalizada do Python. Essa linguagem versátil é a espinha dorsal de inúmeros sites, aplicações e sistemas críticos: - **Redes sociais:** plataformas como YouTube, Instagram e Facebook dependem fortemente de Python. - **Inteligência artificial:** Python é a linguagem preferida para *machine learning* e desenvolvimento de IA. - **Computação em nuvem (*cloud computing*):** gigantes da nuvem como Amazon, Google e Microsoft contam com Python para sua infraestrutura e serviços. - **Finanças:** instituições financeiras usam Python para tudo, desde negociação algorítmica até gerenciamento de riscos. - **Governo e infraestrutura:** agências governamentais e sistemas de infraestrutura crítica dependem de Python para uma variedade de tarefas. Se agentes mal-intencionados tivessem assumido o controle da infraestrutura do Python, eles poderiam ter causado estragos em escala global. Os mercados financeiros poderiam ter desmoronado, as plataformas de mídia social poderiam ter sido desligadas e os serviços essenciais poderiam ter sido interrompidos. Teria sido um apocalipse digital. ## Evitando o desastre: um escape por pouco Felizmente, o desastre foi evitado graças à vigilância da equipe de pesquisa de segurança da JFrog. Como parte de seus esforços contínuos para proteger a *software supply chain*, a equipe rotineiramente verifica pacotes de software populares em busca de vulnerabilidades. Neste caso particular, sua diligência valeu a pena. Eles descobriram o *access token* vazado escondido dentro de um arquivo binário compilado, um lugar onde muitas medidas de segurança não alcançam. A descoberta destaca uma falha crítica nas práticas de segurança de muitas organizações. Embora a verificação de código-fonte em busca de vulnerabilidades seja essencial, não é suficiente. Código malicioso pode ser ocultado dentro de binários compilados, contornando efetivamente as ferramentas de análise de código-fonte. Para realmente proteger seus sistemas, as organizações devem adotar uma abordagem holística que inclua a verificação de código-fonte e binários. ## Lições aprendidas: construindo um mundo digital mais resiliente O quase apocalipse do Python é um alerta para toda a indústria de tecnologia. Ele destaca a interconexão do nosso mundo digital e as consequências devastadoras de vulnerabilidades aparentemente menores. Para evitar incidentes semelhantes no futuro, devemos priorizar a segurança em cada estágio do ciclo de vida de desenvolvimento de software. Isso inclui: - **Práticas de segurança robustas:** os desenvolvedores devem adotar práticas de codificação segura e utilizar ferramentas para identificar e mitigar vulnerabilidades nos estágios iniciais do processo de desenvolvimento. - **Escaneamento abrangente:** as equipes de segurança devem implementar soluções que verifiquem código-fonte e binários em busca de vulnerabilidades, garantindo que nenhuma pedra seja deixada sobre a outra. - **Colaboração e compartilhamento de informações:** a indústria de tecnologia deve promover uma cultura de colaboração e compartilhamento de informações para se manter à frente das ameaças emergentes. Plataformas como *GitHub Security Advisories* fornecem um fórum valioso para relatar e resolver vulnerabilidades. *O dispositivo do fim do mundo* do Python pode ter sido desarmado desta vez, mas a ameaça permanece. À medida que nossa dependência de software aumenta, também aumenta a importância de se ter fortes medidas de segurança em vigor. Ao aprender com essa quase crise, podemos construir um mundo digital mais seguro e resiliente para todos. ## Fuente [Binary secret scanning helped us prevent (what might have been) the worst supply chain attack you can imagineThe JFrog Security Research team has recently discovered and reported a leaked access token with administrator access to Python’s, PyPI’s and Python Software Foundation’s GitHub repositories, which was leaked in a public Docker container hosted on Docker Hub. As a community service, the JFrog Security Research team continuously scans public repositories such as Docker Hub, …![](https://speedmedia.jfrog.com/08612fe1-9391-4cf3-ac1a-6dd49c36b276/media.jfrog.com/wp-content/uploads/2019/04/20131046/Jfrog16-1.png)JFrogdrewt![](https://speedmedia.jfrog.com/08612fe1-9391-4cf3-ac1a-6dd49c36b276/media.jfrog.com/wp-content/uploads/2024/07/09160017/PyPI-Leaked-Token-in-Binary-1200-x-630.png)](https://jfrog.com/blog/leaked-pypi-secret-token-revealed-in-binary-preventing-suppy-chain-attack/?ref=sredevops.org) ### Python pudo haber desencadenado el apocalipsis global por error URL: https://www.sredevops.org/es/python-pudo-haber-desencadenado-el-apocalipsis-global-por-error/ Last updated: 2026-01-08T02:35:54.000Z **En resumen:** Imagina un mundo donde tus plataformas de redes sociales favoritas se apagan, los sistemas financieros colapsan e incluso la exploración espacial se detiene. Este escenario distópico casi se vuelve realidad gracias a un único *access token* filtrado que podría haber dado a los actores maliciosos las llaves del reino, siendo el reino todo el ecosistema Python. Afortunadamente, se evitó el desastre, pero el hecho de que haya estado tan cerca sirve como un duro recordatorio de la fragilidad de nuestro mundo dependiente del software y la importancia de contar con medidas de seguridad sólidas. ## Un problema de software que (casi) se escucha en todo el mundo ¿Recuerdas esas películas de desastres en las que el mundo se hunde en el caos debido a un evento catastrófico? Ahora imagina que, en lugar de un asteroide o una invasión alienígena, el culpable fuera un simple error de codificación. Ese es el escenario espeluznante que se desarrolló cuando los investigadores de seguridad de JFrog descubrieron una vulnerabilidad que podría haber puesto al mundo digital de rodillas. En el corazón de este apocalipsis casi fallido estaba Python, el omnipresente lenguaje de programación que impulsa todo, desde servicios web hasta aplicaciones de IA. Un *GitHub Personal Access Token*, que se dejó expuesto inadvertidamente en un contenedor Docker público, podría haber dado a los actores maliciosos acceso sin restricciones a la infraestructura de Python, lo que podría haberles permitido inyectar código malicioso en los innumerables sistemas que dependen de él. [Incident Report: Leaked GitHub Personal Access Token - The Python Package Index BlogWe responded to an incident related to a leaked GitHub Personal Access Token for a PyPI administrator.![](https://blog.pypi.org/assets/favicon.ico)logoEe Durbin PyPI Admin, Director of Infrastructure (PSF)![](https://blog.pypi.org/assets/images/social/posts/2024-07-08-incident-report-leaked-admin-personal-access-token.png)](https://blog.pypi.org/posts/2024-07-08-incident-report-leaked-admin-personal-access-token/?ref=sredevops.org) ## Python: El motor silencioso de la era digital Para comprender la devastación potencial de un ataque de este tipo, es crucial comprender la influencia generalizada de Python. Este lenguaje versátil es la columna vertebral de innumerables sitios web, aplicaciones y sistemas críticos: - **Redes sociales:** plataformas como YouTube, Instagram y Facebook dependen en gran medida de Python. - **Inteligencia artificial:** Python es el lenguaje elegido para el aprendizaje automático (*machine learning*) y el desarrollo de IA. - **Computación en la nube (*cloud computing*):** gigantes de la nube como Amazon, Google y Microsoft confían en Python para su infraestructura y servicios. - **Finanzas:** las instituciones financieras utilizan Python para todo, desde el comercio algorítmico hasta la gestión de riesgos. - **Gobierno e infraestructura:** las agencias gubernamentales y los sistemas de infraestructura crítica dependen de Python para diversas tareas. Si los actores maliciosos hubieran tomado el control de la infraestructura de Python, podrían haber causado estragos a escala global. Los mercados financieros podrían haberse derrumbado, las plataformas de redes sociales podrían haberse apagado y los servicios esenciales podrían haberse interrumpido. Habría sido un apocalipsis digital. ## Evitando el desastre: un escape por poco Afortunadamente, el desastre se evitó gracias a la vigilancia del equipo de investigación de seguridad de JFrog. Como parte de sus esfuerzos continuos para asegurar la cadena de suministro de software (*software supply chain*), el equipo escanea rutinariamente paquetes de software populares en busca de vulnerabilidades. En este caso, su diligencia valió la pena. Descubrieron el *access token* filtrado escondido dentro de un archivo binario compilado, un lugar donde muchas medidas de seguridad no llegan. El descubrimiento destaca una debilidad crítica en las prácticas de seguridad de muchas organizaciones. Si bien escanear el código fuente en busca de vulnerabilidades es esencial, no es suficiente. El código malicioso se puede ocultar dentro de binarios compilados, eludiendo eficazmente las herramientas de análisis de código fuente. Para asegurar verdaderamente sus sistemas, las organizaciones deben adoptar un enfoque integral que incluya el escaneo tanto del código fuente como de los binarios. ## Lecciones aprendidas: construyendo un mundo digital más resiliente El casi apocalipsis de Python es una llamada de atención para toda la industria tecnológica. Subraya la interconexión de nuestro mundo digital y las consecuencias devastadoras de vulnerabilidades aparentemente menores. Para prevenir incidentes similares en el futuro, debemos priorizar la seguridad en cada etapa del ciclo de vida del desarrollo de software. Esto incluye: - **Prácticas de seguridad sólidas:** los desarrolladores deben adoptar prácticas de codificación seguras y utilizar herramientas para identificar y mitigar vulnerabilidades en las primeras etapas del proceso de desarrollo. - **Escaneo integral:** los equipos de seguridad deben implementar soluciones que escaneen tanto el código fuente como los binarios en busca de vulnerabilidades, asegurándose de que no se deje piedra sin remover. - **Colaboración e intercambio de información:** la industria tecnológica debe fomentar una cultura de colaboración e intercambio de información para adelantarse a las amenazas emergentes. Plataformas como *GitHub Security Advisories* proporcionan un foro valioso para informar y abordar vulnerabilidades. El *dispositivo del fin del mundo* de Python puede haber sido desarmado esta vez, pero la amenaza permanece. A medida que crece nuestra dependencia del software, también lo hace la importancia de contar con medidas de seguridad sólidas. Al aprender de este casi accidente, podemos construir un mundo digital más seguro y resiliente para todos. ## Fuente [Binary secret scanning helped us prevent (what might have been) the worst supply chain attack you can imagineThe JFrog Security Research team has recently discovered and reported a leaked access token with administrator access to Python’s, PyPI’s and Python Software Foundation’s GitHub repositories, which was leaked in a public Docker container hosted on Docker Hub. As a community service, the JFrog Security Research team continuously scans public repositories such as Docker Hub, …![](https://speedmedia.jfrog.com/08612fe1-9391-4cf3-ac1a-6dd49c36b276/media.jfrog.com/wp-content/uploads/2019/04/20131046/Jfrog16-1.png)JFrogdrewt![](https://speedmedia.jfrog.com/08612fe1-9391-4cf3-ac1a-6dd49c36b276/media.jfrog.com/wp-content/uploads/2024/07/09160017/PyPI-Leaked-Token-in-Binary-1200-x-630.png)](https://jfrog.com/blog/leaked-pypi-secret-token-revealed-in-binary-preventing-suppy-chain-attack/?ref=sredevops.org) ### Python could have triggered global apocalypse by mistake URL: https://www.sredevops.org/en/python-could-have-triggered-global-apocalypse-by-mistake/ Last updated: 2024-08-05T07:51:55.000Z **TL;DR:** Imagine a world where your favorite social media platforms go dark, financial systems crash, and even space exploration grinds to a halt. This dystopian scenario almost became a reality thanks to a single leaked access token that could have given malicious actors the keys to the kingdom—the kingdom being the entire Python ecosystem. Thankfully, disaster was averted, but the close call serves as a stark reminder of the fragility of our software-dependent world and the importance of robust security measures. ## A Software Glitch Heard Around the World (Almost) Remember those disaster movies where the world descends into chaos because of a catastrophic event? Now imagine that instead of an asteroid or alien invasion, the culprit was a simple coding error. That's the hair-raising scenario that played out when security researchers at JFrog discovered a vulnerability that could have brought the digital world to its knees. At the heart of this near-miss apocalypse was Python, the ubiquitous programming language that powers everything from web services to AI applications. A leaked GitHub Personal Access Token, inadvertently left exposed in a public Docker container, could have given malicious actors unfettered access to Python's infrastructure, potentially allowing them to inject malicious code into the countless systems that rely on it. ## Python: The Silent Powerhouse of the Digital Age To grasp the potential devastation of such an attack, it's crucial to understand Python's pervasive influence. This versatile language is the backbone of countless websites, applications, and critical systems: - **Social Media:** Platforms like YouTube, Instagram, and Facebook rely heavily on Python. - **Artificial Intelligence:** Python is the language of choice for machine learning and AI development. - **Cloud Computing:** Cloud giants like Amazon, Google, and Microsoft rely on Python for their infrastructure and services. - **Finance:** Financial institutions use Python for everything from algorithmic trading to risk management. - **Government and Infrastructure:** Government agencies and critical infrastructure systems depend on Python for various tasks. Had the malicious actors gained control of Python's infrastructure, they could have wreaked havoc on a global scale. Financial markets could have crashed, social media platforms could have gone dark, and essential services could have been disrupted. It would have been a digital apocalypse. [Incident Report: Leaked GitHub Personal Access Token - The Python Package Index BlogWe responded to an incident related to a leaked GitHub Personal Access Token for a PyPI administrator.![](https://blog.pypi.org/assets/favicon.ico)logoEe Durbin PyPI Admin, Director of Infrastructure (PSF)![](https://blog.pypi.org/assets/images/social/posts/2024-07-08-incident-report-leaked-admin-personal-access-token.png)](https://blog.pypi.org/posts/2024-07-08-incident-report-leaked-admin-personal-access-token/?ref=sredevops.org) ## Averting Disaster: A Narrow Escape Thankfully, disaster was averted thanks to the vigilance of the JFrog security research team. As part of their ongoing efforts to secure the software supply chain, the team routinely scans popular software packages for vulnerabilities. In this instance, their diligence paid off. They discovered the leaked access token lurking within a compiled binary file, a place where many security measures fail to look. The discovery highlights a critical weakness in many organizations' security practices. While scanning source code for vulnerabilities is essential, it's not enough. Malicious code can be hidden within compiled binaries, effectively bypassing source code analysis tools. To truly secure their systems, organizations need to adopt a comprehensive approach that includes scanning both source code and binaries. ## Lessons Learned: Building a More Resilient Digital World The near-miss Python apocalypse is a wake-up call for the entire tech industry. It underscores the interconnectedness of our digital world and the devastating consequences of even seemingly minor vulnerabilities. To prevent similar incidents in the future, we need to prioritize security at every stage of the software development lifecycle. This includes: - **Robust Security Practices:** Developers need to adopt secure coding practices and use tools to identify and mitigate vulnerabilities early in the development process. - **Comprehensive Scanning:** Security teams need to implement solutions that scan both source code and binaries for vulnerabilities, ensuring that no stone is left unturned. - **Collaboration and Information Sharing:** The tech industry needs to foster a culture of collaboration and information sharing to stay ahead of emerging threats. Platforms like GitHub Security Advisories provide a valuable forum for reporting and addressing vulnerabilities. The Python doomsday device may have been disarmed this time, but the threat remains. As our reliance on software grows, so too does the importance of robust security measures. By learning from this near-miss, we can build a more secure and resilient digital world for everyone. ### Source [Binary secret scanning helped us prevent (what might have been) the worst supply chain attack you can imagineThe JFrog Security Research team has recently discovered and reported a leaked access token with administrator access to Python’s, PyPI’s and Python Software Foundation’s GitHub repositories, which was leaked in a public Docker container hosted on Docker Hub. As a community service, the JFrog Security Research team continuously scans public repositories such as Docker Hub, …![](https://speedmedia.jfrog.com/08612fe1-9391-4cf3-ac1a-6dd49c36b276/media.jfrog.com/wp-content/uploads/2019/04/20131046/Jfrog16-1.png)JFrogdrewt![](https://speedmedia.jfrog.com/08612fe1-9391-4cf3-ac1a-6dd49c36b276/media.jfrog.com/wp-content/uploads/2024/07/09160017/PyPI-Leaked-Token-in-Binary-1200-x-630.png)](https://jfrog.com/blog/leaked-pypi-secret-token-revealed-in-binary-preventing-suppy-chain-attack/?ref=sredevops.org) ### O Segredo Aberto do GitHub: Seus Repositórios Privados e Excluídos Não São Tão Privados Assim URL: https://www.sredevops.org/br/o-segredo-aberto-do-github-seus-repositorios-privados-e-excluidos-nao-sao-tao-privados-assim/ Last updated: 2024-08-02T20:37:52.000Z ## Em poucas palavras O jardim do GitHub tem uma erva daninha de privacidade crescendo fora de controle. Acontece que excluir seus forks do GitHub ou até mesmo repositórios inteiros não apaga os dados. Essa informação suculenta permanece pronta para ser coletada, acessível a qualquer pessoa que saiba onde procurar. Estamos falando de chaves de API, informações privadas, o ouro. Isso não é um bug, é um "recurso" e está fazendo algumas pessoas suarem frio. Vamos mergulhar em como isso funciona, por que é um grande problema e o que você pode fazer para proteger seu precioso código. ## Rede de Repositórios do GitHub: Uma Teia Emaranhada de Forks e Segredos O GitHub, o queridinho da colaboração em código aberto, tem um pequeno segredo. Ele gerencia repositórios e seus forks como uma árvore genealógica gigante, com o repositório original como raiz. Parece inocente, certo? Mas aqui está o problema: quando você exclui um repositório público que foi bifurcado, o GitHub não simplesmente destrói a árvore inteira. Em vez disso, ele simplesmente reatribui a raiz para um dos forks sobreviventes. Isso significa que qualquer código submetido ao repositório original, mesmo após um fork, pode ser acessado por meio de qualquer um de seus forks. Sim, você leu certo. Excluído não significa que sumiu, apenas… realocado. Isso fica ainda mais interessante com repositórios privados. Imagine o seguinte: você inicia um repositório privado para um novo projeto, faz um fork dele para adicionar algum ingrediente secreto que você planeja monetizar e, em seguida, abre o código do repositório original. Você pode presumir que essas submissões privadas permanecem privadas. Bem, surpresa! Quaisquer commits feitos no fork privado *antes* de você tornar o repositório original público ainda estão visíveis. Adeus ingrediente secreto. ## Por que isso Importa: Quando o Código Aberto se Torna um Pouco Aberto Demais As implicações aqui são enormes. Aquela chave de API que você acidentalmente subiu? Sim, ela ainda pode estar lá fora, mesmo se você excluiu o repositório. Aquela informação privada que você pensou estar guardada em um fork privado? Pense de novo. Se alguém souber onde procurar, poderá encontrá-la. Este não é apenas um problema hipotético. Pesquisadores de segurança já encontraram dados confidenciais, como chaves de API e chaves privadas, apenas vasculhando os repositórios públicos e forks do GitHub. E adivinha? O GitHub sabe disso. Eles até reconhecem isso em sua documentação, chamando-a de "decisão de design intencional". Agora, antes que você pegue seus forcados, é importante lembrar que o GitHub foi construído sobre os princípios da colaboração em código aberto. Mas há uma diferença entre colaboração aberta e expor dados confidenciais involuntariamente. Este "recurso" parece confundir essa linha, e é um problema. ## O Que Você Pode Fazer: Protegendo Seu Código em um Mundo de Forks Persistentes Então, o que um desenvolvedor deve fazer? Aqui estão algumas dicas para manter em mente: ### 1\. Trate os Repositórios Públicos Como Las Vegas: Presuma que o que Acontece Lá, Permanece Lá Se você fizer o commit em um repositório público, considere-o público para sempre. Isso inclui repositórios e forks excluídos. Verifique duas, três vezes antes de enviar qualquer coisa confidencial. E se você errar, aja rápido. Altere as chaves de API, remova dados confidenciais e entre em contato com o suporte do GitHub se necessário. ### 2\. Repositórios Privados Não São Infalíveis: Esteja Ciente da Linha do Tempo do Código Aberto Se você planeja abrir o código de um projeto, esteja ciente do que você envia para forks privados. Quaisquer commits feitos antes que o projeto se torne público podem ser expostos. Considere manter esses recursos super-secretos em um repositório separado, verdadeiramente privado, até que você esteja pronto para liberá-los. ### 3\. GitHub, Precisamos Conversar: Advocar pela Mudança Este problema não vai desaparecer sozinho. Vamos encorajar o GitHub a repensar esta decisão de design. Podemos começar aumentando a conscientização, enviando feedback e defendendo controles de privacidade mais fortes. Afinal, código aberto não precisa significar sacrificar a segurança. ## Conclusão: Um Chamado de Atenção para a Segurança do Código Aberto Toda essa confusão do GitHub é um chamado de atenção para a comunidade de código aberto. É hora de começar a pensar de forma diferente sobre como lidamos com informações confidenciais. Não vamos deixar a conveniência do código aberto prejudicar nossa segurança e privacidade. Portanto, sigam em frente, colegas desenvolvedores, e codifiquem com responsabilidade. E talvez fiquem de olho nesses forks, nunca se sabe quem pode estar à espreita nos galhos. ## Source: [Anyone can Access Deleted and Private Repository Data on GitHub ◆ Truffle Security Co.You can access data from deleted forks, deleted repositories and even private repositories on GitHub. And it is available forever. This is known by GitHub, and intentionally designed that way.![](https://framerusercontent.com/images/Zc4TyjSMxOgNAgz2xiSmBA3veU.png)![](https://framerusercontent.com/images/QBddtt3Ue3SLvfEshNFBiR49U8I.png)](https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github?ref=sredevops.org) ### El Secreto a Voces de GitHub: Tus Repos Eliminados y Privados no son tan Privados Como Crees URL: https://www.sredevops.org/es/el-secreto-a-voces-de-github-tus-repos-eliminados-y-privados-no-son-tan-privados-como-crees/ Last updated: 2026-01-08T02:36:26.000Z ## En Resumen ¿Alguna vez has hecho commit de algo que no deberías? Porque el jardín de GitHub tiene una maleza de privacidad creciendo sin control. Resulta que eliminar tus forks de GitHub o incluso repositorios enteros no borra realmente los datos. Esta jugosa información se mantiene fresca para ser recogida, accesible a cualquiera que sepa dónde buscar. Estamos hablando de claves API, información privada, el trabajo completo. Esto no es un bug, es una "feature", y está haciendo sudar a algunos. Vamos a sumergirnos en cómo funciona esto, por qué es un gran problema, y qué puedes hacer para proteger tu preciado código. ## La Red de Repositorios de GitHub: Una Enredada Telaraña de Forks y Secretos GitHub, el favorito de la colaboración open source, tiene un pequeño secreto. Gestiona los repositorios y sus forks como un árbol genealógico gigante, con el repositorio original como raíz. Suena bastante inocente, ¿verdad? Pero aquí está la trampa: cuando eliminas un repositorio público que ha sido forkeado, GitHub no se limita a eliminar todo el árbol. En cambio, simplemente reasigna la raíz a uno de los forks supervivientes. Esto significa que cualquier código commited al repositorio original, incluso después de un fork, puede ser accedido a través de cualquiera de sus forks. Sí, lo has leído bien. Eliminado no significa que haya desaparecido, sólo que… se ha reubicado. Esto se vuelve aún más interesante con los repositorios privados. Imagina esto: Iniciaste un repo privado para un nuevo proyecto, lo forkeas para añadirle una salsa secreta que planeas monetizar, y luego liberas como open-source el repositorio original. Podrías asumir que esos commits privados se mantienen privados. Bueno, ¡sorpresa! Cualquier commit hecho al fork privado *antes* de que hicieras público el repositorio original sigue siendo visible. Hasta aquí llegó la salsa secreta. ## Por Qué Esto Importa: Cuando el Open Source se Vuelve Demasiado Open Las implicaciones aquí son enormes. ¿Esa clave API que accidentalmente pusiste en un commit? Sí, puede que siga por ahí, incluso si borraste el repo. ¿Esa información privada que creías guardada en un fork privado? Piénsalo de nuevo. Si alguien sabe dónde buscar, puede encontrarla. Este no es sólo un problema hipotético. Investigadores de seguridad ya han encontrado datos sensibles como claves API y claves privadas simplemente excavando en los repositorios públicos y forks de GitHub. ¿Y adivina qué? GitHub lo sabe. Incluso lo reconocen en su documentación, llamándolo una "decisión de diseño intencionada". Ahora, antes de que agarres tus tridentes, es importante recordar que GitHub fue construido sobre los principios de la colaboración open source. Pero hay una diferencia entre la colaboración abierta y la exposición involuntaria de datos sensibles. Esta "feature" parece difuminar esa línea, y es un problema. ## Lo Que Puedes Hacer: Proteger Tu Código en un Mundo de Forks Persistentes Entonces, ¿qué debe hacer un desarrollador? Aquí tienes algunos consejos a tener en cuenta: ### 1\. Trata los Repos Públicos Como Las Vegas: Asume Que Lo Que Pasa Allí, Allí Se Queda Si haces commit en un repo público, considéralo público para siempre. Esto incluye los repositorios y forks eliminados. Comprueba dos y tres veces antes de enviar cualquier cosa sensible. Y si cometes un error, actúa rápido. Rota las claves API, elimina los datos sensibles y ponte en contacto con el soporte de GitHub si es necesario. ### 2\. Los Repos Privados No Son Infalibles: Ten en Cuenta la Línea de Tiempo del Open Source Si planeas liberar un proyecto como open source, ten en cuenta lo que haces commit en los forks privados. Cualquier commit realizado antes de que el proyecto se haga público podría quedar expuesto. Considera la posibilidad de mantener esas características supersecretas en un repositorio separado y verdaderamente privado hasta que estés listo para publicarlas. ### 3\. GitHub, Tenemos Que Hablar: Abogar por el Cambio Este problema no va a desaparecer por sí solo. Animemos a GitHub a reconsiderar esta decisión de diseño. Podemos empezar por concienciar, enviar feedback y abogar por controles de privacidad más estrictos. Después de todo, open source no tiene por qué significar sacrificar la seguridad. ## Una Llamada de Atención para la Seguridad del Open Source Todo este lío de GitHub es una llamada de atención para la comunidad open source. Es hora de empezar a pensar de forma diferente sobre cómo gestionamos la información sensible. No dejemos que la conveniencia del open source sea a costa de nuestra seguridad y privacidad. Así que adelante, compañeros desarrolladores, y programen con responsabilidad. Y quizás mantengan un ojo en esos forks, nunca se sabe quién podría estar acechando entre las ramas. ## Fuente: [Anyone can Access Deleted and Private Repository Data on GitHub ◆ Truffle Security Co.You can access data from deleted forks, deleted repositories and even private repositories on GitHub. And it is available forever. This is known by GitHub, and intentionally designed that way.![](https://framerusercontent.com/images/Zc4TyjSMxOgNAgz2xiSmBA3veU.png)![](https://framerusercontent.com/images/QBddtt3Ue3SLvfEshNFBiR49U8I.png)](https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github?ref=sredevops.org) ### GitHub's Open Secret: Your Deleted and Private Repos Aren't as Private as You Think URL: https://www.sredevops.org/en/githubs-open-secret-your-deleted-and-private-repos-arent-as-private-as-you-think/ Last updated: 2024-08-02T18:33:39.000Z ## TL;DR Have you ever committed something you shouldn't?, Because the GitHub garden has a privacy weed growing out of control. Turns out, deleting your GitHub forks or even entire repositories doesn't actually erase the data. This juicy info stays ripe for the picking, accessible to anyone who knows where to look. We're talking API keys, private info, the works. This isn't a bug, it's a "feature," and it's making some folks sweat. We'll dive into how this works, why it's a big deal, and what you can do to protect your precious code. ## GitHub's Repository Network: A Tangled Web of Forks and Secrets GitHub, the darling of open source collaboration, has a little secret. It manages repositories and their forks like a giant family tree, with the original repository as the root. Sounds innocent enough, right? But here's the kicker: when you delete a public repository that's been forked, GitHub doesn't just nuke the whole tree. Instead, it simply reassigns the root to one of the surviving forks. This means any code committed to the original repository, even after a fork, can be accessed through any of its forks. Yes, you read that right. Deleted doesn't mean gone, just… relocated. This gets even more interesting with private repositories. Imagine this: You start a private repo for a new project, fork it to add some secret sauce you plan to monetize, and then open-source the original repository. You might assume those private commits stay private. Well, surprise! Any commits made to the private fork *before* you made the original repository public are still visible. So much for secret sauce. ## Why This Matters: When Open Source Goes a Little Too Open The implications here are massive. That API key you accidentally committed? Yeah, it might still be out there, even if you deleted the repo. That private info you thought was tucked away in a private fork? Think again. If someone knows where to look, they can find it. This isn't just a hypothetical problem either. Security researchers have already found sensitive data like API keys and private keys just by digging through GitHub’s public repositories and forks. And guess what? GitHub knows about it. They even acknowledge it in their documentation, calling it an "intentional design decision." Now, before you grab your pitchforks, it's important to remember that GitHub was built on the principles of open-source collaboration. But there's a difference between open collaboration and unintentionally exposing sensitive data. This "feature" seems to blur that line, and it's a problem. ## What You Can Do: Protecting Your Code in a World of Persistent Forks So, what's a developer to do? Here are a few tips to keep in mind: ### 1\. Treat Public Repos Like Vegas: Assume What Happens There Stays There If you commit it to a public repo, consider it public forever. This includes deleted repositories and forks. Double, triple check before you push anything sensitive. And if you do mess up, act fast. Rotate API keys, remove sensitive data, and contact GitHub support if necessary. ### 2\. Private Repos Aren't Foolproof: Be Mindful of the Open-Source Timeline If you're planning to open-source a project, be aware of what you commit to private forks. Any commits made before the project goes public could be exposed. Consider keeping those super-secret features in a separate, truly private repository until you're ready to release them. ### 3\. GitHub, We Need to Talk: Advocate for Change This issue isn't going away on its own. Let's encourage GitHub to rethink this design decision. We can start by raising awareness, submitting feedback, and advocating for stronger privacy controls. After all, open source doesn't have to mean sacrificing security. ## The Takeaway: A Wake-Up Call for Open Source Security This whole GitHub kerfuffle is a wake-up call for the open source community. It's time to start thinking differently about how we handle sensitive information. Let's not let the convenience of open source come at the cost of our security and privacy. So go forth, fellow developers, and code responsibly. And maybe keep a close eye on those forks, you never know who might be lurking in the branches. ## Source: [Anyone can Access Deleted and Private Repository Data on GitHub ◆ Truffle Security Co.You can access data from deleted forks, deleted repositories and even private repositories on GitHub. And it is available forever. This is known by GitHub, and intentionally designed that way.![](https://framerusercontent.com/images/Zc4TyjSMxOgNAgz2xiSmBA3veU.png)![](https://framerusercontent.com/images/QBddtt3Ue3SLvfEshNFBiR49U8I.png)](https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github?ref=sredevops.org) ### Google Cloud Potencia sus Bases de Datos con IA para la Era de los Datos y la Inteligencia URL: https://www.sredevops.org/es/google-cloud-potencia-sus-bases-de-datos-con-ia-para-la-era-de-los-datos-y-la-inteligencia/ Last updated: 2026-01-08T02:35:56.000Z ## TL;DR; Google Cloud está causando sensación en su conferencia Cloud Next en Tokio al inyectar a su línea de bases de datos una buena dosis de IA. Spanner, su base de datos SQL distribuida, ahora cuenta con capacidades de *búsqueda* *gráfica (graphQL)* y *vectorial (Vector)*, perfectas para aprovechar el poder de la IA generativa. Bigtable, su caballo de batalla NoSQL para conjuntos de datos masivos, recibe una dosis de compatibilidad con SQL, lo que lo hace más amigable para los desarrolladores. Incluso están dando la bienvenida a las bases de datos Oracle, lo que permite a los usuarios ejecutar bases de datos Oracle Exadata y Autonomous directamente dentro de Google Cloud. ## Bases de Datos con IA para el ecosistema Moderno en Datos En un mundo inundado de datos, Google Cloud está enfocado en hacer que esos datos trabajen más duro con la IA. Sus ofertas de bases de datos renovadas están diseñadas para ayudar a las empresas a navegar por el mar de información y desbloquear el potencial de la IA generativa. El gigante tecnológico reconoce que, si bien las empresas están entusiasmadas con la IA generativa, gran parte de sus datos están inactivos, encerrados en silos. Para liberar el verdadero poder de la IA, Google Cloud enfatiza la necesidad de romper estas barreras de datos. Su objetivo es crear una plataforma de datos unificada y "multimodal" que reúna datos estructurados y no estructurados, atendiendo a las necesidades de los hambrientos modelos de IA. ## Spanner: De un SQL Robusto a una Potencia de IA Spanner, la columna vertebral de los propios servicios de Google como Search, Gmail y YouTube, está recibiendo una actualización importante. Ya no se trata solo de manejar volúmenes masivos de datos; se trata de preparar esos datos para la IA. Aquí entran las bases de datos "*gráficas" (GraphQL) y "vectoriales"*, cruciales para cerrar la brecha entre los datos tradicionales y las aplicaciones de IA. Google Cloud está agregando estas capacidades a Spanner, lo que permite a las empresas aprovechar el poder de Retrieval Augmented Generation (RAG) para mejorar sus aplicaciones de IA. ¡Spanner también está obteniendo capacidades de búsqueda de texto completo y vectorial, impulsadas por el propio algoritmo ScaNN de Google. Estas adiciones transforman a Spanner en una base de datos versátil y multimodelo, lista para abordar las demandas de las aplicaciones impulsadas por IA. ## Bigtable Abraza SQL para Alegría de los Desarrolladores Bigtable, la base de datos NoSQL de Google Cloud para manejar cantidades masivas de datos no estructurados, está recibiendo un cambio de imagen amigable para el desarrollador con la adición de soporte SQL. No más luchar con APIs complejas; ahora los desarrolladores pueden consultar Bigtable usando comandos SQL familiares. Este movimiento reduce significativamente la barrera de entrada para los desarrolladores que buscan aprovechar el poder de Bigtable. Con soporte para alrededor de 100 funciones SQL, Bigtable se convierte en una herramienta más accesible y versátil para administrar y analizar datos a escala. ## Oracle Encuentra un Hogar en Google Cloud En un movimiento que podría sorprender a algunos, Google Cloud está abriendo sus puertas a las bases de datos Oracle. Los usuarios de Oracle ahora pueden alojar sus bases de datos Exadata y Autonomous directamente dentro de los centros de datos de Google, disfrutando de una experiencia perfecta. Este movimiento estratégico permite a Google Cloud atraer a los usuarios de Oracle y expandir su base de clientes. Para Oracle, asegura que sus clientes continúen pagando tarifas de licencia, incluso mientras usan la infraestructura de Google. ## Un Ecosistema de Datos para el Futuro Estas actualizaciones de las ofertas de bases de datos de Google Cloud destacan su compromiso de crear un ecosistema de datos integral. Al integrar capacidades de IA, mejorar la accesibilidad para los desarrolladores y adoptar asociaciones, Google Cloud se está posicionando como líder en el panorama de datos en evolución. [Data analytics innovations to fuel AI initiatives | Google Cloud BlogGoogle Cloud data platform has 350+ new data analytics capabilities so far this year, many of which integrate new gen AI capabilities.![](https://www.gstatic.com/cloud/images/icons/favicon.ico)Google Cloud![](https://storage.googleapis.com/gweb-cloudblog-publish/images/DO_NOT_USE_CUxs9oC.max-2500x2500.jpg)](https://cloud.google.com/blog/products/data-analytics/data-analytics-innovations-to-fuel-ai-initiatives/?ref=sredevops.org) ### Google Cloud Enhances Databases with AI Power for the Age of Data and Intelligence URL: https://www.sredevops.org/en/google-cloud-enhances-databases-with-ai-power-for-the-age-of-data-and-intelligence/ Last updated: 2024-08-01T18:26:39.000Z ## TL;DR; Google Cloud is making waves at its Cloud Next conference in Tokyo by injecting its database lineup with some serious AI muscle. Spanner, their globally distributed SQL database, now boasts graph and vector search capabilities, perfect for tapping into the power of generative AI. Bigtable, their NoSQL workhorse for massive datasets, gets a dose of SQL compatibility, making it more developer-friendly. They're even welcoming Oracle databases into the fold, allowing users to run Oracle Exadata and Autonomous databases directly within Google Cloud. ## Supercharging Databases with AI for the Modern Data Landscape In a world swimming in data, Google Cloud is laser-focused on making that data work harder with AI. Their revamped database offerings are designed to help businesses navigate the sea of information and unlock the potential of generative AI. The tech giant recognizes that while enterprises are hyped about generative AI, a lot of their data is sitting idle, locked away in silos. To unleash the true power of AI, Google Cloud emphasizes the need to break down these data barriers. Their goal is to create a unified, "multimodal" data platform that brings together structured and unstructured data, catering to the appetites of hungry AI models. ## Spanner: From Robust SQL to AI Powerhouse Spanner, the backbone of Google's own services like Search, Gmail, and YouTube, is getting a serious upgrade. It's not just about handling massive data volumes anymore; it's about making that data AI-ready. Enter graph and vector databases, crucial for bridging the gap between traditional data and AI applications. Google Cloud is adding these capabilities to Spanner, allowing businesses to leverage the power of Retrieval Augmented Generation (RAG) to enhance their AI applications. But wait, there's more! Spanner is also getting full-text and vector search capabilities, powered by Google's own ScaNN algorithm. These additions transform Spanner into a versatile, multi-model database, ready to tackle the demands of AI-driven applications. ## Bigtable Embraces SQL for Developer Joy Bigtable, Google Cloud's NoSQL database for handling massive amounts of unstructured data, is getting a developer-friendly makeover with the addition of SQL support. No more wrestling with complex APIs; now developers can query Bigtable using familiar SQL commands. This move significantly lowers the barrier to entry for developers looking to harness the power of Bigtable. With support for around 100 SQL functions, Bigtable becomes a more accessible and versatile tool for managing and analyzing data at scale. ## Oracle Finds a Home in Google Cloud In a move that might surprise some, Google Cloud is opening its doors to Oracle databases. Oracle users can now host their Exadata and Autonomous databases directly within Google's data centers, enjoying a seamless experience. This strategic move allows Google Cloud to attract Oracle users and expand its customer base. For Oracle, it ensures that their customers continue paying licensing fees, even while using Google's infrastructure. ## A Data Ecosystem for the Future These updates to Google Cloud's database offerings highlight their commitment to creating a comprehensive data ecosystem. By integrating AI capabilities, enhancing developer accessibility, and embracing partnerships, Google Cloud is positioning itself as a leader in the evolving data landscape. [Data analytics innovations to fuel AI initiatives | Google Cloud BlogGoogle Cloud data platform has 350+ new data analytics capabilities so far this year, many of which integrate new gen AI capabilities.![](https://www.gstatic.com/cloud/images/icons/favicon.ico)Google Cloud![](https://storage.googleapis.com/gweb-cloudblog-publish/images/DO_NOT_USE_CUxs9oC.max-2500x2500.jpg)](https://cloud.google.com/blog/products/data-analytics/data-analytics-innovations-to-fuel-ai-initiatives/?ref=sredevops.org) ### SAPwned: Wiz Research revealed SAP AI vulnerabilities that leaked full control on cloud instances and private AI data URL: https://www.sredevops.org/en/sapwned-wiz-research-revealed-sap-ai-vulnerabilities-that-leaked-full-control-on-cloud-instances-and-private-ai-data/ Last updated: 2024-08-01T15:31:28.000Z ## TL/DR Grab your black hats, fellas: Wiz Research team has been poking around AI services to see if they're really as secure as they seem. They audited SAP AI Core, a PaaS which allows to develop, train and run AI managed, scalable services. Spoiler alert: They found some chinks in the armor. Think leaky logs, exposed files, and even a way to hijack the whole system! The good news? They told SAP about it, they patched things up faster than you can say "AI apocalypse," and your data is safe. But it's a good reminder that even with AI, you gotta double-check the locks. ![](https://www.sredevops.org/content/images/2024/08/1721220668-image-20.png) ## Istio and Kubernetes misconfigured: The real vulnerability Remember those "choose your own adventure" books? Their journey into SAP AI Core started out pretty tame. They were like regular users, just setting up an AI project. But things got interesting when they realized they could run their own code inside their system. Not a bug, totally by design. But it's like giving everyone a screwdriver when they visit your spaceship - you never know who's going to start tinkering with the engine. ![](https://www.sredevops.org/content/images/2024/08/1721220959-1-argo-config.png) First hurdle? They had this Istio proxy locking down network access. But like any good hacker (they're the good guys, promise!), they found a loophole. Turns out, setting their user ID to "1337" (we see you, fellow nerds) was like getting a backstage pass to the whole network. From there, they uncovered a chain of vulnerabilities, like breadcrumbs leading them deeper into the system: ### Leaking Loki Their logging service was spilling AWS secrets like it was gossip hour. They're talking access keys to buckets full of logs – juicy stuff! ![](https://www.sredevops.org/content/images/2024/08/1721221788-5-loki_ls_partial_blurred.png) ### EFS Exposé Imagine leaving your diary open in a public park. That's what they did with their Elastic File System, giving anyone on the network access to mountains of customer data. Oops! ### Helm: More Like "Help Yourself" Their Helm server (a tool for managing software packages) was the real MVP. It basically handed over the keys to the kingdom - they're talking access to their internal Docker registry, their Artifactory server, and even the ability to deploy code with full admin privileges. Talk about hitting the jackpot! ![](https://www.sredevops.org/content/images/2024/08/1721221160-2-istio_secret.png) With great power comes, well, the responsibility to tell someone they left the back door open. They reported all of these vulnerabilities to SAP, and they've since battened down the hatches. No harm, no foul. But it highlights a crucial point: security in the age of AI is a whole new ballgame. ## AI: Not Just a Buzzword, But a Security Challenge Here's the thing about AI: it thrives on data, and lots of it. That data is often sensitive, making AI platforms a prime target for attackers. And because these platforms need to run arbitrary code for training models, things can get messy fast if proper isolation isn't in place. Think of it like this: you wouldn't let strangers tinker with your house's electrical panel, right? That's kind of what's happening here. SAP's mistake wasn't in allowing user code (that's the whole point of AI platforms!), but in assuming their internal services were inherently safe just because they were behind a single security checkpoint. ## Lessons Learned: Because Nobody Likes a Repeat Performance So what's the takeaway from their little adventure? - **Defense in Depth:** One layer of security is like a screen door on a submarine - it might look good, but it won't hold up under pressure. You need multiple layers, each protecting different parts of the system. - **Kubernetes Conundrums:** Kubernetes (K8s) is the darling of the cloud world, but it can be tricky to secure. When multiple users share a K8s cluster, it's crucial to create strong boundaries between their workloads and the underlying infrastructure. - **AI Ain't Easy:** AI development comes with its own set of security challenges. Platforms need to balance flexibility for users with robust safeguards to prevent malicious code from wreaking havoc. It's like juggling chainsaws while riding a unicycle – definitely not for amateurs! The cloud is the Wild West, and we're the sheriffs trying to keep things from going full-on Deadwood. Stay tuned for more tales from the trenches as we continue to explore the ever-evolving world of cloud security! ## Security Researchers and DevSecOps teams are a must Big thanks to the intrepid minds at Wiz Research who made this investigation possible: Hillai Ben-Sasson ([@hillai](https://x.com/@hillai?ref=sredevops.org)), Shir Tamari (@[shirtamari](https://x.com/shirtamari?ref=sredevops.org)), Nir Ohfeld ([@nirohfeld](https://x.com/@nirohfeld?ref=sredevops.org)), Sagi Tzadik ([@sagitz\_](https://x.com/@sagitz%5F?ref=sredevops.org)), and Ronen Shustin ([@ronenshh)](https://x.com/@ronenshh%29?ref=sredevops.org). The role of offensive security researchers and devsecops teams is crucial in identifying and fixing vulnerabilities before they can be exploited by malicious actors. We salute you! ## References [SAPwned: SAP AI vulnerabilities expose customers’ cloud environments and private AI artifacts | Wiz BlogWiz Research uncovers vulnerabilities in SAP AI Core, allowing malicious actors to take over the service and access customer data.![](https://www.wiz.io/favicon.png)Wiz.io![](https://www.datocms-assets.com/75231/1721220504-sap-ai-core-blog3-1.png?fm=webp)](https://www.wiz.io/blog/sapwned-sap-ai-vulnerabilities-ai-security?ref=sredevops.org) ### Qual a diferença entre SRE e SysAdmin? São a mesma coisa com outro nome? Queremos a sua opinião! URL: https://www.sredevops.org/br/qual-a-diferenca-entre-sre-e-sysadmin-sao-a-mesma-coisa-com-outro-nome-queremos-a-sua-opiniao/ Last updated: 2024-07-24T04:50:39.000Z Vamos ver quais são as diferenças chave entre um Site Reliability Engineer (SRE) e um Administrador de Sistemas (SysAdmin) "tradicional", destacando como a "filosofia" SRE, impulsionada pela automação, monitoramento e uma colaboração próxima com os desenvolvedores, leva a uma maior confiança nos sistemas e um ciclo de entregas mais rápido e eficiente (sim, isso é DevOps). ![class SRE implements DevOps](https://www.sredevops.org/content/images/2024/07/image-4.png) Mencionamos conceitos vitais de SRE como SLO, *error budget*, métricas, *logs*, *tracing*, e como realmente se podem beneficiar os desenvolvedores. Também, o porquê de não ser a mesma coisa que um SysAdmin com um nome mais "legal" (sim, para mim também é difícil pronunciar em inglês). ### O mito do "SysAdmin em esteroides" É muito comum que se perceba os SREs como administradores de sistemas com um nome fino e elegante. Embora muitos SREs venham de ambientes de administração de sistemas, sua abordagem difere significativamente. Um SRE aproveita suas habilidades de desenvolvimento para automatizar tarefas, construir sistemas de monitoramento e, acima de tudo, fomentar uma cultura de colaboração REAL entre Desenvolvedores e Operações. Não se trata apenas de manter *pipelines* ou colocar muitos passos para implantar seu código, mas de otimizar todos os sistemas, tanto humanos quanto técnicos, para alcançar confiança, estabilidade, segurança nos sistemas, escalabilidade e verdadeira Entrega Contínua (*Continuous Delivery*). ### O Santo Graal SRE: Métricas, Logs e Traces Um SRE vive e respira dados. Recolhe e analisa métricas, *logs* e *traces* para obter informações sobre o desempenho e o comportamento das aplicações em produção. Ao instrumentar aplicações, os SREs podem estabelecer objetivos de nível de serviço (SLO - *Service Level Objectives*) e "orçamentos de erro" (*error budgets*), o que permite aos desenvolvedores inovar e ter mais liberdades criativas dentro de faixas acordadas de riscos e alcances. [ParadeDB: Use the power of Postgres DB for your real-time search and data analytics (and more)ParadeDB is shaking things up in the world of search and analytics by offering a compelling Postgres-based alternative to Elasticsearch. This article dives into ParadeDB’s features, how it stacks up against Elasticsearch, and why you should keep an eye on this emerging technology. ParadeDB: Riding the Postgres Wave Remember when![](https://www.sredevops.org/content/images/size/w256h256/2024/07/Icon-App-76x76@2x.png)SREDevOps.orgNicolás Georger![](https://www.sredevops.org/content/images/2024/07/Screenshot-2024-07-13-at-18.02.33.png)](https://www.sredevops.org/en/paradedb-is-challenging-the-elasticsearch-alternative-youve-been-waiting-for-2/) ### Que ferramentas usa um SRE?: OpenTelemetry, Prometheus, Loki e mais O mundo SRE está repleto de ferramentas poderosas. O OpenTelemetry tornou-se um padrão *de facto* para a instrumentação de aplicações, enquanto o Prometheus e o Loki são ferramentas consolidadas para armazenamento, coleta e visualização de métricas e *logs*, respetivamente. Ferramentas como o Jaeger levam o rastreamento distribuído a um novo nível, o que permite aos SREs rastrear *requests* através de serviços complexos (*service mesh*), microsserviços e outros. [SREDevOps.org – Português BrasileiroEm português (Brasil): SRE, DevOps, Cloud Native, Linux, AI/ML, Platform Engineering, OpenSource e mais![](https://www.sredevops.org/content/images/size/w256h256/2024/07/Icon-App-76x76@2x.png)SREDevOps.org![](https://www.sredevops.org/content/images/2024/07/sredevopsorg-br.png)](https://www.sredevops.org/tag/br/) ## Por que é importante um SRE? *~~O SRE é seu amigo! yay!~~* Um SRE não apenas soluciona problemas, mas os previne. Ao adotar a automação, o monitoramento proativo e uma colaboração próxima com os desenvolvedores, os SREs garantem que os sistemas sejam resilientes, escaláveis e capazes de oferecer uma excelente experiência ao cliente, aos desenvolvedores e ao negócio. Um bom SRE dorme bem à noite, sabendo que seus *clusters* funcionam como devem (e, se não, ele tem alertas para despertá-lo). [O que é Engenharia de Plataforma? O que é isso para mim? O que aconteceu com o DevOps?Você tem ouvido e lido sobre Engenharia de Plataforma em toda a web ultimamente... mas nós realmente entendemos o que é Engenharia de Plataforma? Todos parecem convencidos e empolgados, mas você consegue ver como é diferente do DevOps? Tentaremos fazer um resumo geral com base no material que a Platform![](https://www.sredevops.org/content/images/size/w256h256/2024/07/Icon-App-76x76@2x.png)SREDevOps.orgNicolás Georger![](https://images.unsplash.com/photo-1523961131990-5ea7c61b2107?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=M3wxMTc3M3wwfDF8c2VhcmNofDN8fGludGVncmF0aW9ufGVufDB8fHx8MTY4ODA5NDYzMXww&ixlib=rb-4.0.3&q=80&w=2000)](https://www.sredevops.org/br/o-que-e-engenharia-de-plataforma-o-que-e-isso-para-mim-o-que-aconteceu-com-o-devops/) ### ¿Cuál es la diferencia entre SRE y SysAdmin?, ¿Son lo mismo con otro nombre? Queremos tu opinión URL: https://www.sredevops.org/es/cual-es-la-diferencia-entre-sre-y-sysadmin-son-lo-mismo-con-otro-nombre-queremos-tu-opinion/ Last updated: 2026-01-08T02:36:08.000Z Veamos cuáles son las diferencias clave entre un **Site Reliability Engineer** (SRE) y un **Administrador de Sistemas** (SysAdmin) "tradicional" destacando cómo la *"filosofía"* SRE, impulsada por la automatización, la monitorización y una estrecha colaboración con los desarrolladores, conduce a una **mayor confianza en los sistemas** y un ciclo de entregas más rápido y eficiente *(si, eso es DevOps)*. ![class SRE implements DevOps](https://www.sredevops.org/content/images/2024/07/image-4.png) Mencionamos conceptos vitales de SRE como `SLO`, `error budget`, `métricas`, `logs`, `tracing`, y cómo **realmente se pueden beneficiar desarrolladores,** también el por qué no es lo mismo que un SysAdmin con un nombre más "cool" *(~~si, a mi también me cuesta pronunciarlo en inglés~~).* ## El mito del "SysAdmin en esteroides" Es muy común que se perciba a los SRE como administradores de sistemas con un nombre *fino y elegante*. Si bien muchos SRE provienen de entornos de administración de sistemas, su enfoque difiere significativamente. Un SRE aprovechan sus habilidades de desarrollo para automatizar tareas, construir sistemas de monitorización y por sobre todo fomentar una cultura de colaboración **REAL** entre Desarrolladores y Operaciones. No se trata solo de mantener pipelines ~~o poner demasiados pasos para desplegar tu código~~, sino de optimizar todos los sistemas, tanto humanos como técnicos para lograr confianza, estabilidad, seguridad en los sistemas, escalabilidad y verdadera Entrega Continua (Continuous Delivery). ## El Santo Grial SRE: Métricas, Logs y Trazas Un SRE vive y respira datos. Recopila y analizan métricas, logs y trazas (traces) para obtener información sobre el rendimiento y el comportamiento de las aplicaciones en producción. Al instrumentar aplicaciones, los SRE pueden establecer objetivos de nivel de servicio (SLO, Service Level Objectives) y "*presupuestos de error*" (error budgets), lo que permite a los desarrolladores innovar y tener más libertades creativas dentro de rangos acordados de riesgos y alcances. [Observability - SREDevOps.orgEspañol, Portugues (Brasil) and English: Site Reliability Engineering (SRE), DevOps, Cloud Native, Linux, AI/ML, OpenSource, Platform Engineering![](https://www.sredevops.org/content/images/size/w256h256/2024/07/Icon-App-76x76@2x.png)SREDevOps.org![](https://www.sredevops.org/content/images/2023/11/bg-logo.png)](https://www.sredevops.org/tag/observability/) ## Qué herramientas usa un SRE?: OpenTelemetry, Prometheus, Loki y más El mundo SRE está repleto de herramientas poderosas. OpenTelemetry se ha convertido en un estándar de facto para la instrumentación de aplicaciones, mientras que Prometheus y Loki son herramientas consolidadas para almacenamiento, recolección y visualización de métricas y logs, respectivamente. Herramientas como Jaeger llevan el seguimiento distribuido a un nuevo nivel, lo que permite a los SRE rastrear `requests` a través de servicios complejos (`service mesh`), microservicios y otros. [ParadeDB: Use the power of Postgres DB for your real-time search and data analytics (and more)ParadeDB is shaking things up in the world of search and analytics by offering a compelling Postgres-based alternative to Elasticsearch. This article dives into ParadeDB’s features, how it stacks up against Elasticsearch, and why you should keep an eye on this emerging technology. ParadeDB: Riding the Postgres Wave Remember when![](https://www.sredevops.org/content/images/size/w256h256/2024/07/Icon-App-76x76@2x.png)SREDevOps.orgNicolás Georger![](https://www.sredevops.org/content/images/2024/07/Screenshot-2024-07-13-at-18.02.33.png)](https://www.sredevops.org/en/paradedb-is-challenging-the-elasticsearch-alternative-youve-been-waiting-for-2/) ## ¿Por qué es importante un SRE? *~~El SRE es tu amigo! yay!~~* Un SRE no solo soluciona problemas, sino que los previene. Al adoptar la automatización, la monitorización proactiva y una estrecha colaboración con los desarrolladores, los SRE garantizan que los sistemas sean resistentes, escalables y capaces de ofrecer una excelente experiencia al cliente, a los desarrolladores y al negocio. Un buen SRE duerme bien por la noche, sabiendo que sus clusters funcionan como es debido (y si no, tiene alertas para despertarlo). [Qué es Platform Engineering? SRE? DevOps?(O del por qué DevOps es sólo una parte...) Actualizado: Julio 2024 En esta columna intentaré definir y explicar los conceptos de Platform Engineering, SRE y DevOps, y por qué es importante entenderlos, diferenciarlos y saber cuándo usarlos. Nota: Como todo blog, ésta es una nota basada en experiencias y![](https://www.sredevops.org/content/images/size/w256h256/2024/07/Icon-App-76x76@2x.png)SREDevOps.orgNicolás Georger![](https://images.unsplash.com/photo-1667372335962-5fd503a8ae5b?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=M3wxMTc3M3wwfDF8c2VhcmNofDExfHxkZXZvcHMlMjB8ZW58MHx8fHwxNjg0MTQyMTQ1fDA&ixlib=rb-4.0.3&q=80&w=2000)](https://www.sredevops.org/es/que-es-platform-engineering-sre-devops/) ### Is OrbStack for you? Exploring Container Options for macOS: OrbStack, Lima and Docker Desktop URL: https://www.sredevops.org/en/is-orbstack-for-you-exploring-container-options-for-macos-orbstack-lima-and-docker-desktop/ Last updated: 2024-07-19T08:33:12.000Z macOS users have several solid options for running containers, each with its own strengths. We review OrbStack, Lima (Linux Machines), and Docker Desktop, comparing their features, performance, and ease of use to help you choose the best fit for your development workflow. Whether you're a seasoned Kubernetes veteran or just starting your container journey, we'll explore which tool might be your new best friend for running containers in macOS. ## The Container Craze: Why We Love 'Em Containers have taken the development world by storm, and for good reason. They package applications and their dependencies into neat, portable units, making it a breeze to move software between different environments without compatibility nightmares. This portability is a godsend for developers, allowing them to build and test applications in consistent environments that closely mirror production. ## Docker Desktop: The Reigning Champion (Well, Sort Of) Docker Desktop has long been the go-to choice for running containers on macOS. Its user-friendly interface and tight integration with popular development tools made it a favorite among developers. However, recent changes to Docker Desktop's licensing, particularly for large organizations, have left some users searching for alternatives. ## Enter the Challengers: OrbStack and Lima Two contenders have emerged, aiming to dethrone Docker Desktop and capture the hearts of macOS developers: - **OrbStack:** This newcomer focuses on speed and efficiency. Built on Rust, it boasts impressive performance and a lightweight footprint. OrbStack aims to provide a seamless development experience with features like a built-in Kubernetes cluster and support for Docker Compose. - **Lima:** A veteran in the open-source world, Lima offers flexibility and customization. It allows you to create Linux virtual machines specifically tailored for running containers, giving you granular control over your development environment. Lima might appeal to developers who prefer a more hands-on approach and want to tinker with their setup. [Lima: The Easiest Way to Run any Linux Distro, Kubernetes, k3s and even Docker on macOS and Linux, Apple Silicon (M1/ARM64) compatibleLima is a versatile and user-friendly command line tool (CLI) that empowers you to seamlessly run Linux virtual machines (VMs) on your macOS or Linux system. It’s compatible with any Apple Silicon Mac (M1, M2, etc) ARM64 and Intel x86\_64 processors, vice versa, without anything else than a single![](https://www.sredevops.org/content/images/size/w256h256/2024/07/Icon-App-76x76@2x.png)SREDevOps.orgNicolás Georger![](https://www.sredevops.org/content/images/2024/06/lima-linux-apple.jpeg)](https://www.sredevops.org/en/lima-the-easiest-way-to-run-any-linux-distro-kubernetes-k3s-and-even-docker-on-macos-and-linux-apple-silicon-m1-arm64-compatible/) ## Head-to-Head: Comparing the Contenders Let's break down the key differences between OrbStack, Lima, and Docker Desktop: | Feature | OrbStack | Lima | Docker Desktop | | ----------- | ------------------------------------------------------------ | ----------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ | | Performance | Extremely fast, thanks to its Rust-based architecture | Good performance, but can vary depending on the virtual machine configuration | Good performance, but can be resource-intensive | | Ease of Use | User-friendly interface and simple setup | Requires some command-line knowledge; more configuration needed | User-friendly interface and easy setup | | Features | Built-in Kubernetes, Docker Compose support, port forwarding | Highly customizable, supports different Linux distributions | Comprehensive features, including Kubernetes support, image building, and vulnerability scanning | | Cost | Free for personal use; paid plans for teams | Open-source and free | Free for personal use and small teams; paid plans for larger organizations | ## Choosing Your Champion: Which One's Right for You? The best container engine for your macOS development workflow depends on your specific needs and priorities: - **Speed Demons:** If raw performance is your top priority, OrbStack's blazing-fast speeds might make it your ideal choice. - **Control Freaks:** For developers who crave customization and enjoy getting their hands dirty with configuration, Lima's flexibility could be a perfect match. - **Ease-of-Use Enthusiasts:** If you prefer a user-friendly interface and a streamlined experience, Docker Desktop remains a solid option, especially for those already familiar with its ecosystem. 0:00 /0:45 1× ## Let's Get Practical: Installing and Running a Simple App To give you a taste of each option, let's walk through installing a simple web application using OrbStack, Lima, and Docker Desktop. ### OrbStack 1. **Installation:** Download the OrbStack installer or use Homebrew and just run: ```zsh brew install orbstack ``` **Running a Container:** Once installed, open your terminal and run the following command to start an Nginx web server in a container: ```zsh orbstack run -d -p 80:80 nginx:latest ``` **Accessing Your App:** Open your web browser and navigate to `http://localhost`. You should see the default Nginx welcome page. ```zsh open http://localhost ``` ### Lima **Installation:** Install Lima using Homebrew: ```bash brew install lima ``` **Creating a Lima Instance:** Create a Lima instance with Docker pre-installed: ```bash limactl start --name=my-lima-instance template://docker ``` **Connecting to the Instance:** Connect to your Lima instance: ```bash limactl shell my-lima-instance ``` **Running a Container:** Now, you can run Docker commands as usual: ```bash docker run -d -p 80:80 nginx:latest ``` **Accessing Your App:** Since Lima runs in a virtual machine, you'll need to find its IP address to access your app. Run ```bash # to find the IP address of your my-lima-instance limactl list # and then open it in your web browser open http://$my-lima-instance-ip ``` ### Docker Desktop **Installation:** Download the Docker Desktop installer from the Docker website and follow the installation instructions. **Accessing Your App:** Open your web browser and navigate to `http://localhost`. You should see the Nginx welcome page. **Running a Container:** Open your terminal and run the following command: ```bash docker run -d -p 80:80 nginx:latest ``` ## The Container Landscape: A Constantly Evolving World The world of containers is constantly evolving, with new tools and technologies emerging all the time. While this article focused on OrbStack, Lima, and Docker Desktop, it's worth exploring other options like Rancher Desktop and Podman to find the perfect fit for your development needs. The key is to experiment, try different tools, and choose the one that empowers you to build, ship, and run your applications with ease and efficiency. Happy coding! ## Special Mention: Podman Desktop Well, there is always another option, right? Podman Desktop also runs very well on macOS, read more: [Podman Desktop: Your Gateway to Containers and KubernetesTL;DR 😴 Podman Desktop is an open-source, cross-platform graphical tool designed to make working with containers and Kubernetes on your local machine a breeze. It provides a user-friendly interface for building, running, managing, inspecting, and debugging containers, as well as interacting with Kubernetes deployments. Podman Desktop is a powerful yet![](https://www.sredevops.org/content/images/size/w256h256/2024/07/Icon-App-76x76@2x.png)SREDevOps.orgNicolás Georger![](https://www.sredevops.org/content/images/2024/06/banner-bb0f1ccb389f6bff5debba4110d76b9e.png)](https://www.sredevops.org/en/podman-desktop-your-gateway-to-containers-and-kubernetes/) ## Links [OrbStack · Fast, light, simple Docker & Linux on macOSSay goodbye to slow, clunky containers and VMs. The fast, light, and easy way to run containers and Linux. Develop at lightspeed with our Docker Desktop alternative.![](https://orbstack.dev/img/icon128.png)OrbStack![](https://orbstack.dev/img/icon-square256.png)](https://orbstack.dev/?ref=sredevops.org) [Lima: The Easiest Way to Run any Linux Distro, Kubernetes, k3s and even Docker on macOS and Linux, Apple Silicon (M1/ARM64) compatibleLima is a versatile and user-friendly command line tool (CLI) that empowers you to seamlessly run Linux virtual machines (VMs) on your macOS or Linux system. It’s compatible with any Apple Silicon Mac (M1, M2, etc) ARM64 and Intel x86\_64 processors, vice versa, without anything else than a single![](https://www.sredevops.org/content/images/size/w256h256/2024/07/Icon-App-76x76@2x.png)SREDevOps.orgNicolás Georger![](https://www.sredevops.org/content/images/size/w1200/2024/06/lima-linux-apple.jpeg)](https://www.sredevops.org/en/lima-the-easiest-way-to-run-any-linux-distro-kubernetes-k3s-and-even-docker-on-macos-and-linux-apple-silicon-m1-arm64-compatible/) [Docker Desktop: The #1 Containerization Tool for Developers | DockerDocker Desktop is collaborative containerization software for developers. Get started and download Docker Desktop today on Mac, Windows, or Linux.![](https://www.docker.com/wp-content/uploads/2024/02/cropped-docker-logo-favicon-270x270.png)Docker![](https://www.docker.com/wp-content/uploads/2023/06/meta-image-download-docker-desktop-1110x580.png)](https://www.docker.com/products/docker-desktop/?ref=sredevops.org) ### ### How can I store and back up files and volumes in Kubernetes? Longhorn is our choice here at SREDevOps.org! URL: https://www.sredevops.org/en/how-can-i-store-and-back-up-files-and-volumes-in-kubernetes-longhorn-is-our-choice-here-at-sredevops-org/ Last updated: 2024-11-14T04:44:34.000Z ## TL;DR Tired of your Kubernetes volumes disappearing like your last vacation? 😩Longhorn 1.6 is here to save your data (and your sanity)! This bad boy brings persistent volumes to your Kubernetes cluster, making sure your apps stay fed with data, no matter what chaos the internet throws at them. We'll walk you through what's new and how to perform a basic setup. If you have doubts, feel free to comment and we'll help you! ## Why Longhorn for Persistent Volumes? Imagine this: you're running a stateful application on Kubernetes, like a database or a message queue. These bad boys need their data to stick around, even if a pod decides to take a nosedive. That's where persistent volumes come in, acting like trusty hard drives for your apps. Longhorn steps up as your Kubernetes-native storage superhero, providing these awesome features: - **Easy peasy installation and management:** No need for a PhD in storage sorcery! Longhorn is all about simplicity. - **High availability and disaster recovery:** Replicate your volumes across multiple nodes, so your data laughs in the face of failures. - **Snappy snapshots and backups:** Because sometimes, you need to rewind time (or at least your data). - **Blazing-fast performance:** Built on a distributed block storage architecture, Longhorn keeps your apps running at warp speed. ## New Goodies in Longhorn 1.6: What's the Hype About? This release isn't just about bug fixes and performance tweaks (although there are plenty of those too!). Longhorn 1.6 is packing some seriously cool new features: - **Enhanced Monitoring and Alerting:** Keep a watchful eye on your volumes with improved Prometheus metrics and alerting rules. No more surprises! Prometheus metrics endpoints now available. - **Beefed-Up Security:** Rest easy knowing your data is even more secure with new security enhancements and vulnerability patches. Easily upgrade versions without disruptions, easily encrypt volumes. - **Improved Volume Expansion:** Need more space? No problem! Expanding volumes just got smoother and more efficient. Just... increase the size of each replica. That's all. - **And a Whole Lot More:** We're talking bug fixes, stability improvements, and a bunch of under-the-hood magic to make Longhorn even more awesome. Check out the [release notes](https://github.com/longhorn/longhorn/releases/latest?ref=sredevops.org) for all the juicy details. [Release Longhorn v1.6.2 · longhorn/longhornLonghorn v1.6.2 Release Notes Longhorn 1.6.2 introduces several improvements and bug fixes that are intended to improve system quality, resilience, and stability. The Longhorn team appreciates your…![](https://github.githubassets.com/assets/pinned-octocat-093da3e6fa40.svg)GitHublonghorn![](https://opengraph.githubassets.com/657aab28be8296bb2518d1fe49a9a7a71a69e1e441d030068baf7ca12f615a74/longhorn/longhorn/releases/tag/v1.6.2)](https://github.com/longhorn/longhorn/releases/latest?ref=sredevops.org) ## Rolling Up Our Sleeves: Installing Longhorn 1.6 Alright, enough chit-chat! Let's get this storage party started. We'll assume you've got a Kubernetes cluster up and running. If not, go get one! We'll wait.... well, maybe. Hurry up. ### Pre checks Longhorn provides a script to check if you have all the requirements in your nodes before install anything. You can check and run the script with: ```bash # Get the latest script from the official repo wget https://github.com/longhorn/longhorn/blob/master/scripts/environment_check.sh # Check what you are going to run with nano ./environment_check.sh # Or vi, code, cat, whatever you like to edit # Give execution permissions and run: chmod +x ./environment_check.sh && ./environment_check.sh ``` ### Installing Longhorn If we met the prerequisites, now we need to add the Longhorn chart repository (There is also other methods, but we suggest this one, because... reaasons.) ```bash helm repo add longhorn https://charts.longhorn.io helm repo update ``` Now, let's install Longhorn into the `longhorn-system` namespace: ```bash helm install longhorn longhorn/longhorn \ --namespace longhorn-system \ --create-namespace ``` That's it! Longhorn will work its magic, deploying all the necessary components in your cluster. You can check its status using: ```bash kubectl get pods -n longhorn-system ``` Once all the pods are running happily in their "Running" state, you're good to go! You've got yourself a shiny new Longhorn setup, ready to handle all your persistent volume needs. ## Creating Your First Longhorn Volume Now for the fun part! Let's create a persistent volume using Longhorn. We'll do this by defining a PersistentVolumeClaim (PVC) in our Kubernetes YAML file. This tells Longhorn what kind of volume we need and how much storage space we're craving. Here's a sample PVC definition: ```yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: my-longhorn-volume spec: accessModes: - ReadWriteOnce resources: requests: storage: 1Gi storageClassName: longhorn ``` In this example, we're asking for: - A volume named "my-longhorn-volume" - 1 Gigabyte of storage space - Access mode set to "ReadWriteOnce" (meaning only one pod can access the volume at a time) - And we're using the "longhorn" storage class, which tells Kubernetes to use Longhorn for provisioning this volume Save this YAML file (let's call it \`pvc.yaml\`) and apply it to your cluster using: ```bash kubectl apply -f pvc.yaml ``` Boom! 💥 You've just created a Longhorn volume. You can now use this PVC in your pod definitions to mount the volume and give your apps the persistent storage they deserve. ## Wrapping Up And there you have it! You've learned about Longhorn 1.6, its awesome features, how to install it, and how to create your first persistent volume. Go forth and build amazing stateful applications on Kubernetes with the confidence that your data is safe, secure, and always available with Longhorn! ## Ready to Dive Deeper? - 📚 **Longhorn Documentation:** [https://longhorn.io/docs/](https://longhorn.io/docs/?ref=sredevops.org) [Longhorn | The Longhorn DocumentationCloud native distributed block storage for Kubernetes![](https://longhorn.io/favicon.png)Longhorn![](https://longhorn.io/img/logos/longhorn-icon-color.png)](https://longhorn.io/docs/?ref=sredevops.org) - **Longhorn GitHub:** **Repository:** [**https://github.com/longhorn/longhorn**](https://github.com/longhorn/longhorn?ref=sredevops.org) [GitHub - longhorn/longhorn: Cloud-Native distributed storage built on and for KubernetesCloud-Native distributed storage built on and for Kubernetes - longhorn/longhorn![](https://github.githubassets.com/assets/pinned-octocat-093da3e6fa40.svg)GitHublonghorn![](https://opengraph.githubassets.com/577593a0321a054197c5090ef4007a1bd5e5669b49920334edd5976bb528b118/longhorn/longhorn)](https://github.com/longhorn/longhorn?ref=sredevops.org) ### ParadeDB: Use the power of Postgres DB for your real-time search and data analytics (and more) URL: https://www.sredevops.org/en/paradedb-is-challenging-the-elasticsearch-alternative-youve-been-waiting-for-2/ Last updated: 2025-08-29T08:46:44.000Z ParadeDB is shaking things up in the world of search and analytics by offering a compelling Postgres-based alternative to Elasticsearch. This article dives into ParadeDB's features, how it stacks up against Elasticsearch, and why you should keep an eye on this emerging technology. ## ParadeDB: Riding the Postgres Wave Remember when Elasticsearch was the new kid on the block, promising blazing-fast search without the baggage of traditional databases? Well, the times they are a-changin'! ParadeDB enters the scene, leveraging the rock-solid foundation of PostgreSQL to deliver real-time search and analytics. ParadeDB isn't just another SQL vs. NoSQL debate rehash. It cleverly harnesses Postgres' extensibility, bolting on powerful features like full-text search with BM25 (using pg\_search), dense and sparse vector search (courtesy of pgvector and pgvectorscale), and even hybrid search capabilities. And for the analytics enthusiasts, ParadeDB integrates pg\_lakehouse to provide an analytical query engine that can handle a variety of data formats and object stores. ## Deployment Options: From Your Laptop to the Cloud One of ParadeDB's strengths is its deployment flexibility. Feeling adventurous? Grab their Docker image and have a test instance running in minutes. Prefer the control of a Kubernetes cluster? No problem, they've got a Helm chart for that. While a managed cloud offering is still on the horizon (join their waitlist!), ParadeDB makes it straightforward to get up and running on your own infrastructure. ## Going Head-to-Head with Elasticsearch: A Question of Tradeoffs So, how does ParadeDB really measure up against the reigning champ, Elasticsearch? Here's the lowdown: | ParadeDB Advantages | Elasticsearch Advantages | | ---------------------------------- | ------------------------------------------ | | Familiarity (Postgres experience) | Maturity and Ecosystem (larger community) | | ACID Properties (data consistency) | Scalability (horizontal, massive datasets) | | SQL Power (search & analytics) | Specialized Features (search & analytics) | ## Keep Your Eyes on the Prize: The Future of ParadeDB ParadeDB is still in its early stages (currently in Public Beta), but it's already making waves. The team is actively developing new features, such as a column-oriented table access method for faster analytics within Postgres and support for high-volume data ingestion from sources like Kafka. If you're looking for a robust, Postgres-backed alternative to Elasticsearch, ParadeDB is definitely worth a closer look. Its tight integration with the Postgres ecosystem, combined with its ease of deployment and commitment to open source, makes it an exciting contender in the search and analytics space. **Links:** - [ParadeDB Website](https://paradedb.com/?ref=sredevops.org) [GitHub - paradedb/paradedb: Postgres for Search and AnalyticsPostgres for Search and Analytics. Contribute to paradedb/paradedb development by creating an account on GitHub.![](https://github.githubassets.com/assets/pinned-octocat-093da3e6fa40.svg)GitHubparadedb![](https://opengraph.githubassets.com/5ca4a89c18c81a206e0c179bbb750aa7648bd900b11495c03c2a17efd0a253da/paradedb/paradedb)](https://github.com/paradedb/paradedb?ref=sredevops.org) - [ParadeDB GitHub Repository](https://github.com/paradedb/paradedb?ref=sredevops.org) [GitHub - paradedb/paradedb: Postgres for Search and AnalyticsPostgres for Search and Analytics. Contribute to paradedb/paradedb development by creating an account on GitHub.![](https://github.githubassets.com/assets/pinned-octocat-093da3e6fa40.svg)GitHubparadedb![](https://opengraph.githubassets.com/67c0fbea0f0f1916d4dfc18dcd4ba15987788da3f37ec02e722f3a11f4caabcb/paradedb/paradedb)](https://github.com/paradedb/paradedb?ref=sredevops.org) - [ParadeDB Documentation](https://docs.paradedb.com/?ref=sredevops.org) [Welcome to ParadeDB - ParadeDB![](https://mintlify.s3-us-west-1.amazonaws.com/paradedb/_generated/favicon/apple-touch-icon.png?v=3)ParadeDB![](https://mintlify.com/docs/api/og?division=Documentation&mode=dark&title=Welcome+to+ParadeDB&logoLight=https%3A%2F%2Fmintlify.s3-us-west-1.amazonaws.com%2Fparadedb%2Flogo%2Fdocs.svg&logoDark=https%3A%2F%2Fmintlify.s3-us-west-1.amazonaws.com%2Fparadedb%2Flogo%2Fdocs.svg&primaryColor=%2334d399&lightColor=%2334d399&darkColor=%2334d399)](https://docs.paradedb.com/?ref=sredevops.org) - [ParadeDB Helm Chart Repository](https://github.com/paradedb/helm-charts?ref=sredevops.org) [GitHub - paradedb/helm-charts: Helm chart for deploying ParadeDB on KubernetesHelm chart for deploying ParadeDB on Kubernetes. Contribute to paradedb/helm-charts development by creating an account on GitHub.![](https://github.githubassets.com/assets/pinned-octocat-093da3e6fa40.svg)GitHubparadedb![](https://opengraph.githubassets.com/0e6a87590d17c08c4eb6ac404d8574d81833686f7dee45d027d27a10c685d340/paradedb/helm-charts)](https://github.com/paradedb/helm-charts?ref=sredevops.org) - [ParadeDB Slack Community](https://join.slack.com/t/paradedbcommunity/shared%5Finvite/zt-2lkzdsetw-OiIgbyFeiibd1DG~6wFgTQ?ref=sredevops.org) [Slack![](https://a.slack-edge.com/80588/marketing/img/meta/favicon-32.png)![](https://a.slack-edge.com/80588/marketing/img/downloads/app_stores/ios_mac_app_store_badge.png)](https://join.slack.com/t/paradedbcommunity/shared%5Finvite/zt-2lkzdsetw-OiIgbyFeiibd1DG~6wFgTQ?ref=sredevops.org) ## How to deploy ParadeDB ### Using the ParadeDB Helm Chart First, add the ParadeDB repo to Helm as follows: ```bash helm repo add paradedb https://paradedb.github.io/helm-charts ``` If you had already added this repository earlier, run `helm repo update` to retrieve the latest versions of the packages. You can then run `helm search repo paradedb` to see the charts. To install the `paradedb` chart: ```bash helm install paradedb/paradedb ``` To uninstall the chart: ```bash helm delete ``` You can also download the chart directly from [ArtifactHub](https://artifacthub.io/packages/helm/paradedb/paradedb?ref=sredevops.org). ### Using the Bitnami Helm Chart with ParadeDB `values.yaml` You can install ParadeDB using Helm and the Bitnami Postgres chart directly. The ParadeDB Helm chart can be configured using the `values.yaml` file or by specifying values on the command line during installation. To do so, run: ```bash helm install paradedb oci://registry-1.docker.io/bitnamicharts/postgresql --namespace paradedb --create-namespace --values values.yaml ``` You can configure the values inside the `values.yaml` file. Check the [values.yaml](https://github.com/paradedb/helm-charts/blob/main/charts/paradedb/values.yaml?ref=sredevops.org) file for more information. For a list of possible configurations, see the [Bitnami Postgres chart parameters](https://github.com/bitnami/charts/tree/main/bitnami/postgresql?ref=sredevops.org#parameters). ### Using the Bitnami Helm Chart with ParadeDB `helmfile.yaml` You can install ParadeDB using [Helmfile](https://helmfile.readthedocs.io/en/latest/?ref=sredevops.org). Once Helmfile is installed, you can download the `helmfile.yaml` file from this repository and run: ```bash helmfile apply ``` You can configure values inside the `helmfile.yaml`. For a list of possible configurations, see the [Bitnami Postgres hart parameters](https://github.com/bitnami/charts/tree/main/bitnami/postgresql?ref=sredevops.org#parameters) ### Lemony solves AI privacy and compliance with on premises "LLM Boxes" and Zero Setup platform URL: https://www.sredevops.org/en/lemony-solves-ai-privacy-and-compliance-with-on-premises-llm-boxes-and-zero-setup-platform/ Last updated: 2024-07-12T06:07:05.000Z Lemony presents a generative AI on premises solution designed for businesses, organizations and individuals concerned about data security, privacy, and control. Lemony offers a compelling **alternative to cloud-based AI by keeping all data within an organization's network, ensuring compliance and peace of mind.** We'll delve into Lemony's features, benefits, use cases across various industries, highlighting how they designed a product which harness the power of AI without compromising data security. ## The Bottom Line: Is On-Premise AI Right for Your Business? Lemony's on-premise approach to generative AI presents a compelling proposition for businesses seeking to unlock the transformative potential of AI while maintaining an iron grip on data security and privacy. If your organization handles sensitive data, requires granular control over AI, or simply prefers the peace of mind that comes with keeping your data close to home, Lemony might just be the AI solution you've been waiting for. [Lemony – Boxed LLMs for Business Teams. ‍Own your AI.Lemony is a secure, on-premise generative AI solution that delivers organization-wide trust, ownership, and transparency in AI.![](https://cdn.prod.website-files.com/66717f04838e9ebdfe8da835/6679779e836c41d2742da816_Fav.png)![](https://cdn.prod.website-files.com/66717f04838e9ebdfe8da835/668d8c5d6930f9e15247a990_OG%20Image.jpg)](https://www.lemony.ai/?ref=sredevops.org) ## The Allure of On-Premise AI in a Cloud-Dominant World In a world increasingly reliant on cloud services, the concept of on-premise solutions might seem like a blast from the past. However, when it comes to the sensitive realm of business data and the burgeoning power of generative AI, on-premise solutions like Lemony are making a compelling comeback. Why? Because for many businesses, especially those dealing with stringent regulatory requirements or highly confidential information, entrusting their data to the cloud isn't a risk they're willing to take. Lemony, with its "boxed LLM" approach, flips the script on traditional AI deployment. Instead of sending your valuable data into the ether, Lemony brings the AI to you, neatly packaged in a physical server that lives within your company's firewall. This means no more anxieties about data breaches in the cloud, no more wrestling with compliance headaches, and complete control over your AI's training data and output. ![](https://www.sredevops.org/content/images/2024/07/image-3.png) ## Under the Hood: The Three Layers of Lemony's AI Powerhouse ![](https://www.sredevops.org/content/images/2024/07/image.png) Lemony's on-premise "magic" is built on a three-tiered architecture: 1. **Lemony Node:** The engine room of the operation, the Lemony Node is a scalable hardware unit that brings cloud-level AI processing power to your premises. Need more processing muscle? Just stack more nodes together, like building blocks of AI awesomeness. 2. **Lemony Intelligence:** This is where the brains of the operation reside. Lemony Intelligence acts as the conductor, ensuring seamless integration of AI into your workflows. It maintains a watchful eye on data flows, provides centralized control, and ensures everything plays by your organization's rules. 3. **Lemony AI App:** Think of this as the user-friendly control panel for your AI orchestra. The Lemony AI App empowers teams to interact with their data, generate insights, and automate tasks, all within a secure and intuitive interface. ## Is Lemony suitable for me? Examples of use cases and scenarios ### **Legal, Government, Law** Law firms, bound by strict confidentiality agreements, find a perfect ally in Lemony. Imagine a scenario where a legal team can only upload a fraction of their case files to cloud-based AI tools due to security concerns. Lemony swoops in, allowing them to analyze 100% of their documents securely within their network. No more agonizing over what stays and what goes – Lemony brings the AI insights to the data, not the other way around. ### **Proprietary Research** In the fast-paced world of research and development, staying ahead of the curve is paramount. But what happens when the cost of cloud-based AI and the fear of data leaks put a damper on innovation? Lemony provides a solution – instant access to terabytes of research data without ever leaving the company's servers. This means researchers can unlock insights faster, accelerate discoveries, and keep their competitive edge razor-sharp. ### **Human Resources** HR departments, often dealing with sensitive employee information, find a trustworthy companion in Lemony. Drafting guidelines, creating contracts, extracting insights from employee data. ## Links: ![](https://www.sredevops.org/content/images/2024/07/Screenshot-2024-07-12-at-01.11.32.png) #### Lemony AI [Lemony.ai](https://www.lemony.ai/?ref=sredevops.org) ### Kubeshark: Wireshark for Your Kubernetes Cluster? Find out and learn with us URL: https://www.sredevops.org/en/kubeshark-wireshark-for-your-kubernetes-cluster-find-out-and-learn-with-us/ Last updated: 2025-12-14T04:38:21.000Z **TL;DR:** Flying blind in your Kubernetes environment? Fight challenges of Kubernetes network observability with Kubeshark as the *predator* of network monitoring. Learn how this powerful tool provides real-time, protocol-level insights into your K8s cluster's API traffic, making troubleshooting a breeze and security nightmares a distant memory. [Kubeshark: Wireshark For KubernetesAlon Girmonsky, CEO/Founder will share how Kubeshark monitors K8s network traffic and provides visibility across your Kubernetes clusters![](https://cdn.evbstatic.com/s3-build/prod/1677794-rc2024-07-10_16.04-2866abd/django/images/favicons/safari-pinned-tab.svg)Eventbrite![](https://img.evbuc.com/https%3A%2F%2Fcdn.evbuc.com%2Fimages%2F797002149%2F2210810223903%2F1%2Foriginal.20240626-204350?w=1000&auto=format%2Ccompress&q=75&sharp=10&rect=0%2C91%2C1024%2C512&s=6700494a40c9aa49b34192b6a8b68e8f)](https://www.eventbrite.com/e/kubeshark-wireshark-for-kubernetes-tickets-934653863867?ref=sredevops.org) ### The Struggle is Real: Kubernetes Network Observability Kubernetes has revolutionized how we manage our infrastructure, bringing unprecedented scalability and efficiency. But let's be real, sometimes it feels like we're navigating a labyrinth of microservices, struggling to make sense of the complex network interactions within our clusters. Traditional monitoring tools just don't cut it. We need deep visibility into the API traffic flowing through hundreds of microservices, and those old-school tools leave us feeling like we're in a "blindfolded trust fall" with our Kubernetes clusters. The lack of visibility can turn simple troubleshooting into a marathon of frustration and leave us vulnerable to security threats lurking in the shadows. ### Kubeshark to the Rescue: Shining a Light on Network Traffic Enter Kubeshark, the Wireshark for your Kubernetes cluster! This purpose-built tool is designed to bring clarity and confidence to your Kubernetes network monitoring. Imagine having a "superpowered magnifying glass" that reveals the real-time, protocol-level details of every API call happening within your cluster. Kubeshark gives you the power to: - **Visualize your network traffic:** See every API call, its source and destination, and the data being exchanged, all in real-time. - **Identify bottlenecks and performance issues:** Quickly pinpoint performance bottlenecks and troubleshoot issues by tracing the flow of traffic through your cluster. - **Improve security posture:** Gain valuable insights into potential security vulnerabilities and malicious activity by analyzing the network traffic for suspicious patterns. ### Kubeshark in Action: Unmasking Network Mysteries Enough with the theory! Let's see Kubeshark in action. Imagine a scenario where your application is experiencing slow response times. You launch Kubeshark and start sniffing the network traffic. Within seconds, you see a massive spike in API calls to a specific microservice, indicating a potential bottleneck. You dive deeper into the traffic flow and discover that the service is overloaded with requests. Problem identified, solution in sight! Kubeshark's user-friendly interface lets you: - **Filter and search traffic:** Easily narrow down your search to specific pods, services, or namespaces. - **Analyze traffic flow:** Visualize the flow of traffic through your cluster with detailed timelines and interactive graphs. - **Explore protocol details:** Get granular insights into the specific protocols and payloads of each API call. ### Kubeshark: Your New Best Friend in the Kubernetes Jungle Kubeshark empowers you to understand your Kubernetes network traffic like never before. It’s like having a seasoned network engineer always by your side, ready to unravel even the most complex network mysteries. No more "head-scratching" or "blindly guessing" when troubleshooting network issues. With Kubeshark, you can confidently navigate the Kubernetes jungle and keep your applications running smoothly. ### Links and Resources Don't miss your chance to experience the power of Kubeshark firsthand! Sign up for their free webinar and get a live demo of this revolutionary tool. You'll learn how to use Kubeshark to: - **Unlock network visibility in Kubernetes.** - **Identify and resolve network performance bottlenecks.** - **Enhance your Kubernetes security posture.** **Register now:** [https://www.eventbrite.com/e/kubeshark-wireshark-for-kubernetes-tickets-934653863867](https://www.eventbrite.com/e/kubeshark-wireshark-for-kubernetes-tickets-934653863867?ref=sredevops.org) **Don't let your Kubernetes network be a mystery!** Get your hands on Kubeshark and unlock a world of possibilities. [Kubeshark: Wireshark For KubernetesAlon Girmonsky, CEO/Founder will share how Kubeshark monitors K8s network traffic and provides visibility across your Kubernetes clusters![](https://cdn.evbstatic.com/s3-build/prod/1677794-rc2024-07-10_16.04-2866abd/django/images/favicons/safari-pinned-tab.svg)Eventbrite![](https://img.evbuc.com/https%3A%2F%2Fcdn.evbuc.com%2Fimages%2F797002149%2F2210810223903%2F1%2Foriginal.20240626-204350?w=1000&auto=format%2Ccompress&q=75&sharp=10&rect=0%2C91%2C1024%2C512&s=6700494a40c9aa49b34192b6a8b68e8f)](https://www.eventbrite.com/e/kubeshark-wireshark-for-kubernetes-tickets-934653863867?ref=sredevops.org) ### Resources: - **Kubeshark Website** [Kubeshark — API Traffic Analyzer for KubernetesDeep visibility and monitoring of all API traffic and payloads going in, out and across containers and pods inside a Kubernetes cluster.![](https://cdn.prod.website-files.com/6517451b4cf3869a5219774a/653a5ea3d290d07884e85897_fav-32.png)kubernetes logo![](https://cdn.prod.website-files.com/6517451b4cf3869a5219774a/651ff5f41dbf6459601154e3_header-Kubeshark%20.png)](https://www.kubeshark.co/?ref=sredevops.org) - **Kubeshark Github Repository** [GitHub - kubeshark/kubeshark: The API traffic analyzer for Kubernetes providing real-time K8s protocol-level visibility, capturing and monitoring all traffic and payloads going in, out and across containers, pods, nodes and clusters. Inspired by Wireshark, purposely built for KubernetesThe API traffic analyzer for Kubernetes providing real-time K8s protocol-level visibility, capturing and monitoring all traffic and payloads going in, out and across containers, pods, nodes and clu…![](https://github.githubassets.com/assets/pinned-octocat-093da3e6fa40.svg)GitHubkubeshark![](https://repository-images.githubusercontent.com/359419233/53d02a0d-6bc8-46a2-8549-70236f04220f)](https://github.com/kubeshark/kubeshark?ref=sredevops.org) ### Hardware Open Source? First RISC-V Laptop Launched, Comes with Ubuntu Linux. A Promising Duo. URL: https://www.sredevops.org/en/hardware-open-source-first-risc-v-laptop-launched-comes-with-ubuntu-linux-a-promising-duo/ Last updated: 2026-07-16T04:40:21.000Z ## TL;DR One of the key points of RISC-V is its open and free architecture. If we have evolved exponentially with open source, RISC-V bodes well. The open source RISC-V architecture is generating great interest, promising a new era of free and open hardware. We review the potential of RISC-V, its synergy with operating systems like Ubuntu, and the impact of devices like the DC-ROMA RISC-V II laptop on the future of open computing. ## The Arrival of RISC-V: Farewell to the Reign of Proprietary Hardware In the technological rollercoaster, where innovation advances at the speed of light, there is a silent revolution underway: RISC-V. Forget the days when the brain of your computer, the architecture that controls everything, was in the hands of a handful of companies. RISC-V brings with it the promise of a different future, where hardware is open and/or free, like free and open source software (FLOSS) or open source software (OSS). Ideal scenario: Any company, university, or even a technology enthusiast and "Do It Yourself" (DIY) can take the RISC-V architecture, modify it to their liking and create their own chips without having to ask permission or pay expensive licenses. Could you do it today? NO. That is the magic of RISC-V, its answer is a resounding YES. This open source instruction set architecture (ISA) is gaining ground by leaps and bounds, and it's not hard to see why. Just as the open source movement transformed the way we develop software, RISC-V has the power to do the same with hardware, democratizing access to technology and opening up an infinite range of possibilities. [World’s first RISC-V Laptop gets a massive upgrade and equips with Ubuntu | CanonicalDeepComputing partners with Canonical to unveil a huge boost to the DC-ROMA RISC-V Laptop family The DC-ROMA RISC-V Laptop II is the world’s first RISC-V laptop pre-installed and powered by Ubuntu, which is one of the most popular Linux distributions in the world, providing developers with an outstanding mix of usability and reliability, \[…\]![](https://assets.ubuntu.com/v1/f38b9c7e-COF%20apple-touch-icon.png)UbuntuCanonical![](https://ubuntu.com/wp-content/uploads/7dc7/ROMA-II-announcement-meta-image.png)](https://canonical.com/blog/worlds-first-risc-v-laptop-gets-a-massive-upgrade-and-equips-with-ubuntu?ref=sredevops.org) ## RISC-V Laptops with Ubuntu Linux A tangible example of this revolution in action is the launch of the DC-ROMA RISC-V II laptop. This computer, equipped with the Ubuntu operating system and the K1 SoC from SpacemiT, not only promises powerful performance and surprising energy efficiency, but also represents a bold step towards a future where technology is truly open and accessible to all. The DC-ROMA RISC-V II is not just a laptop, it's a statement of intent. It demonstrates that open and high-performance hardware is no longer a utopia, but a tangible reality. The choice of Ubuntu as the operating system for the DC-ROMA RISC-V II laptop is no coincidence. Ubuntu, like RISC-V, is synonymous with freedom, flexibility, and a passionate community in the software world. This Linux-based operating system has earned the trust of millions of users and developers thanks to its stability, security, and vibrant ecosystem. The synergy between Ubuntu (Canonical) and RISC-V is undeniable: both are committed to openness, collaboration, and barrier-free innovation. This union will allow developers to make the most of RISC-V's potential, creating applications and solutions that were previously impossible. Imagine a world where hardware and software development go hand in hand, without the restrictions of proprietary licenses. That's the future that Ubuntu and RISC-V promise. ## The "Dawn" of a "New Technological Era"? The future of RISC-V is promising. With the support of technological giants and a global community of developers, this architecture has the potential to revolutionize the industry. The arrival of RISC-V laptops with Ubuntu marks a milestone in this revolution, demonstrating that an open, free, collaborative ecosystem is the driving force behind true innovation, where not only a few enjoy its benefits, but collaboration between companies, governments, and society, under free knowledge allows innovation, economic growth, and social equality to become a reality. **For more information about the DC-ROMA RISC-V II laptop, visit:** [World’s first RISC-V Laptop gets a MASSIVE upgrade and equips with Ubuntu – RISC-V International![](https://riscv.org/wp-content/uploads/2020/08/cropped-riscv-favicon-270x270.png)anisha![](https://riscv.org/wp-content/uploads/2024/06/2024-06-10-DC-x-Ubuntu_1024x512.png)](https://riscv.org/news/2024/06/worlds-first-risc-v-laptop-gets-a-massive-upgrade-and-equips-with-ubuntu/?ref=sredevops.org) ### Hardware Open Source? Presentan primer laptop RISC-V y viene con Ubuntu Linux. Dupla prometedora. URL: https://www.sredevops.org/es/hardware-open-source-presentan-primer-laptop-risc-v-y-viene-con-ubuntu-linux-dupla-prometedora/ Last updated: 2026-01-08T02:36:26.000Z ## TL;DR Uno de los puntos claves de RISC-V es su arquitectura abierta y libre. Si con el opensource hemos evolucionado exponencialmente, RISC-V tiene buenos augurios. La arquitectura open source RISC-V está causando profundo interés, prometiendo una nueva era de hardware libre y abierto. Revisamos el potencial de RISC-V, su sinergia con sistemas operativos como Ubuntu y el impacto de dispositivos como la laptop DC-ROMA RISC-V II en el futuro de la computación abierta. ## La Llegada de RISC-V: Adiós al reinado del Hardware Propietario En la montaña rusa tecnológica, donde la innovación avanza a la velocidad de la luz, hay una revolución silenciosa en marcha: RISC-V. Olvida los días en que el cerebro de tu computadora, la arquitectura que lo controla todo, estaba en manos de un puñado de empresas. RISC-V trae consigo la promesa de un futuro diferente, donde el hardware es abierto y/o libre, como el [software libre (FLOSS) o el código abierto (OSS)](https://www.gnu.org/philosophy/floss-and-foss.es.html?ref=sredevops.org). Escenario ideal: Cualquier empresa, universidad o incluso un entusiasta de la tecnología y el "Hazlo tu mismo" (Do It Yourself), puede tomar la arquitectura RISC-V, modificarla a su gusto y crear sus propios chips sin tener que pedir permiso ni pagar costosas licencias. **Lo podrías hacer hoy? NO. Esa es la magia de RISC-V, su respuesta es un contundente SI.** Esta arquitectura de conjunto de instrucciones (ISA) de código abierto está ganando terreno a pasos agigantados, y no es difícil ver por qué. Al igual que el movimiento de código abierto transformó la forma en que desarrollamos software, RISC-V tiene el poder de hacer lo mismo con el hardware, democratizando el acceso a la tecnología y abriendo un abanico infinito de posibilidades. ## Laptops RISC-V con Ubuntu Linux Un ejemplo tangible de esta revolución en acción es el lanzamiento de la laptop DC-ROMA RISC-V II. Este equipo, equipado con el sistema operativo Ubuntu y el SoC K1 de SpacemiT, no solo promete un rendimiento potente y una eficiencia energética sorprendente, sino que también representa un paso audaz hacia un futuro donde la tecnología es verdaderamente abierta y accesible para todos. La DC-ROMA RISC-V II no es solo una laptop, es una declaración de intenciones. Demuestra que el hardware abierto y de alto rendimiento ya no es una utopía, sino una realidad tangible. ## Canonical y RISC-V: Una Alianza prometedora para la Innovación [World’s first RISC-V Laptop gets a massive upgrade and equips with Ubuntu | CanonicalDeepComputing partners with Canonical to unveil a huge boost to the DC-ROMA RISC-V Laptop family The DC-ROMA RISC-V Laptop II is the world’s first RISC-V laptop pre-installed and powered by Ubuntu, which is one of the most popular Linux distributions in the world, providing developers with an outstanding mix of usability and reliability, \[…\]![](https://assets.ubuntu.com/v1/f38b9c7e-COF%20apple-touch-icon.png)UbuntuCanonical![](https://ubuntu.com/wp-content/uploads/7dc7/ROMA-II-announcement-meta-image.png)](https://canonical.com/blog/worlds-first-risc-v-laptop-gets-a-massive-upgrade-and-equips-with-ubuntu?ref=sredevops.org) La elección de Ubuntu como sistema operativo para la laptop DC-ROMA RISC-V II no es una casualidad. Ubuntu, al igual que RISC-V, es sinónimo de libertad, flexibilidad y una comunidad apasionada en el mundo del software. Este sistema operativo basado en Linux ha conquistado la confianza de millones de usuarios y desarrolladores gracias a su estabilidad, seguridad y su vibrante ecosistema. La sinergia entre Ubuntu (Canonical) y RISC-V es innegable: ambos apuestan por la apertura, la colaboración y la innovación sin barreras. Esta unión permitirá a los desarrolladores aprovechar al máximo el potencial de RISC-V, creando aplicaciones y soluciones que antes parecían imposibles. ¿Te imaginas un mundo donde el desarrollo de hardware y software vaya de la mano, sin las restricciones de las licencias propietarias? Ese es el futuro que Ubuntu y RISC-V prometen. ## El "Amanecer" de una "Nueva Era Tecnológica"? El futuro de RISC-V es prometedor. Con el apoyo de gigantes tecnológicos y una comunidad global de desarrolladores, esta arquitectura tiene el potencial de revolucionar la industria. La llegada de laptops RISC-V con Ubuntu marca un hito en esta revolución, demostrando que un ecosistema abierto, libre, colaborativo son los motores de la verdadera innovación, donde no sólo unos pocos disfrutan de sus beneficios, sino que la colaboración de empresas, gobiernos y la sociedad, bajo el libre conocimiento permiten que innovación, crecimiento económico, igualdad social sean una realidad cercana. Para obtener más información sobre la laptop DC-ROMA RISC-V II, visita: [World’s first RISC-V Laptop gets a MASSIVE upgrade and equips with Ubuntu – RISC-V International![](https://riscv.org/wp-content/uploads/2020/08/cropped-riscv-favicon-270x270.png)anisha![](https://riscv.org/wp-content/uploads/2024/06/2024-06-10-DC-x-Ubuntu_1024x512.png)](https://riscv.org/news/2024/06/worlds-first-risc-v-laptop-gets-a-massive-upgrade-and-equips-with-ubuntu/?ref=sredevops.org) ### Chequea Kubernetes con Popeye! Seguridad, configs, problemas y más con Popeye CLI (Además es open source y liviano!) URL: https://www.sredevops.org/es/chequea-kubernetes-con-popeye-seguridad-configs-problemas-y-mas-con-popeye-cli-ademas-es-open-source-y-liviano/ Last updated: 2026-01-08T02:36:03.000Z ## TL/DR; ¿Cansado de revisar manualmente tu clúster de Kubernetes para encontrar problemas? Popeye es como un chequeo de salud para tu clúster, encontrando posibles problemas con tus configuraciones y uso de recursos. Es una herramienta de línea de comandos que **escanea tu clúster *en vivo***, no solo archivos estáticos, y señala cosas como errores de configuración, recursos no utilizados e incluso posibles sobreasignaciones de recursos. **Es de solo lectura, por lo que no tocará tu clúster**, solo te dará un informe amigable *(o tal vez no tan amigable* 🙃*, dependiendo de la salud de tu clúster)*. Incluso puedes ***ponerte fancy*** con diferentes formatos de salida (JSON, HTML, lo que sea), **enviar informes a S3 e integrarlo con Prometheus y Grafana para monitoreo continuo.** ![](https://popeyecli.io/assets/screens/console.png) ## ¿Por qué necesitas un linter de Kubernetes como Popeye? Seamos realistas, Kubernetes es increíble para orquestar tus aplicaciones en containers. Sin embargo, a medida que tus implementaciones crecen, también lo hace la complejidad. De repente, te estás ahogando en un mar de archivos YAML, preguntándote si ese `Service` en el `default` namespace está *realmente* hablando con tu `Pod`, o si ese `PersistentVolumeClaim` de un proyecto eliminado todavía está dando vueltas como un mal olor. **Ahí es donde entra Popeye, flexionando sus músculos con poder de espinaca para darle a tu clúster un chequeo completo.** > **🎶🎶🎤 ¡Popeye el marino soy!...** ### ¡Popeye al rescate! Popeye se sumerge en tu clúster *en vivo*, inspeccionando tus recursos mientras se ejecutan. Esta no es solo una herramienta de análisis estático de prueba en seco. Es la cosa real, buscando problemas comunes que pueden hacerte tropezar: - **Error de configuraciones:** ¿Tus asignaciones de puertos de contenedor son correctas? ¿Tus etiquetas `Pod` coinciden con tus selectores `Service`? - **Uso de recursos:** Popeye incluso puede acceder a tu servidor de métricas (si estás usando uno) y advertirte sobre posibles sobreasignaciones de CPU o memoria *antes* de que tu clúster *tire la toalla.* - **Recursos obsoletos:** ¿Recuerdas ese `Namespace` que pensaste que eliminaste hace meses? Popeye lo encontrará. ¿Esos `Secrets` sin usar? Sí, también los marcará. - **Mejores prácticas de seguridad:** Popeye puede ayudarte a detectar cosas como Pods que se ejecutan como root, límites de recursos faltantes y otras malas prácticas básicas de seguridad. ![](https://popeyecli.io/assets/screens/html.png) ## **Instalación** ¡Tienes opciones! *~~(¡diVeRsIoNN! ¡fuN!)~~* Descarga binarios, usa `brew install`, o `go install` si eres un aficionado a Go. ```bash brew install derailed/popeye/popeye ``` ```bash go install github.com/derailed/popeye@latest ``` ## Comenzando con Popeye **Interpretando el informe:** Popeye codifica por colores sus hallazgos para darte una imagen clara de la salud de tu clúster: - **✅ OK:** ¡Todo parece estar bien! - **🔊 Info:** Solo algunos mensajes de información. - **😱 Warn:** Posibles problemas que podrías querer investigar. - **💥 Error:** ¡Se requiere acción! Estos son problemas que necesitan ser solucionados. **Sube de nivel con Prometheus y Grafana:** Integra Popeye con Prometheus para recopilar métricas y visualizar la salud de tu clúster con el tiempo en Grafana. Incluso puedes configurar alertas para que se te notifique cuando Popeye encuentre algo sospechoso. ![](https://github.com/sredevopsorg/popeye/raw/master/assets/screens/pop-dash.png) ### **Personalizando escaneos (¿Espinacas, alguien?)** Puedes ajustar el comportamiento de Popeye usando un archivo de configuración `spinach.yaml`. ¿Quieres ajustar los umbrales de utilización de recursos, excluir recursos específicos o incluso anular la gravedad de ciertas verificaciones? ¡Spinach te tiene cubierto! ```yaml popeye: allocations: cpu: overPercUtilization: 70 # Trigger a warning if CPU utilization goes above 70% ``` **Ejecuta el escaneo:** Popeye funciona de inmediato. Solo apúntalo a tu clúster: ```bash popeye ``` ¿Quieres escanear un namespace específico? No hay problema: ```bash popeye -n my-awesome-app ``` ### Popeye en acción: Un ejemplo práctico Digamos que estás ejecutando una aplicación web en tu clúster. Tienes un `Deployment`, un `Service`, y algunos otros recursos. Ejecutas Popeye, y este arroja lo siguiente: ```log 😱 WARN po Pods default/my-awesome-app-7c94985768-x5fzk Container 'my-awesome-app' has no resource requests or limits defined! ``` ¡Uy! Parece que olvidaste establecer los límites de recursos en tu `Pod`. Esto significa que tu aplicación podría consumir potencialmente todos los recursos de tu nodo, dejando a otras aplicaciones sin nada. ¡Es hora de actualizar ese archivo YAML! ## Mantén tu clúster saludable con Popeye Popeye es una herramienta esencial para cualquiera que ejecute Kubernetes. Es como tener un experto en Kubernetes constantemente mirándote por encima del hombro, señalando posibles problemas antes de que se conviertan en grandes dolores de cabeza. Entonces, ¡agrega Popeye a tu caja de herramientas y comienza a darle a tu clúster los chequeos que se merece! *~~(O tal vez no...)~~* ## Enlaces útiles - [Popeye GitHub Repository](https://github.com/derailed/popeye?ref=sredevops.org) [GitHub - derailed/popeye: 👀 A Kubernetes cluster resource sanitizer👀 A Kubernetes cluster resource sanitizer. Contribute to derailed/popeye development by creating an account on GitHub.![](https://github.githubassets.com/assets/pinned-octocat-093da3e6fa40.svg)GitHubderailed![](https://repository-images.githubusercontent.com/176379662/c23cb480-3267-11ea-9bae-e0737521678e)](https://github.com/derailed/popeye?ref=sredevops.org) - [Official website](https://popeyecli.io/?ref=sredevops.org) [popeye👀 A Kubernetes cluster resource sanitizerpopeye![](https://github.com/derailed/popeye/raw/master/assets/popeye_logo.png)](https://popeyecli.io/?ref=sredevops.org) ### Algunos checks de ejemplo | | K8s Resource | Linters | Aliases | | -- | ----------------------- | ----------------------------------------------------------------------- | ---------- | | 🛀 | Node | | no | | | | Conditions ie not ready, out of mem/disk, network, pids, etc | | | | | Pod tolerations referencing node taints | | | | | CPU/MEM utilization metrics, trips if over limits (default 80% CPU/MEM) | | | 🛀 | Namespace | | ns | | | | Inactive | | | | | Dead namespaces | | | 🛀 | Pod | | po | | | | Pod status | | | | | Containers statuses | | | | | ServiceAccount presence | | | | | CPU/MEM on containers over a set CPU/MEM limit (default 80% CPU/MEM) | | | | | Container image with no tags | | | | | Container image using latest tag | | | | | Resources request/limits presence | | | | | Probes liveness/readiness presence | | | | | Named ports and their references | | | 🛀 | Service | | svc | | | | Endpoints presence | | | | | Matching pods labels | | | | | Named ports and their references | | | 🛀 | ServiceAccount | | sa | | | | Unused, detects potentially unused SAs | | | 🛀 | Secrets | | sec | | | | Unused, detects potentially unused secrets or associated keys | | | 🛀 | ConfigMap | | cm | | | | Unused, detects potentially unused cm or associated keys | | | 🛀 | Deployment | | dp, deploy | | | | Unused, pod template validation, resource utilization | | | 🛀 | StatefulSet | | sts | | | | Unused, pod template validation, resource utilization | | | 🛀 | DaemonSet | | ds | | | | Unused, pod template validation, resource utilization | | | 🛀 | PersistentVolume | | pv | | | | Unused, check volume bound or volume error | | | 🛀 | PersistentVolumeClaim | | pvc | | | | Unused, check bounded or volume mount error | | | 🛀 | HorizontalPodAutoscaler | | hpa | | | | Unused, Utilization, Max burst checks | | | 🛀 | PodDisruptionBudget | | | | | | Unused, Check minAvailable configuration | pdb | | 🛀 | ClusterRole | | | | | | Unused | cr | | 🛀 | ClusterRoleBinding | | | | | | Unused | crb | | 🛀 | Role | | | | | | Unused | ro | | 🛀 | RoleBinding | | | | | | Unused | rb | | 🛀 | Ingress | | | | | | Valid | ing | | 🛀 | NetworkPolicy | | | | | | Valid, Stale, Guarded | np | | 🛀 | PodSecurityPolicy | | | | | | Valid | psp | | 🛀 | Cronjob | | | | | | Valid, Suspended, Runs | cj | | 🛀 | Job | | | | | | Pod checks | job | | 🛀 | GatewayClass | | | | | | Valid, Unused | gwc | | 🛀 | Gateway | | | | | | Valid, Unused | gw | | 🛀 | HTTPRoute | | | | | | Valid, Unused | gwr | ### ### Check Kubernetes with Popeye! Security, configs, problems, scores and more with an open source and lightweight CLI tool URL: https://www.sredevops.org/en/check-kubernetes-with-popeye-security-configs-problems-scores-and-more-with-an-open-source-and-lightweight-cli-tool/ Last updated: 2024-07-08T11:20:45.000Z ## TL/DR; Tired of manually combing through your Kubernetes cluster for issues? Popeye is like a health check-up for your cluster, finding potential problems with your configurations and resource usage. It's a command-line tool that scans your live cluster, not just static files, and points out things like misconfigurations, unused resources, and even potential resource over-allocations. It's read-only, so it won't touch your cluster, just give you a friendly (or maybe not-so-friendly, depending on your cluster's health) report. You can even get fancy with different output formats (JSON, HTML, you name it), send reports to S3, and integrate it with Prometheus and Grafana for ongoing monitoring. ![](https://popeyecli.io/assets/screens/console.png) ## Why You Need a Kubernetes Linter Like Popeye Let's face it, Kubernetes is awesome for orchestrating your containerized applications. However, as your deployments grow, so does the complexity. Suddenly, you're drowning in a sea of YAML files, wondering if that `Service` in the `default` namespace is *actually* talking to your `Pod`, or if that `PersistentVolumeClaim` from a deleted project is still hanging around like a bad smell. That's where Popeye comes in, flexing its spinach-powered muscles to give your cluster a thorough checkup. ### Popeye to the Rescue! Popeye dives into your *live* cluster, inspecting your resources as they're actually running. This isn't just some dry-run static analysis tool. It's the real deal, looking for common problems that can trip you up: - **Misconfigurations:** Are your container port mappings correct? Do your `Pod` labels match your `Service` selectors? - **Resource Usage:** Popeye can even tap into your metrics server (if you're using one) and warn you about potential CPU or memory over-allocations *before* your cluster throws in the towel. - **Stale Resources:** Remember that `Namespace` you thought you deleted months ago? Popeye will find it. Those unused `Secrets`? Yep, it'll flag those too. - **Security Best Practices:** Popeye can help you catch things like Pods running as root, missing resource limits, and other security gotchas. ![](https://popeyecli.io/assets/screens/html.png) ## **Installation** You've got options! *~~(Yay! fuN!)~~* Download binaries, use `brew install`, or `go install` if you're a Go aficionado. ```bash brew install derailed/popeye/popeye ``` ```bash go install github.com/derailed/popeye@latest ``` ## Getting Started with Popeye **Interpreting the Report:** Popeye color-codes its findings to give you a clear picture of your cluster's health: - **✅ OK:** Everything looks good! - **🔊 Info:** Just some FYI messages. - **😱 Warn:** Potential issues that you might want to look into. - **💥 Error:** Action required! These are problems that need fixing. **Level Up with Prometheus and Grafana:** Integrate Popeye with Prometheus to collect metrics and visualize your cluster's health over time in Grafana. You can even set up alerts so you're notified when Popeye finds something fishy. ![](https://github.com/sredevopsorg/popeye/raw/master/assets/screens/pop-dash.png) ### **Customizing Scans (Spinach, Anyone?)** You can fine-tune Popeye's behavior using a `spinach.yaml` configuration file. Want to adjust resource utilization thresholds, exclude specific resources, or even override the severity of certain checks? Spinach has got you covered! ```yaml popeye: allocations: cpu: overPercUtilization: 70 # Trigger a warning if CPU utilization goes above 70% ``` **Run the Scan:** Popeye works right out of the box. Just point it at your cluster: ```bash popeye ``` Want to scan a specific namespace? No problem: ```bash popeye -n my-awesome-app ``` ### Popeye in Action: A Practical Example Let's say you're running a web app in your cluster. You've got a `Deployment`, a `Service`, and a few other resources. You run Popeye, and it spits out the following: ```log 😱 WARN po Pods default/my-awesome-app-7c94985768-x5fzk Container 'my-awesome-app' has no resource requests or limits defined! ``` Uh oh! Looks like you forgot to set resource limits on your `Pod`. This means your app could potentially consume all the resources on your node, starving out other applications. Time to update that YAML file! ## Keep Your Cluster Healthy with Popeye Popeye is an essential tool for anyone running Kubernetes. It's like having a Kubernetes expert constantly looking over your shoulder, pointing out potential issues before they turn into major headaches. So, add Popeye to your toolbox and start giving your cluster the health checks it deserves! ## Useful Links - [Popeye GitHub Repository](https://github.com/derailed/popeye?ref=sredevops.org) [GitHub - derailed/popeye: 👀 A Kubernetes cluster resource sanitizer👀 A Kubernetes cluster resource sanitizer. Contribute to derailed/popeye development by creating an account on GitHub.![](https://github.githubassets.com/assets/pinned-octocat-093da3e6fa40.svg)GitHubderailed![](https://repository-images.githubusercontent.com/176379662/c23cb480-3267-11ea-9bae-e0737521678e)](https://github.com/derailed/popeye?ref=sredevops.org) - [Official website](https://popeyecli.io/?ref=sredevops.org) [popeye👀 A Kubernetes cluster resource sanitizerpopeye![](https://github.com/derailed/popeye/raw/master/assets/popeye_logo.png)](https://popeyecli.io/?ref=sredevops.org) ### Some of the available linters | | K8s Resource | Linters | Aliases | | -- | ----------------------- | ----------------------------------------------------------------------- | ---------- | | 🛀 | Node | | no | | | | Conditions ie not ready, out of mem/disk, network, pids, etc | | | | | Pod tolerations referencing node taints | | | | | CPU/MEM utilization metrics, trips if over limits (default 80% CPU/MEM) | | | 🛀 | Namespace | | ns | | | | Inactive | | | | | Dead namespaces | | | 🛀 | Pod | | po | | | | Pod status | | | | | Containers statuses | | | | | ServiceAccount presence | | | | | CPU/MEM on containers over a set CPU/MEM limit (default 80% CPU/MEM) | | | | | Container image with no tags | | | | | Container image using latest tag | | | | | Resources request/limits presence | | | | | Probes liveness/readiness presence | | | | | Named ports and their references | | | 🛀 | Service | | svc | | | | Endpoints presence | | | | | Matching pods labels | | | | | Named ports and their references | | | 🛀 | ServiceAccount | | sa | | | | Unused, detects potentially unused SAs | | | 🛀 | Secrets | | sec | | | | Unused, detects potentially unused secrets or associated keys | | | 🛀 | ConfigMap | | cm | | | | Unused, detects potentially unused cm or associated keys | | | 🛀 | Deployment | | dp, deploy | | | | Unused, pod template validation, resource utilization | | | 🛀 | StatefulSet | | sts | | | | Unused, pod template validation, resource utilization | | | 🛀 | DaemonSet | | ds | | | | Unused, pod template validation, resource utilization | | | 🛀 | PersistentVolume | | pv | | | | Unused, check volume bound or volume error | | | 🛀 | PersistentVolumeClaim | | pvc | | | | Unused, check bounded or volume mount error | | | 🛀 | HorizontalPodAutoscaler | | hpa | | | | Unused, Utilization, Max burst checks | | | 🛀 | PodDisruptionBudget | | | | | | Unused, Check minAvailable configuration | pdb | | 🛀 | ClusterRole | | | | | | Unused | cr | | 🛀 | ClusterRoleBinding | | | | | | Unused | crb | | 🛀 | Role | | | | | | Unused | ro | | 🛀 | RoleBinding | | | | | | Unused | rb | | 🛀 | Ingress | | | | | | Valid | ing | | 🛀 | NetworkPolicy | | | | | | Valid, Stale, Guarded | np | | 🛀 | PodSecurityPolicy | | | | | | Valid | psp | | 🛀 | Cronjob | | | | | | Valid, Suspended, Runs | cj | | 🛀 | Job | | | | | | Pod checks | job | | 🛀 | GatewayClass | | | | | | Valid, Unused | gwc | | 🛀 | Gateway | | | | | | Valid, Unused | gw | | 🛀 | HTTPRoute | | | | | | Valid, Unused | gwr | ### ### Vulnerabilidade crítica em OpenSSH "regreSSHion", cheque se você está em risco URL: https://www.sredevops.org/br/vulnerabilidade-critica-em-openssh-regresshion-cheque-se-voce-esta-em-risco/ Last updated: 2024-07-08T07:35:48.000Z ## TL/DR; Uma vulnerabilidade crítica ([CVE-2024-6387](https://www.qualys.com/regresshion-cve-2024-6387/?ref=sredevops.org)), apelidada de "regreSSHion", ressurgiu nas versões do servidor **OpenSSH 8.5p1 a 9.8p1,** o que poderia permitir a execução remota de código como **root** sem autenticação em sistemas Linux vulneráveis. Este **bug**, uma regressão da vulnerabilidade CVE-2006-5051 previamente corrigida, destaca a importância de realizar testes de regressão completos. **Estima-se que aproximadamente 700.000 servidores OpenSSH expostos à Internet são vulneráveis.** Este artigo detalha a vulnerabilidade, seu impacto e as etapas para mitigar. ## O que é a vulnerabilidade regreSSHion? A vulnerabilidade regreSSHion ([CVE-2024-6387](https://www.qualys.com/regresshion-cve-2024-6387/?ref=sredevops.org)) é "um *regresso ao passado"*, uma condição de corrida (*race conditions, raft*) de gerenciadores de sinais no servidor OpenSSH (sshd) que permite que invasores remotos executem potencialmente código arbitrário com privilégios de **root**. O erro ressurgiu nas versões 8.5p1 a 9.8p1 devido à remoção acidental de um componente crítico do código. Essa vulnerabilidade permite que invasores não autenticados obtenham controle total dos sistemas afetados. O nome "regreSSHion" é um jogo de palavras inteligente que destaca que essa vulnerabilidade é uma regressão de uma falha corrigida anteriormente, CVE-2006-5051. [OpenSSH Vulnerability: CVE-2024-6387 FAQs and Resources | Qualys, Inc.Discover what the OpenSSH vulnerability, CVE-2024-6387, is as well as resources and tools to help detect and mitigate vulnerabilities in your network.![](https://www.qualys.com/apple-touch-icon-180x180.png)Qualys![](https://ik.imagekit.io/qualys/wp-content/uploads/2024/06/Q-regreSSHion-1200x628-1.jpg)](https://www.qualys.com/regresshion-cve-2024-6387/?ref=sredevops.org) ## Como funciona o regreSSHion? Esta vulnerabilidade explora uma condição de corrida na forma como o OpenSSH lida com os sinais durante o processo de autenticação. Ao enviar uma sequência específica de sinais no momento certo, um invasor pode forçar o servidor OpenSSH a executar código malicioso com privilégios de **root**. Isso significa que um invasor pode potencialmente assumir o controle total do seu servidor sem a necessidade de nenhuma credencial de acesso válida. ## Qual é o impacto do regreSSHion? A vulnerabilidade regreSSHion representa uma séria ameaça para organizações em todo o mundo, pois pode levar à completa **compromission** do sistema, vazamentos de dados e interrupções de serviço. Ao explorar essa vulnerabilidade, os invasores podem executar código arbitrário com os privilégios mais altos, o que lhes permite: - **Instalar malware:** Injetar **software** malicioso para roubar dados, espionar ou lançar novos ataques. - **Manipular dados:** Alterar ou excluir dados confidenciais, interromper as operações e causar danos à reputação. - **Criar backdoors:** Estabelecer acesso persistente aos sistemas comprometidos para futura exploração. - **Propagar-se lateralmente:** Usar o sistema comprometido como plataforma de lançamento de ataques a outros sistemas da rede. Essa vulnerabilidade é especialmente preocupante porque afeta uma tecnologia amplamente utilizada, o OpenSSH, no qual muitas vezes se confia para administração remota segura e transferência de dados. ## Como mitigar a vulnerabilidade regreSSHion Abordar a vulnerabilidade regreSSHion requer ação imediata. As organizações devem priorizar a aplicação de **patches** aos sistemas afetados como principal estratégia de mitigação. A seguir, é apresentado um detalhamento das etapas principais: - **Gerenciamento de patches:** A mitigação mais eficaz é aplicar os **patches** oficiais lançados pelo OpenSSH. Atualize o OpenSSH para a versão 9.8p1 ou posterior imediatamente. Para versões anteriores, consulte o aviso de segurança do OpenSSH para obter os **patches** específicos. - **Segmentação da rede:** Isole os sistemas críticos e segmente sua rede para limitar o impacto potencial de um ataque. Isso ajuda a evitar que invasores se movam lateralmente dentro da sua rede se um sistema for comprometido. - **Sistemas de detecção e prevenção de intrusões:** Implante sistemas robustos de detecção e prevenção de intrusões para monitorar o tráfego de rede em busca de atividades suspeitas. Configure esses sistemas para detectar e bloquear tentativas de explorar a vulnerabilidade regreSSHion. - **Monitoramento e análise de logs:** Revise periodicamente os **logs** do sistema e de segurança em busca de qualquer indicador de **compromission**. Procure por tentativas incomuns de conexão SSH ou falhas de autenticação. - **Princípio do privilégio mínimo:** Siga o princípio do privilégio mínimo, concedendo aos usuários e processos apenas o nível mínimo de acesso necessário para realizar suas tarefas. Isso limita os danos potenciais que um invasor pode infligir se comprometer uma conta de usuário. ## Ideias recolhidas A vulnerabilidade regreSSHion é um claro lembrete de que mesmo o **software** bem conservado e amplamente utilizado pode ter vulnerabilidades críticas. Medidas de segurança proativas, como aplicação oportuna de **patches**, ferramentas de segurança robustas e a adesão às melhores práticas de segurança são essenciais para mitigar essas ameaças. Ao tomar medidas rápidas para lidar com a vulnerabilidade regreSSHion, as organizações podem reduzir significativamente o risco de serem vítimas de ataques que explorem essa falha. ## Referências - [Blog de Segurança da Qualys](https://blog.qualys.com/vulnerabilities-threat-research/2024/07/01/regresshion-remote-unauthenticated-code-execution-vulnerability-in-openssh-server?ref=sredevops.org) [regreSSHion: Remote Unauthenticated Code Execution Vulnerability in OpenSSH server | Qualys Security BlogThe Qualys Threat Research Unit (TRU) has discovered a Remote Unauthenticated Code Execution (RCE) vulnerability in OpenSSH’s server (sshd) in glibc-based Linux systems. CVE assigned to this…![](https://ik.imagekit.io/qualys/wp-content/uploads/2017/07/cropped-qualys-300x300.png)Qualys, Inc.Bharat Jogi![](https://ik.imagekit.io/qualys/wp-content/uploads/2024/06/Q-regreSSHion-1200x628-1-1070x560.jpg)](https://blog.qualys.com/vulnerabilities-threat-research/2024/07/01/regresshion-remote-unauthenticated-code-execution-vulnerability-in-openssh-server?ref=sredevops.org) - [Segurança do OpenSSH](https://www.openssh.com/security.html?ref=sredevops.org) OpenSSH: SecurityOpenSSH advisories [OpenSSH: SecurityOpenSSH advisories![](https://www.openssh.com/favicon.ico)](https://www.openssh.com/security.html?ref=sredevops.org) ### Vulnerabilidad crítica en OpenSSH "regreSSHion", chequea si estás en riesgo URL: https://www.sredevops.org/es/vulnerabilidad-critica-en-openssh-regresshion-chequea-si-estas-en-riesgo/ Last updated: 2026-01-08T02:36:17.000Z ## ### TL/DR; Una vulnerabilidad crítica ([CVE-2024-6387](https://www.qualys.com/regresshion-cve-2024-6387/?ref=sredevops.org)), apodada "regreSSHion", ha resurgido en las versiones del servidor **OpenSSH 8.5p1 a 9.8p1,** lo que podría permitir la ejecución remota de código como root sin autenticación en sistemas Linux vulnerables. Este bug, una regresión de la vulnerabilidad CVE-2006-5051 previamente parcheada, pone de manifiesto la importancia de realizar pruebas de regresión exhaustivas. **Se estima que aproximadamente 700.000 servidores OpenSSH expuestos a Internet son vulnerables.** Este artículo detalla la vulnerabilidad, su impacto y los pasos para mitigar. [OpenSSH Vulnerability: CVE-2024-6387 FAQs and Resources | Qualys, Inc.Discover what the OpenSSH vulnerability, CVE-2024-6387, is as well as resources and tools to help detect and mitigate vulnerabilities in your network.![](https://www.qualys.com/apple-touch-icon-180x180.png)Qualys![](https://ik.imagekit.io/qualys/wp-content/uploads/2024/06/Q-regreSSHion-1200x628-1.jpg)](https://www.qualys.com/regresshion-cve-2024-6387/?ref=sredevops.org) ## ¿Qué es la vulnerabilidad regreSSHion? La vulnerabilidad regreSSHion (CVE-2024-6387) es "*un regreso al pasado"*, una condición de carrera (race conditions, raft) de manejadores de señales en el servidor OpenSSH (sshd) que permite a los atacantes remotos ejecutar potencialmente código arbitrario con privilegios de root. El error resurgió en las versiones 8.5p1 a 9.8p1 debido a la eliminación accidental de un componente crítico del código. Esta vulnerabilidad permite a los atacantes no autenticados obtener el control total de los sistemas afectados. El nombre "regreSSHion" es un ingenioso juego de palabras que pone de manifiesto que esta vulnerabilidad es una regresión de un fallo previamente corregido, CVE-2006-5051. ## ¿Cómo funciona regreSSHion? Esta vulnerabilidad explota una condición de carrera en la forma en que OpenSSH maneja las señales durante el proceso de autenticación. Enviando una secuencia específica de señales en el momento justo, un atacante puede forzar al servidor OpenSSH a ejecutar código malicioso con privilegios de root. Esto significa que un atacante podría potencialmente tomar el control completo de tu servidor sin necesidad de ninguna credencial de acceso válida. ## ¿Cuál es el impacto de regreSSHion? La vulnerabilidad regreSSHion supone una grave amenaza para las organizaciones de todo el mundo, ya que puede provocar la completa del sistema, filtraciones de datos e interrupciones del servicio. Explotando esta vulnerabilidad, los atacantes pueden ejecutar código arbitrario con los mayores privilegios, lo que les permite: - **Instalar malware:** Inyectar software malicioso para robar datos, espiar o lanzar nuevos ataques. - **Manipular datos:** Alterar o eliminar datos confidenciales, interrumpir las operaciones y causar daños a la reputación. - **Crear puertas traseras:** Establecer un acceso persistente a los sistemas comprometidos para su futura explotación. - **Propagarse lateralmente:** Utilizar el sistema comprometido como plataforma de lanzamiento de ataques a otros sistemas de la red. Esta vulnerabilidad es especialmente preocupante porque afecta a una tecnología muy utilizada, OpenSSH, en la que a menudo se confía para la administración remota segura y la transferencia de datos. ## Cómo mitigar la vulnerabilidad regreSSHion Abordar la vulnerabilidad regreSSHion requiere una acción inmediata. Las organizaciones deben priorizar la aplicación de parches a los sistemas afectados como principal estrategia de mitigación. A continuación, se presenta un desglose de los pasos clave: - **Gestión de parches:** La mitigación más eficaz es aplicar los parches oficiales publicados por OpenSSH. Actualiza OpenSSH a la versión 9.8p1 o posterior inmediatamente. Para versiones anteriores, consulta el aviso de seguridad de OpenSSH para obtener los parches específicos. - **Segmentación de la red:** Aísla los sistemas críticos y segmenta tu red para limitar el impacto potencial de un ataque. Esto ayuda a evitar que los atacantes se muevan lateralmente dentro de tu red si un sistema se ve comprometido. - **Sistemas de detección y prevención de intrusiones:** Despliega sistemas robustos de detección y prevención de intrusiones para supervisar el tráfico de red en busca de actividades sospechosas. Configura estos sistemas para detectar y bloquear los intentos de explotar la vulnerabilidad regreSSHion. - **Supervisión y análisis de registros:** Revisa periódicamente los registros del sistema y de seguridad en busca de cualquier indicador de compromiso. Busca intentos inusuales de conexión SSH o fallos de autenticación. - **Principio de mínimo privilegio:** Cumple el principio de mínimo privilegio concediendo a los usuarios y procesos sólo el nivel mínimo de acceso necesario para realizar sus tareas. Esto limita los daños potenciales que un atacante puede infligir si compromete una cuenta de usuario. ## Ideas recogidas La vulnerabilidad regreSSHion es un claro recordatorio de que incluso el software bien mantenido y ampliamente utilizado puede tener vulnerabilidades críticas. Las medidas de seguridad proactivas, como la aplicación oportuna de parches, las herramientas de seguridad robustas y la adhesión a las mejores prácticas de seguridad son esenciales para mitigar estas amenazas. Al tomar medidas rápidas para hacer frente a la vulnerabilidad regreSSHion, las organizaciones pueden reducir significativamente su riesgo de ser víctimas de ataques que exploten este fallo. ## Referencias - [Blog de Seguridad de Qualys](https://blog.qualys.com/vulnerabilities-threat-research/2024/07/01/regresshion-remote-unauthenticated-code-execution-vulnerability-in-openssh-server?ref=sredevops.org) [regreSSHion: Remote Unauthenticated Code Execution Vulnerability in OpenSSH server | Qualys Security BlogThe Qualys Threat Research Unit (TRU) has discovered a Remote Unauthenticated Code Execution (RCE) vulnerability in OpenSSH’s server (sshd) in glibc-based Linux systems. CVE assigned to this…![](https://ik.imagekit.io/qualys/wp-content/uploads/2017/07/cropped-qualys-300x300.png)Qualys, Inc.Bharat Jogi![](https://ik.imagekit.io/qualys/wp-content/uploads/2024/06/Q-regreSSHion-1200x628-1-1070x560.jpg)](https://blog.qualys.com/vulnerabilities-threat-research/2024/07/01/regresshion-remote-unauthenticated-code-execution-vulnerability-in-openssh-server?ref=sredevops.org) - [Seguridad de OpenSSH](https://www.openssh.com/security.html?ref=sredevops.org) [OpenSSH: SecurityOpenSSH advisories![](https://www.openssh.com/favicon.ico)](https://www.openssh.com/security.html?ref=sredevops.org) ### Qué es Platform Engineering? SRE? DevOps? URL: https://www.sredevops.org/es/que-es-platform-engineering-sre-devops/ Last updated: 2026-01-08T02:36:03.000Z *(O del por qué DevOps es sólo una parte...)* > *Actualizado: Julio 2024* En esta columna intentaré definir y explicar los conceptos de Platform Engineering, SRE y DevOps, y por qué es importante entenderlos, diferenciarlos y saber cuándo usarlos. Nota: Como todo blog, ésta es una nota basada en experiencias y opiniones personales, no es una guía oficial ni un documento técnico. Toda corrección, sugerencia o comentario es bienvenido. ### Platform Engineering Proceso de desarrollo, mantenimiento y mejora de una plataforma o ecosistema donde vivirá tu proyecto, que puede incluir desde la creación de una infraestructura hasta APIs para la provisión interna de los servicios e infraestructura, en conjunto con sistemas tipo ["Internal Developer Portals" (IdP) y similares.](https://www.sredevops.org/tag/internal-developer-platform/) [Internal Developer Platform - SREDevOps.org - SRE, DevOps, Cloud Native, Linux, AI/ML, Platform Engineering, OpenSource![](https://www.sredevops.org/content/images/2024/05/favicon.ico)SREDevOps.org - SRE, DevOps, Cloud Native, Linux, AI/ML, Platform Engineering, OpenSource![](https://www.sredevops.org/content/images/2023/11/bg-logo.png)](https://www.sredevops.org/tag/internal-developer-platform/) ### Site Reliability Engineering (SRE) enfoque para garantizar la disponibilidad y el rendimiento de un sistema o aplicación. Se centra en automatizar y optimizar procesos para garantizar que el sistema esté disponible y funcione correctamente en todo momento. [SRE - SREDevOps.org - SRE, DevOps, Cloud Native, Linux, AI/ML, Platform Engineering, OpenSource![](https://www.sredevops.org/content/images/2024/05/favicon.ico)SREDevOps.org - SRE, DevOps, Cloud Native, Linux, AI/ML, Platform Engineering, OpenSource![](https://www.sredevops.org/content/images/2023/11/bg-logo.png)](https://www.sredevops.org/tag/sre/) ### DevOps DevOps es una cultura y conjunto de prácticas que busca unir el desarrollo de software y la operación de sistemas para mejorar la velocidad y la eficiencia del desarrollo de aplicaciones. [DevOps - SREDevOps.org - SRE, DevOps, Cloud Native, Linux, AI/ML, Platform Engineering, OpenSource![](https://www.sredevops.org/content/images/2024/05/favicon.ico)SREDevOps.org - SRE, DevOps, Cloud Native, Linux, AI/ML, Platform Engineering, OpenSource![](https://www.sredevops.org/content/images/2023/11/bg-logo.png)](https://www.sredevops.org/tag/devops/) En resumen, Platform Engineering se enfoca en desarrollar y mantener una plataforma tecnológica, SRE en garantizar la disponibilidad y rendimiento de un sistema y DevOps en unir el desarrollo de software y operación de sistemas para mejorar la velocidad y eficiencia del desarrollo de aplicaciones. | Nombre | Ideas clave -> | | | | | | --------------------- | -------------- | -------------- | ---------------- | ------------- | ------------- | | **Platform Eng.** \-> | cultura org. | proyectos | automatización | integraciones | self service | | **SRE** \-> | arquitectura | observabilidad | infraestructura | estabilidad | escalabilidad | | **DevOps** \-> | colaboración | desarrollo | entrega continua | integración | cultura ágil | ### Pero, qué realmente necesito y para qué lo haría? El tiempo y esfuerzo requerido para una adopción exitosa de SRE, DevOps o Ingeniería de Plataformas puede variar dependiendo de la organización específica y del estado actual de su infraestructura y procesos de TI. Por lo general, se tarda varios meses a varios años para que una organización adopte completamente y vea los beneficios de estas prácticas. Un ejemplo de estudio de caso de una adopción exitosa de SRE es Google. Desarrollaron el concepto de SRE y lo han estado utilizando durante muchos años. Google ha reportado un aumento significativo en la eficiencia, disponibilidad y confiabilidad de sus sistemas desde la adopción de SRE. En su caso, se tardaron varios años en integrar completamente las prácticas de SRE en su cultura y procesos de ingeniería, pero los resultados valieron la pena el esfuerzo. Otro ejemplo de adopción exitosa de DevOps es Spotify, comenzaron su viaje en 2010 y lograron un aumento significativo en la eficiencia y velocidad de entrega al implementar prácticas de integración continua y entrega continua, así como otras metodologías de DevOps. ### Según la literatura y los expertos en la industria, hay varios errores comunes que las organizaciones cometen al implementar DevOps Existen varios errores comunes que cometen las organizaciones al intentar adoptar DevOps, Platform Engineering, etc, entre ellas están: - Falta de objetivos y metas claros: Sin una comprensión clara de los resultados deseados y beneficios de la ingeniería de plataformas, puede ser difícil medir el progreso y determinar si la implementación es exitosa. - Recursos insuficientes: Adoptar la ingeniería de plataformas requiere una inversión significativa de tiempo y recursos. Sin recursos adecuados, puede ser difícil implementar y mantener la infraestructura y procesos necesarios. - Falta de comunicación y colaboración: La ingeniería de plataformas requiere un alto nivel de colaboración y comunicación entre equipos. Sin una comunicación efectiva, puede ser difícil coordinar esfuerzos y asegurar que todos trabajen hacia los mismos objetivos. - Enfoque excesivo en la tecnología: Las organizaciones también deben enfocarse en construir una cultura y procesos que respalden la ingeniería de plataformas. - Negligencia de la seguridad y cumplimiento: La ingeniería de plataformas requiere un enfoque en la seguridad y cumplimiento para garantizar que los sistemas sean seguros y cumplan con las regulaciones de la industria. - Negligencia de la monitorización y observabilidad: La ingeniería de plataformas requiere un enfoque en la monitorización y observabilidad para garantizar que los sistemas funcionen correctamente y que los problemas puedan ser identificados y resueltos rápidamente. - No involucrar a los miembros del equipo adecuados: La ingeniería de plataformas requiere un equipo diverso con diferentes experticias y antecedentes. No involucrar a las personas adecuadas puede llevar a malentendidos y soluciones inefectivas. Para tener éxito con una cultura de ingeniería de plataformas, las organizaciones deben enfocarse en objetivos y metas claros, proporcionar recursos suficientes, comunicarse y colaborar efectivamente, enfocarse en construir una cultura y procesos que respalden, priorizar la seguridad y cumplimiento, invertir en monitorización y observabilidad, e involucrar a los miembros del equipo adecuados ### Sua Aplicação em Kubernetes Falha na Inicialização? A Propriedade minReadySeconds Pode te Ajudar URL: https://www.sredevops.org/br/sua-aplicacao-em-kubernetes-falha-na-inicializacao-a-propriedade-minreadyseconds-pode-te-ajudar/ Last updated: 2024-07-01T06:16:57.000Z ## Resumo Revisamos a propriedade `minReadySeconds` em Kubernetes e como ela pode ser sua arma secreta para implementar aplicações robustas e prontas para produção. Explicaremos como estabelecer um valor apropriado para `minReadySeconds`, que fornece um período de carência inicial para que as aplicações inicializem e estejam prontas para lidar com o tráfego, garantindo uma experiência fluida para os usuários. ## Lutando Contra a Sobrecarga Inicial: a Necessidade de um Período de Carência Imagine que você acabou de implementar uma nova versão da sua aplicação web no seu cluster Kubernetes. Tudo parece bem - os pods estão iniciando e o Kubernetes está fazendo sua mágica. Mas espere... antes que sua aplicação tenha a oportunidade de respirar, o Kubernetes imediatamente começa a rotear o tráfego para ela. O problema é que sua aplicação depende de uma conexão com o banco de dados e precisa de alguns segundos adicionais para carregar as configurações. Esta situação, meus amigos, é uma receita para o desastre, potencialmente levando a erros, tempos limite e muita frustração para seus usuários. Pense em `minReadySeconds` como aquela xícara de café bem merecida depois de um longo descanso. Dá à sua aplicação o tempo que ela precisa para se organizar antes de receber tráfego real. ## Exemplo de Deployment Usando `minReadySeconds` ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: tests-minready spec: replicas: 3 selector: matchLabels: app: tests-minready template: metadata: labels: app: tests-minready spec: containers: - name: tests-minready image: nginx:stable-alpine-slim ports: - containerPort: 80 ## Valor em segundos minReadySeconds: 10 ``` ## `minReadySeconds` ao Resgate: Tempo Limite Inicial como um Investimento em Estabilidade É aqui que `minReadySeconds` entra em jogo e salva o dia. Ao definir esta propriedade no seu manifesto de Deployment, você está essencialmente dizendo ao Kubernetes: "Espere um minuto! Não envie tráfego para meus pods até que eles tenham tido pelo menos estes segundos para se organizarem." Digamos que você defina `minReadySeconds: 10`. Isso significa que o Kubernetes esperará pacientemente por 10 segundos depois que os pods informarem que seus containers estão prontos, antes de considerar que um pod está realmente disponível para receber tráfego. Este período de carência permite à sua aplicação: - **Estabelecer conexões com o banco de dados:** Chega de tentativas frenéticas de conexão enquanto o tráfego já está batendo! - **Carregar configurações:** Certifique-se de que todas as configurações estejam carregadas antes do primeiro request. - **Executar tarefas de inicialização:** Complete qualquer rotina de inicialização sem a pressão do tráfego de entrada. ## Recompensas por ir Além: Estabilidade, Confiabilidade, Usuários e Devs Felizes Ao incorporar `minReadySeconds` em sua estratégia de implementação, você não está adicionando apenas alguns segundos ao seu tempo de inicialização, você está investindo em uma aplicação mais estável e confiável. Aqui estão algumas maneiras pelas quais isso pode ajudar: - **Menos tempo de inatividade:** Ao prevenir o roteamento prematuro do tráfego, `minReadySeconds` minimiza o risco de erros e acidentes durante a fase de inicialização crítica, o que leva a menos tempo de inatividade e uma experiência mais fluida para os usuários. - **Melhoria da experiência do usuário:** Ninguém gosta de telas de erro! `minReadySeconds` garante que sua aplicação esteja pronta para fornecer uma experiência perfeita desde o momento em que os usuários chegam. - **Melhor confiabilidade:** Uma aplicação bem inicializada é uma aplicação feliz (e um desenvolvedor feliz também). `minReadySeconds` adiciona outra camada de confiabilidade às suas implementações, proporcionando tranquilidade ao saber que suas aplicações estão realmente prontas para a ação. ## Além do Básico: o Que Você Precisa para um Desempenho Ótimo O valor ideal para `minReadySeconds` depende dos requisitos de inicialização específicos da sua aplicação. Analise o processo de inicialização da sua aplicação para determinar um valor apropriado que forneça tempo de inicialização suficiente sem atrasar desnecessariamente as implementações. Lembre-se, o Kubernetes vem com uma caixa de ferramentas cheia de funcionalidades poderosas, e `minReadySeconds` é apenas uma delas. Investigue outras estratégias de implementação e melhores práticas para melhorar ainda mais a estabilidade e resiliência de suas aplicações. Divirta-se "kuberneteando" com seus Deployments! [DeploymentsA Deployment manages a set of Pods to run an application workload, usually one that doesn’t maintain state.![](https://kubernetes.io/icons/apple-touch-icon-256x256.png)Kubernetes![](https://kubernetes.io/images/kubernetes-horizontal-color.png)](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/?ref=sredevops.org#min-ready-seconds) ### ¿Tu app en Kubernetes falla al inicio? La propiedad minReadySeconds puede ayudarte URL: https://www.sredevops.org/es/tu-app-en-kubernetes-falla-al-inicio-la-propiedad-minreadyseconds-puede-ayudarte/ Last updated: 2026-01-08T02:36:11.000Z ## Resumen Revisamos la propiedad `minReadySeconds` en Kubernetes y cómo puede ser tu arma secreta para implementar aplicaciones sólidas y listas para producción. Explicaremos cómo establecer un valor apropiado para `minReadySeconds` , que proporciona un período de gracia inicial para que las aplicaciones se levanten y estén listas para manejar el tráfico, garantizando una experiencia fluida para los usuarios. ## Luchando contra la sobrecarga inicial: la necesidad de un período de gracia Imagina que acabas de implementar una nueva versión de tu aplicación web en tu clúster de Kubernetes. Todo parece bien —los pods están iniciándose y Kubernetes está haciendo su magia. Pero espera... antes de que tu aplicación tenga la oportunidad de respirar, Kubernetes inmediatamente comienza a enrutar el tráfico hacia ella, pero el problema es que tu aplicación depende de una conexión con la base de datos y necesita unos segundos adicionales para cargar las configuraciones. Esta situación, amigos míos, es una receta para el desastre, potencialmente llevando a errores, tiempos de espera y mucha frustración para tus usuarios. Piensa en `minReadySeconds` como esa taza de café bien merecida después de un largo descanso. Le da a tu aplicación el tiempo que necesita para ponerse en orden antes de recibir tráfico real. ### Ejemplo deployment usando minReadySeconds ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: tests-minready spec: replicas: 3 selector: matchLabels: app: tests-minready template: metadata: labels: app: tests-minready spec: containers: - name: tests-minready image: nginx:stable-alpine-slim ports: - containerPort: 80 ### Valor en segundos minReadySeconds: 10 ``` ## minReadySeconds al rescate: tiempo de espera inicial como una inversión en estabilidad Esta es la forma en que `minReadySeconds` entra en juego y salva el día; Al establecer esta propiedad en tu manifiesto de despliegue, **esencialmente le estás diciendo a Kubernetes, "¡Espera un minuto! No envíes tráfico hacia mis pods hasta que hayan tenido al menos estos segundos para ponerse en orden".** Digamos que estableces `minReadySeconds: 10` Esto significa que Kubernetes esperará pacientemente durante 10 segundos después de que los pods informen que sus contenedores están listos antes de considerar que un pod está realmente disponible para recibir tráfico. Este período de gracia permite a tu aplicación: - **Establecer conexiones con la base de datos:** ¡No más intentos frenéticos de conexión mientras el tráfico ya está golpeando! - **Cargar configuraciones:** Asegúrate de que todas las configuraciones estén cargadas antes del primer request. - **Ejecutar tareas de inicio:** Completa cualquier rutina de inicialización sin la presión del tráfico entrante. ## Recompensas por ir más allá: estabilidad, confiabilidad, usuarios y devs felices Al incorporar `minReadySeconds` en tu estrategia de implementación, no estás agregando solo unos segundos a tu tiempo de inicio, estás invirtiendo en una aplicación más estable y confiable. Aquí hay algunas formas en que esto puede ayudar: - **Menos tiempo de inactividad:** Al prevenir el enrutamiento prematuro del tráfico, `minReadySeconds` minimiza el riesgo de errores y accidentes durante la fase de inicio crítica, lo que conduce a menos tiempo de inactividad y una experiencia fluida para los usuarios. - **Mejora de la experiencia del usuario:** ¡Nadie disfruta de las pantallas de error! `minReadySeconds` garantiza que tu aplicación esté lista para proporcionar una experiencia perfecta desde el momento en que los usuarios llegan. - **Mejor confiabilidad:** Una aplicación bien inicializada es una aplicación feliz (y un desarrollador feliz también). `minReadySeconds` agrega otra capa de confiabilidad a tus implementaciones, brindándote tranquilidad al saber que tus aplicaciones están realmente preparadas para la acción. ## Más allá de lo básico: qué necesitas para un rendimiento óptimo El valor ideal para `minReadySeconds` depende de los requisitos de inicio específicos de tu aplicación. Analiza el proceso de inicialización de tu aplicación para determinar un valor apropiado que proporcione suficiente tiempo de inicialización sin retrasar innecesariamente las implementaciones. Recuerda, Kubernetes viene con una caja de herramientas llena de funciones potentes, y `minReadySeconds` es solo una de ellas. Investiga otras estrategias de implementación y mejores prácticas para mejorar aún más la estabilidad y resistencia de tus aplicaciones. Disfruta ~~kuberneteando~~ con tus despliegues! [DeploymentsA Deployment manages a set of Pods to run an application workload, usually one that doesn’t maintain state.![](https://kubernetes.io/icons/apple-touch-icon-256x256.png)Kubernetes![](https://kubernetes.io/images/kubernetes-horizontal-color.png)](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/?ref=sredevops.org#min-ready-seconds) ### Is Your Kubernetes deployment failing at startup? The minReadySeconds property can help you URL: https://www.sredevops.org/en/is-your-kubernetes-deployment-failing-at-startup-the-minreadyseconds-property-can-help-you/ Last updated: 2024-07-01T05:16:27.000Z ## TL/DR Explore the `minReadySeconds` property in Kubernetes and how it can be your secret weapon for deploying rock-solid, production-ready applications. We'll explore how setting an appropriate `minReadySeconds` value provides a crucial grace period for your apps to initialize and be ready to handle traffic, ensuring a smoother user experience. ## Battling Startup Storms: The Need for Graceful Initialization Picture this: you've just deployed a shiny new version of your web application to your Kubernetes cluster. Everything looks good - containers are starting up, and Kubernetes is doing its magic. But wait! Before your app has a chance to catch its breath, Kubernetes starts routing traffic its way. **The problem? Your app relies on a database connection and needs a few precious seconds to load configurations. This scenario, my friends, is a recipe for disaster, potentially leading to errors, timeouts, and a whole lot of frustration for your users.** Think of `minReadySeconds` as that much-needed coffee break after a long vacation. It gives your application the breathing room it needs to start up smoothly and be fully prepared to handle the demands of the real world (or at least the real world of your users). ### Example Deployment Configuration with `minReadySeconds` ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: tests-minready spec: replicas: 3 selector: matchLabels: app: tests-minready template: metadata: labels: app: tests-minready spec: containers: - name: tests-minready image: nginx:stable-alpine-slim ports: - containerPort: 80 minReadySeconds: 10 ``` ## `minReadySeconds` to the Rescue: A Time Buffer for Stability This is where `minReadySeconds` swoops in to save the day! By setting this property in your Deployment configuration, you're essentially telling Kubernetes, "Hold your horses! Don't throw traffic at my pods until they've had at least this many seconds to get their act together." Let's say you set `minReadySeconds: 10`. This means Kubernetes will patiently wait for 10 seconds after a pod's containers are reported as ready before considering it truly available to receive traffic. This grace period allows your app to: - **Establish Database Connections:** No more frantic connection attempts while traffic is already knocking. - **Load Configurations:** Ensures all settings are loaded before the first request hits. - **Run Startup Tasks:** Completes any initialization routines without the pressure of incoming traffic. ## Reaping the Rewards: Stability, Reliability, and Happy Users By incorporating `minReadySeconds` into your deployment strategy, you're not just adding a few seconds to your startup time – you're investing in a more stable and reliable application. Here's how: - **Reduced Downtime:** By preventing premature traffic routing, `minReadySeconds` minimizes the risk of errors and crashes during the critical startup phase, leading to less downtime and a smoother user experience. - **Improved User Experience:** No one likes staring at error messages. `minReadySeconds` helps ensure that your application is ready to provide a seamless and enjoyable experience from the moment users arrive. - **Enhanced Reliability:** A well-initialized application is a happy application (and a happy developer, for that matter). `minReadySeconds` adds an extra layer of reliability to your deployments, giving you peace of mind knowing your apps are truly ready for prime time. ## Beyond the Basics: Fine-tuning for Optimal Performance The ideal `minReadySeconds` value depends on your application's specific startup requirements. Analyze your application's initialization process to determine an appropriate value that provides sufficient warm-up time without unnecessarily delaying deployments. Remember, Kubernetes provides a toolbox of powerful features, and `minReadySeconds` is just one of them. Explore other deployment strategies and best practices to further enhance the stability and resilience of your applications. Happy deploying! [DeploymentsA Deployment manages a set of Pods to run an application workload, usually one that doesn’t maintain state.![](https://kubernetes.io/icons/apple-touch-icon-256x256.png)Kubernetes![](https://kubernetes.io/images/kubernetes-horizontal-color.png)](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/?ref=sredevops.org#min-ready-seconds) ### ¿Cómo la nueva Ley de Ciberseguridad Chilena (Ley Nº 21.663) le afecta a mi empresa?, ¿Cuánto tiempo queda?, ¿Qué debo hacer? URL: https://www.sredevops.org/es/como-la-nueva-ley-de-ciberseguridad-chilena-ley-no-21-663-le-afecta-a-mi-empresa-cuanto-tiempo-queda-que-debo-hacer/ Last updated: 2026-01-08T02:35:58.000Z ## TL;DR Chile acaba de publicar una nueva ley de ciberseguridad (Ley 21.663) que exige a las empresas que proveen servicios esenciales, como la salud, la energía y las finanzas, implementar medidas de seguridad y certificaciones para el año 2025\. **Si no te pones las pilas ahora, podrías enfrentar multas y sanciones, además de aumentar el riesgo de ciberataques.** ## ¿Qué es la Ley 21.663 y qué implica para ti? La Ley 21.663, publicada en el Diario Oficial el 8 de abril de 2024, es una nueva normativa que busca fortalecer la ciberseguridad en Chile. Esta ley no solo define nuevas obligaciones para las empresas, sino que también introduce un enfoque más estratégico y proactivo para la gestión de la seguridad informática. La ley establece la creación de una Agencia Nacional de Ciberseguridad, un Consejo Multisectorial y un Comité Interministerial de Ciberseguridad, que serán los encargados de definir las directrices y políticas para la gestión de la seguridad informática en el país. Además, la ley define diferentes equipos de respuesta a incidentes (CSIRT) para distintos sectores, como el financiero, la salud, la energía, etc. [Promulgamos Ley Marco sobre Ciberseguridad que regula servicios públicos y privados - Gob.clHoy se promulgó la Ley de Ciberseguridad. Revisa la importancia de la seguridad digital y más detalles sobre la nueva normativa junto a Gob.cl.![](https://s3.amazonaws.com/gobcl-prod/favicon/apple-icon-180x180.png)Gobierno de ChileGobierno de Chile![](https://s3.amazonaws.com/gobcl-prod/filer_public_thumbnails/public_files/Litio-por-Chile/ley-ciberserguridad-promulgada.jpg__1440x2000_q70_subsampling-2.jpg)](https://www.gob.cl/noticias/ley-marco-ciberseguridad-regulacion-servicios-publicos-privados-promulgacion/?ref=sredevops.org) ### ¿Qué implica esto para las empresas? Lo más importante para las empresas es que la Ley 21.663 exige la implementación de medidas de seguridad para proteger la información y los sistemas de las organizaciones que ofrecen servicios esenciales. Estas medidas incluyen, entre otras cosas: - **SGSI (Sistema de Gestión de Seguridad de la Información):** La ley exige que las empresas implementen un SGSI que se ajuste a las normas ISO 27001, una norma internacional que define un marco para la gestión de la seguridad de la información. - **Certificaciones:** La ley exige que las empresas obtengan certificaciones que demuestren que cumplen con los requisitos de seguridad establecidos. - **Planes de continuidad de negocio:** Las empresas deben implementar planes de continuidad de negocio que garanticen que puedan seguir operando en caso de un ciberataque. ## ¿Por qué deberías preocuparte por la ciberseguridad ahora? La ciberseguridad es un tema cada vez más importante en un mundo donde la información es cada vez más valiosa y vulnerable. En los últimos años, hemos visto un aumento significativo de los ciberataques, que pueden afectar a empresas de todos los tamaños y sectores. Los ciberataques pueden tener consecuencias devastadoras, como: - Pérdida de datos confidenciales - Interrupción del servicio - Daño a la reputación - Pérdidas financieras ### ¿Qué pasa si no cumples con la ley? Las empresas que no cumplan con las obligaciones de la Ley 21.663 podrían enfrentarse a sanciones, multas e incluso la suspensión de sus servicios. ## ¡No te preocupes, hay soluciones! Implementar las medidas de seguridad que exige la ley puede parecer complejo, pero no es imposible. Existen diferentes herramientas y recursos que pueden ayudarte a cumplir con los requisitos legales y proteger tu empresa de los ciberataques. **Algunos pasos que puedes dar para prepararte para la Ley 21.663:** - **Investiga la norma ISO 27001 y las mejores prácticas de seguridad de la información.** - **Evalúa la seguridad de tu infraestructura y sistemas.** - **Implementa un SGSI (Sistema de Gestión de Seguridad de la Información).** - **Desarrolla un plan de continuidad de negocio.** - **Capacita a tus empleados en seguridad de la información.** - **Considera obtener una certificación en seguridad de la información.** ### ¿Dónde puedo encontrar más información? Para obtener más información sobre la Ley 21.663 y las mejores prácticas de ciberseguridad, puedes consultar los siguientes recursos: [Biblioteca del Congreso Nacional | Ley ChileServicio proporcionado por la Biblioteca del Congreso Nacional (BCN), que contiene la información jurídico-legislativa![](https://www.bcn.cl/static3/img/favicon.ico)www.bcn.cl/leychileBiblioteca del Congreso Nacional![](https://www.bcn.cl/static2/img/share-bcn.jpg)](https://www.bcn.cl/leychile/navegar?idNorma=1202434&ref=sredevops.org) [Sobre la ley que crea la Agencia Nacional de Ciberseguridad y un sistema de respuesta ante incidentes de ciberseguridad. - Diario ConstitucionalCiberseguridad es la preservación de la confidencialidad e integridad de la información y de la disponibilidad y resiliencia de las redes y sistemas informáticos, con el objetivo de proteger a las personas, la sociedad, las organizaciones o las naciones de incidentes de ciberseguridad.![](https://www.diarioconstitucional.cl/wp-content/themes/diarioconstitucional/img/favicon.ico)Diario ConstitucionalElke von Loebenstein![](https://www.diarioconstitucional.cl/wp-content/uploads/2024/05/ley-ciberserguridad-promulgada.jpg__1440x2000_q70_subsampling-2.jpg)](https://www.diarioconstitucional.cl/2024/05/28/sobre-la-ley-que-crea-la-agencia-nacional-de-ciberseguridad-y-un-sistema-de-respuesta-ante-incidentes-de-ciberseguridad/?ref=sredevops.org) - **Diplomados en Ciberseguridad:** [https://diplomadociberseguridad.com/](https://diplomadociberseguridad.com/?ref=sredevops.org) [Diplomados en Ciberseguridad • Capacitación USACHVen por nuestros cursos y diplomados en ciberseguridad certificados por Capacitación USACH (Universidad de Santiago de Chile) mediante Credly.![](https://diplomadociberseguridad.com/wp-content/uploads/2020/12/cropped-favicon-270x270.gif)Diplomados en Ciberseguridad![](https://diplomadociberseguridad.com/wp-content/uploads/2022/04/BannerPordefectoRRSSMesa-de-trabajo-1.png)](https://diplomadociberseguridad.com/?ref=sredevops.org) - **Canal de Youtube: Diplomados en Ciberseguridad:** [https://www.youtube.com/@Diplomados.en.Ciberseguridad](https://www.youtube.com/@Diplomados.en.Ciberseguridad?ref=sredevops.org) [Diplomados en CiberseguridadOfrecemos cursos en línea sincrónicos y diplomados certificados en diversas áreas de ciberseguridad. Respaldados por la Universidad de Santiago de Chile, clasificada en el puesto 13 en el Latin America and the Caribbean Ranking QS World 2024\. ¡Especialízate con nosotros desde cualquier parte del mundo!![](https://www.sredevops.org/content/images/icon/favicon_144x144.png)YouTube![](https://www.sredevops.org/content/images/thumbnail/-MzKpVFGfdtZ9IXUwX4nBvCAOOisP_G-uPOJvNY-gRyIokXb80jl2uyyZDYfmnvO0319Ivjeya0-s900-c-k-c0x00ffffff-no-rj)](https://www.youtube.com/@Diplomados.en.Ciberseguridad?ref=sredevops.org) [ISO/IEC 27001:2022Information security, cybersecurity and privacy protection — Information security management systems — Requirements![](https://www.iso.org/modules/isoorg-template/img/iso/favicon/red/apple-touch-icon-152x152-precomposed.png)ISO![](https://www.iso.org/modules/iso-jahia-service-module/img/iso/iso-logo-print.gif)](https://www.iso.org/standard/27001?ref=sredevops.org) ## ¡No te quedes atrás! La Ley 21.663 es una oportunidad para que Chile se consolide como un país líder en ciberseguridad. Las empresas que se adapten a las nuevas exigencias estarán mejor preparadas para enfrentar los desafíos del futuro. La ciberseguridad no es solo una obligación legal, es una inversión estratégica que te permitirá proteger tu negocio y crecer con seguridad. **Recuerda: La ciberseguridad no es un asunto que se puede dejar para mañana.** ### Podman Desktop: Cómo trabajar en contenedores y Kubernetes fácil y profesional URL: https://www.sredevops.org/es/podman-desktop-como-trabajar-en-contenedores-y-kubernetes-facil-y-profesional/ Last updated: 2026-01-08T02:35:57.000Z ### ## **TL;DR** 🥱 Podman Desktop es una herramienta gráfica (`GUI` ) de código abierto, multiplataforma, diseñada para facilitar el trabajo con contenedores y Kubernetes en tu máquina local. Ofrece una interfaz fácil de usar para crear, ejecutar, administrar, inspeccionar y depurar contenedores, además de interactuar con las implementaciones de Kubernetes. ## Podman Desktop es una herramienta gráfica sólida y accesible que facilita y optimiza el ciclo del desarrollo desarrollo de contenedores y Kubernetes. Ofrece una interfaz fácil de usar que abstrae las complejidades de las herramientas de línea de comandos, lo que facilita que tanto los desarrolladores seniors tanto como los *junior devs,* aprovechen los beneficios de los contenedores y Kubernetes. Ya sea que estés creando, probando o implementando aplicaciones, Podman Desktop proporciona una plataforma unificada para administrar todo el ciclo de vida del contenedor. ## Creación y administración de contenedores con facilidad Podman Desktop permite a los desarrolladores crear, ejecutar y administrar contenedores sin esfuerzo directamente desde su interfaz intuitiva. La herramienta simplifica desarrollar apps en contenedores al ofrecer una gama de características diseñadas para mejorar la productividad, al hacer f ![Podman-desktop-1-11-hero](https://podman-desktop.io/assets/images/light_mode-23a344a6a378922eb7a55ccaf2a4bdf7.png) ### El *sueño* developer: Desarrollar sin otras preocupaciones Una de las cosas más notables de Podman Desktop es su proceso de creación de imágenes simplificado. Atrás quedaron los días de luchar con instrucciones complejas de línea de comandos. En cambio, Podman Desktop proporciona asistentes intuitivos que te guían a través del proceso de selección de imágenes base, definición de dependencias y personalización de configuraciones. Es como tener un asistente amigable que te toma de la mano durante todo el proceso. ### Integración de código Podman Desktop se integra a la perfección con los editores de código e IDE populares como Visual Studio Code . Esto permite a los desarrolladores crear imágenes sin esfuerzo desde sus proyectos, lo que permite un prototipo y una implementación rápidos. Ya no hay que saltar de una herramienta a otra. Puedes concentrarte en tu código y dejar que Podman Desktop se encargue del trabajo pesado. ### Construcciones de varias etapas Podman Desktop admite construcciones de varias etapas, lo que optimiza la construcción de imágenes al permitir que los desarrolladores separen los pasos de construcción de las configuraciones finales de los contenedores, lo que da como resultado imágenes más pequeñas y optimizadas. Esto es una bendición para mantener tus imágenes ligeras y eficientes, lo que a su vez mejora el rendimiento y reduce el consumo de recursos. ### Optimización de imágenes Podman Desktop también ayuda a minimizar el tamaño de las imágenes a través del almacenamiento en caché automático de capas y procesos de construcción optimizados. La herramienta almacena automáticamente en caché las capas durante las construcciones de imágenes, lo que reduce el tiempo de construcción y mejora el rendimiento. Esto significa que pasas menos tiempo esperando que se construyan las imágenes y más tiempo codificando. ## Ejecución y administración de contenedores ### Gestión interactiva de contenedores Podman Desktop proporciona un centro central para administrar los contenedores en ejecución. Puedes iniciar, detener, reiniciar y ver los registros de tus contenedores fácilmente, todo en un solo lugar. La herramienta también proporciona información detallada sobre tus contenedores, incluido el uso de recursos, las conexiones de red y el acceso al sistema de archivos, lo que facilita la supervisión y la resolución de problemas de tus aplicaciones. ### Inspección de contenedores Podman Desktop facilita la obtención de una visión detallada de lo que está sucediendo dentro de tus contenedores. Proporciona una vista de inspección completa, que te da acceso a información detallada del contenedor. Esto incluye el uso de recursos, las conexiones de red y el acceso al sistema de archivos. Es como tener una lupa para tus contenedores, lo que te permite ver todo lo que está sucediendo. ### Terminales interactivas Una de las características más interesantes de Podman Desktop es la capacidad de acceder sin problemas a los contenedores en ejecución con una terminal integrada. Esto permite a los desarrolladores interactuar directamente con el entorno del contenedor, lo que facilita la depuración de problemas (`debug`)o la realización de otras tareas. ### Monitoreo de recursos Podman Desktop también te permite monitorear el consumo de recursos del contenedor, incluida la CPU, la memoria y el uso del disco. Esto te permite identificar posibles cuellos de botella de rendimiento o problemas de asignación de recursos. ## Integración perfecta con Kubernetes > Podman Desktop extiende su funcionalidad más allá de la administración de contenedores para abarcar el desarrollo usando Kubernetes. La herramienta proporciona una interfaz simple y robusta para trabajar con `Pods`, `Deployments`, `Services` y otros recursos de Kubernetes. ![kubernetes enhancements](https://podman-desktop.io/assets/images/nodes-358a64863c12ec5314e2e3da1bdfc84f.png) ### Trabajar con Pods y Kubernetes Podman Desktop facilita el trabajo con los recursos de Kubernetes. Puedes implementar y administrar los recursos de Kubernetes fácilmente desde la interfaz de la herramienta, sin necesidad de complejas configuraciones YAML. La herramienta también proporciona un panel de control de Kubernetes integrado para monitorear y administrar implementaciones, pods, servicios y otros recursos. ### Implementación simplificada Podman Desktop simplifica la implementación y administración de recursos de Kubernetes. Puedes implementar y administrar fácilmente los recursos de Kubernetes directamente desde la interfaz, sin necesidad de complejas configuraciones YAML. Esto facilita mucho comenzar con Kubernetes, incluso si no estás familiarizado con las herramientas de línea de comandos. ### Gestión de recursos Podman Desktop te permite monitorear el uso de recursos de Kubernetes, incluida la CPU, la memoria y la red, y ajustar las solicitudes y límites de recursos para garantizar una asignación eficiente de recursos. ### Panel de control de Kubernetes Podman Desktop también proporciona acceso a un panel de control de Kubernetes integrado para monitorear y administrar implementaciones, pods, servicios y otros recursos. Esto te da una vista centralizada de tu clúster de Kubernetes, lo que facilita el monitoreo del estado y la salud de tus aplicaciones. ## Configuración y personalización Podman Desktop ofrece amplias opciones de configuración para adaptar el entorno a las necesidades específicas de desarrollo. ### Múltiples perfiles de configuración Puedes crear y administrar configuraciones distintas para diferentes proyectos o entornos, lo que garantiza configuraciones de desarrollo consistentes. Esto es ideal para los desarrolladores que trabajan en varios proyectos o necesitan cambiar entre diferentes entornos de desarrollo. ### Asignación de recursos Puedes configurar los recursos de CPU, memoria y disco para las máquinas Podman para optimizar el rendimiento y el uso de recursos en función de los requisitos del proyecto. Esto te permite ajustar el entorno para satisfacer las necesidades específicas de tu proyecto. ## Extensibilidad y filosofía de código abierto Podman Desktop abarca la extensibilidad y el espíritu de código abierto para ofrecer un entorno de desarrollo flexible y personalizable. ### Ecosistema de complementos Podman Desktop tiene un rico ecosistema de complementos, que proporciona acceso a funciones, herramientas e integraciones adicionales. Esto te permite ampliar la funcionalidad de la herramienta para satisfacer tus necesidades específicas. ### Compatibilidad con la extensión de Docker Desktop Otro beneficio de Podman Desktop es su compatibilidad con las extensiones existentes de Docker Desktop. Esto garantiza una experiencia de desarrollo familiar para los usuarios existentes que ya están familiarizados con Docker Desktop. ### Comunidad de código abierto Podman Desktop es un proyecto de código abierto, lo que significa que cualquiera puede contribuir a su desarrollo. El proyecto tiene una vibrante comunidad de desarrolladores que siempre están trabajando para mejorar la herramienta. ## Mantenerse actualizado con Podman y las dependencias Podman Desktop garantiza una experiencia de desarrollo fluida al proporcionar herramientas para administrar actualizaciones y dependencias. ### Actualizaciones automáticas Podman Desktop verifica automáticamente las actualizaciones y las instala en segundo plano, asegurando que siempre estés ejecutando la última versión de la herramienta. Esto garantiza que siempre estés actualizado con las últimas funciones y mejoras de seguridad. ### Gestión de dependencias Podman Desktop simplifica la administración de dependencias al instalar y actualizar automáticamente los componentes necesarios, lo que garantiza un entorno de desarrollo fluido y consistente. ## Podman es compatible con entornos empresariales Podman Desktop aborda las necesidades de los entornos empresariales gracias características que priorizan la seguridad, la estabilidad y el cumplimiento. ### Seguridad Enterprise Grade Podman Desktop se puede integrar con las soluciones de seguridad empresariales existentes, lo que garantiza entornos de desarrollo fáciles, seguros , integrados con pipelines, containers, desarrollo cloud native, kubernetes , etc. Esto lo convierte en una excelente opción para las organizaciones que tienen estrictos requisitos de seguridad. ### Gestión de la configuración Podman Desktop se puede usar con herramientas de gestión de configuración centralizadas, lo que permite configuraciones coherentes en todos los equipos y entornos de desarrollo. Esto garantiza que todos estén utilizando la misma versión de la herramienta y tengan las mismas configuraciones, lo que puede ayudar a prevenir problemas y mejorar la coherencia. ### Compliance y auditoría Podman Desktop proporciona funciones de auditoría y registro de cumplimiento para garantizar que las regulaciones, las mejores prácticas y la seguridad sean fáciles de implementar para todo los entornos de desarrollo. [Introduction | Podman DesktopPodman Desktop is an open source graphical tool enabling you to seamlessly work with containers and Kubernetes from your local environment.![](https://podman-desktop.io/img/favicon.ico)podman desktop![](https://podman-desktop.io/img/banner_podman-desktop.png)](https://podman-desktop.io/docs/intro?ref=sredevops.org) ### Podman Desktop: Your Gateway to Containers and Kubernetes URL: https://www.sredevops.org/en/podman-desktop-your-gateway-to-containers-and-kubernetes/ Last updated: 2024-06-27T03:55:01.000Z TL;DR 😴 Podman Desktop is an open-source, cross-platform graphical tool designed to make working with containers and Kubernetes on your local machine a breeze. It provides a user-friendly interface for building, running, managing, inspecting, and debugging containers, as well as interacting with Kubernetes deployments. Podman Desktop is a powerful yet approachable graphical tool that streamlines containerization and Kubernetes development workflows. It offers a user-friendly interface that abstracts away the complexities of command-line tools, making it easier for both seasoned developers and newcomers to leverage the benefits of containers and Kubernetes. Whether you're building, testing, or deploying applications, Podman Desktop provides a unified platform to manage your entire container lifecycle. ## Building and Managing Containers with Ease Podman Desktop empowers developers to effortlessly build, run, and manage containers directly from its intuitive interface. The tool simplifies containerization by offering a range of features designed to enhance productivity. ![Podman-desktop-1-11-hero](https://podman-desktop.io/assets/images/light_mode-23a344a6a378922eb7a55ccaf2a4bdf7.png) ### Simplified Image Creation One of the most noticeable things about Podman Desktop is its simplified image creation process. Gone are the days of wrestling with complex command-line instructions. Instead, Podman Desktop provides intuitive wizards that guide you through the process of selecting base images, defining dependencies, and customizing configurations. It's like having a friendly assistant who holds your hand through the entire process. ### Code Integration Podman Desktop integrates seamlessly with popular code editors and IDEs. This allows developers to effortlessly build images from their projects, enabling rapid prototyping and deployment. No more jumping back and forth between different tools. You can stay focused on your code and let Podman Desktop handle the heavy lifting. ### Multi-Stage Builds Podman Desktop supports multi-stage builds, which streamlines image construction by allowing developers to separate build steps from final container configurations, resulting in smaller, optimized images. This is a boon for keeping your images lean and mean, which in turn improves performance and reduces resource consumption. ### Image Optimization Podman Desktop also helps minimize image sizes through automatic layer caching and optimized build processes. The tool automatically caches layers during image builds, which reduces build time and improves performance. This means you spend less time waiting for images to build and more time coding. ## Running and Managing Containers ### Interactive Container Management Podman Desktop provides a central hub for managing running containers. You can easily start, stop, restart, and view logs for your containers all in one place. The tool also provides detailed information about your containers, including resource usage, network connections, and file system access, making it easy to monitor and troubleshoot your applications. ![kubernetes enhancements](https://podman-desktop.io/assets/images/nodes-358a64863c12ec5314e2e3da1bdfc84f.png) ### Container Inspection Podman Desktop makes it easy to get a detailed look at what's happening inside your containers. It provides a comprehensive inspection view, giving you access to detailed container information. This includes resource usage, network connections, and file system access. It's like having a magnifying glass for your containers, allowing you to see everything that's going on. ### Interactive Terminals One of the coolest features of Podman Desktop is the ability to seamlessly access running containers with a built-in terminal. This allows developers to directly interact with the container environment, making it easy to debug issues or perform other tasks. ### Resource Monitoring Podman Desktop also lets you monitor container resource consumption, including CPU, memory, and disk usage. This allows you to identify potential performance bottlenecks or resource allocation issues. ## Seamless Kubernetes Integration Podman Desktop extends its functionality beyond container management to encompass Kubernetes development. The tool provides a powerful interface for working with Pods, Deployments, Services, and other Kubernetes resources. ### Working with Pods and Kubernetes Podman Desktop makes working with Kubernetes resources a breeze. You can easily deploy and manage Kubernetes resources directly from the tool's interface, without the need for complex YAML configurations. The tool also provides a built-in Kubernetes dashboard for monitoring and managing deployments, pods, services, and other resources. ### Simplified Deployment Podman Desktop simplifies deploying and managing Kubernetes resources. You can easily deploy and manage Kubernetes resources directly from the interface without the need for complex YAML configurations. This makes it much easier to get started with Kubernetes, even if you're not familiar with the command-line tools. ### Resource Management Podman Desktop allows you to monitor Kubernetes resource usage, including CPU, memory, and network, and adjust resource requests and limits to ensure efficient resource allocation. ### Kubernetes Dashboard Podman Desktop also provides access to a built-in Kubernetes dashboard for monitoring and managing deployments, pods, services, and other resources. This gives you a centralized view of your Kubernetes cluster, making it easy to monitor the health and status of your applications. ## Configuration and Customization Podman Desktop offers extensive configuration options to tailor the environment to specific development needs. ### Multiple Configuration Profiles You can create and manage distinct configurations for different projects or environments, ensuring consistent development setups. This is great for developers who work on multiple projects or need to switch between different development environments. ### Resource Allocation You can configure CPU, memory, and disk resources for Podman machines to optimize performance and resource usage based on project requirements. This allows you to fine-tune the environment to meet the specific needs of your project. ## Extensibility and Open Source Philosophy Podman Desktop embraces extensibility and the open-source spirit to offer a flexible and customizable development environment. ### Plugin Ecosystem Podman Desktop has a rich ecosystem of plugins, providing access to additional features, tools, and integrations. This allows you to extend the functionality of the tool to meet your specific needs. ### Docker Desktop Extension Compatibility Another benefit of Podman Desktop is its compatibility with existing Docker Desktop extensions. This ensures a familiar development experience for existing users who are already familiar with Docker Desktop. ### Open Source Community Podman Desktop is an open source project, which means that anyone can contribute to its development. The project has a vibrant community of developers who are always working to improve the tool. ## Keeping Up-to-Date with Podman and Dependencies Podman Desktop ensures a seamless development experience by providing tools for managing updates and dependencies. ### Automatic Updates Podman Desktop automatically checks for updates and installs them in the background, ensuring you're always running the latest version of the tool. This ensures you're always up-to-date with the latest features and security enhancements. ### Dependency Management Podman Desktop simplifies dependency management by automatically installing and updating necessary components, ensuring a smooth and consistent development environment. [Release v1.11.1 · containers/podman-desktopWhat’s Changed fix: avoid electron popups when closing the window with exit on close by @benoitf in #7803 Full Changelog: v1.11.0...v1.11.1![](https://github.githubassets.com/assets/apple-touch-icon-180x180-a80b8e11abe2.png)GitHubcontainers![](https://opengraph.githubassets.com/96e954202a2d51e0c9378d65ce52ffe1d2d084231ef80eb4ddc1ed4040f7ea1c/containers/podman-desktop/releases/tag/v1.11.1)](https://github.com/containers/podman-desktop/releases/latest?ref=sredevops.org) ## Enterprise-Ready Features Podman Desktop addresses the needs of enterprise environments with features that prioritize security, stability, and compliance. ### Enterprise-Grade Security Podman Desktop can be integrated with existing enterprise security solutions, ensuring secure container development and deployment processes. This makes it a great choice for organizations that have strict security requirements. ### Configuration Management Podman Desktop can be used with centralized configuration management tools, enabling consistent settings across development teams and environments. This ensures that everyone is using the same version of the tool and has the same configurations, which can help to prevent problems and improve consistency. ### Compliance and Auditing Podman Desktop provides compliance auditing and logging features to ensure adherence to industry regulations and best practices. [Introduction | Podman DesktopPodman Desktop is an open source graphical tool enabling you to seamlessly work with containers and Kubernetes from your local environment.![](https://podman-desktop.io/img/favicon.ico)podman desktop![](https://podman-desktop.io/img/banner_podman-desktop.png)](https://podman-desktop.io/docs/intro?ref=sredevops.org) ### Ensuring Business Continuity: Synthetic Monitoring Strategies in AWS URL: https://www.sredevops.org/en/ensuring-business-continuity-synthetic-monitoring-strategies-in-aws/ Last updated: 2024-06-25T06:42:38.000Z Businesses must ensure business continuity in order to continue operating and reduce losses amid unforeseen disruptions. As rightly mentioned by PWC in its article on Business Continuity, "[67% of organizations](https://www.pwc.com/gx/en/issues/crisis-solutions/business-resilience/business-continuity.html?ref=sredevops.org) applied a business continuity plan as part of their response to the COVID-19 pandemic." To identify problems before they affect users, synthetic monitoring simulates user interactions with programs, which is a critical function of synthetic monitoring. In this article, we will examine the value of [synthetic monitoring](https://middleware.io/blog/how-to-use-synthetic-monitoring/?ref=sredevops.org) in AWS systems, as well as its advantages and optimal setup procedures. ![](https://lh7-us.googleusercontent.com/docsz/AD_4nXeZxTWDQglcahwCCk3uD72_-ayrDt2WqkFtu4DEzHHuIBukl8VzRgIcJDpTFXWSiKazMpzanI7XxLMe9BeGAv0DrZm_bvOrPOFUxgH-To_vhxzwvsXiqe2mfxm-skQwqUQkh4kA6O3L_R6SG4WyFR4xUz7y?key=8Ss1x2E4lDLSYCoYxoHEgw) [Source](https://www.businessresearchinsights.com/market-reports/synthetic-monitoring-market-111751?ref=sredevops.org) ## **What is Synthetic Monitoring?** Synthetic monitoring is a technique used for keeping an eye on programs by imitating user interactions and the user's journey. Information on the performance and uptime of crucial business operations as well as frequent application pathways is provided by this targeted monitoring. Applications may be synthetically monitored from both within and outside the firewall to guarantee their availability and overall performance. ### **Synthetic v/s Traditional Monitoring** | Features | Synthetic Monitoring | Traditional Monitoring | | ---------------------------- | ------------------------------------------- | ---------------------------------------- | | Approach | Simulates user interactions | Monitors infrastructure components | | Proactive vs. Reactive | Proactive (prevents issues) | Reactive (detects existing issues) | | User Experience Focus | Yes | No | | Global Monitoring Capability | Yes | Limited | | Performance Metrics | Real user interaction metrics | System performance metrics | | Setup Complexity | Moderate | Varies (can be complex) | | Use Case | Application performance and user experience | Infrastructure health and resource usage | ### Benefits of Synthetic Monitoring for a Cloud-based system Synthetic monitoring is essential to guarantee the best possible performance and dependability of cloud-based systems in AWS. The following are the main advantages of synthetic monitoring for an AWS cloud-based system: #### **1\. Enhanced User Experience and Performance of Applications** Synthetic monitoring assists companies in maintaining optimum performance and user experience. This is achieved through proactive identification and resolution of performance issues before they affect actual users. This ensures that the user experience is smooth and effective, which is crucial for cloud-based systems where users might be situated anywhere in the world. #### **2\. Decreased Outages and Downtime** In order to reduce downtime, synthetic monitoring offers comprehensive breakdowns of network timing data and reaction time by location. This facilitates quicker root cause investigation and timely remedial action. This is especially crucial for cloud-based systems as system outages can have serious negative effects on finances and reputation. #### **3\. Quicker Identification and Fixing of Problems** IT teams can identify and fix problems more quickly using synthetic monitoring, which lowers the need for expensive emergency support and maintenance services. Additionally, by taking a proactive stance, reputational harm from subpar application performance or interruptions is avoided. ## **Recent Trends in Synthetic Monitoring** Keeping abreast of the most recent developments in monitoring tactics becomes crucial as technology advances and the desire for flawless user experiences rises. This is especially true for synthetic monitoring, which keeps evolving and changing to fit the demands of contemporary applications. ### **1\. Growing Need for Service Level Agreement (SLA) Target Monitoring** One major factor propelling the synthetic monitoring market is the growing requirement for SLA target monitoring. The need for organizations to guarantee that their digital services adhere to particular performance and availability criteria is driving this development. ### **2\. Growing Need for Application Performance Management** As online and mobile apps get more complex, there is an increasing demand for application performance management. The optimal performance and user satisfaction of these apps are guaranteed by synthetic monitoring methods. ### **3\. Growing Need for DevOps** The synthetic monitoring industry has expanded as a result of the implementation of DevOps principles, which prioritize continuous monitoring throughout the software development lifecycle. ### **4\. Development of the IT and Telecommunications Sector** Because of the [growing demand](https://www.mordorintelligence.com/industry-reports/synthetic-monitoring-market?ref=sredevops.org) for efficient monitoring of complex infrastructure and the significance of API management in upgrading IT services, the IT and Telecommunications sector is anticipated to exhibit notable development in the synthetic monitoring market. ## **Why Use Synthetic Monitoring in AWS?** CloudWatch Synthetics, Lambda, and S3 for storage are just a few of the services provided by AWS that provide synthetic monitoring. There are several advantages of integrating synthetic monitoring with these services, including: - **Proactive Monitoring**: By proactively identifying problems before they affect consumers, synthetic monitoring reduces losses and downtime - **Scriptable Tests**: Synthetic monitoring makes it possible to create scripts that are specifically designed to evaluate user interactions and application functioning - **Customized Alerts**: When performance deviates from average, timely warnings are made possible by customizing alerting thresholds - **Visual Proof**: Screenshots offer visual proof of test outcomes and problem identification ## **Companies Offering Synthetic Monitoring Solutions** ![](https://lh7-us.googleusercontent.com/docsz/AD_4nXdsY09pzwlxQZQDrJauiQL5i5mQcWTmkPN7owWd8I5yH77dk2qtOfifpHq-p4j4G7OgK8fcrkBTdGArrPNiRg-CM2pDykjZtUOZIWUq-PkStLvJrEFWLpaoS1uzEmGSiIAwntSYGNNgz3rEW0HkT8YUlO-S?key=8Ss1x2E4lDLSYCoYxoHEgw) Source: [https://www.businessresearchinsights.com/market-reports/synthetic-monitoring-market-111751](https://www.businessresearchinsights.com/market-reports/synthetic-monitoring-market-111751?ref=sredevops.org) - **Dynatrace LLC:** Dynatrace is a top supplier of synthetic monitoring solutions, with tools that guarantee the best possible user experiences & enable total insight into applications - **Smart Bear Software Inc**.: Another well-known participant in the synthetic monitoring space is Smart Bear Software Inc., which provides products that mimic user behaviors in order to spot performance problems - **HP Enterprise Company**: The HP Enterprise Company is a reputable provider of synthetic monitoring solutions that aid companies in guaranteeing the availability & performance of their digital services - **Dell Technologies Inc.**: Dell Technologies is a major participant in the synthetic monitoring industry, providing solutions to meet the demands of different sectors & industries - **BMC Software Inc.:** BMC Software is a well-known supplier of artificial intelligence (AI) solutions. Its primary goal is to guarantee the availability and performance of vital telecom and IT systems ## **Important Metrics and What They Show** Knowing and monitoring critical performance parameters is essential when it comes to synthetic monitoring for cloud-based systems. Organizations may detect and address problems early on with the use of these metrics, which offer insights into a number of areas related to application performance and user experience. We examine many of the most significant synthetic monitoring metrics below, along with an explanation of the information they each provide on the functionality and state of the system: - **Response Time**: Calculates how long it takes for a web service or application to reply to a request from a user. Due to the potential for user annoyance and platform desertion, this statistic is essential for guaranteeing a flawless user experience - **Resource Utilization**: Monitors how much memory, CPU, and disk space are used by the system. In order to improve performance, this aids in locating possible bottlenecks and optimizing resource allocation - **Error Rates**: Tracks the frequency of different types of mistakes that take place when users engage. This measure is essential for spotting and fixing performance problems before they affect actual users - **Transaction Performance**: Evaluates the effectiveness and speed of particular user journeys or transactions. This promotes performance optimization and guarantees the smooth operation of crucial business processes - **Availability**: Monitors the availability and uptime of online services. To make sure that services are always available and operational, this statistic is crucial. - **Geographic and Device-Specific Insights**: Offers information on how customers utilize services across the world and on various devices. This aids in performance optimization for different user groups and gadgets. - **Third-party Dependency Monitoring**: Keeps track of how well third-party services—like payment gateways or content delivery networks (CDNs), which are essential parts of a lot of online applications—perform. ## **Reasons Your Organization Needs a Business Continuity Plan** ### **1\. Competitive Edge** When a crisis hits, a well-prepared business continuity plan allows you to bounce back quickly. This minimizes downtime, lost revenue, and damage to your reputation. Your company may differentiate itself as an expert and one that can be depended upon by quickly restoring access to your company's data and documents, reestablishing employee communication, and enabling staff to assist customers. ### **2\. Backups are not enough** An enterprise backup often exceeds one petabyte in size. This strains the boundaries of traditional storage. Capacity and bandwidth can be strained even by a small to mid-sized firm backing up many terabytes of data. If your gear or data center isn't equipped to manage this amount of data, it becomes useless. Organizations may operate vital business applications from backup instances on cloud-based virtual servers by implementing business continuity and disaster recovery solutions that make use of cloud technologies and virtual servers. With this strategy, you can minimize downtime and efficiently "flip a switch." ### **3\. Insurance does not protect your data** Cyberattacks are becoming more proficient and effective globally. Insurance may not cover replacing lost data as a result of a breach in the data center, server, backup, or even loss of access. Moreover, even if insurance does cover the cost of repairs, the entire cost of a disaster's damages will not be covered. It can pay for the repairs, but it cannot make up for the income loss and missed business opportunities brought on by downtime. ### **4\. Disaster Recovery** Disasters can occur at any point. That is what makes them so devastating—their unexpectedness. Major occurrences like earthquakes, floods, and natural catastrophes are among the main causes of IT outages. Moreover, accidents, inept workers, user behavior that compromises security, and human error-related data erasure can also cause significant downtimes. Recovery from such occurrences is made possible by business continuity, which lays out the steps that must be followed to guarantee that activities continue regardless of the type of disaster. A recovery plan asks the following questions and addresses them: - Can you move to a server or network housed in a running data center in the event of a power outage? - Do you have a standby server (or virtual server) available in case of server failure? - Can your staff operate remotely in the event that your office site becomes unusable? When creating your business continuity strategy, you take into account every scenario that might arise. Offsite and redundant backup continues to be one of the most crucial components of IT resilience, mostly due to the possibility of power outages or office relocation. ## **Setting Up Synthetic Monitoring in AWS** The following are the essential steps for configuring[ AWS CloudWatch Synthetics](https://aws.amazon.com/blogs/mt/visual-monitoring-of-applications-with-amazon-cloudwatch-synthetics/?ref=sredevops.org) for synthetic monitoring: - **Open the Amazon Management Console**: Enter your credentials to access the AWS Management Console. - **Enable CloudWatch Synthetics**: To utilize CloudWatch Synthetics, go to the "CloudWatch" service and choose "Synthetics" from the menu on the left. ![](https://lh7-us.googleusercontent.com/docsz/AD_4nXd5FhmdGRgD1Pu6JK91xlsqH-EE3eAiEH998QMbzmVScEiPelxKMP0cm1nrDNCEUzRm1goFOYPRXJfxMJvKNVkeMEjigVXWquoP0POxoQhu9lENb359pEb1-t8i_W0RwxNEyAHruNiLZI5uyE3gNuS8B-SW?key=8Ss1x2E4lDLSYCoYxoHEgw) Source [https://aws.amazon.com/blogs/mt/visual-monitoring-of-applications-with-amazon-cloudwatch-synthetics/](https://aws.amazon.com/blogs/mt/visual-monitoring-of-applications-with-amazon-cloudwatch-synthetics/?ref=sredevops.org) - **Create a New Canary:** To start configuring a new synthetic test, click the "Create Canary" button in the Synthetics dashboard. - **Set up Canary Settings**: Give your canary a name, select the runtime environment (Python, Node.js, etc.), and specify how frequently tests should be run. - **Define Test Script:** Compose a script that describes the procedures that must be taken in order to complete the synthetic test. Python, Java, and Node.js are among the programming languages supported by AWS CloudWatch Synthetics. Set up the settings for your test, including HTTP headers, endpoint URLs, and any other variables required for your infrastructure or application. ![](https://lh7-us.googleusercontent.com/docsz/AD_4nXfr2EeTQrNzCDxAFtp8ysbACVNQ5rxjnLCV65wt4aKtZyU_Lf4HeFxQXMurtIGwfJxC7liitxiW5-NMxaObcwqSTO0GZzmj-8LnTvRP_v-AAmUnIXXw15MMCNQaiI6o0xY5AqmeKYgoiMufkttVlAvCq7A?key=8Ss1x2E4lDLSYCoYxoHEgw) [Source](https://aws.amazon.com/blogs/mt/monitor-your-private-endpoints-using-cloudwatch-synthetics/?ref=sredevops.org) - **Define Roles and Permissions for the Canary**: Indicate the IAM roles and access levels the Canary needs in order to run its test script. - **Examine and Deploy**: After making sure the setup information is correct, deploy the Canary to begin tracking your digital services. - **Follow Canary Execution**: Keep tabs on Canary's progress via the Synthetics dashboard, which provides test outcomes, reaction times, success rates, and any faults found. - **Iterate and Adjust**: Based on the requirements of your application, examine test results often and make necessary adjustments to the scripts, settings, or monitoring intervals. ## **Challenges and Considerations for Synthetic Monitoring in AWS** ### **Safety Risks** - **Authentication**: Make sure that authentication is secure by using AWS Secrets Manager and granting only the minimal amount of IAM Role permissions. - **Data encryption**: To avoid unwanted access,[ encrypt test results](https://www.opsramp.com/guides/aws-monitoring-tool/cloudwatch-synthetics/?ref=sredevops.org) and sensitive data. Role-based access control should be used to limit access to artificial monitoring setups and data. ### **Expense Control** - **Optimize Test Schedules**: To reduce pointless runs, modify test frequency in accordance with application dynamics. - **Strategies for Data Retention**: Set up policies for data retention so that only essential data is kept on file, saving money on storage. - **Cost optimization**: Keep an eye on and make adjustments to expenses related to synthetic monitoring, including S3 storage and Lambda calls. ### **Combination with Different Services** - **CloudWatch Integration**: Make sure that CloudWatch and your system integrate seamlessly to provide real-time alerts and monitoring. - **Lambda Integration**: To automate processes and integrate with additional AWS services, use Lambda functions. - **Integration with S3**: Save test outcomes and screenshots in S3 for convenient access and long-term storage. ### **Further Considerations** - **Complexity of Monitoring**: Synthetic monitoring, particularly for large-scale applications, may be complicated. Make sure configuration and testing are done thoroughly. - **Test Script Maintenance**: To account for modifications in application operations and provide precise monitoring, test scripts should be updated on a regular basis. ## **Conclusion** To maintain business continuity in AWS settings, synthetic monitoring is essential. Businesses may proactively identify problems and save downtime and losses by knowing the value of synthetic monitoring, its advantages, and best practices for implementing it. Ensuring the upkeep and efficiency of AWS-based apps and infrastructure is made possible by synthetic monitoring, which offers visible proof, scriptable tests, customized warnings, and proactive monitoring. Synthetic monitoring may be made even more successful for enterprises by combining it with AWS services like Lambda, S3, and CloudWatch Synthetics. ### Kueue: La forma más sencilla de gestionar colas de trabajos y recursos en Kubernetes URL: https://www.sredevops.org/es/kueue-la-forma-mas-sencilla-de-gestionar-colas-de-trabajos-y-recursos-en-kubernetes/ Last updated: 2026-01-08T02:36:08.000Z Kueue es una potente herramienta diseñada para mejorar la gestión de colas de trabajos y recursos dentro de los clústeres Kubernetes. Al ofrecer un conjunto de APIs y un *controller*, Kueue te permite gestionar eficientemente la ejecución de trabajos, la asignación de recursos y el rendimiento general del clúster. Kueue es un sistema de colas de trabajos nativo de la nube para aplicaciones por lotes, HPC, AI/ML y similares en un clúster Kubernetes. Utiliza Kueue para construir un servicio por lotes *multi-tenant* con cuotas y una jerarquía para compartir recursos entre equipos de tu organización. En función de las cuotas disponibles, Kueue decide cuándo los trabajos deben esperar y cuándo y dónde deben ejecutarse. Kueue funciona en combinación con el *kube-scheduler* estándar, el *cluster-autoscaler* y el resto del ecosistema de Kubernetes. Esta combinación permite a Kueue ejecutarse tanto *on-prem* como en la nube, donde los recursos pueden ser heterogéneos, fungibles y aprovisionados dinámicamente. ### Características Clave para Cargas de Trabajo Optimizadas en Kubernetes - **Job Management (Gestión de trabajos):** Kueue permite la puesta en cola de trabajos priorizados con estrategias flexibles como StrictFIFO y BestEffortFIFO. - **Resource Management (Gestión de recursos):** Logra un reparto equitativo de los recursos e implementa políticas de *preemption* entre los distintos *tenants*. - **Dynamic Resource Reclaim (Recuperación dinámica de recursos):** Libera automáticamente la cuota a medida que se completan los *pods* de trabajo, maximizando la utilización de los recursos. - **Resource Flavor Fungibility (Fungibilidad de los tipos de recursos):** Permite el préstamo de cuotas o *preemption* en ClusterQueues y Cohorts para una mayor flexibilidad. - **Amplia gama de integraciones:** Integración perfecta con tipos de trabajo populares, como BatchJob, trabajos de entrenamiento Kubeflow, RayJob, RayCluster, JobSet y Pods simples. - **Información detallada del sistema:** Obtén información valiosa sobre el estado de tu sistema a través de métricas Prometheus y *Conditions* incorporados. ### Preparación para producción y soporte robusto Kueue cuenta con una versión API v1beta1 madura, documentación completa, amplia cobertura de pruebas y verificación de escalabilidad. Con lanzamientos regulares, seguridad robusta y una creciente lista de usuarios en entornos de producción, Kueue es una solución fiable para gestionar tus cargas de trabajo de Kubernetes. ### Instalación y uso sencillo Kueue es compatible con Kubernetes 1.22 y superiores. Instala la última versión sin esfuerzo con un solo comando: ```bash # ¡Comprueba la versión si es necesario! kubectl apply --server-side -f [https://github.com/kubernetes-sigs/kueue/releases/download/v0.7.0/manifests.yaml ``` Consulta la documentación de Kueue para obtener guías de instalación detalladas y ejemplos de uso. [DocumentationPowerful, extensible, and feature-packed frontend toolkit. Build and customize with Sass, utilize prebuilt grid system and components, and bring projects to life with powerful JavaScript plugins.![](https://kueue.sigs.k8s.io/favicons/apple-touch-icon-180x180.png).cls-1{fill:none}.cls-2{fill:#fff}.cls-3{fill:#326ce5}Kueue](https://kueue.sigs.k8s.io/docs/?ref=sredevops.org) ### Roadmap El desarrollo de Kueue está impulsado activamente por los comentarios y contribuciones de la comunidad. En 2023, la hoja de ruta del proyecto prioriza: - *Preemption* cooperativa para cargas de trabajo con *checkpointing*. - Estrategias de asignación de *flavors* para optimizar la asignación de recursos. - Integración con el *cluster-autoscaler* para el aprovisionamiento garantizado de recursos. - Mayor integración con diversas cargas de trabajo personalizadas como Kubeflow, Spark, Ray y herramientas de flujo de trabajo. Los objetivos a largo plazo incluyen soporte presupuestario, un panel de control fácil de usar y soporte *multi-clúster*. ### Comunidad y soporte Únete a la vibrante comunidad de Kueue para mantenerte informado, participar en debates y contribuir al desarrollo continuo del proyecto. Conéctate con los mantenedores a través de Slack y la lista de correo para obtener soporte y colaborar. ### Empieza a usar Kueue Kueue ofrece un enfoque simplificado y eficiente para la gestión de colas de trabajos y recursos en Kubernetes. Aprovechando sus potentes funciones, puedes optimizar el rendimiento de tu clúster, garantizar una asignación equitativa de los recursos y agilizar tus procesos de gestión de cargas de trabajo. ¡Instala Kueue hoy mismo y experimenta los beneficios de primera mano! [GitHub - kubernetes-sigs/kueue: Kubernetes-native Job QueueingKubernetes-native Job Queueing. Contribute to kubernetes-sigs/kueue development by creating an account on GitHub.![](https://github.githubassets.com/assets/pinned-octocat-093da3e6fa40.svg)GitHubkubernetes-sigs![](https://opengraph.githubassets.com/43569c8be5373a49c864811d8eb22f19e11b25e522371154142ee93ae48183b2/kubernetes-sigs/kueue)](https://github.com/kubernetes-sigs/kueue/?ref=sredevops.org) ### Kueue: Streamlining Kubernetes Job Queueing and Resource Management URL: https://www.sredevops.org/en/kueue-streamlining-kubernetes-job-queueing-and-resource-management/ Last updated: 2025-03-10T23:38:42.000Z Kueue is a powerful tool designed to enhance job queueing and resource management within Kubernetes clusters. By offering a set of APIs and a controller, **Kueue empowers you to efficiently manage job execution, resource allocation, and overall cluster performance.** > Kueue is a cloud-native job queueing system for batch, HPC, AI/ML, and similar applications in a Kubernetes cluster. > > Use Kueue to build a multi-tenant batch service with quotas and a hierarchy for sharing resources among teams in your organization. Based on the available quotas, Kueue decides when jobs should wait and when and where they should run. > > Kueue works in combination with standard kube-scheduler, cluster-autoscaler, and the rest of the kubernetes ecosystem. This combination allows Kueue to run both on-prem and in the cloud, where resources can be heterogeneous, fungible, and dynamically provisioned. ## Key Features for Optimized Kubernetes Workloads - **Job Management:** Kueue enables prioritized job queueing with flexible strategies like `StrictFIFO` and `BestEffortFIFO`. - **Resource Management:** Achieve fair resource sharing and implement preemption policies between different tenants. - **Dynamic Resource Reclaim:** Automatically release quota as job pods complete, maximizing resource utilization. - **Resource Flavor Fungibility:** Enable quota borrowing or preemption in ClusterQueues and Cohorts for enhanced flexibility. - **Wide Range of Integrations:** Seamlessly integrate with popular job types, including BatchJob, Kubeflow training jobs, RayJob, RayCluster, JobSet, and plain Pods. - **Enhanced System Insights:** Gain valuable insights into your system's state through built-in Prometheus metrics and Conditions. ## Production Readiness and Robust Support Kueue boasts a mature v1beta1 API version, comprehensive documentation, extensive test coverage, and scalability verification. With regular releases, robust security, and a growing list of adopters in production environments, Kueue is a reliable solution for managing your Kubernetes workloads. ## Installation and Usage Made Easy Kueue is compatible with Kubernetes 1.22 and above. Install the latest release effortlessly with a single command: ```bash # Check version if needed! kubectl apply --server-side -f https://github.com/kubernetes-sigs/kueue/releases/download/v0.7.0/manifests.yaml ``` Explore the Kueue documentation for detailed installation guides and usage examples. [DocumentationPowerful, extensible, and feature-packed frontend toolkit. Build and customize with Sass, utilize prebuilt grid system and components, and bring projects to life with powerful JavaScript plugins.![](https://www.sredevops.org/content/images/icon/apple-touch-icon-180x180.png).cls-1{fill:none}.cls-2{fill:#fff}.cls-3{fill:#326ce5}Kueue](https://kueue.sigs.k8s.io/docs/?ref=sredevops.org) ## Roadmap Kueue's development is actively driven by community feedback and contributions. In 2023, the project's roadmap prioritizes: - Cooperative preemption for workloads with checkpointing. - Flavor assignment strategies for optimizing resource allocation. - Integration with the cluster-autoscaler for guaranteed resource provisioning. - Broader integration with various custom workloads like Kubeflow, Spark, Ray, and workflow tools. Long-term goals include budget support, a user-friendly dashboard, and multi-cluster support. ## Community and Support Join the vibrant Kueue community to stay informed, participate in discussions, and contribute to the project's ongoing development. Connect with maintainers through Slack and the mailing list for support and collaboration. ## Get Started with Kueue Kueue offers a simplified and efficient approach to job queueing and resource management in Kubernetes. By leveraging its powerful features, you can optimize your cluster's performance, ensure fair resource allocation, and streamline your workload management processes. Install Kueue today and experience the benefits firsthand. [GitHub - kubernetes-sigs/kueue: Kubernetes-native Job QueueingKubernetes-native Job Queueing. Contribute to kubernetes-sigs/kueue development by creating an account on GitHub.![](https://github.githubassets.com/assets/pinned-octocat-093da3e6fa40.svg)GitHubkubernetes-sigs![](https://opengraph.githubassets.com/43569c8be5373a49c864811d8eb22f19e11b25e522371154142ee93ae48183b2/kubernetes-sigs/kueue)](https://github.com/kubernetes-sigs/kueue/?ref=sredevops.org) ### Lima: La forma más fácil de ejecutar cualquier distribución de Linux, Kubernetes, k3s e incluso Docker en macOS y Linux, compatible con Apple Silicon (M1/ARM64) URL: https://www.sredevops.org/es/lima-la-forma-mas-facil-de-ejecutar-cualquier-distribucion-de-linux-kubernetes-k3s-e-incluso-docker-en-macos-y-linux-compatible-con-apple-silicon-m1-arm64/ Last updated: 2026-01-08T02:36:27.000Z > Qué es Lima: Una herramienta de línea de comandos (CLI) versátil y fácil de usar para ejecutar máquinas virtuales (VM) de Linux en tu sistema macOS o Linux Lima es compatible con cualquier procesador Apple Silicon (M1, M2, etc.) y procesadores Intel x86\_64, y te permite ejecutar VMs de Linux sin necesidad de nada más que un solo comando: ```bash # Ejemplo: Ejecutar Kubernetes de 64 bits en un Macbook Pro M2: limactl create template://k8s --arch x86_64 --rosetta ``` ![demo](https://lima-vm.io/images/demo.gif) ## Características clave - Compartir archivos y encaminamiento de puertos sin esfuerzo: Compartir archivos y acceder a servicios VM sin problemas. - Soporte de tiempo de ejecución de contenedor integrado: Soporte integrado para containerd y compatibilidad con otros motores como Docker y Podman. - Compatibilidad entre arquitecturas: Ejecutar distribuciones de Linux basadas en ARM en Macs basadas en Intel, y viceversa. - Varias distribuciones de Linux: Elija entre opciones populares como Ubuntu (predeterminado), Debian, Fedora, Arch Linux y más. - Proyecto de la Fundación Cloud Native Computing Foundation. [Lima![](https://lima-vm.io/favicons/apple-touch-icon-180x180.png)Lima![](https://lima-vm.io/images/logo.svg)](https://lima-vm.io/?ref=sredevops.org) ## Integración sin esfuerzo para una mayor productividad Con Lima, comparte archivos y carpetas entre tu sistema operativo host y la VM de Linux sin necesidad de protocolos de transferencia de archivos engorrosos o sincronización manual. Esto optimiza tu flujo de trabajo, ya sea que estés editando código, trabajando con documentos o transfiriendo conjuntos de datos grandes. El encaminamiento de puertos automático de Lima simplifica el acceso a los servicios que se ejecutan dentro de la VM, lo que te permite interactuar con aplicaciones web, bases de datos y otros servicios de red alojados en la VM directamente desde tu sistema host. Esta integración sin problemas aumenta en gran medida tus procesos de desarrollo, pruebas y depuración. ## Administración y personalización sin esfuerzo de las VMs La interfaz de línea de comandos (CLI) de Lima, limactl, proporciona comandos intuitivos para administrar tus VMs. Crea, inicia, detén y elimina VMs sin esfuerzo, todo desde la comodidad de tu terminal. Las opciones de configuración extensas de Lima te permiten adaptar la VM a tus necesidades específicas. Asigna fácilmente recursos como núcleos de CPU, memoria y espacio en disco, o ajusta parámetros como configuraciones de red, reglas de encaminamiento de puertos y otros parámetros. Esta flexibilidad te permite crear VMs optimizadas para tareas específicas, garantizando un rendimiento y uso de recursos óptimos. ## Una herramienta versátil para diversos casos de uso: Linux, Kubernetes y más allá Las aplicaciones de Lima van mucho más allá de simplemente ejecutar distribuciones de Linux. Su naturaleza amigable con los contenedores y el soporte para varios motores de tiempo de ejecución de contenedores, como containerd, Docker y Podman, lo convierten en una plataforma ideal para cargas de trabajo contenerizadas. Ya sea que estés desarrollando aplicaciones nativas en la nube, experimentando con herramientas de orquestación de contenedores como Kubernetes o creando entornos de desarrollo portátiles, Lima proporciona una base sólida para tus flujos de trabajo basados en contenedores. La versatilidad de Lima brilla a través de su compatibilidad con una amplia gama de sistemas operativos invitados, incluidas populares distribuciones de Linux como Ubuntu, Debian, Fedora y muchas más. Esto te permite elegir el entorno que mejor se adapte a tus requisitos de proyecto y preferencias personales. ## Instalación sencilla Empezar con Lima es fácil, gracias a sus múltiples opciones de instalación: - `Homebrew` (macOS y Linux): `brew install lima` - `Nix` (macOS y Linux): `nix-env -i lima` - Fuente (usuarios avanzados): Clona el repositorio, compila e instala. [GitHub - lima-vm/lima: Linux virtual machines, with a focus on running containers](https://github.com/lima-vm/lima?ref=sredevops.org) [GitHub - lima-vm/lima: Linux virtual machines, with a focus on running containersLinux virtual machines, with a focus on running containers - lima-vm/lima![](https://github.githubassets.com/assets/pinned-octocat-093da3e6fa40.svg)GitHublima-vm![](https://opengraph.githubassets.com/897585175c22c2be8793dd95f2d6bcbfdcdda98356a8139ee2d6464dee036970/lima-vm/lima)](https://github.com/lima-vm/lima?ref=sredevops.org) # Tu puerta de entrada a Linux en macOS y Linux Si eres un desarrollador que desea probar aplicaciones en un entorno Linux, un administrador de sistemas que administra servidores Linux o simplemente alguien curioso por explorar las distribuciones Linux, Lima ofrece una solución fácil de usar y eficiente. Simplifica la configuración y la administración de VMs de Linux, brindándote la flexibilidad y el poder que necesitas para trabajar eficazmente con Linux en tu plataforma preferida. ## Empodera tu flujo de trabajo con Lima Sumérgete en el mundo de las VMs de Linux con Lima y desbloquea un nuevo nivel de productividad y versatilidad en tu trabajo. Su interfaz intuitiva, su rica funcionalidad y su compatibilidad entre plataformas lo convierten en una herramienta indispensable para cualquiera que desee aprovechar el poder de Linux en macOS o Linux. Con Lima, tienes una poderosa aliada para optimizar tus tareas de desarrollo, pruebas y administración, lo que te permite enfocarte en lo que realmente importa: lograr tus objetivos con la eficiencia y confiabilidad que brinda Linux. ## Bonus track: Ejecutar Docker en macOS sin Docker Desktop Lima también puede usarse como una alternativa liviana y eficiente a Docker Desktop en macOS. Al aprovechar las capacidades de virtualización de Lima y la tecnología de contenedores de Docker, puedes crear un entorno Docker sin la sobrecarga de Docker Desktop. Esta aproximación ofrece tiempos de inicio más rápidos, un consumo de recursos reducido y una experiencia de Docker más optimizada para tus necesidades específicas. ### Instalar Docker en macOS sin Docker Desktop: ```bash # Para crear y comenzar una instancia de Lima preconfigurada para Docker limactl start template://docker ``` Con Docker ejecutándose en Lima, ahora puedes usar el comando `nerdctl` (o el comando `docker` después de una configuración adecuada) para interactuar con Docker como lo harías normalmente. Disfruta de los beneficios de un entorno Docker liviano y eficiente sin la necesidad de Docker Desktop. ### Lima: The Easiest Way to Run any Linux Distro, Kubernetes, k3s and even Docker on macOS and Linux, Apple Silicon (M1/ARM64) compatible URL: https://www.sredevops.org/en/lima-the-easiest-way-to-run-any-linux-distro-kubernetes-k3s-and-even-docker-on-macos-and-linux-apple-silicon-m1-arm64-compatible/ Last updated: 2024-06-14T09:01:26.000Z Lima is a versatile and user-friendly command line tool (CLI) that empowers you to seamlessly run Linux virtual machines (VMs) on your macOS or Linux system. It's c**ompatible with any Apple Silicon Mac (M1, M2, etc) ARM64 and Intel x86\_64 processors**, vice versa, without anything else than a single command: ```bash # Example: Run Kubernetes 64 bits on a Macbook Pro M2: limactl create template://k8s --arch x86_64 --rosetta ``` ![demo](https://lima-vm.io/images/demo.gif) ## Key Features - **Effortless File Sharing and Port Forwarding:** Share files and access VM services seamlessly. - **Container Runtime Support:** Built-in support for containerd and compatibility with other engines like Docker and Podman. - **Cross-Architecture Compatibility:** Run ARM-based Linux distributions on Intel-based Macs, and vice versa. - **Diverse Linux Distributions:** Choose from popular options like Ubuntu (default), Debian, Fedora, Arch Linux, and more. - [**Cloud Native Computing Foundation**](https://cncf.io/?ref=sredevops.org) **sandbox project.** ![](https://camo.githubusercontent.com/73b069e6161e584fe92b3607886ad43df24382aeaa3ce54834e7e335488ebe28/68747470733a2f2f7777772e636e63662e696f2f77702d636f6e74656e742f75706c6f6164732f323032322f30372f636e63662d636f6c6f722d62672e737667) ## Seamless Integration for Enhanced Productivity With Lima, effortlessly share files and folders between your host operating system and the Linux VM, eliminating the need for cumbersome file transfer protocols or manual synchronization. This streamlines your workflow, whether you're editing code, working with documents, or transferring large datasets. Lima's automatic port forwarding simplifies access to services running within the VM, allowing you to interact with web applications, databases, and other network services hosted in the VM directly from your host system. This seamless integration significantly enhances your development, testing, and debugging processes. ## Effortless VM Management and Customization Lima's command-line interface (CLI) tool, `limactl`, provides intuitive commands for managing your VMs. Create, start, stop, and delete VMs with ease, all from the comfort of your terminal. Lima's extensive configuration options enable you to tailor the VM to your specific needs. Easily allocate resources like CPU cores, memory, and disk space, or fine-tune network settings, port forwarding rules, and other parameters. This flexibility empowers you to create VMs optimized for specific tasks, ensuring optimal performance and resource utilization. ## A Versatile Tool for Diverse Use Cases: Linux, Kubernetes, and Beyond Lima's applications extend far beyond simply running Linux distributions. Its container-friendly nature and support for various container runtimes, such as containerd, Docker, and Podman, make it an ideal platform for containerized workloads. Whether you're developing cloud-native applications, experimenting with container orchestration tools like Kubernetes, or building portable development environments, Lima provides a solid foundation for your container-based workflows. Lima's versatility shines through its compatibility with a wide range of guest operating systems, including popular Linux distributions like Ubuntu, Debian, Fedora, and many more. This allows you to choose the environment that best aligns with your project requirements and personal preferences. ## Installation Made Simple Getting started with Lima is a breeze, thanks to its multiple installation options: - **Homebrew (macOS and Linux):** `brew install lima` - **Nix (macOS and Linux):** `nix-env -i lima` - **Source (advanced users):** Clone the repository, compile, and install. [GitHub - lima-vm/lima: Linux virtual machines, with a focus on running containersLinux virtual machines, with a focus on running containers - lima-vm/lima![](https://github.githubassets.com/assets/pinned-octocat-093da3e6fa40.svg)GitHublima-vm![](https://opengraph.githubassets.com/897585175c22c2be8793dd95f2d6bcbfdcdda98356a8139ee2d6464dee036970/lima-vm/lima)](https://github.com/lima-vm/lima?ref=sredevops.org) Lima Repository on Github ## Your Gateway to Linux on macOS and Linux Whether you're a developer looking to test applications in a Linux environment, a system administrator managing Linux servers, or simply curious about exploring Linux distributions, Lima provides a user-friendly and efficient solution. It simplifies the setup and management of Linux VMs, offering the flexibility and power you need to work effectively with Linux on your preferred platform. ## Empowering Your Workflow with Lima Dive into the world of Linux VMs with Lima and unlock a new level of productivity and versatility in your work. Its intuitive interface, rich feature set, and cross-platform compatibility make it an indispensable tool for anyone seeking to harness the power of Linux on macOS or Linux. With Lima, you have a powerful ally to streamline your development, testing, and administration tasks, allowing you to focus on what truly matters – achieving your goals with the efficiency and reliability that Linux provides. ## Bonus Track: Running Docker on macOS without Docker Desktop Lima can also be used as a lightweight and efficient alternative to Docker Desktop on macOS. By leveraging Lima's virtualization capabilities and Docker's containerization technology, you can create a seamless Docker environment without the overhead of Docker Desktop. This approach offers faster startup times, reduced resource consumption, and a more streamlined Docker experience tailored to your specific needs. 💡 ****How to install Docker on macOS without Docker Desktop:** ```bash # to create and start a Lima instance pre-configured for Docker limactl start template://docker ``` With Docker running on Lima, you can now use the \`nerdctl\` command (or the \`docker\` command after appropriate configuration) to interact with Docker as you normally would. Enjoy the benefits of a lightweight and efficient Docker environment without the need for Docker Desktop. ### Ex-empleado de OpenAI habla sobre la AGI, la superinteligencia y la dinámica de poder global URL: https://www.sredevops.org/es/ex-empleado-de-openai-habla-sobre-la-agi-la-superinteligencia-y-la-dinamica-de-poder-global/ Last updated: 2026-01-08T02:36:11.000Z En un episodio reciente del podcast Dwarkesh Patel, el ex-empleado de OpenAI, [Leopold Ashenbrenner](https://www.linkedin.com/in/leopold-aschenbrenner/?ref=sredevops.org), miembro del ahora disuelto equipo de *superalineación*, brindó una visión cautivadora y perspicaz del mundo de la `AI` avanzada, su trayectoria potencial y sus implicaciones para la humanidad. ### Analizando las ideas de Ashenbrenner: Ashenbrenner, conocido por su profundo conocimiento de la `AI`, articuló con elocuencia sus puntos de vista sobre una variedad de temas, que incluyen: - **El estado actual de la AGI:** Habló sobre las capacidades de `GPT-4` y si representa la "chispa" de la Inteligencia Artificial General, como sugieren algunos expertos. También exploró la línea de tiempo potencial desde la `AGI` hasta la superinteligencia, cuestionando si sería una evolución gradual o una explosión rápida. - **Más allá de los apocalípticos y utópicos de la `AI`:** Ashenbrenner desafía la dicotomía simplista de los apocalípticos de la `AI` (que abogan por un alto total en el desarrollo de la `AI`) y los utópicos (que visualizan un futuro idílico impulsado por la `AI`). Él enfatiza la necesidad de considerar un espectro más amplio de posibilidades y consecuencias potenciales. - **La geopolítica de la superinteligencia:** Una preocupación clave planteada fue el potencial de la `AI` para perturbar el equilibrio de poder global. Ashenbrenner argumenta que naciones como China ven la supremacía de la `AI` como crucial para sus intereses nacionales. Advierte sobre una posible carrera armamentista de `AI`, con consecuencias devastadoras si una nación obtiene una ventaja decisiva. - **La importancia de "desatar" la `AI`:** Usó el término "desatar" para describir el proceso de desbloquear todo el potencial de los sistemas de `AI`. Esto implica ir más allá del simple pre-entrenamiento en conjuntos de datos masivos y desarrollar técnicas para que la `AI` aprenda y se adapte de forma autónoma, similar a `AlphaGo` y `AlphaStar` de DeepMind. - **La `AI` como catalizador del rápido avance tecnológico:** Ashenbrenner sugiere que la `AI` podría acelerar significativamente el progreso tecnológico, comprimiendo potencialmente décadas de innovación en unos pocos años. Esto podría conducir a una "explosión de inteligencia", con profundas implicaciones para varios campos, incluyendo la robótica y las aplicaciones militares. - **El potencial de las dictaduras impulsadas por la `AI`:** Una de las posibilidades más escalofriantes discutidas fue el potencial de la `AI` para empoderar a los regímenes autoritarios. Ashenbrenner pinta una imagen de vigilancia, censura y represión habilitadas por la `AI`, lo que sugiere que la superinteligencia podría consolidar el control de las dictaduras en las próximas generaciones. ### Conclusiones y reflexiones clave: La entrevista de Ashenbrenner sirve como un duro recordatorio de que el desarrollo de la `AI` avanzada no es simplemente un esfuerzo tecnológico sino también profundamente político y social. Algunas conclusiones clave incluyen: - **La necesidad de matices y una consideración amplia:** Es crucial ir más allá de las narrativas simplistas de fatalidad o utopía de la `AI`. Debemos participar en discusiones matizadas sobre los beneficios y riesgos potenciales de la `AI`, explorando una gama más amplia de futuros posibles. - **La urgencia de la cooperación internacional:** Para mitigar los riesgos de una carrera armamentista de `AI` y garantizar que el desarrollo de la `AI` beneficie a toda la humanidad, la cooperación internacional es primordial. Esto incluye establecer pautas éticas, fomentar la transparencia y promover la investigación y el despliegue responsable de la `AI`. - **La importancia de la preparación social:** A medida que la `AI` transforma rápidamente nuestro mundo, es esencial prepararse para su impacto social. Esto incluye abordar el posible desplazamiento laboral, garantizar un acceso equitativo a los beneficios de la `AI` y protegerse contra la discriminación y el sesgo impulsados por la `AI`. Las ideas de Ashenbrenner ofrecen una perspectiva aleccionadora pero que invita a la reflexión sobre el futuro de la `AI` y su impacto potencial en la humanidad. Es un llamado a la acción para que investigadores, legisladores y ciudadanos por igual participen en un diálogo informado y proactivo para dar forma a la trayectoria del desarrollo de la `AI` y garantizar un futuro donde esta poderosa tecnología sirva como una fuerza para el bien. ### Paper completo: [SITUATIONAL AWARENESS: The Decade AheadLeopold Aschenbrenner, June 2024\. Fuente: https://situational-awareness.ai/situationalawareness.pdf20 MBdownload-circle](https://www.sredevops.org/content/files/2024/06/situationalawareness.pdf "Download") ### Entrevista completa original: ### Run Apache Kafka on Kubernetes in Minutes with Strimzi URL: https://www.sredevops.org/en/run-apache-kafka-on-kubernetes-in-minutes-with-strimzi/ Last updated: 2024-06-12T05:05:32.000Z ### Key Features of Strimzi - **Secure by Default**: Strimzi includes built-in security features like TLS, SCRAM-SHA, and OAuth authentication, as well as automated certificate management. - **Simple yet Configurable**: Strimzi offers flexible deployment options, including NodePort, Load Balancer, and Ingress, as well as features like rack awareness for high availability. - **Kubernetes Native Experience**: Strimzi uses a Kubernetes Operator to manage the entire Kafka lifecycle, allowing you to use familiar kubectl commands to deploy and manage your Kafka clusters. ## What is Strimzi? Strimzi is an open-source project that provides a way to run an Apache Kafka cluster on Kubernetes in various deployment configurations. It abstracts away the underlying infrastructure, allowing developers and operations teams to focus on the applications themselves rather than worrying about the intricacies of the hosting environment. One of the key benefits of Strimzi is its ability to automate the deployment, scaling, and management of Kafka clusters. By using Kubernetes Custom Resources, Strimzi makes it easy to create, configure, and maintain Kafka clusters, topics, and users, all within your Kubernetes environment. Strimzi also includes built-in security features, such as TLS encryption, SCRAM-SHA authentication, and OAuth support, ensuring that your Kafka cluster is secure by default. Additionally, Strimzi provides options for exposing your Kafka cluster outside of Kubernetes, including NodePort, Load Balancer, and Ingress, making it easy to integrate with other applications and services. Whether you're running Kafka on a local Minikube cluster, a Kubernetes Kind environment, or a production-grade Kubernetes deployment, Strimzi makes it simple to get started and manage your Kafka infrastructure. ## Getting Help If you encounter any issues while using Strimzi, you can get help in the following ways: - Send an email to the [Strimzi Mailing list](https://lists.cncf.io/g/cncf-strimzi-users/topics?ref=sredevops.org) - Ask your question on the [Strimzi Slack Workspace](https://slack.cncf.io/?ref=sredevops.org) ## Quickstarts ## Minikube Minikube provides a local Kubernetes, designed to make it easy to learn and develop for Kubernetes. The Kubernetes cluster is started either inside a virtual machine, a container or on bare-metal, depending on the minikube driver you choose. ## Installing the dependencies This quickstart assumes that you have the latest version of the `minikube` binary, which you can get from the [minikube website](https://minikube.sigs.k8s.io/docs/start/?ref=sredevops.org). Minikube requires a container or virtual machine manager. The Minikube documentation includes a list of suggested options in the [getting started guide](https://minikube.sigs.k8s.io/docs/start/?ref=sredevops.org). You'll also need the `kubectl` binary, which you can get by following the [kubectl installation instructions](https://kubernetes.io/docs/tasks/tools/?ref=sredevops.org) from the Kubernetes website. Once you have all the binaries installed, make sure everything works: ``` # Validate minikube minikube version # Validate kubectl kubectl version ``` ## Starting the Kubernetes cluster Start a local development cluster of [Minikube](https://minikube.sigs.k8s.io/docs/start/?ref=sredevops.org) that runs in a container or virtual machine manager. ``` minikube start --memory=4096 # 2GB default memory isn't always enough ``` ## Deploy Strimzi using installation files Before deploying the Strimzi cluster operator, create a namespace called `kafka`: ``` kubectl create namespace kafka ``` Apply the Strimzi install files, including `ClusterRoles`, `ClusterRoleBindings` and some **Custom Resource Definitions** (`CRDs`). The CRDs define the schemas used for the custom resources (CRs, such as `Kafka`, `KafkaTopic` and so on) you will be using to manage Kafka clusters, topics and users. ``` kubectl create -f 'https://strimzi.io/install/latest?namespace=kafka' -n kafka ``` The YAML files for `ClusterRoles` and `ClusterRoleBindings` downloaded from strimzi.io contain a default namespace of `myproject`. The query parameter `namespace=kafka` updates these files to use `kafka` instead. By specifying `-n kafka` when running `kubectl create`, the definitions and configurations without a namespace reference are also installed in the `kafka` namespace. If there is a mismatch between namespaces, then the Strimzi cluster operator will not have the necessary permissions to perform its operations. Follow the deployment of the Strimzi cluster operator: ``` kubectl get pod -n kafka --watch ``` You can also follow the operator's log: ``` kubectl logs deployment/strimzi-cluster-operator -n kafka -f ``` Once the operator is running it will watch for new custom resources and create the Kafka cluster, topics or users that correspond to those custom resources. ## Create an Apache Kafka cluster Create a new Kafka custom resource to get a single node Apache Kafka cluster: ``` # Apply the `Kafka` Cluster CR file kubectl apply -f https://strimzi.io/examples/latest/kafka/kraft/kafka-single-node.yaml -n kafka ``` Wait while Kubernetes starts the required pods, services, and so on: ``` kubectl wait kafka/my-cluster --for=condition=Ready --timeout=300s -n kafka ``` The above command might timeout if you're downloading images over a slow connection. If that happens you can always run it again. ## Send and receive messages With the cluster running, run a simple producer to send messages to a Kafka topic (the topic is automatically created): ``` kubectl -n kafka run kafka-producer -ti --image=quay.io/strimzi/kafka:0.41.0-kafka-3.7.0 --rm=true --restart=Never -- bin/kafka-console-producer.sh --bootstrap-server my-cluster-kafka-bootstrap:9092 --topic my-topic ``` Once everything is set up correctly, you'll see a prompt where you can type in your messages: ``` If you don't see a command prompt, try pressing enter. >Hello Strimzi! ``` And to receive them in a different terminal, run: ``` kubectl -n kafka run kafka-consumer -ti --image=quay.io/strimzi/kafka:0.41.0-kafka-3.7.0 --rm=true --restart=Never -- bin/kafka-console-consumer.sh --bootstrap-server my-cluster-kafka-bootstrap:9092 --topic my-topic --from-beginning ``` If everything works as expected, you'll be able to see the message you produced in the previous step: ``` If you don't see a command prompt, try pressing enter. >Hello Strimzi! ``` Enjoy your Apache Kafka cluster, running on Minikube! ## Deleting your Apache Kafka cluster When you are finished with your Apache Kafka cluster, you can delete it by running: ``` kubectl -n kafka delete $(kubectl get strimzi -o name -n kafka) ``` This will remove all Strimzi custom resources, including the Apache Kafka cluster and any KafkaTopic custom resources but leave the Strimzi cluster operator running so that it can respond to new Kafka custom resources. Next, delete the Persistent Volume Claim (PVC) that was used by the cluster: ``` kubectl delete pvc -l strimzi.io/name=my-cluster-kafka -n kafka ``` Without deleting the PVC, the next Kafka cluster you might start will fail as it will try to use the volume that belonged to the previous Apache Kafka cluster. ## Deleting the Strimzi cluster operator When you want to fully remove the Strimzi cluster operator and associated definitions, you can run: ``` kubectl -n kafka delete -f 'https://strimzi.io/install/latest?namespace=kafka' ``` ## Deleting the `kafka` namespace Once it is not used, you can also delete the Kubernetes namespace: ``` kubectl delete namespace kafka ``` ## Where next? - For an overview of the Strimzi components check out the [overview guide](https://strimzi.io/docs/operators/latest/overview?ref=sredevops.org). - For alternative examples of the custom resource that defines the Kafka cluster have a look at these [examples](https://github.com/strimzi/strimzi-kafka-operator/tree/0.41.0/examples/kafka?ref=sredevops.org) ### The Vision of Generative AI's Future, Its Relationship with Kubernetes, and Basically, All of Humanity, According to What Nvidia "Promises" Us URL: https://www.sredevops.org/en/the-vision-of-generative-ais-future-its-relationship-with-kubernetes-and-basically-all-of-humanity-according-to-what-nvidia-promises-us/ Last updated: 2024-06-06T05:43:40.000Z > "Reading between the lines, there is a clear omission of how those who currently work in said industry would benefit, or in general, all > workers and their disadvantages compared to the proprietary giants who -at least for now- are the only ones who truly benefit from this inevitable historical paradigm shift." The recent statements from Nvidia CEO Jensen Huang offer a plausible and realistic, yet naive or conveniently "optimistic" vision of the future of technology—a future where generative AI takes center stage. Huang paints a vivid picture of an "AI factory," where they compare themselves to Nikola Tesla's coil, capable of producing valuable data tokens as raw material for various industries. This is not just the era of AI; it is the dawn of generative AI, marking a paradigm shift in how we interact with and "harness" the power of artificial intelligence. ## From Perception to Creation: The Generative AI Revolution Huang emphasizes a fundamental transition in AI capabilities, moving from mere perception to the realm of generation. This new generation of AI is not limited to analyzing existing data; it creates new valuable data, represented as "tokens" that encompass various forms, from text and images to audio and even scientific simulations. Imagine an AI that not only understands language but creates compelling narratives, composes music, or designs innovative pharmaceuticals. This is the promise of generative AI, a promise that is about to revolutionize industries ranging from healthcare and finance to entertainment and manufacturing. ## "Democratizing" AI: NIMs, Microservices in Kubernetes "for Everyone" At the heart of Huang's vision lies the concept of "NIM" - Nvidia Inference Microservices. These pre-trained AI models, interacting through their `Kubernetes`\-compatible APIs, act as specialized agents, each an expert in a specific task. They are orchestrated as microservices through `Kubernetes`, allowing anyone to "assemble" them based on their own specific goals or needs. According to Nvidia, just as "packaged software" empowered a generation of PC users, NIMS aim to "democratize" AI, enabling businesses and individuals to harness its power without the need for deep technical expertise. Need to translate languages, generate marketing copy, or analyze medical images? There's likely a NIM for that. This modular approach enables the creation of complex AI systems by assembling teams of specialized NIMS, each contributing its unique capabilities to solve a larger problem. ## The Rise of the AI Workforce: Transforming Customer Service and Beyond One sector ripe for AI disruption is customer service, a multi-billion dollar industry facing challenges of efficiency, personalization, and also well-known systematic labor abuses. Huang envisions AI agents, powered by language models, capable of understanding and responding to customer queries with "unprecedented" speed and accuracy. These AI-powered assistants will not just answer questions; they will anticipate needs, offer personalized solutions, and even provide emotional support, ultimately leading to more satisfying customer experiences and increased business efficiency. However, reading between the lines, there is a clear omission of how those who currently work in said industry would benefit, or in general, all workers and their disadvantages compared to the proprietary giants who -at least for now- are the only ones who truly benefit from this inevitable historical paradigm shift. ## Beyond Human: Digital Humans and the Future of Interaction Looking ahead, Huang sells us, sorry, presents us with the concept of "digital humans," AI entities capable of engaging in natural and empathetic interactions. These digital beings, driven by language models and endowed with "emotional intelligence," have the potential to revolutionize how we interact with technology. Imagine a virtual assistant that not only manages your schedule but also offers companionship, provides emotional support, or teaches you new skills. (Hello, HAL-9000). ![Community Standards - meme](https://images3.memedroid.com/images/UPLOADED838/6180306a61189.jpeg) ## The Need for Speed: Driving AI's Exponential Growth with Accelerated Computing Behind this AI revolution lies a fundamental truth: AI thrives on computational power. Training sophisticated AI models, particularly large language models, requires massive amounts of data and processing power. Nvidia, a leader in accelerated computing, plays a pivotal role in this ecosystem, providing the necessary hardware and software infrastructure to drive AI's exponential growth. From high-performance GPUs to specialized software frameworks like `CUDA`, Nvidia is committed to pushing the boundaries of computation, enabling researchers and developers to tackle increasingly complex AI challenges. ## Simulating Reality: Earth-2 and the Power of Synthetic Data To illustrate AI's transformative potential, Huang highlights "Earth-2," a meticulously crafted digital twin of our planet created through AI simulations. This ambitious project aims to model and predict the effects of climate change, allowing scientists to test mitigation strategies and prepare for future challenges. Earth-2 exemplifies the growing importance of synthetic data in AI, where algorithms can learn and evolve within virtual environments, accelerating research and development across various fields. ## The Future is Physical: AI Embraces the Real World While much of the current focus on AI centers on the digital realm, Huang emphasizes the importance of "physics-based AI," artificial intelligence deeply integrated with the laws of physics and capable of interacting with the physical world. This next generation of AI will not merely exist in the digital ether; it will power robots, autonomous vehicles, and smart infrastructure, seamlessly navigating and manipulating the world around us. Imagine robots that can not only assemble products but also design and build their successors, or AI systems that manage power grids, optimize traffic flow, or personalize healthcare treatments in real-time. This is the future of AI, a future where the line between the digital and the physical becomes increasingly fluid. ## Nvidia's Vision: A Future Forged by Intelligent Automation Huang's vision for the future is clear: "Everything that moves will be automated, will be intelligent, will be driven by an AI system." This future, while potentially disruptive, holds immense promise. AI, in Huang's view, has the potential to free us from mundane tasks, unlock unprecedented levels of efficiency, and create new avenues for creativity and innovation. Nvidia, with its focus on accelerated computing, enabling technologies like `CUDA`, and its commitment to pushing the boundaries of AI research, positions itself as a key player in shaping this exciting, AI-driven future. ## A Call to Action: Study, Understand, and Disseminate Open Knowledge as the True Generative AI Revolution Jensen Huang's message is clear: the generative AI revolution is here, and it's time to embrace its transformative potential. In my understanding, everything is true as long as the technology is open, free, and widespread, remains so, and there are no barriers to entry to such knowledge, such as the proprietary concentration of the hardware capable of running such technology, as well as the secrecy in which the big players operate, without any ability for the rest of humanity to understand or hold them accountable for the decisions their owners make regarding the entire future of humanity or the ability to compete healthily. However, there are glimmers of hope, such as the Hugging Face initiative for open-source projects. [🤗 Hugging Face Invierte $10 Millones en Democratizar la IA con GPUs GratuitasHugging Face, líder en aprendizaje automático, está destinando $10 millones en GPUs compartidas gratuitas para impulsar la innovación en IA y contrarrestar la centralización de esta tecnología en manos de gigantes tecnológicos. Esta iniciativa busca empoderar a desarrolladores independientes, académicos y startups, brindándoles las herramientas necesarias para competir en igualdad![](https://www.sredevops.org/content/images/2024/05/favicon.ico)SREDevOps.org - SRE, DevOps, Cloud, LinuxNicolás Georger![](https://www.sredevops.org/content/images/2024/05/Screenshot-2023-07-01-at-01.11.12.png)](https://www.sredevops.org/es/hugging-face-invierte-10-millones-en-democratizar-la-ia-con-gpus-gratuitas/) [NATURAL 20⚡LEARN AI. Join the AI Revolution. Improve your productivity and profits with AI![](https://assets.skool.com/skool/ed24268642ae417a9b8e3b9827cdd1fd.ico)![](https://assets.skool.com/f/2f19653641fa42198dc7d879d7acbf5e/e31f3af301994cdea70956438ac07e78880f0bdbb8674b3694c64cf1db043eb5)](https://www.skool.com/natural20/about?ref=sredevops.org) ### La visión del futuro de la IA Generativa, su relación con Kubernetes y básicamente, toda la humanidad, según lo que nos "promete" Nvidia URL: https://www.sredevops.org/es/la-vision-del-futuro-de-la-ia-generativa-su-relacion-con-kubernetes-y-basicamente-toda-la-humanidad-segun-lo-que-nos-promete-nvidia/ Last updated: 2026-01-08T02:35:55.000Z > "Leyendo entre líneas, hay una clara omisión a cómo se beneficiarían quienes actualmente trabajan en dicha industria, o en general de todos los trabajadores y sus desventajas frente a los gigantes propietarios que -al menos por ahora- son los únicos realmente beneficiados con este inevitable cambio de paradigma histórico." Las recientes declaraciones del CEO de Nvidia, Jensen Huang, ofrecen una visión plausible y realista, a su vez ingenua o convenientemente "optimista" del futuro de la tecnología, un futuro donde la IA generativa toma el protagonismo. Huang pinta una imagen vívida de una "fábrica de IA", donde se comparan ellos mismos como "equivalentes" a la [bobina de Nikola Tesla (Никола Тесла)](https://es.wikipedia.org/wiki/Bobina%5Fde%5FTesla?ref=sredevops.org), capaz de producir los valiosos tokens de datos como materia prima para diversas industrias. Esta no es solo la era de la IA; es el amanecer de la IA generativa, marcando un cambio de paradigma en cómo interactuamos y "aprovechamos" el poder de la inteligencia artificial. ## De la Percepción a la Creación: La Revolución de la IA Generativa Huang enfatiza una transición fundamental en las capacidades de la IA, pasando de la mera percepción al ámbito de la generación. Esta nueva generación de IA no se limita a analizar los datos existentes; crea nuevos datos valiosos, representados como "tokens" que abarcan varias formas, desde texto e imágenes hasta audio e incluso simulaciones científicas. Imagina una IA que no solo comprende el lenguaje, sino que crea narrativas convincentes, compone música o diseña productos farmacéuticos innovadores. Esta es la promesa de la IA generativa, una promesa que está a punto de revolucionar industrias que van desde la atención médica y las finanzas hasta el entretenimiento y la manufactura. ## "Democratizando" la IA: NIMs, microservicios en Kubernetes "para todos" En el centro de la visión de Huang se encuentra el concepto de **"NIM" - Nvidia Inference Microservices**. Estos modelos de IA preentrenados, que interactúan a través de sus APIs compatibles con Kubernetes, actúan como agentes especializados, cada uno experto en una tarea específica y orquestados como microservicios a través de Kubernetes, para que cada quien pueda "ensamblarlos" en base a sus propios objetivos o necesidades específicas. Según nVidia, al igual que el "software empaquetado" empoderó a una generación de usuarios de PC, los NIMS tienen como objetivo supuesto, "democratizar" la IA, permitiendo que las empresas y las personas aprovechen su poder sin necesidad de una profunda experiencia técnica. ¿Necesitas traducir idiomas, generar textos de marketing o analizar imágenes médicas? Es probable que haya un NIM para eso. Este enfoque modular permite la creación de sistemas de IA complejos mediante el ensamblaje de equipos de NIMS especializados, cada uno de los cuales aporta sus capacidades específicas para resolver un problema mayor. ## El Auge de la Fuerza Laboral de IA: Transformando el Servicio al Cliente y Más Allá Un sector listo para la disrupción de la IA es el servicio al cliente, una industria multimillonaria que se enfrenta a desafíos de eficiencia, personalización y también conocidos abusos laborales sistemáticos. Huang prevé agentes de IA, impulsados por modelos de lenguaje, capaces de comprender y responder a las consultas de los clientes con una velocidad y precisión "sin precedentes". Estos asistentes impulsados por IA no solo responderán preguntas; anticiparían "necesidades", ofrecerán "soluciones personalizadas" e incluso brindarán "apoyo emocional", lo que en última instancia conducirá a experiencias del cliente más satisfactorias y a una mayor eficiencia empresarial, pese a que leyendo entre líneas, hay una clara omisión a cómo se beneficiarían quienes actualmente trabajan en dicha industria, o en general de todos los trabajadores y sus desventajas frente a los gigantes propietarios que -al menos por ahora- son los únicos realmente beneficiados con este inevitable cambio de paradigma histórico. ## Más Allá de lo Humano: Humanos Digitales y el Futuro de la Interacción Mirando hacia el futuro, Huang nos ~~vende~~ , perdòn, nos presenta el concepto de "humanos digitales", entidades de IA capaces de participar en interacciones naturales y empáticas. Estos seres digitales, impulsados por modelos de lenguaje, dotados de *"inteligencia emocional"*, tienen el potencial de revolucionar la forma en que interactuamos con la tecnología. Imagina un asistente virtual que no solo administra tu agenda, sino que también te ofrece compañía, te brinda apoyo emocional o te enseña nuevas habilidades. (Hola, HAL-9000). ![Community Standards - meme](https://images3.memedroid.com/images/UPLOADED838/6180306a61189.jpeg) ## La Necesidad de Velocidad: Impulsando el Crecimiento Exponencial de la IA con Computación Acelerada Detrás de esta revolución de la IA se esconde una verdad fundamental: la IA prospera gracias a la potencia computacional. El entrenamiento de modelos de IA sofisticados, en particular los modelos de lenguaje extensos, requiere cantidades masivas de datos y potencia de procesamiento. Nvidia, líder en computación acelerada, juega un papel fundamental en este ecosistema, proporcionando la infraestructura de hardware y software necesaria para impulsar el crecimiento exponencial de la IA. Desde GPU de alto rendimiento hasta marcos de software especializados como CUDA, Nvidia se compromete a superar los límites de la computación, permitiendo a los investigadores y desarrolladores abordar desafíos de IA cada vez más complejos. ## Simulando la Realidad: Earth-2 y el Poder de los Datos Sintéticos Para ilustrar el potencial transformador de la IA, Huang destaca "Earth-2", un gemelo digital de nuestro planeta elaborado meticulosamente mediante simulaciones de IA. Este amb icioso proyecto tiene como objetivo modelar y predecir los efectos del cambio climático, permitiendo a los científicos probar estrategias de mitigación y prepararse para los desafíos futuros. Earth-2 ejemplifica la creciente importancia de los datos sintéticos en la IA, donde los algoritmos pueden aprender y evolucionar dentro de entornos virtuales, acelerando la investigación y el desarrollo en varios campos. ## El Futuro es Físico: la IA Abraza el Mundo Real Si bien gran parte del enfoque actual de la IA se centra en el ámbito digital, Huang destaca la importancia de la "IA basada en la física", una inteligencia artificial profundamente integrada con las leyes de la física y capaz de interactuar con el mundo físico. Esta próxima generación de IA no solo existirá en el éter digital; impulsará robots, vehículos autónomos e infraestructura inteligente, navegando y manipulando sin problemas el mundo que nos rodea. Imagina robots que no solo pueden ensamblar productos, sino también diseñar y construir a sus sucesores, o sistemas de IA que administren redes eléctricas, optimicen el flujo de tráfico o personalicen los tratamientos de atención médica en tiempo real. Este es el futuro de la IA, un futuro donde la línea entre lo digital y lo físico se vuelve cada vez más fluida. ## La Visión de Nvidia: Un Futuro Forjado por la Automatización Inteligente La visión de Huang para el futuro es clara: "Todo lo que se mueva se automatizará, será inteligente, estará impulsado por un sistema de IA". Este futuro, aunque potencialmente disruptivo, alberga una promesa inmensa. La IA, en opinión de Huang, tiene el potencial de liberarnos de tareas mundanas, desbloquear niveles de eficiencia sin precedentes y crear nuevas vías para la creatividad y la innovación. Nvidia, con su enfoque en la computación acelerada, tecnologías habilitadoras como CUDA y su compromiso de superar los límites de la investigación en IA, se posiciona como un actor clave en la configuración de este futuro emocionante impulsado por la IA. ## Un llamado a la Acción: Estudiar, Conocer y Divulgar el conocimiento abierto como la verdadera Revolución de la IA Generativa El mensaje de Jensen Huang es claro: la revolución de la IA generativa está aquí y es hora de abrazar su potencial transformador. A mi entender, todo es cierto mientras la tecnología sea abierta, libre y difundida, lo siga siendo y además no existan barreras de entrada a dicho conocimiento, como la concentración propietaria del hardware capaz de ejecutar dicha tecnología, a su vez el secretismo en que los grandes actores operan, sin ningún tipo de capacidad del resto de la humanidad de comprender, tampoco hacer responsables de las decisiones que toman sus dueños frente a todo el futuro de la humanidad o la capacidad de competir de forma sana, aunque existen atisbos como la iniciativa de Hugging Face para los proyectos open source. [🤗 Hugging Face Invierte $10 Millones en Democratizar la IA con GPUs GratuitasHugging Face, líder en aprendizaje automático, está destinando $10 millones en GPUs compartidas gratuitas para impulsar la innovación en IA y contrarrestar la centralización de esta tecnología en manos de gigantes tecnológicos. Esta iniciativa busca empoderar a desarrolladores independientes, académicos y startups, brindándoles las herramientas necesarias para competir en igualdad![](https://www.sredevops.org/content/images/2024/05/favicon.ico)SREDevOps.org - SRE, DevOps, Cloud, LinuxNicolás Georger![](https://www.sredevops.org/content/images/2024/05/Screenshot-2023-07-01-at-01.11.12.png)](https://www.sredevops.org/es/hugging-face-invierte-10-millones-en-democratizar-la-ia-con-gpus-gratuitas/) [NATURAL 20⚡LEARN AI. Join the AI Revolution. Improve your productivity and profits with AI![](https://assets.skool.com/skool/ed24268642ae417a9b8e3b9827cdd1fd.ico)![](https://assets.skool.com/f/2f19653641fa42198dc7d879d7acbf5e/e31f3af301994cdea70956438ac07e78880f0bdbb8674b3694c64cf1db043eb5)](https://www.skool.com/natural20/about?ref=sredevops.org) ### Faltando apenas alguns dias para a PlatformCon 2024, por que devo me registrar? O que ela pode fazer por mim? URL: https://www.sredevops.org/br/faltando-apenas-alguns-dias-para-a-platformcon-2024-por-que-devo-me-registrar-o-que-ela-pode-fazer-por-mim/ Last updated: 2024-06-03T13:16:48.000Z ## PlatformCon 2024: Mais que um hype, um mergulho no Platform Engineering Prepare-se! O PlatformCon 2024, um dos maiores eventos de Platform Engineering do mundo, rola de 10 a 14 de junho de 2024\. O evento será principalmente virtual, mas terá um ponto físico em Londres e alguns eventos satélite em outras cidades ao redor do mundo. Essa é a chance de se conectar com uma comunidade de feras em Platform Engineering e DevOps para discutir metodologias, trocar experiências, desvendar desafios e muito mais, te ajudando a construir plataformas realmente úteis. [Register for PlatformCon 2024Connect with fellow platform practitioners, learn from the best in the industry and engage directly with speakers on Slack.![](https://cdn.prod.website-files.com/6542483d1e2222ac4a899bdd/65490612ad61feab01ec5449_256x256-platformcon24-webclip.png)![](https://cdn.prod.website-files.com/6542483d1e2222ac4a899bdd/65e5f5d593595a337ac83d1c_PlatformCon%202024%20opengraph.jpg)](https://platformcon.com/register?ref=sredevops.org) Conecte-se com outros profissionais da área, aprenda com os melhores do mercado e interaja diretamente com os palestrantes no Slack. ### Precisa convencer seu chefe (ou a si mesmo :wink-wink:) de que essa não é mais uma conferência qualquer? A gente te dá alguns motivos - ou desculpas - para não perder o PlatformCon 2024. ### Platform Engineering: Hype ou a bola da vez? Afinal, o que é Platform Engineering? Em um artigo anterior aqui no SREDevOps.org, nós falamos sobre [O que é Platform Engineering? Para que serve? E o que aconteceu com o DevOps?](https://www.sredevops.org/es/que-es-platform-engineering-para-que-me-sirve-que-paso-con-devops/). Basicamente, o Platform Engineer assume três papéis: arquiteto técnico, facilitador de equipe e gerente de produto. Essa pegada multidisciplinar ajuda a acelerar, simplificar e facilitar os ciclos de desenvolvimento, tira um peso das costas dos desenvolvedores e permite que cada equipe esteja mais sincronizada com seus ciclos de deploy, entre outras vantagens. [O que é Engenharia de Plataforma? O que é isso para mim? O que aconteceu com o DevOps?Você tem ouvido e lido sobre Engenharia de Plataforma em toda a web ultimamente... mas nós realmente entendemos o que é Engenharia de Plataforma? Todos parecem convencidos e empolgados, mas você consegue ver como é diferente do DevOps? Tentaremos fazer um resumo geral com base no material que a Platform![](https://www.sredevops.org/content/images/2024/05/favicon.ico)SREDevOps.org - SRE, DevOps, Cloud, LinuxNicolás Georger![](https://images.unsplash.com/photo-1523961131990-5ea7c61b2107?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=M3wxMTc3M3wwfDF8c2VhcmNofDN8fGludGVncmF0aW9ufGVufDB8fHx8MTY4ODA5NDYzMXww&ixlib=rb-4.0.3&q=80&w=2000)](https://www.sredevops.org/br/o-que-e-engenharia-de-plataforma-o-que-e-isso-para-mim-o-que-aconteceu-com-o-devops/) Você provavelmente já viu o termo Platform Engineering pipocando por toda a internet ultimamente, mas será que realmente entendemos o que ele significa? Todo mundo parece estar empolgado, mas você consegue ver a diferença entre Platform Engineering e DevOps? No nosso artigo, tentamos dar uma visão geral com base em... Em 2024, vimos um boom de artigos e discussões sobre Platform Engineering, sua relação com DevOps e as principais considerações para turbinar ainda mais seus processos de desenvolvimento. Equipes, devs, SREs (entre outros) querem saber mais sobre o assunto, e essa conferência é o lugar perfeito para aprender com especialistas, entusiastas e se conectar com outras pessoas da comunidade internacional. Afinal, hype e curiosidade também são motivos válidos, não é? ### Aprenda com especialistas em Platform Engineering e DevOps Quer saber quem serão os palestrantes do PlatformCon 2024? Líderes da indústria como Kelsey Hightower (Kubernetes), Gregor Hohpe (autor de "Enterprise Integration Patterns"), Charity Majors (Honeycomb), Manuel Pais (autor de "Team Topologies"), Nicki Watt (Open Credo) e muitos outros vão te guiar pelos temas-chave da conferência. Aqui no SREDevOps.org, acreditamos que a melhor forma de aprender sobre novas tecnologias, metodologias e abordagens é através do compartilhamento de experiências entre a comunidade. É disso que se trata o PlatformCon. A conferência também oferece aos participantes acesso aos palestrantes através de canais do Slack. Uma ótima maneira de interagir com o mundo em constante evolução do Platform Engineering e aprender com os líderes da indústria. (Sim, também é um negócio, e não há nada de errado com isso, mas essa é outra história). [SchedulePlan your PlatformCon experience and stay up-to-date with our event schedule. Check out our Schedule page for information on keynote speakers, breakout sessions, and more.![](https://cdn.prod.website-files.com/6542483d1e2222ac4a899bdd/65490612ad61feab01ec5449_256x256-platformcon24-webclip.png)![](https://cdn.prod.website-files.com/6542483d1e2222ac4a899bdd/65c4bd15615264e7a3a7c5c3_PlatformCon%202024%20opengraph%20February.jpg)](https://platformcon.com/schedule?ref=sredevops.org) Planeje sua experiência no PlatformCon e fique por dentro da programação do evento. Acesse a página da agenda para informações sobre palestrantes principais, sessões paralelas e muito mais. ### Uma experiência personalizada: DevOps + Platform Engineering Como já mencionamos, o Platform Engineering é multidisciplinar e, com isso, as abordagens e práticas também são. As cinco seções da conferência destacadas abaixo buscam personalizar sua experiência em Platform Engineering. - **Histórias:** Aprenda com profissionais que estão construindo plataformas em suas organizações e receba dicas para sua própria implementação. - **Cultura:** Concentre-se nas relações entre desenvolvedores e equipes envolvidas no Platform Engineering: de DevOps e engenheiros de confiabilidade do site a arquitetos de software e muito mais. - **Ferramentas:** Mergulhe nos componentes técnicos das plataformas de desenvolvimento e descubra quais ferramentas e tecnologias os desenvolvedores estão usando para resolver problemas específicos. As conversas serão focadas em IaC, GitOps, Kubernetes e muito mais. - **Impacto:** Explore o lado comercial do Platform Engineering. Entenda as métricas-chave que os executivos de nível C medem e receba dicas sobre como obter apoio da liderança para construir uma plataforma de desenvolvimento. - **Blueprints:** Tenha a base para construir sua própria plataforma de desenvolvimento, cobrindo arquiteturas de referência importantes e considerações-chave de design. ### [Engage with Inspiring Speakers | PlatformCon TalksDiscover thought-provoking discussions and gain insights from industry experts at PlatformCon Talks. Join us now!![](https://cdn.prod.website-files.com/6542483d1e2222ac4a899bdd/65490612ad61feab01ec5449_256x256-platformcon24-webclip.png)PlatformCon TalksGregor HohpeEnterprise Strategist, AWS![](https://cdn.prod.website-files.com/6542483d1e2222ac4a899bdd/65c4bd15615264e7a3a7c5c3_PlatformCon%202024%20opengraph%20February.jpg)](https://platformcon.com/talks?ref=sredevops.org) ### Inscreva-se hoje mesmo para aperfeiçoar sua plataforma Aprenda mais sobre Platform Engineering e dê o próximo passo na criação de plataformas de desenvolvimento. [Register for PlatformCon 2024Connect with fellow platform practitioners, learn from the best in the industry and engage directly with speakers on Slack.![](https://cdn.prod.website-files.com/6542483d1e2222ac4a899bdd/65490612ad61feab01ec5449_256x256-platformcon24-webclip.png)![](https://cdn.prod.website-files.com/6542483d1e2222ac4a899bdd/65e5f5d593595a337ac83d1c_PlatformCon%202024%20opengraph.jpg)](https://platformcon.com/register?ref=sredevops.org) Conecte-se com outros profissionais da área, aprenda com os melhores do mercado e interaja diretamente com os palestrantes no Slack. ### A pocos días de PlatformCon 2024, por qué debería inscribirme? De qué me puede servir? URL: https://www.sredevops.org/es/a-pocos-dias-de-platformcon-2024-por-que-deberia-inscribirme-de-que-me-puede-servir/ Last updated: 2026-01-08T02:36:09.000Z PlatformCon 2024, uno de los eventos sobre *platform engineering* más grandes del mundo, se llevará a cabo del 10 al 14 de junio de 2024\. Principalmente será un evento virtual, pero también habrá un evento presencial en Londres, así como algunos eventos satélite en otras ciudades en el mundo. Este evento reúne a una comunidad activa de **profesionales influyentes en el ámbito de *platform engineering* y DevOps** para discutir metodologías, experiencias, desafíos y más, lo cual sirve para ayudarte a construir plataformas realmente útiles. [Register for PlatformCon 2024Connect with fellow platform practitioners, learn from the best in the industry and engage directly with speakers on Slack.![](https://cdn.prod.website-files.com/6542483d1e2222ac4a899bdd/65490612ad61feab01ec5449_256x256-platformcon24-webclip.png)![](https://cdn.prod.website-files.com/6542483d1e2222ac4a899bdd/65e5f5d593595a337ac83d1c_PlatformCon%202024%20opengraph.jpg)](https://platformcon.com/register?ref=sredevops.org) Si necesitas convencer a tu jefe *(o a ti mismo :wink-wink:)* de que esta no es una conferencia tìpica e inùtil? Te damos algunas razones -o excusas- para asistir a PlatformCon 2024. ## *Platform Engineering*: Hype? O algo más que moda geek? Entonces, ¿qué es *platform engineering*? En un artículo anterior en SREDevOps.org, hablamos sobre [Qué es Platform Engineering? Para qué me sirve? Qué pasó con DevOps?](https://www.sredevops.org/es/que-es-platform-engineering-para-que-me-sirve-que-paso-con-devops/) desde el cual podemos decir que el rol de un o una *platform engineer* es quién desempeña tres roles: arquitecto técnico, facilitador/habilitador de la comunidad o equipos y product manager. Este enfoque multidisciplina ayuda a acelerar, simplificar y facilitar los ciclos de desarrollo, quitar carga a los desarrolladores y permitir que cada equipo esté más sincronizado con sus ciclos de despliegue, entre otros.. [Qué es Platform Engineering? Para qué me sirve? Qué pasó con DevOps?¿Has estado escuchando y leyendo sobre Platform Engineering (ingeniería de plataformas) en toda la web últimamente... pero ¿realmente entendemos qué es Platform Engineering? Todo el mundo parece estar convencido y entusiasmado, pero ¿puedes ver en qué se diferencia de DevOps? Intentaremos dar un resumen general apoyándonos en el material que![](https://www.sredevops.org/content/images/2024/05/favicon.ico)SREDevOps.org - SRE, DevOps, Cloud, LinuxNicolás Georger![](https://images.unsplash.com/photo-1523961131990-5ea7c61b2107?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=M3wxMTc3M3wwfDF8c2VhcmNofDN8fGludGVncmF0aW9ufGVufDB8fHx8MTY4ODA5NDYzMXww&ixlib=rb-4.0.3&q=80&w=2000)](https://www.sredevops.org/es/que-es-platform-engineering-para-que-me-sirve-que-paso-con-devops/) En 2024, hemos visto un aumento en artículos y conversaciones sobre *platform engineering*, cómo se relaciona con DevOps y las principales consideraciones para optimizar aún más tus procesos de desarrollo. Los equipos, devs, SRE (entre otros) queremos saber más sobre esto, y ésta conferencia es el lugar perfecto para aprender de expertos, entusiastas y conectar con otras personas en la comunidad internacional. > *Bueno, el hype y la curiosidad también son ~~excusas~~* razones *válidas, no?* ## Aprende de expertos en *Platform Engineering* y DevOps **Quiénes serán los expositores en PlatformCon este 2024?** Líderes de la industria te ayudarán a comprender este ecosistema y en los temas clave de la conferencia, con nombres destacados, como **Kelsey Hightower (Kubernetes), Gregor Hohpe (autor de "Enterprise Integration Patterns"), Charity Majors (Honeycomb), Manuel Pais (autor de "Team Topologies"), Nicki Watt (Open Credo)** y muchos más. En SREDevOps.org, valoramos el intercambio de conocimientos entre pares y creemos que la mejor manera para que todos podamos aprender sobre nuevas iniciativas tecnológicas, metodologías y enfoques a prácticas existentes es a través de las experiencias compartidas entre las comunidades,, de las personas. De eso se trata PlatformCon. Esta conferencia también ofrece a los asistentes acceso a los oradores a través de canales de Slack. Una buena manera de interactuar con el mundo en constante evolución de *platform engineering,* aprender de los expertos que están liderando esta industria. (Si, también es un negocio, y eso no es nada malo de por si, pero eso es otro tema). [SchedulePlan your PlatformCon experience and stay up-to-date with our event schedule. Check out our Schedule page for information on keynote speakers, breakout sessions, and more.![](https://cdn.prod.website-files.com/6542483d1e2222ac4a899bdd/65490612ad61feab01ec5449_256x256-platformcon24-webclip.png)![](https://cdn.prod.website-files.com/6542483d1e2222ac4a899bdd/65c4bd15615264e7a3a7c5c3_PlatformCon%202024%20opengraph%20February.jpg)](https://platformcon.com/schedule?ref=sredevops.org) ## Una experiencia personalizada: DevOps + *Platform Engineering* Como mencionamos, *platform engineering* es multidisciplinaria, y con eso, también lo son los enfoques y prácticas. Las cinco secciones de la conferencia destacadas a continuación buscan personalizar tu experiencia en *platform engineering*. - **Historias:** Esta sección te permite aprender de los profesionales que están construyendo plataformas en sus organizaciones y te proporcionará consejos para tu propia adopción. - **Cultura:** Esta sección se enfoca en las relaciones entre todos los desarrolladores y equipos involucrados en *platform engineering*: desde DevOps e ingenieros de confiabilidad del sitio hasta arquitectos de software y más. - **Herramientas:** Esta sección se centra en los componentes técnicos de las plataformas de desarrollo y profundiza en qué herramientas y tecnologías utilizan los desarrolladores para resolver problemas específicos. Las conversaciones se enfocarán en IaC, GitOps, Kubernetes y más. - **Impacto:** Esta sección trata sobre el lado comercial de *platform engineering*. Se profundizará en las métricas clave que los ejecutivos de nivel C miden y ofrecerá consejos sobre cómo obtener el apoyo del liderazgo para construir una plataforma de desarrollo. - **Blueprints:** Esta sección te dará la base para construir tu propia plataforma de desarrollo, cubriendo importantes arquitecturas de referencia y consideraciones clave de diseño. [Engage with Inspiring Speakers | PlatformCon TalksDiscover thought-provoking discussions and gain insights from industry experts at PlatformCon Talks. Join us now!![](https://cdn.prod.website-files.com/6542483d1e2222ac4a899bdd/65490612ad61feab01ec5449_256x256-platformcon24-webclip.png)PlatformCon TalksGregor HohpeEnterprise Strategist, AWS![](https://cdn.prod.website-files.com/6542483d1e2222ac4a899bdd/65c4bd15615264e7a3a7c5c3_PlatformCon%202024%20opengraph%20February.jpg)](https://platformcon.com/talks?ref=sredevops.org) ## Regístrate hoy mismo para perfeccionar tu plataforma Aprender más sobre *platform engineering* y ayudar a determinar los mejores pasos a seguir en tu camino hacia la creación de plataformas de desarrollo. [Register for PlatformCon 2024Connect with fellow platform practitioners, learn from the best in the industry and engage directly with speakers on Slack.![](https://cdn.prod.website-files.com/6542483d1e2222ac4a899bdd/65490612ad61feab01ec5449_256x256-platformcon24-webclip.png)![](https://cdn.prod.website-files.com/6542483d1e2222ac4a899bdd/65e5f5d593595a337ac83d1c_PlatformCon%202024%20opengraph.jpg)](https://platformcon.com/register?ref=sredevops.org) ### LocalAI: Como Usar ChatGPT (e Muitos Outros Modelos) em Seus Próprios Computadores... E em Modo Cluster! URL: https://www.sredevops.org/br/localai-como-usar-chatgpt-e-muitos-outros-modelos-em-seus-proprios-computadores-e-em-modo-cluster/ Last updated: 2024-05-28T04:13:55.000Z > LocalAI v2.16.0: Avanços Significativos em IA Descentralizada para Usuários e Desenvolvedores A LocalAI lançou sua versão 2.16.0, trazendo recursos chave que impulsionam a execução de modelos de inteligência artificial (IA) de forma local e distribuída. Essa atualização marca um marco importante na democratização da IA, permitindo que usuários e desenvolvedores aproveitem modelos maiores e mais complexos sem depender exclusivamente de serviços em nuvem. ## Principais Novidades: - **Inferência Distribuída para Modelos de Maior Escala:** O LocalAI agora permite distribuir a carga de processamento de grandes modelos de IA em múltiplos dispositivos. Isso possibilita a execução de modelos mais sofisticados e melhora o desempenho geral. - **Redes Privadas P2P para IA:** O LocalAI introduz uma inovadora capacidade de processamento de IA entre pares (P2P). Os usuários podem criar redes privadas e seguras para compartilhar a carga de trabalho de IA, garantindo maior controle sobre os dados e a privacidade. - **Respostas Mais Inteligentes com Gramáticas Mistas:** Os modelos de IA do LocalAI agora podem compreender e gerar respostas mais diversas e estruturadas, combinando texto livre com dados formatados (listas, tabelas) para uma interação mais natural e informativa. - **Novos Modelos e Configuração Simplificada:** Foram adicionados novos modelos de IA, como Aya-35b, Mistral-0.3 e Hermes-Theta, e os existentes foram atualizados. Além disso, a implementação foi simplificada graças a um único binário que facilita a instalação e o gerenciamento. - **Correções e Melhorias de Desempenho:** O LocalAI corrigiu erros e otimizou o desempenho, incluindo a adoção de um novo sistema para backends de Python que agiliza o processamento. ## Por Que Essa Atualização é Relevante? - **Entusiastas de IA/ML:** O LocalAI facilita a experimentação com modelos potentes sem a necessidade de serviços caros em nuvem. - **Desenvolvedores:** Os novos recursos, como a inferência distribuída e as gramáticas mistas, abrem novas possibilidades para criar aplicações de IA personalizadas. - **Usuários Preocupados com a Privacidade:** A rede P2P oferece controle total sobre os dados e o processamento de IA. [Releases · mudler/LocalAI:robot: The free, Open Source OpenAI alternative. Self-hosted, community-driven and local-first. Drop-in replacement for OpenAI running on consumer-grade hardware. No GPU required. Runs gguf, trans…![](https://github.githubassets.com/assets/pinned-octocat-093da3e6fa40.svg)GitHubmudler![](https://opengraph.githubassets.com/f951cbafa7843054b4ab06c262629e69006736efa0f57805b3241a382274e007/mudler/LocalAI)](https://github.com/mudler/LocalAI/releases?ref=sredevops.org) > *Versión realizada con prompting y la ayuda de Google Gemini* ### LocalAI: Cómo usar ChatGPT (y muchos otros modelos) en tus propios computadores... ¡Y en modo cluster! URL: https://www.sredevops.org/es/localai-como-usar-chatgpt-y-muchos-otros-modelos-en-tus-propios-computadores-y-en-modo-cluster/ Last updated: 2026-01-08T02:36:27.000Z ## LocalAI v2.16.0: Avances significativos en IA descentralizada para usuarios y desarrolladores LocalAI ha lanzado su versión 2.16.0, presentando características clave que potencian la ejecución de modelos de inteligencia artificial (IA) de forma local y distribuida. Esta actualización marca un hito importante en la democratización de la IA, permitiendo a usuarios y desarrolladores aprovechar modelos más grandes y complejos sin depender exclusivamente de servicios en la nube. ### **Principales novedades:** 1. **Inferencia distribuida para modelos de mayor escala:** LocalAI ahora permite distribuir la carga de procesamiento de modelos de IA grandes en múltiples dispositivos. Esto posibilita la ejecución de modelos más sofisticados y mejora el rendimiento general. 2. **Redes privadas P2P para IA:** LocalAI introduce una innovadora capacidad de procesamiento de IA entre pares (P2P). Los usuarios pueden crear redes privadas y seguras para compartir la carga de trabajo de IA, garantizando mayor control sobre los datos y la privacidad. 3. **Respuestas más inteligentes con gramáticas mixtas:** Los modelos de IA de LocalAI ahora pueden comprender y generar respuestas más diversas y estructuradas, combinando texto libre con datos formateados (listas, tablas) para una interacción más natural e informativa. 4. **Nuevos modelos y configuración simplificada:** Se han añadido nuevos modelos de IA, como Aya-35b, Mistral-0.3 y Hermes-Theta, y se han actualizado los existentes. Además, la implementación se ha simplificado gracias a un único binario que facilita la instalación y gestión. 5. **Correcciones y mejoras de rendimiento:** LocalAI ha solucionado errores y optimizado el rendimiento, incluyendo la adopción de un nuevo sistema para backends de Python que agiliza el procesamiento. ![](https://www.sredevops.org/content/images/2024/05/Gemini_Generated_Image_vtm8z5vtm8z5vtm8.jpeg) ### **¿Por qué es relevante esta actualización?** - **Entusiastas IA/ML:** LocalAI facilita la experimentación con modelos potentes sin requerir costosos servicios en la nube. - **Desarrolladores:** Las nuevas funciones, como la inferencia distribuida y las gramáticas mixtas, abren nuevas posibilidades para crear aplicaciones de IA personalizadas. - **Usuarios preocupados por la privacidad:** La red P2P brinda control total sobre los datos y el procesamiento de IA. [Release v2.16.0 · mudler/LocalAIWelcome to LocalAI’s latest update! 🎉🎉🎉 woot woot! So excited to share this release, a lot of new features are landing in LocalAI!!!!! 🎉🎉🎉 🌟 Introducing Distributed Llama.cpp Inferencing Now it i…![](https://github.githubassets.com/assets/pinned-octocat-093da3e6fa40.svg)GitHubmudler![](https://opengraph.githubassets.com/46a278e447fd5cc279efe662a88e5d0790235947c7ed591d94961dcdf3754565/mudler/LocalAI/releases/tag/v2.16.0)](https://github.com/mudler/LocalAI/releases/tag/v2.16.0?ref=sredevops.org) ### 🤗 Hugging Face Investe $10 Milhões para Democratizar a IA com GPUs de Graça URL: https://www.sredevops.org/br/hugging-face-investe-10-milhoes-para-democratizar-a-ia-com-gpus-de-graca/ Last updated: 2024-05-25T23:24:16.000Z A Hugging Face, líder em aprendizado de máquina, está investindo $10 milhões em GPUs compartilhadas gratuitas para impulsionar a inovação em IA e combater a centralização dessa tecnologia nas mãos de gigantes da tecnologia. Essa iniciativa visa empoderar desenvolvedores independentes, acadêmicos e startups, fornecendo as ferramentas necessárias para competirem em igualdade de condições. ## O Desafio da Centralização da IA Clem Delangue, CEO da Hugging Face, expressou sua preocupação com a crescente concentração de poder no desenvolvimento de IA. Os avanços mais significativos, como o GPT-4 da OpenAI, os algoritmos do Google Search e o sistema Full Self-Driving da Tesla, permanecem ocultos dentro das grandes empresas. Essa situação não apenas limita a inovação, mas também cria uma barreira de entrada para novos players. ## A Visão da Hugging Face: Um Futuro Descentralizado A Hugging Face busca mudar esse paradigma ao fomentar uma abordagem de código aberto no desenvolvimento de IA. A empresa acredita que um futuro descentralizado, onde a IA esteja disponível para todos, é fundamental para evitar a concentração excessiva de poder. ## ZeroGPU: Democratizando o Acesso a GPUs Para alcançar esse objetivo, a Hugging Face lançou o programa ZeroGPU, que fornece acesso gratuito a GPUs compartilhadas através de sua plataforma Spaces. Essa iniciativa elimina a necessidade de cada usuário ter uma GPU dedicada, tornando-a mais econômica e energeticamente eficiente. ## Nivelando o Campo de Jogo O acesso a GPUs de alto desempenho é um gargalo importante no desenvolvimento de IA. O ZeroGPU utiliza dispositivos Nvidia A100, que oferecem um poder de computação significativo, para impulsionar projetos de IA de código aberto. Isso permite que desenvolvedores independentes e startups compitam com as grandes empresas que têm acesso a recursos computacionais massivos. ## O Impulso do Código Aberto Com esse investimento, a Hugging Face está liderando o caminho para um futuro onde a IA seja mais acessível e colaborativa. A empresa testemunhou o poder do código aberto no desenvolvimento de modelos de linguagem como o Llama da Meta, que gerou milhares de variações desde seu lançamento. Em resumo, o investimento da Hugging Face em GPUs gratuitas é um passo significativo para a democratização da IA. Ao fornecer acesso a recursos computacionais de ponta, a empresa está empoderando a comunidade de desenvolvedores e fomentando um futuro mais aberto e colaborativo para a inteligência artificial. ### 🤗 Hugging Face Invierte $10 Millones en Democratizar la IA con GPUs Gratuitas URL: https://www.sredevops.org/es/hugging-face-invierte-10-millones-en-democratizar-la-ia-con-gpus-gratuitas/ Last updated: 2026-01-08T02:36:10.000Z **Hugging Face, líder en aprendizaje automático, está destinando $10 millones en GPUs compartidas gratuitas para impulsar la innovación en IA y contrarrestar la centralización de esta tecnología en manos de gigantes tecnológicos.** Esta iniciativa busca empoderar a desarrolladores independientes, académicos y startups, brindándoles las herramientas necesarias para competir en igualdad de condiciones. ### El Desafío de la Centralización de la IA Clem Delangue, CEO de Hugging Face, expresó su preocupación por la creciente concentración del poder en el desarrollo de IA. Los avances más significativos, como GPT-4 de OpenAI, los algoritmos de Google Search y el sistema Full Self-Driving de Tesla, permanecen ocultos dentro de las grandes empresas. Esta situación no solo limita la innovación, sino que también crea una barrera de entrada para nuevos actores. ### La Visión de Hugging Face: Un Futuro Descentralizado Hugging Face busca cambiar este paradigma al fomentar un enfoque de código abierto en el desarrollo de IA. La empresa cree que un futuro descentralizado, donde la IA esté disponible para todos, es fundamental para evitar la concentración excesiva de poder. ### ZeroGPU: Democratizando el Acceso a GPUs Para lograr este objetivo, Hugging Face ha lanzado el programa ZeroGPU, que proporciona acceso gratuito a GPUs compartidas a través de su plataforma Spaces. Esta iniciativa elimina la necesidad de que cada usuario tenga una GPU dedicada, lo que la hace más rentable y eficiente energéticamente. ### Nivelando el Campo de Juego El acceso a GPUs de alto rendimiento es un cuello de botella importante en el desarrollo de IA. ZeroGPU utiliza dispositivos Nvidia A100, que ofrecen una potencia de cálculo significativa, para impulsar proyectos de IA de código abierto. Esto permite a los desarrolladores independientes y startups competir con las grandes empresas que tienen acceso a recursos computacionales masivos. ### El Impulso del Código Abierto Con esta inversión, Hugging Face está liderando el camino hacia un futuro donde la IA sea más accesible y colaborativa. La empresa ha sido testigo del poder del código abierto en el desarrollo de modelos de lenguaje como Llama de Meta, que ha generado miles de variaciones desde su lanzamiento. **En resumen, la inversión de Hugging Face en GPUs gratuitas es un paso significativo hacia la democratización de la IA.** Al proporcionar acceso a recursos computacionales de vanguardia, la empresa está empoderando a la comunidad de desarrolladores y fomentando un futuro más abierto y colaborativo para la inteligencia artificial. > Nota: El texto ha sido optimizado utilizando [Google Gemini.](https://gemini.google.com/app?ref=sredevops.org) Fuemte: [Hugging Face is sharing $10 million worth of compute to help beat the big AI companiesHugging Face is hoping to lower the barrier to entry for developing AI apps.![](https://www.theverge.com/icons/apple_touch_icon.png)The Verge![](https://cdn.vox-cdn.com/thumbor/YfbAPr5W2LWFBFrBB8Hk0JRgnUs=/0x0:2040x1360/1200x628/filters:focal(1017x848:1018x849)/cdn.vox-cdn.com/uploads/chorus_asset/file/25449118/STK267_HUGGING_FACE_E.jpg)](https://www.theverge.com/2024/5/16/24156755/hugging-face-celement-delangue-free-shared-gpus-ai?ref=sredevops.org) ### Kubernetes Gateway API v1.1: Service mesh, GRPCRoute e muito mais URL: https://www.sredevops.org/br/kubernetes-gateway-api-v1-1-service-mesh-grpcroute-e-muito-mais/ Last updated: 2025-08-17T21:01:14.000Z Após o lançamento GA do Gateway API em outubro passado, o Kubernetes SIG Network anuncia o lançamento da versão v1.1 do [Gateway API](https://gateway-api.sigs.k8s.io/?ref=sredevops.org). Neste lançamento, várias características passam a fazer parte do *Canal Padrão* (GA), incluindo o suporte para service mesh e GRPCRoute. Também introduzem algumas características novas e experimentais, como persistência de sessão e verificação de certificados de cliente. ## Novidades ### Passagem para o Canal Padrão Este lançamento inclui a passagem para o Canal Padrão de quatro características muito aguardadas. Isso significa que já não são conceitos experimentais; a inclusão no Canal Padrão denota um alto nível de confiança na API e proporciona garantias de compatibilidade. Claro, como qualquer outra API do Kubernetes, as características do Canal Padrão podem continuar evoluindo com adições retrocompatíveis e certamente virão mais refinamentos e melhorias para essas novas características no futuro. Para mais informações sobre como tudo isso funciona, consulte a [Política de Versionamento do Gateway API](https://gateway-api.sigs.k8s.io/concepts/versioning/?ref=sredevops.org). ![](https://gateway-api.sigs.k8s.io/images/release-channel-overlap.svg) ### [Suporte para Service Mesh](https://gateway-api.sigs.k8s.io/mesh/?ref=sredevops.org) O suporte para service mesh no Gateway API permite aos usuários utilizarem a mesma API para gerenciar o tráfego de entrada e o *tráfego de malha*, reutilizando as mesmas interfaces de política e roteamento. No Gateway API v1.1, as rotas (como HTTPRoute) agora podem ter um Serviço como `parentRef`, para controlar como o tráfego se comporta para serviços específicos. Para mais informações, leia a [documentação de service mesh do Gateway API](https://gateway-api.sigs.k8s.io/mesh/?ref=sredevops.org) ou consulte a [lista de implementações do Gateway API](https://gateway-api.sigs.k8s.io/implementations/?ref=sredevops.org#service-mesh-implementation-status). [Traefik v3.0 já está disponível e inclui suporte para Kubernetes Gateway API, WebAssembly e mais. Veja aqui como atualizar para a v3.0Este ano marca o nono aniversário do Traefik e hoje ele se tornou um dos gateways modernos mais utilizados, com mais de 3 bilhões de downloads e mais de 750 colaboradores. Está no Top 15 do DockerHub e tem 47.000 estrelas no GitHub. Aqui no SREDevOps.org, o Traefik![](https://sredevops.org/content/images/2024/05/favicon.ico)SREDevOps.org - SRE, DevOps, Cloud, LinuxNicolás Georger![](https://sredevops.org/content/images/2024/05/traefik-v3-announcement-image-1-1.png)](https://www.sredevops.org/br/traefik-v3-0-ja-esta-disponivel-e-inclui-suporte-para-kubernetes-gateway-api-webassembly-e-mais-veja-aqui-como-atualizar-para-a-v3-0/) Como exemplo, pode-se fazer um deployment Canary de uma workload com um HTTPRoute da seguinte maneira: ```yaml apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: color-canary namespace: faces spec: parentRefs: - name: color kind: Service group: "" port: 80 rules: - backendRefs: - name: color port: 80 weight: 50 - name: color2 port: 80 weight: 50 ``` Isso dividiria o tráfego enviado ao Serviço `color` no namespace `faces` 50/50 entre o Serviço `color` original e o Serviço `color2`, utilizando uma configuração portátil que é fácil de mover de uma malha para outra. ### [GRPCRoute](https://gateway-api.sigs.k8s.io/guides/grpc-routing/?ref=sredevops.org) Se você já está utilizando a versão experimental do GRPCRoute, recomendamos esperar antes de atualizar para a versão do canal padrão do GRPCRoute até que os controladores que você está utilizando tenham sido atualizados para suportar a versão v1 do GRPCRoute. Até lá, é seguro atualizar para a versão experimental do GRPCRoute em v1.1 que inclui as versões de API v1alpha2 e v1. ### [Porta em ParentReference](https://gateway-api.sigs.k8s.io/reference/spec/?ref=sredevops.org#gateway.networking.k8s.io%2fv1.ParentReference) Foi adicionado o campo `port` ao ParentReference, o que permite anexar recursos aos **GatewayListeners**, Serviços ou outros recursos principais (dependendo da implementação). Vincular a uma porta também permite anexar a múltiplos *Listeners* ao mesmo tempo. Por exemplo, você pode anexar um `HTTPRoute` a um ou mais `Listeners` específicos de um Gateway de acordo com o campo `port` do Listener, em vez do campo `name` do Listener. Para mais informações, consulte [Attach to Gateways.](https://gateway-api.sigs.k8s.io/api-types/httproute/?ref=sredevops.org#attaching-to-gateways) [HTTPRoute - Kubernetes Gateway API![](https://gateway-api.sigs.k8s.io/images/k8s-favicon.png)logo![](https://gateway-api.sigs.k8s.io/images/httproute-basic-example.svg)](https://gateway-api.sigs.k8s.io/api-types/httproute/?ref=sredevops.org#attaching-to-gateways) ### [Perfis e Relatórios de *Conformance*](https://gateway-api.sigs.k8s.io/concepts/conformance/?ref=sredevops.org#conformance-profiles) A API Conformance foi ampliada com o campo `mode` (destinado a especificar o modo da implementação) e o `gatewayAPIChannel` (padrão ou experimental). Tanto `gatewayAPIVersion` quanto `gatewayAPIChannel` agora são preenchidos automaticamente pela API Machinery, junto com uma breve descrição do resultado dos testes. Os Relatórios foram reorganizados de uma maneira mais estruturada, e as implementações agora podem adicionar informações sobre como os testes foram executados e fornecer passos de reprodução. ## Novas características no Canal Experimental ### [Verificação de Certificados de Cliente em Gateway](https://gateway-api.sigs.k8s.io/geps/gep-91/?ref=sredevops.org) Os Gateways agora podem configurar a verificação de certificados de cliente para cada Gateway`Listener, `através da introdução de um novo campo `frontendValidation` dentro de `tls`. Este campo suporta a configuração de uma lista de *Certificados CA* **(`Certificate Authority`)** que podem ser utilizados como um ponto de confiança para validar os certificados apresentados pelo cliente. ✅ **Exemplo de validação de certificado de cliente no Gateway** ```yaml apiVersion: gateway.networking.k8s.io/v1beta1 kind: Gateway metadata: name: my-gateway namespace: default spec: gatewayClassName: my-gateway-class listeners: - name: https protocol: HTTPS port: 443 tls: mode: Terminate certificateRefs: - name: example-cert options: group: example.com kind: TLSValidation name: validation frontendValidation: certificateRefs: - name: client-ca ``` ### [Persistência de Sessão](https://gateway-api.sigs.k8s.io/geps/gep-1725/?ref=sredevops.org) A persistência de sessão permite que os usuários controlem o comportamento de balanceamento de carga para sessões específicas, garantido que o tráfego seja roteado consistentemente para o mesmo backend. O campo `sessionAffinity` foi introduzido para `HTTPRoute` e `TLSRoute` com suporte inicial para afinidade baseada em cookies. ```yaml apiVersion: gateway.networking.k8s.io/v1beta1 kind: HTTPRoute metadata: name: example spec: rules: - matches: - path: value: "/" backendRefs: - name: foo port: 8080 sessionAffinity: cookie: name: my-cookie path: "/" maxAge: 3600 ``` Para mais informações, consulte a documentação de [persistência de sessão do Gateway API](https://gateway-api.sigs.k8s.io/concepts/persistencia-de-sess%C3%A3o/?ref=sredevops.org). ## Obrigado! Estamos empolgados com este novo lançamento do Gateway API e com a incrível comunidade que tornou isso possível. Para mais informações, consulte a documentação do [Gateway API](https://gateway-api.sigs.k8s.io/?ref=sredevops.org). ### Kubernetes Gateway API v1.1: Service mesh, GRPCRoute y mucho más URL: https://www.sredevops.org/es/kubernetes-gateway-api-v1-1-service-mesh-grpcroute-y-mucho-mas/ Last updated: 2026-01-08T02:36:04.000Z Después del lanzamiento GA de Gateway API el pasado octubre, Kubernetes SIG Network anuncia el lanzamiento de la versión v1.1 de [Gateway API](https://gateway-api.sigs.k8s.io/?ref=sredevops.org). En este lanzamiento, varias características pasan a formar parte del *Canal Estándar* (GA), incluyendo el soporte para service mesh y GRPCRoute. También introducen algunas características nuevas y experimentales, como persistencia de sesión y verificación de certificados de cliente. ## Novedades ### Paso al Canal Estándar Este lanzamiento incluye el paso al Canal Estándar de cuatro características muy esperadas. Esto significa que ya no son conceptos experimentales; la inclusión en el Canal Estándar denota un alto nivel de confianza en la API y proporciona garantías de compatibilidad. Por supuesto, como con cualquier otra API de Kubernetes, las características del Canal Estándar pueden seguir evolucionando con adiciones retrocompatibles y ciertamente vendrán más refinamientos y mejoras a estas nuevas características en el futuro. Para más información sobre cómo funciona todo esto, consulta la [Política de Versiones de Gateway API](https://gateway-api.sigs.k8s.io/concepts/versioning/?ref=sredevops.org). [Versioning - Kubernetes Gateway API![](https://gateway-api.sigs.k8s.io/images/k8s-favicon.png)logo![](https://gateway-api.sigs.k8s.io/images/release-channel-overlap.svg)](https://gateway-api.sigs.k8s.io/concepts/versioning/?ref=sredevops.org) #### [Soporte para Service Mesh](https://gateway-api.sigs.k8s.io/mesh/?ref=sredevops.org) El soporte para service mesh en Gateway API permite a los usuarios utilizar la misma API para gestionar el tráfico de entrada y el *tráfico de malla,* reutilizando las mismas interfaces de política y enrutamiento. En Gateway API v1.1, las rutas (como HTTPRoute) ahora pueden tener un Servicio como `parentRef`, para controlar cómo se comporta el tráfico a servicios específicos. Para más información, lee la [documentación de service mesh de Gateway API](https://gateway-api.sigs.k8s.io/mesh/?ref=sredevops.org) o consulta la [lista de implementaciones de Gateway API](https://gateway-api.sigs.k8s.io/implementations/?ref=sredevops.org#service-mesh-implementation-status). [Traefik v3.0 ya está disponible e incluye soporte para Kubernetes Gateway API, WebAssembly y más. Aquí puedes ver cómo actualizar a v3.0Este año se cumple el noveno aniversario de Traefik y hoy se convirtió en uno de los gateways modernos más utilizados, con más de 3 mil millones de descargas y más de 750 colaboradores. Está en el Top 15 de DockerHub y tiene 47.000 estrellas en GitHub. Aquí en![](https://www.sredevops.org/content/images/2024/05/favicon.ico)SREDevOps.org - SRE, DevOps, Cloud, LinuxNicolás Georger![](https://www.sredevops.org/content/images/2024/05/traefik-v3-announcement-image-1.png)](https://www.sredevops.org/es/traefik-v3-ya-esta-disponible-e-incluye-soporte-para-kubernetes-gateway-api-webassembly-y-mas-aqui-puedes-ver-como-actualizar-a-v3/) Como ejemplo, se podría hacer un despliegue Canary de una carga de trabajo (workload) con un HTTPRoute de la siguiente manera: ```yaml apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: color-canary namespace: faces spec: parentRefs: - name: color kind: Service group: "" port: 80 rules: - backendRefs: - name: color port: 80 weight: 50 - name: color2 port: 80 weight: 50 ``` Esto dividiría el tráfico enviado al Servicio `color` en el namespace `faces` 50/50 entre el Servicio `color` original y el Servicio `color2`, utilizando una configuración portátil que es fácil de mover de una malla a otra. ### [GRPCRoute](https://gateway-api.sigs.k8s.io/guides/grpc-routing/?ref=sredevops.org) Si ya estás utilizando la versión experimental de GRPCRoute, te recomendamos esperar antes de actualizar a la versión del canal estándar de GRPCRoute hasta que los controladores que estés utilizando hayan sido actualizados para soportar la versión v1 de GRPCRoute. Hasta entonces, es seguro actualizar a la versión experimental de GRPCRoute en v1.1 que incluye las versiones de API v1alpha2 y v1. ### [Puerto en ParentReference](https://gateway-api.sigs.k8s.io/reference/spec/?ref=sredevops.org#gateway.networking.k8s.io%2fv1.ParentReference) Se agregó el campo `port` a ParentReference, lo que permite adjuntar recursos a los **GatewayListeners**, Servicios u otros recursos principales (dependiendo de la implementación). Vincular a un puerto también permite adjuntar a múltiples *Listeners* a la vez. Por ejemplo, puedes adjuntar un `HTTPRoute` a uno o más `Listeners` específicos de un Gateway según el campo `port` del Listener, en lugar del campo `name` del Listener. Para más información, consulta [Attach to Gateways.](https://gateway-api.sigs.k8s.io/api-types/httproute/?ref=sredevops.org#attaching-to-gateways) [HTTPRoute - Kubernetes Gateway API![](https://gateway-api.sigs.k8s.io/images/k8s-favicon.png)logo![](https://gateway-api.sigs.k8s.io/images/httproute-basic-example.svg)](https://gateway-api.sigs.k8s.io/api-types/httproute/?ref=sredevops.org#attaching-to-gateways) ### [Perfiles y Reportes *Conformance*](https://gateway-api.sigs.k8s.io/concepts/conformance/?ref=sredevops.org#conformance-profiles) La API Conformance se ha ampliado con el campo `mode` (destinado a especificar el modo de la implementación) y el `gatewayAPIChannel` (estándar o experimental). Tanto `gatewayAPIVersion` como `gatewayAPIChannel` ahora se rellenan automáticamente por la API Machinery, junto con una breve descripción del resultado de las pruebas. Los Reportes se han reorganizado de una manera más estructurada, y las implementaciones ahora pueden agregar información sobre cómo se han ejecutado las pruebas y proporcionar pasos de reproducción. ## Nuevas características en el Canal Experimental ### [Verificación de Certificados de Cliente en Gateway](https://gateway-api.sigs.k8s.io/geps/gep-91/?ref=sredevops.org) Los Gateways ahora pueden configurar la verificación de certificados de cliente para cada Gateway`Listener, `mediante la introducción de un nuevo campo `frontendValidation` dentro de `tls`. Este campo admite la configuración de una lista de *Certificados CA* **(`Certificate Authority`)** que pueden utilizarse como un punto de confianza para validar los certificados presentados por el cliente. ✅ ****Ejemplo de validación de certificado de cliente en API Gateway:** Cómo un CACertificate almacenado en el ConfigMap `foo-example-com-ca-cert` se puede utilizar para validar los certificados presentados por los clientes que se conectan al Listener del Gateway `foo-https`. ```yaml apiVersion: gateway.networking.k8s.io/v1 kind: Gateway metadata: name: client-validation-basic spec: gatewayClassName: acme-lb listeners: name: foo-https protocol: HTTPS port: 443 hostname: foo.example.com tls: certificateRefs: kind: Secret group: "" name: foo-example-com-cert frontendValidation: caCertificateRefs: kind: ConfigMap group: "" name: foo-example-com-ca-cert ``` [Manage TLS Certificates in a ClusterKubernetes provides a certificates.k8s.io API, which lets you provision TLS certificates signed by a Certificate Authority (CA) that you control. These CA and certificates can be used by your workloads to establish trust. certificates.k8s.io API uses a protocol that is similar to the ACME draft. Note:Certificates created using the certificates.k8s.io API are signed by a dedicated CA. It is possible to configure your cluster to use the cluster root CA for this purpose, but you should never rely on this.![](https://kubernetes.io/icons/apple-touch-icon-256x256.png)Kubernetes![](https://kubernetes.io/images/kubernetes-horizontal-color.png)](https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/?ref=sredevops.org) ### [Persistencia de Sesión y BackendLBPolicy](https://gateway-api.sigs.k8s.io/geps/gep-1619/?ref=sredevops.org) [Persistencia de Sesión](https://gateway-api.sigs.k8s.io/reference/spec/?ref=sredevops.org#gateway.networking.k8s.io%2fv1.SessionPersistence) se está introduciendo en Gateway API a través de una nueva política ([BackendLBPolicy](https://gateway-api.sigs.k8s.io/reference/spec/?ref=sredevops.org#gateway.networking.k8s.io/v1alpha2.BackendLBPolicy)) para la configuración a nivel de Servicio y como campos dentro de `HTTPRoute` y `GRPCRoute` para la configuración a nivel de ruta. `BackendLBPolicy` y las API a nivel de ruta proporcionan la misma configuración de persistencia de sesión, incluyendo tiempos de espera, nombre de sesión, tipo de sesión y tiempo de vida de cookies. ✅ ****Ejemplo de** **`BackendLBPolicy`** **con persistencia de s** **esión** *basada en cookies* para el servicio `foo`: Establece el nombre de sesión en `foo-session`, define tiempos de espera (timeouts), y configura cookies como sesión: ```yaml apiVersion: gateway.networking.k8s.io/v1alpha2 kind: BackendLBPolicy metadata: name: lb-policy namespace: foo-ns spec: targetRefs: - group: core kind: service name: foo sessionPersistence: sessionName: foo-session absoluteTimeout: 1h idleTimeout: 30m type: Cookie cookieConfig: lifetimeType: Session ``` ### Más detalles y extras #### [Aclaraciones de Terminología TLS](https://gateway-api.sigs.k8s.io/geps/gep-2907/?ref=sredevops.org) Como parte de un objetivo más amplio de hacer que la terminología sobre TLS sea más coherente en toda la API, se han algunos cambios que rompen la compatibilidad en BackendTLSPolicy. Esto ha dado lugar a una nueva versión de API (v1alpha3) y requerirá que cualquier implementación existente de esta política maneje adecuadamente la actualización de versión, por ejemplo, haciendo una copia de seguridad de los datos y desinstalando la versión v1alpha2 antes de instalar esta nueva versión. Cualquier referencia a los campos de BackendTLSPolicy v1alpha2 deberá actualizarse a v1alpha3\. Los cambios específicos en los campos incluyen: - `targetRef` se convierte en `targetRefs` para permitir que un BackendTLSPolicy se adjunte a múltiples objetivos - `tls` se convierte en `validation` - `tls.caCertRefs` se convierte en `validation.caCertificateRefs` - `tls.wellKnownCACerts` se convierte en `validation.wellKnownCACertificates` Para obtener una lista completa de los cambios incluidos en este lanzamiento, consulta las [notas de lanzamiento de v1.1.0.](https://github.com/kubernetes-sigs/gateway-api/releases/tag/v1.1.0?ref=sredevops.org) ## Desarrollo de API Gateway La idea de Gateway API se propuso inicialmente [en KubeCon San Diego 2019](https://youtu.be/Ne9UJL6irXY?si=wgtC9w8PMB5ZHil2&ref=sredevops.org) como la próxima generación de la API Ingress. Desde entonces, se ha formado una increíble comunidad para desarrollar lo que probablemente se haya convertido en [la API más colaborativa en la historia de Kubernetes](https://www.youtube.com/watch?v=V3Vu%5FFWb4l4&ref=sredevops.org). Más de 200 personas han contribuido a esta API hasta ahora, y ese número sigue creciendo. > Los mantenedores quieren agradecer a *todos* los que han contribuido a Gateway API, ya sea en forma de commits al repositorio, discusiones, ideas o apoyo general. Literalmente no habríamos llegado tan lejos sin el apoyo de esta comunidad dedicada y activa. ## ¿Cómo utilizar y probar Kubernetes API Gateway fácil? A diferencia de otras APIs de Kubernetes, **no necesitas actualizar a la última versión de Kubernetes para obtener la última versión de Gateway API.** Siempre que estés ejecutando Kubernetes 1.26 o posterior, podrás ponerte en marcha con esta versión de Gateway API. ### Para probar la API, sigue la [Guía de Inicio Rápido](https://gateway-api.sigs.k8s.io/guides/?ref=sredevops.org): [Getting started - Kubernetes Gateway API![](https://gateway-api.sigs.k8s.io/images/k8s-favicon.png)logo![](https://gateway-api.sigs.k8s.io/images/logo/logo-text-large-horizontal-white.png)](https://gateway-api.sigs.k8s.io/guides/?ref=sredevops.org) ## Participa Hay muchas oportunidades para participar y ayudar a definir el futuro de las APIs de Kubernetes, tanto para `ingress` como para `service mesh`. - Revisa las [guías de usuario](https://gateway-api.sigs.k8s.io/guides?ref=sredevops.org) para ver qué casos de uso se pueden abordar. - Prueba uno de los [controladores de Gateway existentes](https://gateway-api.sigs.k8s.io/implementations/?ref=sredevops.org) (Recientemente publicamos sobre Traefik v3, que tiene soporte para APIGateway) [Traefik v3.0 ya está disponible e incluye soporte para Kubernetes Gateway API, WebAssembly y más. Aquí puedes ver cómo actualizar a v3.0Este año se cumple el noveno aniversario de Traefik y hoy se convirtió en uno de los gateways modernos más utilizados, con más de 3 mil millones de descargas y más de 750 colaboradores. Está en el Top 15 de DockerHub y tiene 47.000 estrellas en GitHub. Aquí en![](https://www.sredevops.org/content/images/2024/05/favicon.ico)SREDevOps.org - SRE, DevOps, Cloud, LinuxNicolás Georger![](https://www.sredevops.org/content/images/2024/05/traefik-v3-announcement-image-1.png)](https://www.sredevops.org/es/traefik-v3-ya-esta-disponible-e-incluye-soporte-para-kubernetes-gateway-api-webassembly-y-mas-aqui-puedes-ver-como-actualizar-a-v3/) - O [únete a la comunidad](https://gateway-api.sigs.k8s.io/contributing/?ref=sredevops.org) y colabora a construir el futuro de Kubernetes. **Fuente:** [Gateway API v1.1: Service mesh, GRPCRoute, and a whole lot moreFollowing the GA release of Gateway API last October, Kubernetes SIG Network is pleased to announce the v1.1 release of Gateway API. In this release, several features are graduating to Standard Channel (GA), notably including support for service mesh and GRPCRoute. We’re also introducing some new experimental features, including session persistence and client certificate verification. What’s new Graduation to Standard This release includes the graduation to Standard of four eagerly awaited features.![](https://kubernetes.io/icons/apple-touch-icon-256x256.png)Kubernetes![](https://kubernetes.io/blog/2024/05/09/gateway-api-v1-1/gateway-api-logo.svg)](https://kubernetes.io/blog/2024/05/09/gateway-api-v1-1/?ref=sredevops.org) ### Traefik v3.0 já está disponível e inclui suporte para Kubernetes Gateway API, WebAssembly e mais. Veja aqui como atualizar para a v3.0 URL: https://www.sredevops.org/br/traefik-v3-0-ja-esta-disponivel-e-inclui-suporte-para-kubernetes-gateway-api-webassembly-e-mais-veja-aqui-como-atualizar-para-a-v3-0/ Last updated: 2026-01-06T05:04:21.000Z Este ano marca o nono aniversário do Traefik e hoje ele se tornou um dos *gateways* modernos mais utilizados, com mais de 3 bilhões de downloads e mais de 750 colaboradores. Está no Top 15 do DockerHub e tem 47.000 estrelas no GitHub. **Aqui no SREDevOps.org, o Traefik é nosso IngressController favorito e já o utilizamos em nosso Cluster Kubernetes com k3s v1.29.4**. O Traefik 1.0 foi lançado em 2016\. Três anos depois, nasceu o Traefik 2.0\. Hoje, após 5 anos de desenvolvimento, o Traefik 3.0 está disponível para o público em geral 🎉 **O Traefik v3.0 é um grande passo adiante no mundo cloud native, adicionando suporte para as mais recentes tecnologias como WASM, OpenTelemetry, Kubernetes Gateway API e SPIFFE.** O registro de mudanças no Github é impressionante, com mais de 200 *pull requests* mesclados, cada um com novos recursos. A lista de novas possibilidades é tão grande que a [TraefikLabs publicará uma série de artigos em seu blog](https://traefik.io/blog/?ref=sredevops.org), cada um aprofundando um recurso. ## Como posso migrar do Traefik v2 para o v3? Uma nova *major version* é sempre algo muito aguardado: novo design, novos recursos, melhor experiência do usuário... Mas a desvantagem costuma ser a dor e os riscos da migração. Uma versão principal geralmente significa mudanças de última hora, mas isso não deveria implicar uma experiência de migração dolorosa, e com o **Traefik v3 é muito fácil migrar e atualizar**. O Traefik v3 inclui um processo de transição simplificado a partir do v2\. Como lembrete, o Traefik tem 2 tipos de configurações: ### A *configuração estática* que é carregada quando o Traefik é iniciado e gerencia as opções globais **Exemplo: Traefik + Kubernetes Ingress** ``` ## Static configuration ## Todas as opções: ## https://doc.traefik.io/traefik/providers/kubernetes-ingress/#provider-configuration providers: kubernetesIngress: namespaces: - "mynamespace" ``` ``` ## Exemplo de Kubernetes Ingress apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: myingress namespace: mynamespace annotations: # Traefik Entrypoint configurado na porta 80 traefik.ingress.kubernetes.io/router.entrypoints: web # Traefik Entrypoint configurado na porta 443 traefik.ingress.kubernetes.io/router.entrypoints: websecure spec: rules: - host: example.com http: paths: - path: /bar pathType: Exact backend: service: name: whoami port: number: 80 # Porta do serviço whoami - path: /foo pathType: Exact backend: service: name: whoami port: number: 80 # Porta do serviço whoami ``` ### A *configuração dinâmica* pode ser atualizada enquanto o Traefik está em execução e contém todas as regras de roteamento Foram feitas alterações mínimas em opções específicas da configuração estática, e é garantida a compatibilidade com a sintaxe do v2 na configuração dinâmica. Isso oferecerá uma mudança gradual para adotar a sintaxe v3, permitindo que os usuários migrem progressivamente seus *IngressResources* do Kubernetes, tags do Docker, etc. para o novo formato. ## Exemplo: Como migrar o Traefik do v2.11 para o v3.0 no Kubernetes ⚠️ Certifique-se de realizar este exemplo em um ambiente de teste. Pessoalmente, recomendo usar o [****Lima (Linux Machines) e k3s**](https://github.com/lima-vm/lima/blob/master/examples/k3s.yaml?ref=sredevops.org)****, compatível com macOS e Linux, de uso muito fácil e rápido.** ### Passo 1: Preparar e testar A primeira coisa a fazer é identificar como as mudanças feitas no v3 afetam sua configuração estática. As mudanças incompatíveis são mínimas e direcionadas a opções muito específicas. Em 90% dos casos de uso, esse processo deve levar apenas alguns minutos. **Alguns exemplos de mudanças incompatíveis:** | Recurso | Deprecated | Remoção | | -------------------------------------------------------- | ---------- | ------- | | Kubernetes CRD Provider API Version traefik.io/v1alpha1 | 3.0 | 4.0 | | Kubernetes Ingress API Version networking.k8s.io/v1beta1 | N/A | 3.0 | | CRD API Version apiextensions.k8s.io/v1beta1 | N/A | 3.0 | **Você também deve considerar:** - Docker e Swarm agora são 2 providers distintos - HTTP/3 não é mais uma opção experimental - Rancher v1 foi abandonado, pois o projeto não é mais mantido ativamente, etc. [Consulte a documentação sobre configuração estática](https://doc.traefik.io/traefik/migration/v2-to-v3/?ref=sredevops.org#static-configuration), bem como a seção de operações, para obter a lista completa e preparar sua nova configuração estática v3. **Adicione este snippet à sua configuração estática atual para usar a sintaxe v2 por padrão em seus recursos atuais que usam o Traefik:** ``` core: defaultRuleSyntax: v2 ``` Quando estiver pronto para testar, inicie o Traefik v3 com essa nova configuração. Se você não obtiver nenhum registro de erro, está tudo certo. Caso contrário, não há problema, as opções de migração restantes são explicadas nos logs do Traefik e você pode aplicá-las. Quando seu ambiente de teste não mostrar erros do Traefik no v3 e o acesso aos seus aplicativos, APIs, serviços, etc. estiver funcionando, você pode passar para a próxima etapa. ### Passo 2: Rolling Update Agora que você testou sua configuração estática atualizada, é hora de migrar progressivamente suas instâncias de produção para o Traefik v3\. Use o mecanismo de *rolling update* do Kubernetes para substituir gradualmente os Pods atuais pelos novos. ⚠️ Antes de ativar qualquer alteração na produção, certifique-se de ****ter monitoramento sobre o tráfego de entrada** para detectar instantaneamente qualquer problema. O Traefik é compatível com diferentes métodos de observabilidade, como ****OpenTelemetry, Prometheus e outros.** Enquanto a atualização contínua estiver em andamento, monitore constantemente o tráfego de entrada em busca de erros inesperados (ou incomuns), **e tenha um rollback preparado** para voltar à configuração funcional. Em seguida, aproveite o logging, registros de depuração e acesso do Traefik para entender e solucionar o problema antes de atualizar novamente. Caso não tenha certeza, consulte a documentação ou [comente em nosso Discord](https://discord.com/invite/bK9rXFTvpk?ref=sredevops.org). Depois que todos os pods forem atualizados... 🎉🎊🍾 você pode passar para a última etapa. ### Passo 3: Atualização Progressiva dos Ingresses Agora que você está executando o Traefik v3, comece a migrar seus *ingresses* para o novo formato. 📍 Lembre-se de que esta etapa pode ser feita posteriormente, pois o Traefik v3 é compatível com o formato v2 da **configuração dinâmica*. Mas, é claro, você pode começar a usar os novos recursos imediatamente nos novos **ingresses* e migrar os **ingresses* mais antigos depois. > A configuração dinâmica no v3 tem algumas mudanças. Por exemplo, os *Router Rule Matchers* têm uma sintaxe atualizada, o *Kubernetes Ingress API Group* foi modificado e a opção TCP LoadBalancer `terminationDelay` foi removida. A lista completa pode ser encontrada na seção de configuração dinâmica da documentação de migração. Progressivamente, altere cada roteador para a sintaxe v3, teste e atualize cada *IngressResource* e verifique se o tráfego de entrada não é afetado. Depois de validar a migração de um *IngressResource* v3, você pode remover o *IngressResource* v2 e implantar a versão v3\. Repita para cada *IngressResource*. No final do processo, você pode remover com segurança o snippet adicionado no passo 1: ``` core: defaultRuleSyntax: v2 ``` ...e pronto, você já está totalmente migrado para o Traefik v3 🎉! E você fez isso de forma progressiva, mantendo o controle durante todo o processo, com a opção de reverter qualquer alteração a qualquer momento. Este exemplo com Kubernetes pode ser feito em qualquer orquestrador ou ambiente, o processo permanece o mesmo. Em breve, publicaremos mais artigos sobre o suporte a WASM (e o plugin Web Application Firewall), OpenTelemetry, SPIFFE/Tailscale/HTTP/3 e Kubernetes Gateway API. ## Links úteis - Traefik 3.0 no [GitHub](https://github.com/traefik/traefik/releases/tag/v3.0.0?ref=sredevops.org) & no [DockerHub](https://hub.docker.com/%5F/traefik?ref=sredevops.org) - [Documentação do Traefik](https://doc.traefik.io/traefik/?ref=sredevops.org), [Site](https://traefik.io/?ref=sredevops.org), & [GitHub](https://github.com/traefik/traefik?ref=sredevops.org) - [Fórum da comunidade](https://community.traefik.io/?ref=sredevops.org) ### Traefik v3.0 ya está disponible e incluye soporte para Kubernetes Gateway API, WebAssembly y más. Aquí puedes ver cómo actualizar a v3.0 URL: https://www.sredevops.org/es/traefik-v3-ya-esta-disponible-e-incluye-soporte-para-kubernetes-gateway-api-webassembly-y-mas-aqui-puedes-ver-como-actualizar-a-v3/ Last updated: 2026-01-08T02:35:57.000Z Este año se cumple el noveno aniversario de Traefik y hoy se convirtió en uno de los *gateways* modernos más utilizados, con más de 3 mil millones de descargas y más de 750 colaboradores. Está en el Top 15 de DockerHub y tiene 47.000 estrellas en GitHub. **Aquí en SREDevOps.org, Traefik es nuestro IngressController favorito y ya lo utilizamos en nuestro Cluster Kubernetes con k3s v1.29.4**. Traefik 1.0 se lanzó en 2016\. Tres años después, nació Traefik 2.0\. Hoy, después de 5 años de desarrollo, Traefik 3.0 está generalmente disponible 🎉 **Traefik v3.0 es un gran paso adelante en el mundo cloud native, añadiendo soporte para las últimas tecnologías como WASM, OpenTelemetry, Kubernetes Gateway API y SPIFFE.** El registro de cambios en Github es impresionante, con más de 200 *pull requests* fusionados, cada uno con nuevas características. La lista de nuevas posibilidades es tan grande que desde [TraefikLabs publicarán una serie de artículos en su blog](https://traefik.io/blog/?ref=sredevops.org), cada uno profundizando en una característica. ## ¿Cómo puedo migrar desde Traefik v2 a v3? Una nueva *major version* siempre es algo muy esperado: nuevo diseño, nuevas funcionalidades, mejor experiencia de usuario... Pero la desventaja suele ser el dolor y riesgos de migrar. Una versión mayor a menudo significa cambios de última hora, pero eso no debería implicar una experiencia de migración dolorosa, y con **Traefik v3 es muy fácil migrar y actualizar**. Traefik v3, incluye un proceso de transición simplificado desde v2\. Como recordatorio, Traefik tiene 2 tipos de configuraciones: ### La *configuración estática* que se carga cuando Traefik se inicia y gestiona las opciones globales **Ejemplo: Traefik + Kubernetes Ingress** ```yaml ## Static configuration ## Todas las opciones: ## https://doc.traefik.io/traefik/providers/kubernetes-ingress/#provider-configuration providers: kubernetesIngress: namespaces: - "mynamespace" ``` ```yaml ## Ejemplo de Kubernetes Ingress apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: myingress namespace: mynamespace annotations: # Traefik Entrypoint configurado en puerto 80 traefik.ingress.kubernetes.io/router.entrypoints: web # Traefik Entrypoint configurado en puerto 443 traefik.ingress.kubernetes.io/router.entrypoints: websecure spec: rules: - host: example.com http: paths: - path: /bar pathType: Exact backend: service: name: whoami port: number: 80 # Puerto del servicio whoami - path: /foo pathType: Exact backend: service: name: whoami port: number: 80 # Puerto del servicio whoami ``` ### La *configuración dinámica* se puede actualizar mientras Traefik está en funcionamiento y contiene todas las reglas de routing Se han realizado cambios mínimos en opciones específicas de la configuración estática, y se asegura la compatibilidad con la sintaxis de la v2 en la configuración dinámica. Esto ofrecerá un cambio gradual para adoptar la sintaxis v3, permitiendo a los usuarios migrar progresivamente tus *IngressResources* de Kubernetes, Docker tags, etc. al nuevo formato. [Traefik V3 Migration Documentation | Traefik | v3.0Migrate from Traefik Proxy v2 to v3 and update all the necessary configurations to take advantage of all the improvements. Read the technical documentation.![](https://doc.traefik.io/traefik/v3.0/assets/images/logo-traefik-proxy-icon.svg)logo![](https://doc.traefik.io/traefik/v3.0/assets/images/logo-traefik-proxy-logo.svg)](https://doc.traefik.io/traefik/v3.0/migration/v2-to-v3/?ref=traefik.io#dynamic-configuration) ## Ejemplo: Cómo migrar Traefik de v2.11 a v3.0 en Kubernetes 💡 Asegurate de realizar este ejemplo en un entorno de pruebas. Personalmente recomiendo utilizar [****Lima (Linux Machines) y k3s**](https://github.com/lima-vm/lima/blob/master/examples/k3s.yaml?ref=sredevops.org)****, compatible con macOS y Linux de muy fácil y rápido uso.** ### Paso 1: Preparar y probar Lo primero que hay que hacer es identificar cómo afecta a tu configuración estática los cambios realizados en v3\. Los cambios incompatibles son mínimos y se dirigen a opciones muy específicas, en el 90% de los casos de uso, este proceso debería llevar un par de minutos solamente. **Algunos ejemplos de cambios incompatibles:** | Característica | Deprecated | Eliminación | | -------------------------------------------------------- | ---------- | ----------- | | Kubernetes CRD Provider API Version traefik.io/v1alpha1 | 3.0 | 4.0 | | Kubernetes Ingress API Version networking.k8s.io/v1beta1 | N/A | 3.0 | | CRD API Version apiextensions.k8s.io/v1beta1 | N/A | 3.0 | **También debes considerar:** - Docker y Swarm son ahora 2 providers distintos - HTTP/3 ya no es una opción experimental, - Rancher v1 ha sido abandonado ya que el proyecto ya no se mantiene activamente, etc. [Consulta la documentación sobre configuración estática](https://doc.traefik.io/traefik/migration/v2-to-v3/?ref=sredevops.org#static-configuration), así como la sección operaciones, para obtener la lista completa y preparar tu nueva configuración estática v3. [Traefik V3 Migration Documentation - TraefikMigrate from Traefik Proxy v2 to v3 and update all the necessary configurations to take advantage of all the improvements. Read the technical documentation.![](https://doc.traefik.io/traefik/assets/images/logo-traefik-proxy-icon.svg)logo![](https://doc.traefik.io/traefik/assets/images/logo-traefik-proxy-logo.svg)](https://doc.traefik.io/traefik/migration/v2-to-v3/?ref=sredevops.org#static-configuration) **Agrega este snippet a tu configuración estática actual, así utilizarás por defecto la sintaxis v2 en tus actuales recursos que utilizan Traefik:** ```yaml core: defaultRuleSyntax: v2 ``` Cuando estés listo para probar, inicia Traefik v3 con esta nueva configuración. Si no obtienes ningún registro de error, estás OK, de lo contrario, no hay problema, las opciones de migración restantes se explican en los logs de Traefik y puedes aplicarlos. Cuando tu entorno de prueba no muestre errores de Traefik en v3 y los accesos a tus aplicaciones, APIs, services, etc; funcionan, puedes pasar al siguiente paso. ### Paso 2: Rolling Update Ahora que has probado tu configuración estática actualizada, es el momento de migrar progresivamente tus instancias de producción a Traefik v3\. Utilice el mecanismo de *rolling update* de Kubernetes para reemplazar incrementalmente los Pods actuales por los nuevos. ⚠️ Antes de activar cualquier cambio en producción, asegurate de ****tener monitoreo sobre el tráfico de entrada** para detectar instantáneamente cualquier problema. Traefik es compatible con distintos métodos de observabilidad, como ****OpenTelemetry, Prometheus y otros.** Mientras la actualización continua está en curso, revisa constantemente el tráfico de entrada en busca de errores inesperados (o inusuales), **y ten preparado un rollback** para volver a la configuración funcional. Luego, aprovecha el logging, registros de depuración y acceso de Traefik para comprender y solucionar el problema antes de volver a actualizar. En caso de que no estés seguro, consulta la documentación o [comenta en nuestro Discord](https://discord.com/invite/bK9rXFTvpk?ref=sredevops.org). Una vez que todos los pods estén actualizados... 🎉🎊🍾 puedes pasar al último paso. ### Paso 3: Actualización Progresiva de Ingresses Ahora que ejecutas Traefik v3, comienza a migrar tus *ingress* al nuevo formato. 📍 Ten en cuenta que este paso se puede hacer más tarde, ya que Traefik v3 es compatible con el formato v2 de **configuración dinámica*. Pero, por supuesto, puede empezar a utilizar las nuevas características de inmediato en los nuevos **ingresses*, y migrar los **ingresses* más antiguos después. > La configuración dinámica en v3 tiene algunos cambios. Por ejemplo, los *Router Rule Matchers* tienen una sintaxis actualizada, se ha modificado *Kubernetes Ingress API Group* y se ha eliminado la opción TCP LoadBalancer `terminationDelay`. La lista completa se puede encontrar en la sección configuración dinámica de la documentación de migración. Progresivamente, cambia cada router a la sintaxis v3, prueba y actualiza cada *IngressResource* y comprueba que el tráfico de entrada no se ve afectado. Una vez validada la migración de un *IngressResource* v3, puedes eliminar el *IngressResource* v2 y desplegar la versión v3\. Repita por cada *IngressResource*. Al final del proceso, puedes eliminar con seguridad el snippet añadido en el paso 1: ```yaml core: defaultRuleSyntax: v2 ``` ...y listo, ya estás totalmente migrado a Traefik v3 🎉! Y lo has hecho de forma progresiva, manteniendo el control durante todo el proceso, con la opción de revertir cualquier cambio en cualquier momento. Este ejemplo con Kubernetes se puede hacer en cualquier orquestador o entorno, el proceso sigue siendo el mismo. Pronto publicaremos más artículos sobre el soporte a WASM (y el plugin Web Application Firewall), OpenTelemetry, SPIFFE/Tailscale/HTTP/3, y Kubernetes Gateway API. ## Enlaces útiles - Traefik 3.0 en [GitHub](https://github.com/traefik/traefik/releases/tag/v3.0.0?ref=sredevops.org) & en [DockerHub](https://hub.docker.com/%5F/traefik?ref=sredevops.org) - [Traefik Docs](https://doc.traefik.io/traefik/?ref=sredevops.org), [Página web](https://traefik.io/?ref=sredevops.org), & [GitHub](https://github.com/traefik/traefik?ref=sredevops.org) - [Foro de la comunidad](https://community.traefik.io/?ref=sredevops.org) Fuente: [Traefik 3.0 GA Has Landed: Here’s How to MigrateAfter 5 years of development, the wait is finally over: Traefik 3.0 is generally available! This article will focus on the beginning, the elephant in the room: the migration.![](https://traefik.io/favicon.svg)Traefik Labs: Say Goodbye to Connectivity ChaosEmile Vauge![](https://traefik.io/static/9e82ee5c495de1fd070a1c14e8a4f256/f3583/Traefik-3-GA-Has-Landed---Here-s-How-to-Migrate---Twitter.png)](https://traefik.io/blog/traefik-3-0-ga-has-landed-heres-how-to-migrate/?ref=sredevops.org) ### IBM continúa devorando: Hashicorp (Terraform) será su próxima adquisición URL: https://www.sredevops.org/es/ibm-continua-devorando-hashicorp-terraform-sera-su-proxima-adquisicion/ Last updated: 2026-01-08T02:36:12.000Z ### IBM lo confirma: Comprará HashiCorp En el mundo de la nube híbrida, se sabía que HashiCorp, creadores de la popular herramienta de infraestructura como código (IaC) Terraform, estaba buscando ser adquirida. También sabíamos que el cambio de la licencia Mozilla de código abierto de Terraform por la Business Source License (BSL 1.1) había dejado tras de sí a muchos desarrolladores y socios de Terraform descontentos. Esos usuarios de código abierto crearon un fork de Terraform llamado OpenTofu. OpenTofu despegó rápidamente, lo que provocó la intervención de los abogados. [OpenTF ahora es OpenTofu y es parte de Linux Foundation, ¡ya puedes usar el primer alpha!Hace poco te contábamos por qué Terraform estaba muerto -al menos para la comunidad Open Source-, el por qué es importante la confianza y la responsabilidad de todos los actores en el ecosistema de código abierto. Aquí puedes ver nuestra publicación de la muerte de Terraform. Vamos al grano Ya![](https://www.sredevops.org/content/images/size/w256h256/format/png/2023/10/SREDevOpsOrg-1.svg)SREDevOps.org - Comunidad SRE, DevOps, Cloud, LinuxNicolás Georger![](https://www.sredevops.org/content/images/2023/10/tofu-insurance.png)](https://www.sredevops.org/es/opentf-ahora-es-opentofu-y-es-parte-de-linux-foundation-ya-puedes-usar-el-primer-alpha/) Pero ese lío no impidió que IBM anunciara la compra de HashiCorp por 35 dólares por acción, lo que supone una prima de 6.400 millones de dólares. El presidente y consejero delegado de IBM, Arvind Krishna, anunció la adquisición en una conferencia financiera del primer trimestre. Krishna señaló: > "A medida que la IA generativa sigue evolucionando, la complejidad de las estrategias tecnológicas ha aumentado significativamente. El historial estelar de HashiCorp en la simplificación de esta moderna proliferación de infraestructuras les convierte en una incorporación ideal a la visión de nube híbrida de IBM." La adquisición de HashiCorp encaja perfectamente con la adquisición en 2019 por parte de IBM de Red Hat, potencia en Linux y en la nube. Desde un punto de vista técnico, Ansible y Terraform están bien adaptados para trabajar juntos. IBM espera claramente que HashiCorp Terraform y Vault, su gestor de secretos y cifrado, ayuden a fortalecer sus esfuerzos de nube híbrida y DevOps. El cofundador y CTO de HashiCorp, Armon Dadgar, está entusiasmado con la unión de fuerzas con IBM. "Esta fusión no es sólo una trayectoria de crecimiento para HashiCorp, sino una puerta de entrada para llevar soluciones avanzadas en la nube a un público más amplio, acelerando la innovación y la eficiencia empresarial en la gestión de la nube." El CEO de HashiCorp, Dave McJannet, se mostró de acuerdo. "El liderazgo y la rica historia de IBM en innovaciones de nube híbrida la convierten en el hogar perfecto para HashiCorp, ya que entramos en una fase vigorosa de nuestro crecimiento." Fuentes de IBM dicen que McJannet reportará a Rob Thomas, vicepresidente senior de IBM a cargo de software. La industria responde"Según nuestra investigación, más de seis herramientas son utilizadas por las organizaciones para apoyar la computación en nube y la automatización. La combinación de las carteras de productos de IBM, Red Hat y, potencialmente, HashiCorp sugiere cambios en la computación en nube y en el panorama general de la automatización", afirma Paul Nashawaty, jefe de prácticas de The Futurum Group. "Es una alianza de profesionales experimentados que va más allá de una simple fusión tecnológica para dar a las organizaciones las herramientas y conocimientos que necesitan para gestionar la compleja red de TI moderna con eficiencia y previsión." Mientras que a los inversores de HashiCorp parece haberles salido rentable la operación, a los de IBM no parece entusiasmarles tanto. En las primeras operaciones posteriores a la apertura del mercado, las acciones de IBM bajaron. Incluso antes de que apareciera el cambio a BSL 1.1, el crecimiento de los ingresos de HashiCorp se había ralentizado. Hay que señalar que, aunque los resultados de IBM fueron mediocres en la mayoría de los ámbitos, en la comunicación financiera se destacaron las noticias positivas en software. Krishna y el director financiero Jim Kavanaugh atribuyeron este crecimiento a Red Hat, especialmente a su plataforma de nube híbrida OpenShift y a su plataforma Ansible DevOps. Kavanaugh dijo: "Ambas ofertas también siguieron ganando cuota de mercado este trimestre". En concreto, los ingresos de Red Hat crecieron un 11*% interanual, con OpenShift creciendo más de un 40%.* Dejando de lado los aspectos comerciales por ahora, es una pregunta abierta lo que esto significará para Terraform y OpenTofu. ¿Regresará IBM Terraform a sus raíces de código abierto? ¿Intentará IBM, uno de los principales miembros de la Fundación Linux, unir a los bandos enfrentados? Permanezca atento. Va a ser un viaje lleno de baches. Fuente: [IBM Confirms: It’s Buying HashiCorp - DevOps.comEveryone knew HashiCorp was attempting to find a buyer. Few suspected it would be IBM.![](https://devops.com/wp-content/uploads/2021/10/android-chrome-256x256-1-254x254.png)DevOps.comSteven J. Vaughan-Nichols![](https://devops.com/wp-content/uploads/2024/04/pens-hamid-roshaan-CeoO3ph_w-E-unsplash.jpg)](https://devops.com/ibm-confirms-its-buying-hashicorp/?ref=sredevops.org) ### Un exploit en GitHub permitía inyectar archivos en -casi- cualquier repositorio y distribuir malware "legítimo" URL: https://www.sredevops.org/es/un-exploit-en-github-permitia-inyectar-archivos-en-casi-cualquier-repositorio-y-distribuir-malware-legitimo/ Last updated: 2026-01-08T02:36:37.000Z ## Una vulnerabilidad de seguridad en GitHub permitía a atacantes inyectar malware en repositorios legítimos. El atacante podría subir un archivo malicioso como comentario en un issue o pull request. Incluso si el comentario se eliminaba, el archivo malicioso seguía siendo accesible a través de una URL pública. Esto se debe a que la URL del archivo se generaba en base al nombre del repositorio y el nombre del archivo, y no requería que el comentario estuviera presente. Este exploit se podía utilizar para engañar a los usuarios para que descarguen malware que parecía provenir de una fuente confiable. Por ejemplo, un atacante podría subir un ejecutable malicioso al repositorio de instalación de drivers de un fabricante popular de tarjetas gráficas. El malware se podía disfrazar como un nuevo driver que soluciona problemas en un juego popular. Brodie Robertson, el creador del video, sugiere que GitHub debería implementar un escaneo más estricto de los archivos subidos a través de comentarios y pull requests. También sugiere que GitHub debería dificultarles a los atacantes la explotación de este tipo de vulnerabilidad cambiando la forma en que se generan las URL para los archivos. *Traducido con la ayuda de Google Gemini* ### O WebAssembly está pronto para a produção? WASI Preview 2 torna isso possível URL: https://www.sredevops.org/br/o-webassembly-esta-pronto-para-a-producao-wasi-preview-2-torna-isso-possivel/ Last updated: 2024-04-15T12:03:03.000Z > Resumo: > > O WebAssembly, ou Wasm, há muito tempo promete revolucionar o desenvolvimento de aplicativos. O sonho era simples, mas poderoso (e familiar): escrever seu código uma vez e fazê-lo funcionar em qualquer lugar. O Wasm também prometia executar o código em velocidades quase nativas. Melhor ainda, ao contrário das tentativas anteriores de tempos de execução universais, como o Java, o Wasm oferecia garantias de segurança mais altas e uma postura de segurança padrão de negação por padrão (o acesso aos recursos do sistema é desativado, a menos que seja orientado de outra forma por um desenvolvedor). > Até recentemente, a realidade do Wasm estava aquém de seu potencial prometido. Ainda faltavam as ferramentas e os recursos essenciais necessários para uma adoção mais ampla. No entanto, o WASI Preview 2 preencheu essas lacunas e abriu as portas para a adoção em massa do Wasm em ambientes de produção. > > O modelo de componente e o suporte a HTTP incorporados ao WASI Preview 2 simplificam determinados aspectos em comparação com o POSIX, tornando o WASI uma interface mais moderna e portátil para aplicativos da Web e de back-end. Com essa tecnologia, os desenvolvedores podem escolher bibliotecas de qualquer ecossistema ou linguagem, compilá-las como módulos e estruturá-las em um único aplicativo. Isso permite que as equipes de uma organização desenvolvam sistemas com a pilha de sua escolha e, em seguida, unifiquem seus componentes e módulos em um aplicativo monolítico. > > Não é difícil ver como o WASI Preview 2 transformou a possibilidade do futuro da Wasm. Essa tecnologia deve impulsionar um rápido aumento na adoção e na implementação do Wasm, o que beneficiará os desenvolvedores e os investidores em tecnologia de todo o mundo. O WASI Preview 2 é o ponto de inflexão que leva a uma era de desenvolvimento de software mais fácil, mais rápido e mais seguro para todos. ### Por que o WASI Preview 2 torna o WebAssembly pronto para a produção? O WebAssembly, ou Wasm, prometeu revolucionar o desenvolvimento de aplicativos. O sonho era simples, mas poderoso (e familiar): escrever seu código uma vez e fazê-lo funcionar em qualquer lugar. O Wasm também prometia executar o código em velocidades quase nativas. Melhor ainda, ao contrário das tentativas anteriores de tempos de execução universais, como o Java, o Wasm oferecia garantias de segurança mais altas e uma postura de segurança padrão de negação por padrão (o acesso aos recursos do sistema é desativado, a menos que seja orientado de outra forma por um desenvolvedor). Apesar do enorme potencial e da crescente comunidade, o Wasm não tinha as ferramentas, as interfaces e as APIs necessárias para torná-lo realmente pronto para a produção. Os desenvolvedores que quisessem usar o Wasm tinham que se tornar especialistas em Wasm, entrando em águas turvas e não documentadas, ou recorrer a empresas especializadas em Wasm, como a Cosmonic ou a Fermyon, que oferecem PaaS que simplificam a curva de aprendizado inicial. ### Mais do que uma prévia: estabilizando o modelo de componentes A WASI Preview 2, embora chamada de "prévia", é apenas no nome. O WASI Preview 2 é o elo perdido que a Wasm precisava para se tornar uma opção viável para casos de uso de produção. WASI, que significa WebAssembly System Interface, é um conjunto de padrões que define uma maneira padrão e segura de os módulos Wasm interagirem com os recursos do sistema. O WASI Preview 2 representa um marco significativo na evolução do Wasm porque fornece um padrão sólido a partir do qual os desenvolvedores podem construir com confiança, sabendo que toda a plataforma não terá alterações que envolvam refatoração ou incompatibilidades (semelhante ao controle de versão da API). Essa peça crucial do quebra-cabeça oferece uma maneira de compor módulos Wasm em componentes maiores, mesmo que tenham sido programados em linguagens diferentes. É um grande avanço em termos de flexibilidade e compatibilidade. O modelo de componente define uma IAB (interface de aplicativo binário) canônica que padroniza a maneira como os componentes se comunicam entre si e impede que eles acessem as memórias de outros componentes. Isso elimina os tipos mais comuns de bugs e vulnerabilidades de segurança. Outro aspecto importante do WASI Preview 2 é a estabilização das APIs. Isso garante a compatibilidade futura dos aplicativos Wasm, dando aos desenvolvedores a confiança necessária para construir sobre o Preview 2 sem se preocupar com futuros desastres. É análogo ao modo como o POSIX (Portable System Interface) padronizou as interfaces nos sistemas operacionais Unix, facilitando muito a criação de software "portátil". ### Além do 'POSIX para Wasm' Mas a WASI pretende ir além, incluindo interfaces para todas as coisas que não são necessariamente recursos do sistema. A WASI inclui o HTTP como uma interface de primeira classe, um recurso crítico de rede e conexão que não está presente no POSIX, oferecendo melhores opções para manter o controle do que um módulo pode fazer, em vez de lidar com ele como um soquete (é claro que você também pode fazer isso). Ele também simplifica alguns aspectos em comparação com o POSIX, o que torna o WASI Preview 2 uma interface mais moderna e portátil, tanto para aplicativos da Web quanto de back-end. As implicações práticas do WASI Preview 2 são enormes. Anteriormente, os desenvolvedores tinham dificuldades para criar aplicativos Wasm fora de sistemas especializados (como o PaaS, que mascarava a complexidade). A falta de APIs e ferramentas estáveis dificultava a confiança no Wasm como uma tecnologia pronta para a produção. Em resumo, ao criar aplicativos Wasm, agora você pode escolher bibliotecas (ou bibliotecas com nomes errados) de qualquer ecossistema ou linguagem, compilá-las como módulos e estruturá-las para criar um único aplicativo. As equipes da sua organização podem desenvolver os sistemas pelos quais são responsáveis com a pilha de sua escolha. Em seguida, por meio de componentes e módulos, os desenvolvedores e as equipes podem unificá-los em um aplicativo monolítico com a confiança de que as peças se encaixarão e se comportarão de maneira previsível. Até o momento, esse potencial tem sido contido por lacunas em ferramentas, estabilidade e recursos essenciais. O WASI Preview 2 preenche muito bem essas lacunas, abrindo caminho para que o Wasm cumpra sua promessa de facilidade de desenvolvimento em ambientes de produção. O WASI Preview 2 e o modelo de componentes devem impulsionar um rápido aumento na adoção e na implementação do Wasm. Acima de tudo, é um grande passo à frente que deve deixar qualquer desenvolvedor ou líder de tecnologia entusiasmado com o futuro do Wasm e incentivá-lo a colocar a mão na massa para criar aplicativos Wasm. O WASI Preview 2 deve ser esse ponto de inflexão para o Wasm. Ele tornará o desenvolvimento de software mais fácil, mais rápido e mais seguro para os desenvolvedores de todos os lugares. Adaptado do original de Oscar Spencer em The New Stack: [Why WASI Preview 2 Makes WebAssembly Production ReadyUntil recently, Wasm’s reality didn’t live up to the hype. Preview 2 is the missing link that Wasm needed to become viable for production use cases.![](https://thenewstack.io/favicon.ico)The New StackOscar Spencer![](https://cdn.thenewstack.io/media/2024/04/7ae76b9b-merging.png)](https://thenewstack.io/why-wasi-preview-2-makes-webassembly-production-ready/?ref=sredevops.org) ### WebAssembly listo para producción? WASI Preview 2 lo hace realidad URL: https://www.sredevops.org/es/webassembly-listo-para-produccion-wasi-preview-2-lo-hace-realidad/ Last updated: 2026-01-08T02:36:18.000Z > Resumen: > > WebAssembly, o Wasm para abreviar, ha prometido desde hace mucho tiempo revolucionar el desarrollo de aplicaciones. El sueño era simple pero poderoso (y familiar): escribe tu código una vez y hazlo funcionar en cualquier lugar. Wasm también prometió ejecutar código a velocidades cercanas a las nativas. Incluso mejor, a diferencia de intentos anteriores de runtimes universales como Java, Wasm ofreció garantías de seguridad más elevadas y una postura de seguridad predeterminada deny-by-default (el acceso a los recursos del sistema está deshabilitado a menos que un desarrollador lo indique de otra manera). > Hasta hace poco, la realidad de Wasm no alcanzó el potencial prometido. Las herramientas y características críticas necesarias para una adopción más amplia todavía faltaban. Sin embargo, WASI Preview 2 ha llenado esas brechas y ha abierto la puerta a la adopción masiva de Wasm en entornos de producción. > > El modelo de componentes y el soporte HTTP integrado en WASI Preview 2 simplifican ciertos aspectos en comparación con POSIX, haciendo que WASI sea una interfaz más moderna y portable para aplicaciones web y back-end. Con esta tecnología, los desarrolladores pueden elegir bibliotecas de cualquier ecosistema o lenguaje, compilarlas como módulos y estructurarlos en una sola aplicación. Esto permite que los equipos dentro de una organización desarrollen sistemas con el stack de su preferencia y luego unifiquen sus componentes y módulos en una aplicación monolítica. > > No es difícil ver cómo WASI Preview 2 ha transformado la posibilidad del futuro de Wasm. Esta tecnología debe impulsar un aumento rápido en la adopción y despliegue de Wasm, lo que beneficiará a desarrolladores e inversionistas tecnológicos alrededor del mundo. WASI Preview 2 es el punto de inflexión que lleva a una era de desarrollo de software más fácil, rápido y seguro para todos. ### **¿Por qué WASI Preview 2 hace que WebAssembly esté listo para producción?** WebAssembly, o Wasm para abreviar, ha prometido desde hace mucho tiempo revolucionar el desarrollo de aplicaciones. El sueño era simple pero poderoso (y familiar): escribe tu código una vez y hazlo funcionar en cualquier lugar. Wasm también prometió ejecutar código a velocidades cercanas a las nativas. Incluso mejor, a diferencia de intentos anteriores de runtimes universales como Java, Wasm ofreció garantías de seguridad más elevadas y una postura de seguridad predeterminada deny-by-default *(el acceso a los recursos del sistema está deshabilitado a menos que un desarrollador lo indique de otra manera)*. Hasta hace poco, la realidad de Wasm no cumplía con la promesa. A pesar del enorme potencial y la comunidad creciente, Wasm carecía de las herramientas, interfaces y APIs necesarias para que fuera verdaderamente apto para producción. Los desarrolladores que deseaban usar Wasm tenían que convertirse en expertos en Wasm, adentrándose en aguas oscuras y sin documentar o recurrir a empresas especializadas en Wasm como Cosmonic o Fermyon, que ofrecen PaaS simplificadoras de la curva inicial de aprendizaje. ### **Más que una vista previa: estabilizando el modelo de componente** WASI Preview 2, aunque se llame "vista previa", es sólo el nombre. WASI Preview 2 es el eslabón perdido que Wasm necesitaba para volverse una opción viable para casos de uso en producción. WASI, que significa "Interfaz de Sistema WebAssembly" (Inglés), es un conjunto de estándares que definen una manera estándar y segura para que los módulos Wasm interactúen con recursos de sistema. WASI Preview 2 representa un hito significativo en la evolución de Wasm porque provee un standard sólido desde el cual los desarrolladores pueden construir con confianza sabiendo que toda la plataforma no va a tener cambios que impliquen refactoring o incompatibilidades (similar a [API versioning](https://www.postman.com/api-platform/api-versioning/?ref=sredevops.org)). En el corazón de WASI Preview 2 se encuentra el Modelo de Componente WebAssembly. Esta pieza crucial del rompecabezas brinda una manera de componer módulos Wasm en componentes más grandes, incluso si fueron programados en diferentes lenguajes. Es un gran paso adelante en términos de flexibilidad y compatibilidad. El modelo de componentes define una IAB canónica (interfaz de aplicación binaria) que estandariza la manera en que los componentes se comunican entre sí y les impide acceder a las memorias de otros componentes. Esto elimina los tipos de errores y vulnerabilidades de seguridad más comunes. Otro aspecto clave de WASI Preview 2 es la estabilización de las API. Esto garantiza la compatibilidad en el futuro para aplicaciones Wasm, dando a los desarrolladores la confianza para construir encima de Preview 2 sin preocuparse por desastres futuros. Es análogo al modo en que POSIX (la Interfaz de Sistema Portátil) estandarizó las interfaces a través de sistemas operativos Unix, facilitando en gran medida la creación de software "portable". ### **Más allá de 'POSIX para Wasm'** Pero WASI tiene la intención de ir más allá, incluidas las interfaces para todas las cosas que no son necesariamente recursos de sistema. WASI incluye HTTP como una interfaz de primera clase, una capacidad de red y conexión crítica que no está presente en POSIX, brindando mejores opciones para mantener tracing de lo que un módulo está permitido hacer en lugar de manejarlo como un socket (por supuesto, también puedes hacer eso). También simplifica ciertos aspectos en comparación con POSIX que hacen que WASI Preview 2 sea una interfaz más moderna y portable — tanto para aplicaciones web como de back-end. Las implicaciones prácticas de WASI Preview 2 son enormes. Anteriormente, los desarrolladores lucharon por construir aplicaciones Wasm fuera de sistemas especializados (como PaaS que enmascaraban la complejidad). La falta de APIs y herramientas estables hizo difícil la confianza en Wasm como tecnología apta para producción. Preview 2 cambia todo eso, allanando el camino para una adopción más amplia, incluso mayoritaria, de Wasm. En resumen, cuando se construyen aplicaciones Wasm, ahora se pueden elegir bibliotecas (o mal llamadas librerías) de cualquier ecosistema o lenguaje, compilarlas como módulos y estructurarlos para hacer una sola aplicación. Los equipos dentro de su organización pueden desarrollar los sistemas de los que son responsables con el stack que prefieran. Luego, a través de componentes y módulos, los desarrolladores y equipos pueden unificarlos en una aplicación monolítica con la confianza de que las piezas encajarán y se comportarán de manera predecible. No hay duda de que Wasm siempre ha sido una tecnología con un enorme potencial. Hasta ahora, ese potencial ha sido frenado por brechas en las herramientas, la estabilidad y las características críticas. WASI Preview 2 llena esas brechas agradablemente, allanando el camino para que Wasm realice su promesa de amigabilidad con el desarrollador en entornos de producción. WASI Preview 2 y el modelo de componentes deben impulsar un aumento rápido en la adopción y el despliegue de Wasm. Por encima de todo, es un gran paso adelante que debería entusiasmar a cualquier desarrollador o líder tecnológico sobre el futuro de Wasm y alentarlos a ensuciarse las manos construyendo aplicaciones Wasm. Cada gran cambio tecnológico tiene un punto de inflexión que impulsa la adopción. WASI Preview 2 debería ser ese punto de inflexión para Wasm. Hará que desarrollar software sea más fácil, más rápido y más seguro para los desarrolladores en todas partes. *Adaptación del original por Oscar Spencer en The New Stack:* [Why WASI Preview 2 Makes WebAssembly Production ReadyUntil recently, Wasm’s reality didn’t live up to the hype. Preview 2 is the missing link that Wasm needed to become viable for production use cases.![](https://thenewstack.io/favicon.ico)The New StackOscar Spencer![](https://cdn.thenewstack.io/media/2024/04/7ae76b9b-merging.png)](https://thenewstack.io/why-wasi-preview-2-makes-webassembly-production-ready/?ref=sredevops.org) ### Kube-Bench: Chequea la seguridad de tus clusters Kubernetes URL: https://www.sredevops.org/es/kube-bench-chequea-la-seguridad-de-tus-clusters-kubernetes/ Last updated: 2026-01-08T02:36:02.000Z Kube-bench es una herramienta de código abierto que realiza una evaluación de seguridad completa de los entornos de Kubernetes. Es como el "Juramento Hipocrático" para Kubernetes, verificando todo lo posible contra las [mejores prácticas y benchmarks de CIS](https://www.cisecurity.org/cis-benchmarks?ref=sredevops.org) para asegurarse de que tu entorno esté lo más seguro posible. [CIS Benchmarks™CIS Benchmarks help you safeguard systems, software, and networks against today’s evolving cyber threats.![](https://www.cisecurity.org/dist/cisecurity/img/icons/apple-touch-icon.png)CIS![](https://www.cisecurity.org/-/media/project/cisecurity/cisecurity/data/media/img/uploads/2018/10/6.png?h=627&iar=0&w=1200&rev=ee7de3f0131f4917be21261baf18121e&hash=7FEA903120BA9E3926CAFDEF8D901327)](https://www.cisecurity.org/cis-benchmarks?ref=sredevops.org) Para entender por qué kube-bench es esencial, empecemos por reconocer que Kubernetes es increíblemente potente, pero también presenta desafíos de seguridad únicos. Como plataforma de orquestación de contenedores, Kubernetes ofrece mucha flexibilidad en cómo se pueden desplegar y administrar aplicaciones. Desafortunadamente, esta flexibilidad abre muchas oportunidades para que los atacantes exploten errores de configuración, dejando tus entornos [vulnerables a brechas de seguridad](https://kubernetes.io/docs/reference/issues-security/official-cve-feed/?ref=sredevops.org). [Official CVE FeedFEATURE STATE: Kubernetes v1.27 \[beta\] This is a community maintained list of official CVEs announced by the Kubernetes Security Response Committee. See Kubernetes Security and Disclosure Information for more details. The Kubernetes project publishes a programmatically accessible feed of published security issues in JSON feed and RSS feed formats. You can access it by executing the following commands: JSON feed RSS feed Link to JSON format curl -Lv https://k8s.io/docs/reference/issues-security/official-cve-feed/index.json Link to RSS format![](https://kubernetes.io/favicons/apple-touch-icon-180x180.png)Kubernetes![](https://kubernetes.io/images/kubernetes-horizontal-color.png)](https://kubernetes.io/docs/reference/issues-security/official-cve-feed/?ref=sredevops.org) Aquí es donde kube-bench entra en juego. Diseñado para escanear toda tu implementación de Kubernetes, incluyendo sus configuraciones, políticas de red y controles de acceso. La herramienta verifica luego estos aspectos contra una amplia [variedad de benchmarks en base a la distribución y versión de kubernetes (EKS, GKE, Rancher, k3s y otros)](https://github.com/aquasecurity/kube-bench/blob/main/docs/platforms.md?ref=sredevops.org) . Si encuentra alguna discrepancia o debilidad, lo resaltará en un informe fácil de entender. Uno de los aspectos más valiosos de kube-bench es que se actualiza constantemente para reflejar la última investigación de seguridad y desarrollos en Kubernetes. Esto asegura que tu entorno se mantenga al día con las mejores prácticas y estándares actuales, ayudando a reducir amenazas potenciales. La simplicidad de kube-bench es otro aspecto importante. Ofrece una interfaz de línea de comandos intuitiva que cualquier persona puede usar, independientemente de tu experiencia técnica. Los informes generados por kube-bench son fáciles de leer y entender, lo que permite a miembros no técnicos del equipo grasp la situación de seguridad de tu entorno de Kubernetes. Otra característica clave de kube-bench es tu capacidad para integrarse de manera sencilla con otras herramientas de tu cadena de herramientas de DevOps. Esto hace que sea fácil de automatizar las evaluaciones de seguridad como parte de tu flujo de trabajo de despliegue, asegurándose de que se realicen verificaciones de seguridad regularmente sin esfuerzo adicional. En resumen, Kubernetes ofrece muchos beneficios en cuanto a la implementación y gestión de aplicaciones, pero también presenta desafíos de seguridad únicos. Para mantenerse protegido contra las amenazas potenciales, herramientas como kube-bench son esenciales para identificar y abordar las debilidades en tu entorno antes de que los atacantes puedan explotarlas. Al utilizar kube-bench regularmente y mantenerse al día con sus últimas actualizaciones, puedes asegurar de que tu implementación de Kubernetes permanezca lo más segura posible en todo momento. ### Cómo utilizar kube-bench? Toda la documentación, la puedes encontrar en su [repositorio en Github](https://github.com/aquasecurity/kube-bench/blob/main/docs/index.md?ref=sredevops.org). [kube-bench/docs/installation.md at main · aquasecurity/kube-benchChecks whether Kubernetes is deployed according to security best practices as defined in the CIS Kubernetes Benchmark - aquasecurity/kube-bench![](https://github.githubassets.com/assets/pinned-octocat-093da3e6fa40.svg)GitHubaquasecurity![](https://opengraph.githubassets.com/a303d45d1f8d197663f40a8dc592b18ea4cc0ebf378a8ee30363a09918654e0d/aquasecurity/kube-bench)](https://github.com/aquasecurity/kube-bench/blob/main/docs/installation.md?ref=sredevops.org) ### Cultivando una cultura de observabilidad en DevOps con monitoreo de registros URL: https://www.sredevops.org/es/cultivando-una-cultura-de-observabilidad-en-devops-con-monitoreo-de-registros/ Last updated: 2026-01-08T02:36:38.000Z > Descubre el poder de la observabilidad DevOps con el monitoreo de registros (logs monitoring) eficaz y aprende a obtener una nueva comprensión de los sistemas, optimizar el rendimiento y establecer una estrategia DevOps de largo plazo. ## ¿Por qué el monitoreo de registros es clave para tu estrategia de observabilidad DevOps? El panorama DevOps está experimentando un aumento en la demanda de observabilidad. Se prevé que el mercado mundial de herramientas y plataformas de observabilidad alcance los 4.100 millones de dólares en 2028, [con una CAGR del 11,7%](https://www.marketsandmarkets.com/Market-Reports/observability-tools-and-platforms-market-69804486.html?ref=sredevops.org), lo que demuestra la creciente importancia de obtener una visión profunda de la salud y el rendimiento del sistema para una eficiencia DevOps óptima. En este entorno dinámico, el monitoreo de registros eficaz emerge como un pilar crucial para construir una sólida cultura DevOps de observabilidad. Este blog explorará cómo el monitoreo de registros te permite desbloquear un nuevo nivel de visibilidad del sistema, optimizar el rendimiento y lograr una estrategia DevOps de largo plazo. [What Is Log Monitoring? A Detailed Guide (Updated) | MiddlewareLog monitoring is critical for DevOps and developers as it provides insights into issues when and where it occurs. Here’s a detailed log monitoring guide![](https://middleware.io/favicon.ico)Middleware Logos![](https://middleware.io/wp-content/uploads/2022/08/log-monitoring.jpg)](https://middleware.io/blog/what-is-log-monitoring/?ref=sredevops.org) ## Las bases de la observabilidad DevOps: comprender la tríada MTL La observabilidad en DevOps se basa en un poderoso trío: métricas, trazas y registros (MTL), cada uno de los cuales ofrece una perspectiva única sobre la salud y el rendimiento de tu sistema. A continuación, encontrarás más detalles sobre cada elemento de la tríada MTL: ### Métricas (metrics) Las métricas son mediciones cuantitativas capturadas en intervalos regulares, lo que ofrece una visión general del estado de salud del sistema. Piensa en ellas como indicadores en el cuadro de instrumentos de un coche, que muestran información vital constantemente. Por ejemplo, un sitio web de comercio electrónico puede utilizar métricas para realizar un seguimiento del número de visualizaciones de páginas de productos por hora, el tiempo medio que tarda un carrito de la compra en pasar por el proceso de pago y el número de transacciones de pago correctas por minuto. Estas métricas proporcionan información sobre el comportamiento de los clientes, el rendimiento del sitio web y los posibles cuellos de botella en el proceso de pago. **Tipos de métricas:** - **Utilización de recursos:** utilización de CPU (%), consumo de memoria (MB), operaciones de E/S de disco por segundo (IOPS) - **Rendimiento:** latencia de las solicitudes API (milisegundos), tiempos de respuesta (segundos), número de transacciones procesadas por minuto - **Impacto empresarial:** tasa de conversión de clientes (%), tiempo de cumplimiento de pedidos (horas), número de usuarios activos ### **Trazas (traces)** Las trazas registran el recorrido detallado realizado por las solicitudes individuales a medida que viajan a través de tu sistema. Señalan la secuencia exacta de eventos para una acción específica. Por ejemplo, una traza puede seguir el proceso de un usuario que realiza un pedido en línea, registrando las interacciones con una base de datos de productos, un servicio de carrito de la compra y un sistema de procesamiento de pagos. **Tipos:** Las trazas pueden capturar información sobre: - Las llamadas de base de datos realizadas por una solicitud. - Las interacciones con otros servicios (p. ej., pasarelas de pago). - Los pasos de procesamiento dentro de tu aplicación. ### Registros (Logs) Los registros son mensajes de eventos generados por diversos componentes de tu sistema. Proporcionan datos ricos y textuales sobre lo que está sucediendo, incluidos errores, éxitos y actividad del usuario. Por ejemplo: Un registro de aplicación puede registrar un mensaje "El usuario X no ha podido iniciar sesión debido a una contraseña incorrecta", lo que ayuda a diagnosticar problemas de inicio de sesión. Hay diferentes categorías de registros, como: - Registros de aplicaciones: mensajes generados por tu software que detallan eventos y errores dentro del código. - Registros del sistema: mensajes de sistemas operativos o componentes de infraestructura, que registran eventos como reinicios de servicios o alertas de seguridad. - Registros de acceso: rastrean las acciones y solicitudes de los usuarios en tu aplicación (p. ej., intentos de inicio de sesión, llamadas API). Al comprender estas distinciones y utilizar todas las tres fuentes de datos (MTL), los equipos DevOps obtienen una visión completa de la salud de su sistema, lo que permite una resolución más rápida de problemas, la optimización del rendimiento y la prevención proactiva de problemas. ### **La potencia de MTL en conjunto** El verdadero poder de la observabilidad reside en la explotación de todos los tres elementos de la tríada MTL. Al combinar métricas, trazas y registros, se obtiene una comprensión completa de la salud y el rendimiento de tu sistema. Las métricas ofrecen una visión general a alto nivel, las trazas proporcionan datos de flujo de solicitudes detallados y los registros aportan un contexto rico para la resolución de problemas. Esta visión holística permite a los equipos DevOps: • Identificar y diagnosticar rápidamente los problemas. • Optimizar el rendimiento y la utilización de los recursos de la aplicación. • Detectar y prevenir de forma proactiva los problemas potenciales. • Obtener una comprensión más profunda del comportamiento del sistema y las interacciones de los usuarios. ## **Los beneficios de construir una cultura DevOps de observabilidad** Una fuerte cultura DevOps de observabilidad con un monitoreo de registros eficaz ofrece numerosas ventajas: • Tiempo de respuesta a incidentes mejorado: identificar y diagnosticar rápidamente los problemas analizando los datos de registro, lo que da lugar a tiempos de resolución más rápidos y reducción de las interrupciones. • Mejora del rendimiento del sistema: obtener información sobre los cuellos de botella de la aplicación y las ineficiencias de rendimiento a través del análisis de registros, lo que permite esfuerzos de optimización dirigidos. • Detección proactiva de problemas: aprovechar los datos de registro para identificar problemas potenciales antes de que se conviertan en incidentes críticos, fomentando la mantenimiento preventivo. • Mejora de la colaboración y la comunicación: visibilidad compartida del comportamiento del sistema a través de la gestión centralizada de registros, lo que fomenta una mejor colaboración entre los equipos de desarrollo y operaciones. ## **Cómo implementar estrategias de monitoreo de registros para la observabilidad DevOps** Aquí te mostramos cómo implementar un monitoreo de registros eficaz para una sólida cultura DevOps de observabilidad: • Elección de las herramientas adecuadas: selecciona una solución de monitoreo de registros que se integre sin problemas con tu ecosistema DevOps existente y ofrezca funciones como el monitoreo en tiempo real, la gestión centralizada de registros y los análisis avanzados. • Establecimiento de la gestión centralizada de registros: crea un repositorio central para todos tus registros, asegurando la recopilación, el almacenamiento y el análisis eficientes. • Normalización del formato de registros: implementa un formato de registro coherente en tus aplicaciones para simplificar el procesamiento y el análisis. • Definición de las políticas de retención de registros: determina las duraciones de almacenamiento de registros adecuadas en función de los requisitos de cumplimiento y las necesidades de solución de problemas. • Integración de registros con las prácticas de observabilidad más amplias: correlaciona los datos de registro con métricas y trazas para una visión holística del comportamiento del sistema. ## **Vencer los desafíos a la hora de establecer la observabilidad DevOps con el monitoreo de registros** Construir una cultura de observabilidad DevOps con éxito mediante el monitoreo de registros no está exento de desafíos. A continuación, encontrarás algunos desafíos comunes y estrategias para superarlos: **Escalabilidad y complejidad** A medida que tu sistema crece y genera más registros, gestionarlos se vuelve cada vez más difícil. Esto puede dar lugar a problemas de rendimiento a medida que el sistema lucha por manejar el volumen de datos. El almacenamiento de grandes cantidades de datos puede resultar costoso, especialmente con el almacenamiento en la nube. El análisis y la gestión manual de archivos de registro masivos son engorrosos y poco eficientes. **Solución:** Las herramientas de gestión de registros diseñadas para el manejo de grandes volúmenes de registros ofrecen funciones como el almacenamiento centralizado para una gestión y un acceso más sencillos, la indexación y la compresión para búsquedas más rápidas y una reducción de las necesidades de almacenamiento, y las alertas y los informes para un análisis más sencillo. **Agregación y filtrado de registros** La agregación y el filtrado de registros implican la recopilación de registros de diversas fuentes y la eliminación de información irrelevante para reducir el volumen general de datos que necesita ser almacenado y analizado, lo que mejora el rendimiento y la eficiencia. **Seguridad y privacidad de los datos** Los registros pueden contener información sensible como nombres de usuario, direcciones IP, datos financieros, información de seguridad o información propietaria. Si esta información cae en manos equivocadas, puede dar lugar a robo de identidad, pérdidas financieras, daños a la reputación o multas reglamentarias. **Solución:** La implementación de estrictos controles de acceso, como contraseñas fuertes, autenticación de múltiples factores y control de acceso basado en roles, restringe el acceso al personal autorizado. Las técnicas de anonimización de datos, como el tokenizado y el pseudonimizado, ocultan la información sensible dentro de los registros, lo que permite su análisis sin comprometer la privacidad del usuario. **Falta de personal cualificado** La capacidad de recopilar, analizar e interpretar los registros requiere una plantilla cualificada. La capacidad de recopilar, analizar e interpretar los registros es crucial para tareas como la resolución de problemas de sistemas, la supervisión de amenazas de seguridad y la optimización del rendimiento. Sin embargo, un desafío importante radica en la brecha entre el gran volumen de datos de registro generados y el reducido grupo de personal con la experiencia necesaria para gestionarlos. **Solución:** Invertir en programas de formación para equipar a los equipos de desarrollo y operaciones con habilidades de análisis de registros. Considera las certificaciones ofrecidas por plataformas líderes de monitoreo de registros. **Casos de éxito: ejemplificando el éxito de DevOps gracias al monitoreo de registros** Los ejemplos del mundo real demuestran el poder transformador del monitoreo de registros en DevOps: El conocido servicio de streaming Netflix atribuye su infraestructura altamente resistente y escalable a su enfoque basado en datos. Un elemento central de este enfoque es la agregación y el análisis meticulosos de registros. Al aprovechar una plataforma de registro centralizado, los ingenieros de Netflix pueden identificar y solucionar rápidamente los problemas, minimizando las interrupciones para sus millones de suscriptores. Puedes conocer el enfoque de Netflix en cuanto a la observabilidad en este artículo informativo. [Lessons from Building Observability Tools at NetflixOur mission at Netflix is to deliver joy to our members by providing high-quality content, presented with a delightful experience. We are…![](https://cdn-static-1.medium.com/_/fp/icons/Medium-Avatar-500x500.svg)Netflix TechBlogNetflix Technology Blog![](https://miro.medium.com/v2/resize:fit:860/1*qpKlpxWko8OSApsBq2FPRA.png)](https://netflixtechblog.com/lessons-from-building-observability-tools-at-netflix-7cfafed6ab17?ref=sredevops.org) El servicio de viajes en línea Expedia se enfrentó a desafíos en el rendimiento y la estabilidad de las aplicaciones, lo que afectó a la experiencia del cliente. Al implementar una solución de gestión de registros integral, Expedia obtuvo una visión en tiempo real del comportamiento de las aplicaciones. Esto le permitió identificar y abordar proactivamente los posibles problemas antes de que escalaran, lo que dio lugar a una mejora significativa en el tiempo de actividad de la aplicación y la satisfacción del cliente. [How Expedia Group built Database as a Service (DBaaS) offering using AWS Service Catalog | Amazon Web ServicesEnabling agile application development teams to self-serve and quickly provision the resources that they need while adhering to the organization’s governance and controls can be challenging. In this post, we’ll explore Expedia Group’s Cerebro platform, a Database as a Service (DBaaS) offering built on AWS technologies. By using this platform, Expedia Group is able to \[…\]![](https://a0.awsstatic.com/main/images/site/touch-icon-ipad-144-smile.png)Amazon Web Services![](https://d2908q01vomqb2.cloudfront.net/827bfc458708f0b442009c9c9836f7e4b65557fb/2020/06/03/Blog-Post_thumbnail.png)](https://aws.amazon.com/blogs/mt/how-expedia-group-built-database-as-a-service-dbaas-offering-using-aws-service-catalog/?ref=sredevops.org) Estos casos de estudio destacan los beneficios tangibles del monitoreo de registros eficaz en una cultura DevOps de observabilidad. Al implementar las mejores prácticas y aprender de ejemplos exitosos, puedes lograr mejoras similares en tu organización. ## **Cultivar una mentalidad DevOps: fomento de la colaboración y el aprendizaje** Una sólida cultura DevOps de observabilidad florece gracias a la colaboración y el aprendizaje continuos. A continuación, te mostramos cómo fomentar este estado mental: • Abraza una cultura de mejora continua: fomenta un estado mental de crecimiento en el que a los equipos se les anime a aprender de los datos de registro e iterar en las prácticas de monitoreo. • Promueve la colaboración transfuncional: rompe las barreras entre los equipos de desarrollo, operaciones y seguridad. Fomenta la compartición de conocimientos y la colaboración en torno al análisis de registros. • Invierte en la formación y el desarrollo de habilidades: equípate a tus equipos con las habilidades necesarias para aprovechar eficazmente el análisis de registros. Considera talleres y certificaciones específicas de tu plataforma de monitoreo de registros preferida. Al fomentar un entorno colaborativo y orientado al aprendizaje, tus equipos estarán equipados para optimizar continuamente su uso del análisis de registros, lo que dará lugar a una cultura DevOps más robusta y eficiente. ## **Tendencias futuras: el papel en evolución del monitoreo de registros en la observabilidad DevOps** El mundo de DevOps y la observabilidad está en continua evolución. A continuación, te ofrecemos una visión de futuro sobre el papel del monitoreo de registros en la observabilidad DevOps: • Tecnologías emergentes: la inteligencia artificial (IA) y el aprendizaje automático (ML) desempeñarán un papel cada vez más significativo en el análisis de registros, automatizando la detección de anomalías y la identificación de causas raíz. • El auge del monitoreo nativo de la nube: las soluciones de monitoreo de registros se integrarán aún más seamlessly con la infraestructura y las aplicaciones nativas de la nube. • Enfoque en la seguridad y el cumplimiento: las soluciones de monitoreo de registros ofrecerán cada vez más funciones avanzadas de privacidad de datos y cumplimiento reglamentario. Mantenerse informado sobre estas tendencias garantizará que tus prácticas DevOps sigan siendo a prueba de futuro. Al adaptarse a las tendencias emergentes de las herramientas de monitoreo de registros y aprovecharlas estratégicamente, podrás desbloquear aún más valor de tus esfuerzos de observabilidad DevOps. ## **Conclusión** El monitoreo de registros sirve como piedra angular para construir una sólida cultura DevOps de observabilidad. Al implementar estrategias eficaces de monitoreo de registros, puedes aprovechar el poder para responder a los incidentes de forma más rápida y minimizar las interrupciones y optimizar el rendimiento y la eficiencia del sistema de la aplicación. Aprovecha el poder de los datos de registro para construir un futuro DevOps más fuerte y eficiente para tu organización. ### Building a DevOps Culture of Observability with Log Monitoring URL: https://www.sredevops.org/en/building-a-devops-culture-of-observability-with-log-monitoring/ Last updated: 2026-01-07T20:41:40.000Z ### *Why Log Monitoring is Key to Your DevOps Observability Strategy* The DevOps landscape is witnessing a surge in the demand for observability. The global observability tools and platforms market is anticipated to balloon from USD 2.4 billion in 2023 to a staggering USD 4.1 billion by 2028, reflecting a[ CAGR of 11.7](https://www.marketsandmarkets.com/Market-Reports/observability-tools-and-platforms-market-69804486.html?ref=sredevops.org#:~:text=The%20global%20observability%20tools%20and%20platforms%20market%20is%20expected%20to,11.7%25%20during%20the%20forecast%20period.)%. This growth signifies the increasing importance of gaining deep insights into system health and performance for optimal DevOps efficiency. In this dynamic environment, effective [log monitoring](https://middleware.io/blog/what-is-log-monitoring/?ref=sredevops.org) emerges as a critical pillar for building a strong DevOps culture of observability. This blog will delve into how log monitoring empowers you to unlock a new level of system visibility, optimize performance, and achieve a future-proof DevOps strategy. ## **The Foundations of DevOps Observability: Understanding the MTL Triad** Observability in DevOps relies on a powerful trio—Metrics, Traces, and Logs (MTL), each providing a unique perspective into the health and performance of your system. Here are some more details about each element of the MTL triad: ### **Metrics** Metrics are quantitative measurements captured at regular intervals, offering a high-level view of system health. Imagine them as gauges on a car's dashboard, constantly displaying vital information. For example, an e-commerce website can use metrics to track the number of product page views per hour, the average time it takes for a shopping cart to checkout, and the number of successful payment transactions per minute. These metrics provide insights into customer behavior, website performance, and potential bottlenecks in the checkout process. **Types of Metrics:** - **Resource Utilization:** CPU utilization (%), memory consumption (MB), disk I/O operations per second (IOPS) - **Performance:** API request latency (milliseconds), response times (seconds), number of transactions processed per minute - **Business Impact:** Customer conversion rate (%), order fulfillment time (hours), number of active users ### **Traces:** Traces record the detailed path taken by individual requests as they travel through your system. They pinpoint the exact sequence of events for a specific action. For example, a trace might follow a user placing an order online, recording interactions with a product database, shopping cart service, and payment processing system. **Types:** Traces can capture information about: - Database calls are made by a request. - Interactions with other services (e.g., payment gateway). - Processing steps within your application. ### **Log** Logs are event messages generated by various components in your system. They provide rich, textual data about what's happening, including errors, successes, and user activity. Example: An application log might record a message "User X failed to login due to invalid password," which helps diagnose login issues. There are different categories of logs, such as: - **Application logs:** Messages generated by your software detailing events and errors within the code. - **System logs:** Messages from operating systems or infrastructure components, recording events like service restarts or security alerts. - **Access logs:** Track user actions and requests within your application (e.g., login attempts, API calls). By understanding these distinctions and using all three data sources (MTL), DevOps teams gain a comprehensive view of their system's health, allowing for faster troubleshooting, performance optimization, and proactive problem prevention. ### **The Power of MTL Together** The true power of observability lies in leveraging all three elements of the MTL triad. By combining metrics, traces, and logs, you gain a comprehensive understanding of your system's health and performance. Metrics provide a high-level overview, traces offer detailed request flow data, and logs deliver rich context for troubleshooting. This holistic view empowers DevOps teams to: - Quickly identify and diagnose issues. - Optimize application performance and resource utilization. - Proactively detect and prevent potential problems. - Gain deeper insights into system behavior and user interactions. ## **The Benefits of Building a DevOps Culture of Observability** A strong DevOps culture of observability with effective log monitoring offers numerous advantages: - **Improved incident response:** Quickly identify and diagnose issues by analyzing log data, leading to faster resolution times and reduced downtime. - **Enhanced system performance:** Gain insights into application bottlenecks and performance inefficiencies through log analysis, enabling targeted optimization efforts. - **Proactive problem detection:** Leverage log data to identify potential issues before they escalate into critical incidents, promoting preventative maintenance. - **Improved collaboration and communication:** Shared visibility into system behavior through centralized log management fosters better collaboration between development and operations teams. ## **Implementing Log Monitoring Strategies for Observability** Here's how to implement effective log monitoring for a strong DevOps culture of observability: - **Choosing the right tools:** Select a log monitoring solution that integrates seamlessly with your existing DevOps ecosystem and offers features like real-time monitoring, centralized log management, and advanced analytics. - **Setting up centralized log management:** Establish a central repository for all your logs, ensuring efficient collection, storage, and analysis. - **Standardizing log formatting:** Implement consistent log formatting across your applications to simplify parsing and analysis. - **Defining log retention policies:** Determine appropriate log storage durations based on compliance requirements and troubleshooting needs. - **Integrating logs with broader observability practices:** Correlate log data with metrics and traces for a holistic view of system behavior. ## **Overcoming Challenges in Establishing DevOps Observability with Log Monitoring** Building a successful DevOps observability culture with log monitoring isn't without its hurdles. Here are some common challenges and strategies to overcome them: ### **Scalability and Complexity** As your system grows and generates more logs, managing them becomes increasingly difficult. This can lead to performance issues as the system struggles to handle the data volume. Storing large amounts of data can become expensive, especially with cloud storage. Manually managing and analyzing massive log files is time-consuming and inefficient. **Solution:** Log management tools designed for handling large log volumes offer features like centralized storage for easier management and access, indexing and compression for faster searching and reduced storage needs, and alerting and reporting for easier analysis. Log aggregation and filtering involve collecting logs from various sources and filtering out irrelevant information to reduce the overall data volume that needs to be stored and analyzed, improving performance and efficiency. ### **Data Security and Privacy** Log data can contain sensitive information like usernames, IP addresses, financial data, security information, or proprietary information. If this data falls into the wrong hands, it can lead to identity theft, financial loss, reputational damage, or regulatory fines. **Solution:** Implementing strict access controls like strong passwords, multi-factor authentication, and role-based access control restricts access to authorized personnel only. Data anonymization techniques like tokenization and pseudonymization mask sensitive information within logs, allowing for analysis without compromising user privacy. ### **Lack of Skilled Personnel** Effectively utilizing the wealth of information contained within log data requires a skilled workforce. The ability to collect, analyze, and interpret logs is crucial for tasks like troubleshooting system issues, monitoring security threats, and optimizing performance. However, a significant challenge lies in the gap between the vast amount of log data generated and the limited pool of personnel with the necessary expertise to handle it. **Solution:** Invest in training programs to equip your development and operations teams with log analysis skills. Consider certifications offered by leading log monitoring platforms. ## **Case Studies: Exemplifying DevOps Success through Log Monitoring** Real-world examples showcase the transformative power of log monitoring in DevOps: Leading streaming service[ Netflix famously attributes](https://netflixtechblog.com/lessons-from-building-observability-tools-at-netflix-7cfafed6ab17?ref=sredevops.org) its highly resilient and scalable infrastructure to its data-driven approach. A core element of this approach is meticulous log aggregation and analysis. By leveraging a centralized logging platform, Netflix engineers can quickly identify and troubleshoot issues, minimizing downtime for their millions of subscribers. You can learn more about Netflix's approach to observability in this informative article. [Lessons from Building Observability Tools at NetflixOur mission at Netflix is to deliver joy to our members by providing high-quality content, presented with a delightful experience. We are…![](https://cdn-static-1.medium.com/_/fp/icons/Medium-Avatar-500x500.svg)Netflix TechBlogNetflix Technology Blog![](https://miro.medium.com/v2/resize:fit:860/1*qpKlpxWko8OSApsBq2FPRA.png)](https://netflixtechblog.com/lessons-from-building-observability-tools-at-netflix-7cfafed6ab17?ref=sredevops.org) Online travel booking giant Expedia faced challenges with application performance and stability, which impacted customer experience. By implementing a comprehensive log management solution,[ Expedia gained real-time visibility](https://aws.amazon.com/blogs/mt/how-expedia-group-built-database-as-a-service-dbaas-offering-using-aws-service-catalog/?ref=sredevops.org) into application behavior. This enabled them to proactively identify and address potential issues before they escalated, leading to a significant improvement in application uptime and customer satisfaction. [How Expedia Group built Database as a Service (DBaaS) offering using AWS Service Catalog | Amazon Web ServicesEnabling agile application development teams to self-serve and quickly provision the resources that they need while adhering to the organization’s governance and controls can be challenging. In this post, we’ll explore Expedia Group’s Cerebro platform, a Database as a Service (DBaaS) offering built on AWS technologies. By using this platform, Expedia Group is able to \[…\]![](https://a0.awsstatic.com/main/images/site/touch-icon-ipad-144-smile.png)Amazon Web Services![](https://d2908q01vomqb2.cloudfront.net/827bfc458708f0b442009c9c9836f7e4b65557fb/2020/06/03/Blog-Post_thumbnail.png)](https://aws.amazon.com/blogs/mt/how-expedia-group-built-database-as-a-service-dbaas-offering-using-aws-service-catalog/?ref=sredevops.org) These case studies highlight the tangible benefits of effective log monitoring within a DevOps culture of observability. By implementing best practices and learning from successful examples, you can achieve similar improvements in your organization. ## **Cultivating a DevOps Mindset: Encouraging Collaboration and Learning** A strong DevOps culture of observability thrives on collaboration and continuous learning. Here's how to cultivate this mindset: - **Embrace a culture of continuous improvement:** Foster a growth mindset where teams are encouraged to learn from log data and iterate on monitoring practices. - **Promote cross-functional collaboration:** Break down silos between development, operations, and security teams. Encourage knowledge sharing and collaboration around log analysis. - **Invest in training and upskilling:** Equip your teams with the necessary skills to leverage log monitoring effectively. Consider workshops and certifications specific to your chosen log monitoring platform. By fostering a collaborative and learning-oriented environment, your teams will be empowered to continuously optimize their use of log monitoring, leading to a more robust and efficient DevOps culture. ## **Future Trends: The Evolving Role of Log Monitoring in DevOps Observability** The world of DevOps and observability is constantly evolving. Here's a glimpse into the future of log monitoring: - **Emerging Technologies:** Artificial intelligence (AI) and machine learning (ML) will play an increasingly significant role in log analysis, automating anomaly detection and root cause identification. - **The Rise of Cloud-Native Monitoring:** Log monitoring solutions will become even more seamlessly integrated with cloud-native infrastructure and applications. - **Focus on Security and Compliance:** As data security concerns rise, log monitoring solutions will offer advanced features for data privacy and regulatory compliance. Staying informed about these trends will ensure your DevOps practices remain future-proof. By adapting to the evolving landscape of log monitoring tools and leveraging them strategically, you can unlock even greater value from your DevOps observability efforts. ## **Conclusion** Log monitoring serves as a cornerstone for building a robust DevOps culture of observability. By implementing effective log monitoring strategies, you gain the power to respond to incidents faster and minimize downtime and optimize system performance and application efficiency. Leverage the power of log data to build a stronger, more efficient DevOps future for your organization. ### Kubernetes v1.30: Un adelanto a las mejoras y cambios importantes que debes saber URL: https://www.sredevops.org/es/kubernetes-v1-30-un-adelanto-a-las-mejoras-y-cambios-importantes-que-debes-saber/ Last updated: 2026-01-08T02:36:30.000Z > ***Un adelanto de Kubernetes v1.30*** ## Una mirada rápida: cambios interesantes en Kubernetes v1.30 Es un nuevo año y una nueva versión de Kubernetes está en camino. Estamos a mitad del ciclo de lanzamiento y tenemos una gran cantidad de mejoras interesantes y emocionantes que llegarán en la v1.30\. Desde características completamente nuevas en fase alfa, hasta características establecidas que se gradúan a estables, y mejoras muy esperadas, ¡este lanzamiento tiene algo para que todos los entusiastas de Kubernetes, Linux y el cloud computing presten atención! Para mantenerte al tanto hasta el lanzamiento oficial, ¡aquí tienes un adelanto de las mejoras que más nos entusiasman en este ciclo! ## Cambios importantes para Kubernetes v1.30 ### Parámetros estructurados para la asignación dinámica de recursos (KEP-4381) [DRA: structured parameters · Issue #4381 · kubernetes/enhancementsEnhancement Description One-line enhancement description (can be used as a release note): The original dynamic resource allocation (DRA) uses claim and class parameters that are opaque to Kubernete…![](https://github.githubassets.com/assets/pinned-octocat-093da3e6fa40.svg)GitHubkubernetes![](https://opengraph.githubassets.com/3d768ec0cf53043413f3c0dda31c364b190a7fe16581335522bdf97071ae6f26/kubernetes/enhancements/issues/4381)](https://github.com/kubernetes/enhancements/issues/4381?ref=sredevops.org) La asignación dinámica de recursos se agregó a Kubernetes como una característica alfa en la v1.26\. Define una alternativa a la API tradicional de complementos de dispositivos para solicitar acceso a recursos de terceros. Por diseño, la asignación dinámica de recursos utiliza parámetros para recursos que son completamente opacos para el núcleo de Kubernetes. Este enfoque plantea un problema para el Cluster Autoscaler (CA) o cualquier controlador de nivel superior que necesite tomar decisiones para un grupo de pods. No puede simular el efecto de asignar o desasignar reclamaciones a lo largo del tiempo. Solo los controladores DRA de terceros tienen la información disponible para hacer esto. Los parámetros estructurados para la asignación dinámica de recursos son una extensión de la implementación original que aborda este problema al construir un marco para permitir que estos parámetros de reclamación sean menos opacos. En lugar de manejar la semántica de todos los parámetros de reclamación ellos mismos, los controladores podrían administrar los recursos y describirlos utilizando un "modelo estructurado" específico predefinido por Kubernetes. Esto permitiría a los componentes conscientes de este "modelo estructurado" tomar decisiones sobre estos recursos sin depender de algún controlador de terceros. Por ejemplo, el scheduler podría asignar reclamaciones rápidamente sin necesidad de una comunicación de ida y vuelta con los controladores de asignación dinámica de recursos. El trabajo realizado para este lanzamiento se centra en definir el marco necesario para habilitar diferentes "modelos estructurados" y en implementar el modelo de "recursos con nombre". Este modelo permite enumerar instancias de recursos individuales y, en comparación con la API tradicional de complementos de dispositivos, agrega la capacidad de seleccionar esas instancias individualmente a través de atributos. ### Soporte de intercambio de memoria (swap) en nodos (KEP-2400) [Node memory swap support · Issue #2400 · kubernetes/enhancementsEnhancement Description One-line enhancement description (can be used as a release note): Kubernetes nodes support swap memory. Kubernetes Enhancement Proposal: https://github.com/kubernetes/enhanc…![](https://github.githubassets.com/assets/pinned-octocat-093da3e6fa40.svg)GitHubkubernetes![](https://opengraph.githubassets.com/930fdb9daae6c127b451bfebf83dd8d04b8bfc7e52b0582c891eab3fdaac8ad0/kubernetes/enhancements/issues/2400)](https://github.com/kubernetes/enhancements/issues/2400?ref=sredevops.org) En Kubernetes v1.30, el soporte de intercambio de memoria (swap) en nodos Linux obtiene un gran cambio en la forma en que funciona, con un fuerte énfasis en mejorar la estabilidad del sistema. En versiones anteriores de Kubernetes, la puerta de enlace de características NodeSwap estaba deshabilitada de forma predeterminada y, cuando se habilitaba, utilizaba el comportamiento UnlimitedSwap como comportamiento predeterminado. Para lograr una mejor estabilidad, el comportamiento UnlimitedSwap (que podría comprometer la estabilidad del nodo) se eliminará en la v1.30. El soporte actualizado y aún en beta para el intercambio de memoria (swap) en nodos Linux estará disponible de forma predeterminada. Sin embargo, el comportamiento predeterminado será ejecutar el nodo configurado en modo NoSwap (no Unlimited Original: *Martes, 12 de marzo de 2024* **Autores:** Amit Dsouza, Frederick Kautz, Kristin Martin, Abigail McCarthy, Natali Vlatko Fuente: [A Peek at Kubernetes v1.30Authors: Amit Dsouza, Frederick Kautz, Kristin Martin, Abigail McCarthy, Natali Vlatko A quick look: exciting changes in Kubernetes v1.30 It’s a new year and a new Kubernetes release. We’re halfway through the release cycle and have quite a few interesting and exciting enhancements coming in v1.30\. From brand new features in alpha, to established features graduating to stable, to long-awaited improvements, this release has something for everyone to pay attention to!![](https://kubernetes.io/favicons/apple-touch-icon-180x180.png)Kubernetes![](https://kubernetes.io/images/favicon.png)](https://kubernetes.io/blog/2024/03/12/kubernetes-1-30-upcoming-changes/?ref=sredevops.org) ### Ya comienza KubeCon + CloudNativeCon Europe 2024, la versión geek de la peregrinación a "La Meca Cloud" URL: https://www.sredevops.org/es/ya-comienza-kubecon-cloudnativecon-europe-2024-el-evento-imprescindible-para-la-comunidad-cloud-native/ Last updated: 2026-01-08T02:36:18.000Z Del 20 al 22 de marzo de 2024, París se convertirá en el epicentro de la comunidad Cloud con la llegada de **KubeCon + CloudNativeCon Europe 2024**, el evento insignia de la Cloud Native Computing Foundation (CNCF). Durante estos tres días, la comunidad de adopters y tecnólogos de las principales comunidades de open source y cloud native se reunirá en la capital francesa para compartir conocimientos, experiencias y avances en este campo en constante evolución. KubeCon + CloudNativeCon Europe 2024 es una oportunidad única para sumergirse en el fascinante mundo de las tecnologías cloud native y descubrir cómo están transformando la forma en que desarrollamos, desplegamos y gestionamos aplicaciones. El evento contará con la participación de los proyectos graduados e incubados de la CNCF, que compartirán sus últimas novedades y mejores prácticas. Además, los asistentes podrán disfrutar de un completo programa de conferencias, talleres y sesiones de networking, donde podrán conectar con expertos de la industria, desarrolladores y entusiastas de la tecnología cloud native de todo el mundo. Ya sea que estés dando tus primeros pasos en el mundo de Kubernetes y las tecnologías cloud native, o que seas un experto en la materia, KubeCon + CloudNativeCon Europe 2024 tiene algo para ti. Podrás asistir a sesiones técnicas de alto nivel, participar en talleres prácticos y descubrir las últimas tendencias y mejores prácticas en el desarrollo y despliegue de aplicaciones cloud native. 💡 Puedes registrarte para ver el streaming aquí: [https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/?ref=sredevops.org) Además, el evento ofrecerá la oportunidad de conocer de primera mano los proyectos de la CNCF, como Kubernetes, Prometheus, Envoy y muchos otros, y descubrir cómo estas tecnologías están impulsando la innovación en empresas de todo el mundo. Si no puedes asistir en persona, no te preocupes. La CNCF ofrecerá una transmisión en vivo gratuita de las keynotes del 20 al 22 de marzo, para que puedas seguir el evento desde cualquier parte del mundo. No pierdas la oportunidad de ser parte de KubeCon + CloudNativeCon Europe 2024 y descubrir cómo las tecnologías cloud native están revolucionando la forma en que construimos y desplegamos aplicaciones. ¡Reserva tu plaza hoy mismo y únete a la comunidad cloud native en París! Para más detalles sobre el evento, visita el sitio web oficial: [KubeCon + CloudNativeCon Europe | LF EventsCNCF’s flagship conference gathers adopters & technologists from leading OS and cloud native communities for education and advancement of cloud native computing.![](https://events.linuxfoundation.org/wp-content/uploads/2023/09/Favicon_32x32.png)LF Events![](https://events.linuxfoundation.org/wp-content/uploads/2023/09/SocialSnackable_1200x628.png)](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/?ref=sredevops.org) CLo [https://events.linuxfoundation.org/kubecon-cloudn](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/?ref=sredevops.org) ### Ya puedes registrarte en PlatformCon 2024, entre el 10 y 14 de Junio 2024 URL: https://www.sredevops.org/es/ya-puedes-registrarte-en-platformcon-2024-entre-el-10-y-14-de-junio-2024/ Last updated: 2026-01-08T02:36:10.000Z PlatformCon 2024, es la cita virtual más importante del año para la comunidad e industrias alrededor de la Platform Engineering, DevOps, SRE y más. **Del 10 al 14 de junio**, prepárate para cinco días llenos de conocimiento, experiencias y networking con más de **17.000 ingenieros de plataformas** de todo el mundo. **En PlatformCon 2024 encontrarás:** - **Los mejores speakers de la industria:** Expertos de empresas como Google, Netflix, Spotify, Amazon y muchas más compartirán sus conocimientos y experiencias en charlas, talleres y paneles de discusión. - **Las últimas tendencias en DevOps e ingeniería de plataformas:** Descubre las tecnologías más innovadoras y las mejores prácticas para mejorar la eficiencia y la productividad de tu equipo. - **Oportunidades únicas de networking:** Conéctate con otros profesionales de la industria, comparte ideas y encuentra nuevas oportunidades de colaboración. **#PlatformCon #DevOps #IngenieríaDePlataformas #Latinoamérica** [Register for PlatformCon 2024Connect with fellow platform practitioners, learn from the best in the industry and engage directly with speakers on Slack.![](https://assets-global.website-files.com/6542483d1e2222ac4a899bdd/65490612ad61feab01ec5449_256x256-platformcon24-webclip.png)![](https://assets-global.website-files.com/6542483d1e2222ac4a899bdd/65c4bd15615264e7a3a7c5c3_PlatformCon%202024%20opengraph%20February.jpg)](https://platformcon.com/register?ref=sredevops.org) [Registrate en PlatformCon.com](https://platformcon.com/register?ref=sredevops.org) ![](https://www.sredevops.org/content/images/2024/01/platformcon-2024-2.png) ## PlaformCon 2024 10 - 14 de Junio 2024 [Registrate](https://platformcon.com/register?ref=sredevops.org) ### Adiós a WaveWorks, pioneros en GitOps y más URL: https://www.sredevops.org/es/adios-a-waveworks-pioneros-en-gitops-y-mas/ Last updated: 2026-01-08T02:36:27.000Z *En un movimiento que refleja la naturaleza volátil del panorama de las startups tecnológicas, *Weaveworks*, una vez un faro de innovación en el dominio de la gestión de *contenedores* nativos de la nube ("cloud native"), anunció el cese de sus operaciones.* El lunes, el CEO de Weaveworks anunció en una sorpresiva [**publicación en LinkedIn**](https://www.linkedin.com/posts/richardsonalexis%5Fhi-everyone-i-am-very-sad-to-announce-activity-7160295096825860096-ZS67?ref=sredevops.org) el cierre de la empresa. La historia de Weaveworks es un clásico ejemplo de una startup que lucha contra las **dinámicas del mercado** y las **limitaciones de capital**. A pesar de lograr un crecimiento de dos dígitos en 2023, la empresa enfrentó ventas "irregulares" y una **pista decreciente**, exacerbada por las **conversaciones de adquisición fallidas**, un escenario que muchas startups temen pero que algunas inevitablemente encuentran. ### Innovación en el espacio "cloud native" Fundada en 2014, una época en la que el término "cloud native" era más una palabra de moda que una realidad empresarial, Weaveworks se propuso con la ambición de dar forma al futuro de la gestión de infraestructura en la nube con su nuevo concepto: **GitOps**. Sin embargo, a pesar de su espíritu pionero y entrada temprana al mercado, la empresa luchó contra un enemigo demasiado común: la **sostenibilidad financiera**. ### **Weave GitOps**: Un sueño que no se concretó **Weave GitOps**, un paquete de software de código abierto destinado a agilizar el proceso de **entrega continua (CD)** de implementación de aplicaciones y actualizaciones desde un repositorio Git en clusters de **Kubernetes**, era la esperanza de la empresa para un mañana mejor. No iba a ser así. ### Competencia y capitalización La competencia en el espacio "cloud native" se ha intensificado a lo largo de los años, con rivales como **CircleCI** y **Harness Labs**, atrayendo atención y financiación. La lucha de Weaveworks contra estos competidores mejor capitalizados subraya las duras realidades del ecosistema de startups, donde la innovación por sí sola no garantiza el éxito. ### **Financiamiento insuficiente** A lo largo de su existencia, Weaveworks recaudó más de $61 millones de dólares. Pero, su última ronda de financiación en 2020 ascendió a US$36 millones. Eso estuvo bien, pero cuatro años es una eternidad en el mundo del **capital de riesgo**. A medida que la economía entró en recesión en 2022, la empresa, como muchas otras, se encontró primero incapaz de obtener más inversiones y luego no logró llegar a una **fusión** que le hubiera dado un camino a seguir. ### Lecciones aprendidas El cierre de Weaveworks es un recordatorio de los desafíos que enfrentan las startups en el competitivo mercado actual. Incluso con un equipo talentoso y un producto innovador, el éxito no está garantizado. La **falta de financiamiento**, la **competencia feroz** y las **condiciones económicas cambiantes** pueden allanar el camino hacia el fracaso. Las startups que buscan tener éxito en el futuro deben ser conscientes de estos desafíos y estar preparadas para adaptarse a las cambiantes condiciones del mercado. La **gestión financiera prudente**, la **estrategia de marketing sólida** y la **capacidad de pivotar** cuando sea necesario serán fundamentales para la supervivencia. Fuente: [https://thenewstack.io/end-of-an-era-weaveworks-closes-shop-amid-cloud-native-turbulence/](https://thenewstack.io/end-of-an-era-weaveworks-closes-shop-amid-cloud-native-turbulence/?ref=sredevops.org) [End of an Era: Weaveworks Closes Shop Amid Cloud Native TurbulenceAlexis Richardson, CEO and co-founder of Weaveworks, took to LinkedIn to share the somber news of the company’s closing.![](https://thenewstack.io/favicon.ico)The New StackSteven J. Vaughan-Nichols![](https://cdn.thenewstack.io/media/2024/02/264bbdf7-weaveworks.png)](https://thenewstack.io/end-of-an-era-weaveworks-closes-shop-amid-cloud-native-turbulence/?ref=sredevops.org) ### Qué esperar sobre Kubernetes este 2024? Fairwind presenta "2024 Kubernetes Benchmark Report", aquí un resumen URL: https://www.sredevops.org/es/que-esperar-sobre-kubernetes-este-2024-fairwind-presenta-2024-kubernetes-benchmark-report-aqui-un-resumen/ Last updated: 2026-01-08T02:36:30.000Z ### Puntos clave: - **La adopción de Kubernetes sigue creciendo**, lo que permite a las organizaciones automatizar el despliegue, la administración y el escalado de aplicaciones en contenedores. - **Los equipos de DevOps, ingeniería de plataformas y desarrollo se centran cada vez más en la estabilidad, la seguridad y la rentabilidad de sus cargas de trabajo.** - **Fairwinds analizó más de 330.000 cargas de trabajo de cientos de organizaciones para el informe de 2024.** - **Los usuarios de Kubernetes han mejorado significativamente la estabilidad y la eficiencia de las cargas de trabajo, pero aún hay áreas que necesitan mejoras.** ### Principales preocupaciones de Kubernetes en 2024: - **Aplicar políticas de manera consistente para gestionar la rentabilidad, la estabilidad y la seguridad de Kubernetes.** - **Saber cómo se comparan las configuraciones de las organizaciones con las de sus pares y cómo mejorarlas.** - **El informe de referencia muestra que muchas organizaciones han hecho mejoras significativas, en parte debido a la adopción de software que ayuda a identificar las configuraciones incorrectas automáticamente.** ### **Rentabilidad:** - **El 37% de las organizaciones tienen un 50% o más de cargas de trabajo que necesitan un ajuste del tamaño de contenedores para mejorar la rentabilidad.** - **Fairwinds Insights permite a los ingenieros de plataformas optimizar los recursos de las aplicaciones, identificando fácilmente recursos informáticos desperdiciados y obteniendo recomendaciones de recursos precisas y accionables.** ### **Estabilidad:** - **El 65% de las organizaciones carecen de probes de liveness y readiness, lo que afecta la estabilidad general.** - **El 55% de las organizaciones tienen más del 21% de las cargas de trabajo sin réplicas, lo que puede afectar la estabilidad y la disponibilidad de los contenedores.** - **Este año, el 67% de las organizaciones tienen más del 11% de las cargas de trabajo afectadas por la falta de solicitudes de CPU, lo que ha disminuido del 78% en 2023.** ### Seguridad: - **El 28% de las organizaciones tienen más del 90% de las cargas de trabajo ejecutándose con capacidades inseguras, lo que ha disminuido del 33% en 2023.** - **El 70% de las organizaciones tienen un 11% o más de sus cargas de trabajo ejecutándose con charts de Helm desactualizados, lo que puede resultar en la falta de parches de seguridad críticos.** ### **Conclusiones principales:** - **Los contenedores y Kubernetes pueden ofrecer a las empresas beneficios significativos, pero sin comprender estas configuraciones esenciales y cómo establecerlas de manera adecuada, puede ser difícil navegar por las complejidades inherentes de Kubernetes.** - **Este informe ayuda a identificar áreas potenciales de configuración incorrecta en Kubernetes y el impacto que pueden tener en la estabilidad, la seguridad y la rentabilidad de sus cargas de trabajo en el próximo año.** ### **Para obtener más información** - Consulta el informe completo de Benchmark de Kubernetes 2024 de Fairwinds. > Fuente: [https://www.fairwinds.com/blog/2024-kubernetes-benchmark-report-kubernetes-workload-analysis](https://www.fairwinds.com/blog/2024-kubernetes-benchmark-report-kubernetes-workload-analysis?ref=sredevops.org) ### ¿Usas GKE (Kubernetes en Google)? Tus clusters pueden estar abiertos a cualquier usuario de Google 🚨 URL: https://www.sredevops.org/es/usas-gke-kubernetes-en-google-tus-clusters-pueden-estar-abiertos-a-cualquier-usuario-de-google/ Last updated: 2026-01-08T02:36:10.000Z Ojo con el grupo `system:authenticated` en GKE, que incluye a todas las cuentas de Google, incluidas las tuyas. **Esto abre tu cluster a básicamente cualquier usuario autenticado en cualquier servicio Google**. ### **Recomendaciones** Para evitarlo, ten cuidado con los permisos que le das a ese grupo. En particular, no le des permiso para crear o administrar recursos críticos. También puedes usar herramientas de supervisión y auditoría para detectar cualquier cambio no deseado en permisos, accesos, credenciales, etc. ### **Recomendaciones específicas** - Si utilizas RBAC, chequea permisos que tiene el grupo. - Asegúrate de que solo los usuarios que lo necesitan tengan acceso a los recursos que necesitan. - Implementa un proceso de supervisión y auditoría para detectar vulnerabilidades y configuraciones erróneas, que sean compatibles con tu flujo de trabajo y tus equipos. Esta característica de GKE es intencionada y no es una vulnerabilidad, por eso, es importante que los usuarios de GKE administren meticulosamente sus permisos RBAC para evitar problemas. ### Fuente [How to Secure GKE’s Achilles Heel using RBAC?GKE Security Blindspot: “system:authenticated” Group! Patch the vulnerability with RBAC. Protect your cluster from unauthorized access. ➡️ \*\*![](https://www.armosec.io/wp-content/uploads/2021/11/cropped-armo-favicon-300x300.png)ARMOBen Hirschberg![](https://www.armosec.io/wp-content/uploads/2024/01/GKE_rbac_Social_B.png)](https://www.armosec.io/blog/secure-gke-cluster-rbac/?%5Fhsmi=291466332&ref=sredevops.org) ### K8Studio, una GUI para administrar e interactuar fácilmente con Kubernetes, alternativa a Lens o k9s URL: https://www.sredevops.org/es/k8studio-una-gui-para-administrar-e-interactuar-facilmente-con-kubernetes-alternativa-a-lens-o-k9s/ Last updated: 2026-01-08T02:36:33.000Z [K8Studio Kubernetes IDEIt’s been an exhilarating journey since we first embarked on the K8studio project four years ago. Although there were pauses along the way…![](https://cdn-static-1.medium.com/_/fp/icons/Medium-Avatar-500x500.svg)ITNEXTGuillermo Quiros![](https://miro.medium.com/v2/resize:fit:800/0*W2g4ivjjDsjWJe4K.png)](https://itnext.io/k8studio-kubernetes-ide-3e2979457b9e?ref=sredevops.org) > "Nu0estro objetivo principal sigue siendo inquebrantable: crear una interfaz gráfica integral que permita a los usuarios administrar sin esfuerzo sus clústeres de Kubernetes." Las características principales de K8 Studio son las siguientes: - **Vista multiclúster:** Esta vista permite a los usuarios ver y administrar múltiples clústeres de Kubernetes desde una sola interfaz. - **Vista de implementación:** Esta vista proporciona una representación visual de las implementaciones de Kubernetes, incluidas sus cargas de trabajo, pods, estado y configuración. - **Vista de nodo:** Esta vista proporciona una representación visual de los nodos de Kubernetes, incluidos sus pods, contenedores, servicios y estado. - **Filtrar y buscar:** K8 Studio proporciona una variedad de opciones de filtrado y búsqueda para ayudar a los usuarios a encontrar los objetos que están buscando. - **Caja de herramientas:** La caja de herramientas de K8 Studio contiene todos los tipos de objetos disponibles en Kubernetes, clasificados por categorías. - **Editor rápido:** El editor rápido de K8 Studio proporciona una representación estructurada del YAML del archivo, lo que facilita la edición de los objetos. - **Editor YML:** K8 Studio también incluye un editor YML tradicional para aquellos que prefieren trabajar con el formato YAML. - **Configuración:** K8 Studio proporciona una interfaz para administrar configuraciones, incluidas las configuraciones de mapas de configuración y secretos. - **SSH y registros:** K8 Studio permite a los usuarios conectarse a un pod o nodo mediante SSH o leer sus registros. - **Exportar:** K8 Studio proporciona una variedad de opciones de exportación para ayudar a los usuarios a compartir sus objetos con otros. En detalle, las características de K8 Studio incluyen las siguientes: **Vista multiclúster** La vista multiclúster de K8 Studio proporciona una vista resumida de múltiples clústeres, que incluye información de monitoreo, las aplicaciones que se han implementado en el clúster, cuántos pods se están ejecutando y cuántos están pendientes o tienen un error. **Vista de implementación** La vista de implementación de K8 Studio proporciona una representación visual de las implementaciones de Kubernetes, incluidas sus cargas de trabajo, pods, estado y configuración. Los usuarios pueden ver la topología de red de las implementaciones, el estado de los pods y la versión del pod en ejecución. **Vista de nodo** La vista de nodo de K8 Studio proporciona una representación visual de los nodos de Kubernetes, incluidos sus pods, contenedores, servicios y estado. Los usuarios pueden ver la topología de red de los nodos, el estado de los pods y los recursos disponibles. **Filtrar y buscar** K8 Studio proporciona una variedad de opciones de filtrado y búsqueda para ayudar a los usuarios a encontrar los objetos que están buscando. Los usuarios pueden filtrar por nombre, etiqueta, espacio de nombres, tipo de objeto y otros criterios. **Caja de herramientas** La caja de herramientas de K8 Studio contiene todos los tipos de objetos disponibles en Kubernetes, clasificados por categorías. Los usuarios pueden arrastrar y soltar objetos de la caja de herramientas a la vista interactiva o al árbol del proyecto. **Editor rápido** El editor rápido de K8 Studio proporciona una representación estructurada del YAML del archivo, lo que facilita la edición de los objetos. El editor rápido proporciona sugerencias, validación y descripciones de propiedades para ayudar a los usuarios a crear y editar objetos. **Editor YML** K8 Studio también incluye un editor YML tradicional para aquellos que prefieren trabajar con el formato YAML. El editor YML incluye resaltador de sintaxis y autocompletado de palabras clave. **Configuración** K8 Studio proporciona una interfaz para administrar configuraciones, incluidas las configuraciones de mapas de configuración y secretos. Los usuarios pueden crear, editar, eliminar y exportar configuraciones. **SSH y registros** K8 Studio permite a los usuarios conectarse a un pod o nodo mediante SSH o leer sus registros. Los usuarios pueden conectarse a un pod o nodo seleccionado usando la terminal incorporada de K8 Studio. **Exportar** K8 Studio proporciona una variedad de opciones de exportación para ayudar a los usuarios a compartir sus objetos con otros. Los usuarios pueden exportar objetos individuales a archivos YAML o volcar el filtro de configuración del clúster completo a una carpeta. También tienen la opción de exportar la vista existente a SVG o HTML. En general, K8 Studio es una herramienta poderosa que puede ayudar a los usuarios a administrar y administrar clústeres de Kubernetes. ### Congreso Futuro 2024, sigue el streaming de difusión científica promovido desde Chile para el mundo URL: https://www.sredevops.org/es/congreso-futuro-2024-sigue-el-streaming-de-difusion-cientifica-promovido-desde-chile-para-el-mundo/ Last updated: 2026-01-08T02:36:34.000Z > "Buscamos abrir el debate respecto a la urgente necesidad que tiene Chile (y el mundo) de contar con más y mejor ciencia y tecnología, así como ideas para generar el país que queremos. Esto representa gran parte de nuestro interés, expresado en casi 8 años de trabajo sistemático con todas las esferas que componen nuestra sociedad." [Congreso FuturoBuscamos abrir el debate respecto a la urgente necesidad de que en Chile (y el mundo) se cuente con más y mejor ciencia y tecnología, así como ideas que permitan generar el país que queremos. Esto representa gran parte de nuestro interés, expresado en casi 8 años de un sistemático trabajo realizado con todas las esferas que componen nuestra sociedad.![](https://www.youtube.com/s/desktop/7197d3dc/img/favicon_144x144.png)YouTube![](https://yt3.googleusercontent.com/u1X8WqV2YHv9mLlpl5Kn7u7r95eCOQVKnPCwxUiwtw4rxRuRitSzGlwqZovLR4KQSXsABgw3Vw=s900-c-k-c0x00ffffff-no-rj)](https://youtube.com/@congreso.futuro?si=ofK7cM0eW2Z2MM9n&ref=sredevops.org) ### Qué es Congreso Futuro? > Somos una plataforma de divulgación gratuita de conocimiento, ciencia, tecnología y arte que se realiza desde el 2011. > > Organizado por el **Senado de Chile**, la **Fundación Encuentros del Futuro**, la **Academia Chilena de Ciencias** y todas las universidades del país, somos un espacio ciudadano de diálogo y reflexión sobre los temas sociales, culturales y políticos que la sociedad del presente enfrentará en un futuro cercano. > > Reunimos a expertos y líderes de opinión a nivel nacional e internacional con la sociedad civil para motivar el conocimiento a través de charlas, conferencias, paneles y mesas de conversación. ### Timoni, a new and easy alternative to Helm, or how to manage complex applications in Kubernetes URL: https://www.sredevops.org/en/timoni-a-new-and-easy-alternative-to-helm-or-how-to-manage-complex-applications-in-kubernetes/ Last updated: 2025-02-07T04:08:51.000Z [Timoni](https://timoni.sh/?ref=sredevops.org) is a package manager for Kubernetes, based on the [CUE](https://cuelang.org/?ref=sredevops.org) language and inspired by [Helm](https://helm.sh/?ref=sredevops.org) . ### Concepts equivalent to Helm If you're familiar with Helm, a Timoni [**module**](https://timoni.sh/module/?ref=sredevops.org) is the equivalent of a **helm chart** , a [**bundle**](https://timoni.sh/bundle/?ref=sredevops.org) is the equivalent of an **umbrella chart** , and an [**instance**](https://timoni.sh/concepts/?ref=sredevops.org#instance) is the equivalent of a **Helm release** . The Timoni project focuses on improving the UX of creating Kubernetes configurations. Instead of mixing Go templates with YAML like Helm, or layering YAML on top of each other like Kustomize, Timoni relies on cuelang's security, code generation, and data validation features to deliver a better experience building, packaging, and delivering applications to Kubernetes. > **Warning** > > Please note that Timoni is in active development and is still in its infancy. > > APIs and CLI can change their specs ## Begin To start with Timoni, you know... READ THE DOCS! [timoni.sh](https://timoni.sh/quickstart/?ref=sredevops.org) . [QuickstartTimoni is a package manager for Kubernetes powered by CUE lang.![](https://www.sredevops.org/content/images/icon/favicon-1.png)logoStefan Prodan![](https://www.sredevops.org/content/images/thumbnail/logo_card.png)](https://timoni.sh/quickstart/?ref=sredevops.org) ## Characteristics ### Application packaging and distribution Timoni enables software vendors to define complex application implementations, packaged as [Modules](https://timoni.sh/module/?ref=sredevops.org) , using type safe Kubernetes templates and rich customization options for end users. The configuration of the application packaged in a module is [distributed](https://timoni.sh/module-distribution/?ref=sredevops.org) as a Open Container Initiative (OCI) artifact, along with application images, in a container registry. Timoni modules are semantically versioned and cryptographically [signed](https://timoni.sh/module-sign/?ref=sredevops.org) . With Timoni, platform engineers can manage the Kubernetes lifecycle drivers, including updating CRDs. Module authors can [import CRD schemas](https://timoni.sh/module/?ref=sredevops.org#kubernetes-crds) from YAML files and incorporate custom Kubernetes resources in the implementations of their applications. ### Application lifecycle management With Timoni, users can manage the entire lifecycle of applications deployed on Kubernetes. From highly customized installation to seamless upgrades, end-to-end testing, safe rollback and uninstall. With Timoni, users can bundle microservices and distributed monoliths into a deployable unit. Timoni [Bundle](https://timoni.sh/bundle/?ref=sredevops.org) offers a declarative way to manage delivering applications across clusters, where secrets and other environment-specific settings The values are [loaded dynamically](https://timoni.sh/bundle-runtime/?ref=sredevops.org) during installation or updates. [TimoniTimoni is a package manager for Kubernetes powered by CUE lang.![](https://www.sredevops.org/content/images/icon/favicon-2.png)logoStefan Prodan![](https://www.sredevops.org/content/images/thumbnail/logo_card-1.png)](https://timoni.sh/?ref=sredevops.org) ### Timoni, una nueva y fácil alternativa a Helm, o cómo gestionar aplicaciones complejas en Kubernetes URL: https://www.sredevops.org/es/timoni-una-nueva-y-facil-alternativa-a-helm-o-como-gestionar-aplicaciones-complejas-en-kubernetes/ Last updated: 2026-01-08T02:36:34.000Z [Timoni](https://timoni.sh/?ref=sredevops.org) es un administrador de paquetes para Kubernetes, basado en lenguaje [CUE](https://cuelang.org/?ref=sredevops.org) e inspirado en [Helm](https://helm.sh/?ref=sredevops.org) . ### Conceptos equivalentes a Helm Si estás familiarizado con Helm, un [**módulo**](https://timoni.sh/module/?ref=sredevops.org) de Timoni es el equivalente a un **helm chart**, un [**bundle**](https://timoni.sh/bundle/?ref=sredevops.org) es el equivalente a un **umbrella chart**, y una [**instancia**](https://timoni.sh/concepts/?ref=sredevops.org#instance) es el equivalente de un **Helm release**. El proyecto Timoni se enfoca en mejorar la UX de la creación de configuraciones de Kubernetes. En lugar de mezclar plantillas de Go con YAML como Helm, o superponer YAML uno encima del otro como Kustomize, Timoni confía en las funciones de seguridad, generación de código y validación de datos de cuelang para ofrecer una mejor experiencia de creación, empaquetado y entrega de aplicaciones a Kubernetes. > **Advertencia** > > Ten en cuenta que Timoni se encuentra en desarrollo activo y aún está en sus inicios. > > Las API y la CLI pueden cambiar sus specs ## Empezar Para comenzar con Timoni, ya sabes... READ THE DOCS! [timoni.sh](https://timoni.sh/quickstart/?ref=sredevops.org). ## Características ### Empaquetado y distribución de aplicaciones Timoni permite a los proveedores de software definir implementaciones de aplicaciones complejas, empaquetado como [Módulos](https://timoni.sh/module/?ref=sredevops.org), usando tipo seguro Plantillas de Kubernetes y ricas opciones de personalización para usuarios finales. La configuración de la aplicación empaquetada en un módulo es [distribuido](https://timoni.sh/module-distribution/?ref=sredevops.org) como un Artefacto de Open Container Initiative (OCI), junto a las imágenes de la aplicación, en un registro de contenedores. Los módulos Timoni están versionados semánticamente y criptográficamente [firmado](https://timoni.sh/module-sign/?ref=sredevops.org). Con Timoni, los ingenieros de plataformas pueden gestionar el ciclo de vida de Kubernetes controladores, incluida la actualización de los CRD. Los autores de módulos pueden [importar esquemas CRD](https://timoni.sh/module/?ref=sredevops.org#kubernetes-crds) desde archivos YAML e incorporar recursos personalizados de Kubernetes en las implementaciones de sus aplicaciones. ### Gestión del ciclo de vida de la aplicación Con Timoni, los usuarios pueden gestionar todo el ciclo de vida de las aplicaciones implementadas en Kubernetes. Desde una instalación altamente personalizada hasta actualizaciones perfectas, pruebas de un extremo a otro, reversión segura y desinstalación. Con Timoni, los usuarios pueden agrupar microservicios y monolitos distribuidos en una unidad implementable. Timoni [Bundle](https://timoni.sh/bundle/?ref=sredevops.org) ofrece una forma declarativa de gestionar la entrega de aplicaciones a través de clústeres, donde los secretos y otras configuraciones específicas del entorno los valores se [cargan dinámicamente](https://timoni.sh/bundle-runtime/?ref=sredevops.org) durante la instalación o las actualizaciones. ## Licencia Timoni tiene \[licencia de Apache 2.0\] (LICENCIA) y acepta contribuciones a través de solicitudes de extracción de GitHub. Consulte la \[guía de contribución\] (CONTRIBUTING.md) para obtener más información. ### 2024 Will you continue with agile and scrum? You will be extinct in 2025, what can you do? URL: https://www.sredevops.org/en/2024-will-you-continue-with-agile-and-scrum-you-will-be-extinct-in-2025-what-can-you-do/ Last updated: 2026-01-07T20:35:55.000Z > **The key to a successful project is to give people freedom and autonomy, to lead with clear, simple objectives that can be achieved little by little. In this sense, "Platform Engineering" is having the organizational and technical tools that make it possible, that is, the evolution of the DevOps culture.** **To do this, organizations need to invest in internal development platforms that allow teams to focus on building applications, without having to worry about infrastructure or operational processes.** **These platforms must have the following capabilities:** - **Infrastructure automation:** create and manage development environments, deploy applications and manage security in an efficient and scalable way, without adding problems to be able to do a *Hello World in Kubernetes.* - **Infrastructure as Code (IaC):** Defines IT infrastructure in code, making infrastructure automation easier and simpler. - **Container orchestration:** Kubernetes and Linux will continue to be at the core of everything. Remember it. - **Continuous integration and delivery (CI/CD) services:** that automate the application development, deployment and testing process. **With these capabilities, development teams can:** - **Free yourself from administrative tasks and focus on what you enjoy: code.** - **Improve your productivity and efficiency.** - **Reduce errors and risks.** - **Accelerate time to market for applications.** This year we will continue with PlatformCon and you can register here: [Register for PlatformCon 2024Connect with fellow platform practitioners, learn from the best in the industry and engage directly with speakers on Slack.![](https://assets-global.website-files.com/6542483d1e2222ac4a899bdd/65490612ad61feab01ec5449_256x256-platformcon24-webclip.png)![](https://assets-global.website-files.com/6542483d1e2222ac4a899bdd/65490497e22e5d6fda6c8d2a_PlatformCon%202024%20opengraph.jpg)](https://platformcon.com/register?ref=sredevops.org) ### 2024 Você continuará com ágil e scrum? Você estará extinto em 2025, o que você pode fazer? URL: https://www.sredevops.org/br/2024-voce-continuara-com-agil-e-scrum-voce-estara-extinto-em-2025-o-que-voce-pode-fazer/ Last updated: 2026-01-07T20:36:07.000Z > **A chave para um projeto de sucesso é dar liberdade e autonomia às pessoas, liderar com objetivos claros, simples e que possam ser alcançados aos poucos. Neste sentido, “Engenharia de Plataformas” é dispor de ferramentas organizacionais e técnicas que possibilitem, ou seja, a evolução da cultura DevOps.** **Para isso, as organizações precisam investir em plataformas internas de desenvolvimento que permitam que as equipes se concentrem na construção de aplicações, sem terem que se preocupar com infraestrutura ou processos operacionais.** **Estas plataformas devem ter as seguintes capacidades:** - **Automação de infraestrutura:** crie e gerencie ambientes de desenvolvimento, implante aplicações e gerencie a segurança de forma eficiente e escalável, sem agregar problemas para poder fazer um *Hello World em Kubernetes.* - **Infraestrutura como Código (IaC):** Define a infraestrutura de TI em código, tornando a automação da infraestrutura mais fácil e simples. - **Orquestração de contêineres:** Kubernetes e Linux continuarão no centro de tudo. Lembre se. - **Serviços de integração e entrega contínua (CI/CD):** que automatizam o processo de desenvolvimento, implantação e teste de aplicativos. **Com esses recursos, as equipes de desenvolvimento podem:** - **Liberte-se de tarefas administrativas e concentre-se no que você gosta: código.** - **Melhore sua produtividade e eficiência.** - **Reduza erros e riscos.** - **Acelere o tempo de lançamento de aplicativos no mercado.** Este ano continuaremos com a PlatformCon e você pode se cadastrar aqui: [Registre-se na PlatformCon 2024Conecte-se com outros profissionais de plataforma, aprenda com os melhores do setor e interaja diretamente com palestrantes no Slack.![](https://assets-global.website-files.com/6542483d1e2222ac4a899bdd/65490612ad61feab01ec5449_256x256-platformcon24-webclip.png)![](https://assets-global.website-files.com/6542483d1e2222ac4a899bdd/65490497e22e5d6fda6c8d2a_PlatformCon%202024%20opengraph.jpg)](https://platformcon.com/register?ref=sredevops.org) ### 2024 Seguirás con agile y scrum? Estarás extinto el 2025, qué puedes hacer? URL: https://www.sredevops.org/es/2024-seguiras-con-agile-y-scrum-estaras-extinto-el-2025-que-puedes-hacer/ Last updated: 2026-01-08T02:36:34.000Z > **La clave para un proyecto exitoso es entregar libertad y autonomía a las personas, liderar con objetivos claros, simples, y que se puedan ir cumpliendo poco a poco. En este sentido, "Platform Engineering" es tener las herramientas organizacionales y técnicas que lo hagan posible, es decir, la evolución de la cultura DevOps.** **Para eso, las organizaciones tienen que invertir en plataformas de desarrollo internas que permitan a los equipos centrarse en crear aplicaciones, sin tener que preocuparse por la infraestructura o los procesos operativos.** **Estas plataformas tienen que tener las siguientes capacidades:** - **Automatización de la infraestructura:** que cree y gestione entornos de desarrollo, implemente aplicaciones y gestione la seguridad de forma eficiente y escalable, no sumar problemas para poder hacer un *Hola Mundo en Kubernetes.* - **Infraestructura como código (IaC):** que defina la infraestructura de TI en código, para que la automatización de la infraestructura sea más fácil y sencilla. - **Orquestación de contenedores:** Kubernetes y Linux seguirán siendo el núcleo de todo. Recuerdalo. - **Servicios de integración y entrega continua (CI/CD):** que automaticen el proceso de desarrollo, implementación y prueba de aplicaciones. **Con estas capacidades, los equipos de desarrollo pueden:** - **Liberarse de las tareas administrativas y centrarse en lo que disfrutan: código.** - **Mejorar su productividad y eficiencia.** - **Reducir los errores y los riesgos.** - **Acelerar el tiempo de comercialización de las aplicaciones.** Este año seguiremos con PlatformCon y puedes registrarte aqui: [Register for PlatformCon 2024Connect with fellow platform practitioners, learn from the best in the industry and engage directly with speakers on Slack.![](https://assets-global.website-files.com/6542483d1e2222ac4a899bdd/65490612ad61feab01ec5449_256x256-platformcon24-webclip.png)![](https://assets-global.website-files.com/6542483d1e2222ac4a899bdd/65490497e22e5d6fda6c8d2a_PlatformCon%202024%20opengraph.jpg)](https://platformcon.com/register?ref=sredevops.org) ### What is Web Assembly (WASM) and what is it for? URL: https://www.sredevops.org/en/what-is-web-assembly-wasm-and-what-is-it-for/ Last updated: 2026-07-16T04:30:43.000Z Have you heard of WebAssembly (Wasm)? **In simple: It is a new way of where and how the source code is processed, moving the load from cloud instances (or servers, etc.) to the end user's browser through "micro sandboxes" that will compile the app.** Imagine Wasm is an actor that can communicate with current browsers natively. A kind of translator that allows certain programming languages *\- such as C/C++, C# and Rust* \- to speak the "language of the web". The interesting part is that it does this very efficiently, running as fast as the browser allows. Furthermore, Wasm is a *very careful* agent. When in action, it makes sure you don't screw up or cause conflicts with the browser. It remains in its own space, as if it were in its own bubble, theoretically isolated from the rest of the system (sandbox). And what does this have to do with the "Cloud Native" world? It allows cloud applications to delegate costs (time, resources, traffic... yes, also billing) contributing to more efficient, secure and easy-to-manage applications for both users and all of us who suffer with pipelines, deployments and blablabla. Let's talk about efficiency. Wasm a Formula 1? Well, that's what Wasm does. It converts programs into a special format that can be executed directly by the machine, without unnecessary detours. In terms of security, Wasm is like someone who feels most comfortable in their own home. He doesn't leave his area and he doesn't go snooping where he shouldn't. That means it doesn't mess with the operating system or cause browser problems. Total tranquility. And in terms of scalability, Wasm is like that versatile piece of clothing that you can wear on any occasion. Works anywhere that accepts WebAssembly. Do you need your application to grow? Wasm can adapt to change. ### Finally, here are concrete examples of how Wasm is used in Cloud Native applications: - **Microservices:** Imagine microservices as little helpers that do specific tasks. Wasm gives them special training to make them efficient and secure in the cloud world. - **Micro front-ends:** They are like chapters in a book, but for applications. Wasm makes them portable so they work in any browser. As simple as that. - **Artificial Intelligence and Machine Learning:** Do you remember the movies where machines seem to think? Wasm allows machine learning models to work their magic in the cloud. In short, Wasm is like a glimpse into the future of cloud applications. But attention... ### Wasm Risks and Threats The last risk to WebAssembly that I would like to point out worries and scares me because I have seen it happen too often. It scares me because ego, bad practices, *"don't touch just because,"* **secrecy and contempt for others can lead to this** . And it scares me because old school thinking about **"capturing a market" (hello Microsoft),** often results in following a course of action that results in... > **Fragmentation.** This occurs when a core technology is co-opted by many parties, each attempting to make its implementation incompatible with the others. Sometimes, the incompatibility is made "in the name of speed" or the fulfillment of short-term criteria. *"We needed to go outside the box to meet customer demand."* Other times, it comes as a response to competitors: *"We decided not to share the source code so we could gain a competitive advantage."* Unfortunately, sometimes it is simply due to ignorance and lack of community involvement. ### Technical Debt Is A Business Problem! URL: https://www.sredevops.org/en/technical-debt-is-a-business-problem/ Last updated: 2025-03-07T03:45:42.000Z Technical debt is a metaphorical concept in software development that refers to the cumulative consequences of choosing expedient, suboptimal solutions to meet immediate needs. While often considered a technical challenge, it has far-reaching implications for business operations and success. In the dynamic landscape of technology, businesses are under constant pressure to deliver products quickly. However, when corners are cut to meet tight deadlines, technical debt accrues. This debt can manifest in various forms, such as inefficient code, outdated technologies, or delayed system updates. The impact of technical debt on business is profound. It can lead to increased costs, longer development cycles, and decreased overall productivity. The interest on technical debt accumulates as teams struggle with legacy systems, making it harder to adapt to changing market demands and implement new features swiftly. Martin Fowler's technical debt quadrant categorizes debt as reckless, prudent, deliberate, or inadvertent. Each type has different implications for the business. Reckless debt, incurred without consideration, can result in critical issues, while prudent debt acknowledges the trade-offs made for strategic reasons. Businesses must recognize technical debt as a systemic problem, not just an IT challenge. It affects cycle times, increases costs, and delays time-to-market. The drain on productivity due to poorly designed code demands more time and effort from development teams, hindering innovation and responsiveness. Addressing technical debt requires a holistic approach, involving collaboration between technical and business stakeholders. Proactive strategies, such as regular code reviews, continuous refactoring, and investing in modernization efforts, can mitigate the impact of technical debt on the business. In conclusion, ***technical debt is not merely a technical concern but a critical business problem***. Businesses that neglect to manage technical debt may find themselves struggling to adapt, innovate, and compete in the ever-evolving digital landscape. ### Trabajo remoto y el Ego del manager URL: https://www.sredevops.org/es/trabajo-remoto-y-el-ego-del-manager/ Last updated: 2026-01-08T02:36:18.000Z El trabajo remoto y el ego de una clase de managers que quieren compensar alguna falta/deficiencia de ellos con el presencial/híbrido. El año es 2023, la sociedad está desarrollada y la tecnología ha alcanzado niveles que, independientemente de dónde estés o de qué horas sean, eres capaz de realizar el trabajo en el área de informática de manera remota. Sin embargo, hay un grupo de \[controladores\] que insisten que regresar al modo híbrido/presencial/semipresencial es la solución de sus vidas.\*\* Hoy tenemos grandes compañías que cayeron en razón y pusieron la cuenta por el valor gasto del remoto vs híbrido, y esas compañías han crecido considerablemente en los 2 últimos años, incluso con términos de contratos, sus números siguen creciendo. En gran parte, más del 65% es porque el gasto con oficinas se ha eliminado casi por completo. Sumado a eso, tenemos al colaborador que no tiene que subir al metro, micro o Uber, ya que su trabajo puede ser hecho de una computadora conectada a internet en cualquier parte del mundo. ### El argumento... El grupo de managers que insiste en esa postura rara de regreso a oficina, coworks y similares, solo me hace pensar que, no poseen una voz de mando en casa, y para justificar su ego, y algo que les falte, obligan a sus empleados a regresar a la oficina, y el que no hace, de a poco los van a ir echando y/o reemplazando. En ese aspecto, yo tuve una experiencia en una empresa, la cual, el manager por más de 2 situaciones insinuó el aspecto de que era importante que estuviera presente en esos eventos (que podrían haber sido una videollamada), y yo en mi condición, por la distancia que vivo de la empresa, no tenía condiciones de moverme. Debido a eso, pasaron 2 meses y me terminaron el contrato, porque sí. Es lamentable que ese tipo de situación ocurra, aún más, que gran parte de los profesionales del área de IT tiene ya su oficina armada, tiene su rutina en la casa, y tiene su pega hecha como corresponde, justamente porque están en una situación que no genera estrés. Moverse a la oficina genera estrés, y en muchos casos pérdida de rendimiento, aparte de ser totalmente inútil. Si quieres compartir con los colaboradores, organiza un asado, y el que quiera va. ### Vestir la polera... Algo que se escucha desde los tiempos antiguos... pero vengamos y hablemos claro, trabajamos por los billetes, nada más ni nada menos. La relación es un contrato de servicio, en donde un lado necesita y el otro cumple, eso, nada más. Sin embargo, muchas veces esa clase de managers insiste que somos una familia, una comunidad o cualquier otra cosa rara que se les ocurra. Esa actitud genera un ambiente tóxico, en donde se pierden buenos profesionales porque "no están conformes con la cultura de la empresa". Yo tengo una frase para eso: a mí me pagan para cumplir mi pega, no para ser simpático y pasar pano en la cabeza de gente haciendo malas cosas. ### MySQL 8.2 is what we were all waiting for for Kubernetes with Transparent Read/Write Splitting URL: https://www.sredevops.org/en/mysql-8-2-is-what-we-were-all-waiting-for-for-kubernetes-with-transparent-read-write-splitting/ Last updated: 2023-11-16T19:47:47.000Z Oracle recently announced the [general availability of MySQL 8.2](https://blogs.oracle.com/mysql/post/mysql-82-transparent-readwrite-splitting?ref=sredevops.org) , which includes **support for read/write splitting** . This long-awaited feature was introduced in the latest *innovation release (an equivalent of a "release candidate"),* which helps **optimize database performance and scalability** . [Read-write splitting](https://dev.mysql.com/doc/mysql-router/8.2/en/router-read-write-splitting.html?ref=sredevops.org) allows applications to transparently direct all write traffic to read-write instances (primary/sources) and all read traffic to read-only instances, depending on the instance type (InnoDB Cluster or Replica). Cluster). [Frederic Descamps](https://www.linkedin.com/in/freddescamps/?ref=sredevops.org) , MySQL community manager, explains: > "At large scale, we distribute reads across replicas, but this must be managed somehow in the application: pointing writes to one place and reads to another place. Since MySQL 8.2, MySQL Router can now identify reads and writes, and then route them to primary instances in the case of an InnoDB cluster, or to an asynchronous replication source for writes and to secondary instances or replicas for reads." You can perform a simple PoC (proof of concept) yourself, using mysql-operator: [mysql-operator/deploy at 8.2.0-2.1.1 · mysql/mysql-operatorMySQL Operator for Kubernetes. Contribute to mysql/mysql-operator development by creating an account on GitHub.![](https://github.githubassets.com/assets/pinned-octocat-093da3e6fa40.svg)GitHubmysql![](https://opengraph.githubassets.com/db883678f682ce8143ce855be9263af781b9dc0871040fff21e707a6b73826fc/mysql/mysql-operator)](https://github.com/mysql/mysql-operator/tree/8.2.0-2.1.1/deploy?ref=sredevops.org) You will need to deploy the following manifests: ```bash kubectl apply -f "https://github.com/mysql/mysql-operator/blob/8.2.0-2.1.1/deploy/deploy-crds.yaml" # CRDs kubectl apply -f "https://github.com/mysql/mysql-operator/blob/8.2.0-2.1.1/deploy/deploy-operator.yaml" # Operator kubectl apply -f "https://github.com/mysql/mysql-operator/blob/8.2.0-2.1.1/samples/sample-secret.yaml" # Secret (edit recommended) kubectl apply -f "https://github.com/mysql/mysql-operator/blob/8.2.0-2.1.1/samples/sample-cluster.yaml" # Cluster 3 instances 1 router ``` Based on: [https://www.infoq.com/news/2023/11/mysql-read-write-splitting/](https://www.infoq.com/news/2023/11/mysql-read-write-splitting/?ref=sredevops.org) Further reading: [https://lefred.be/content/mysql-8-2-read-write-splitting-a-what-cost/](https://lefred.be/content/mysql-8-2-read-write-splitting-a-what-cost/?ref=sredevops.org) ### MySQL 8.2 es lo que todos estábamos esperando para Kubernetes con Transparent Read/Write Splitting URL: https://www.sredevops.org/es/mysql-8-2-es-lo-que-todos-estabamos-esperando-para-kubernetes-con-transparent-read-write-splitting/ Last updated: 2026-01-08T02:36:12.000Z Oracle ha anunciado recientemente la [disponibilidad general de MySQL 8.2](https://blogs.oracle.com/mysql/post/mysql-82-transparent-readwrite-splitting?ref=sredevops.org) , que incluye **soporte para división de lectura/escritura (read/write splitting)**. Esta característica tan esperada se introdujo en la última *versión de innovación (un equivalente a "release candidate"),* que ayuda a **optimizar el rendimiento y la escalabilidad** de la base de datos. [Read-write splitting](https://dev.mysql.com/doc/mysql-router/8.2/en/router-read-write-splitting.html?ref=sredevops.org) permite a las aplicaciones dirigir de forma transparente todo el tráfico de escritura a instancias de lectura-escritura (primarias/sources) y todo el tráfico de lectura a instancias de sólo lectura, dependiendo del tipo de instancia (InnoDB Cluster o Replica Cluster). [Frederic Descamps](https://www.linkedin.com/in/freddescamps/?ref=sredevops.org) , administrador de la comunidad MySQL, explica: > "A gran escala, distribuimos las lecturas entre las réplicas, pero esto debe gestionarse de alguna manera en la aplicación: apuntando las escrituras a un lugar y las lecturas a otro lugar. Desde MySQL 8.2, MySQL Router ahora puede identificar las lecturas y escrituras, para luego enrutarlas a instancias primarias en el caso de un clúster InnoDB, o a una fuente de replicación asincrónica para las escrituras y a instancias secundarias o réplicas para las lecturas." Puedes realizar tu mismo una simple PoC (proof of concept/prueba de concepto), utilizando mysql-operator: [mysql-operator/deploy at 8.2.0-2.1.1 · mysql/mysql-operatorMySQL Operator for Kubernetes. Contribute to mysql/mysql-operator development by creating an account on GitHub.![](https://github.githubassets.com/assets/pinned-octocat-093da3e6fa40.svg)GitHubmysql![](https://opengraph.githubassets.com/db883678f682ce8143ce855be9263af781b9dc0871040fff21e707a6b73826fc/mysql/mysql-operator)](https://github.com/mysql/mysql-operator/tree/8.2.0-2.1.1/deploy?ref=sredevops.org) Necesitarás desplegar los siguientes manifiestos: ```bash kubectl apply -f "https://github.com/mysql/mysql-operator/blob/8.2.0-2.1.1/deploy/deploy-crds.yaml" # CRDs kubectl apply -f "https://github.com/mysql/mysql-operator/blob/8.2.0-2.1.1/deploy/deploy-operator.yaml" # Operator kubectl apply -f "https://github.com/mysql/mysql-operator/blob/8.2.0-2.1.1/samples/sample-secret.yaml" # Secret (recomendado editar) kubectl apply -f "https://github.com/mysql/mysql-operator/blob/8.2.0-2.1.1/samples/sample-cluster.yaml" # Cluster 3 instancias 1 router ``` Basado en: [https://www.infoq.com/news/2023/11/mysql-read-write-splitting/](https://www.infoq.com/news/2023/11/mysql-read-write-splitting/?ref=sredevops.org) Lectura complementaria: [https://lefred.be/content/mysql-8-2-read-write-splitting-a-what-cost/](https://lefred.be/content/mysql-8-2-read-write-splitting-a-what-cost/?ref=sredevops.org) ### Como posso armazenar arquivos no Kubernetes? CubeFS é uma excelente opção URL: https://www.sredevops.org/br/como-posso-armazenar-arquivos-no-kubernetes-cubefs-e-uma-excelente-opcao/ Last updated: 2024-07-24T12:41:00.000Z ![](https://www.sredevops.org/content/images/2024/07/k8s-component.d9c57140.png) [CubeFS | A Cloud Native Distributed Storage SystemCubeFS is a distributed file system and object storage service for cloud native applications.![](https://cubefs.io/icon/favicon.ico)A Cloud Native Distributed Storage System![](https://cubefs.io/images/github-small.svg)](https://cubefs.io/docs/master/deploy/k8s.html?ref=sredevops.org#deployment-architecture) ## O que é CubeFS? CubeFS é um produto de armazenamento nativo em nuvem, sendo um dos projetos de grau "Incubadora" da CNCF ( [Cloud Native Computing Foundation](https://www.cncf.io/projects/cubefs/?ref=sredevops.org) ). Ele suporta vários protocolos de acesso a dados, como **S3, POSIX e HDFS,** e suporta dois *mecanismos de armazenamento* : multi-réplica e [código de eliminação](https://blog.min.io/erasure-coding/?ref=sredevops.org) . Ele fornece aos usuários múltiplas funções, como multilocação, implantação multi-AZ e replicação entre regiões, e é amplamente utilizado em cenários como big data, IA, plataformas de contêiner, bancos de dados, armazenamento de middleware e separação de computação, compartilhamento de dados e Proteção de dados. ## Por que CubeFS? ### Multiprotocolo Suporta vários protocolos de acesso como S3, POSIX e HDFS, e o acesso entre protocolos é interoperável. - **Compatível com POSIX** : Compatível com a interface POSIX, tornando o desenvolvimento de aplicativos extremamente simples para aplicativos de camada superior, tão conveniente quanto usar um sistema de arquivos local. Além disso, o CubeFS relaxou os requisitos de consistência da semântica POSIX durante a implementação para equilibrar o desempenho das operações de arquivos e metadados. - **Compatível com S3** – Com suporte ao protocolo de armazenamento de objetos AWS S3, os usuários podem usar o SDK nativo do Amazon S3 para gerenciar recursos no CubeFS. - **Compatível com HDFS** : Compatível com o protocolo de interface Hadoop FileSystem, os usuários podem usar CubeFS para substituir o sistema de arquivos Hadoop (HDFS) sem afetar os negócios da camada superior. ### Multimotor Ao oferecer suporte a dois mecanismos: multi-réplica e codificação de eliminação, os usuários podem escolher com flexibilidade de acordo com seus cenários de negócios. - **Mecanismo de armazenamento multi-réplica** : os dados entre as cópias estão em um relacionamento de espelho e a consistência dos dados entre as cópias é garantida por meio de um protocolo de replicação altamente consistente. Os usuários podem configurar com flexibilidade diferentes números de cópias de acordo com os cenários de sua aplicação. - **Mecanismo de armazenamento de codificação de eliminação** : O mecanismo de codificação de eliminação tem as características de alta confiabilidade, alta disponibilidade, baixo custo e suporta escala ultragrande (EB). De acordo com os diferentes modelos AZ, os modos de codificação de eliminação podem ser selecionados de forma flexível. ### Multi usuário Apoie o gerenciamento de vários locatários e forneça políticas detalhadas de isolamento de locatários. ### Altamente escalável Você pode criar facilmente serviços de armazenamento distribuído com escala de nível PB ou EB, e cada módulo pode ser escalado horizontalmente. ### Alto rendimento CubeFS suporta cache multinível para otimizar o acesso a arquivos pequenos e oferece suporte a vários protocolos de replicação de alto desempenho. - **Gerenciamento de metadados** \- O cluster de metadados usa armazenamento de metadados na memória e duas árvores B (inodeBTree e dentryBTree) para gerenciar índices e melhorar o desempenho de acesso aos metadados. - **Protocolo de replicação de consistência forte** : CubeFS adota diferentes protocolos de replicação de acordo com o modo de gravação do arquivo para garantir a consistência dos dados entre as réplicas. Se o arquivo for gravado sequencialmente, o protocolo de replicação de backup primário será usado para otimizar o desempenho de E/S. Se o arquivo for gravado aleatoriamente para substituir o conteúdo do arquivo existente, um protocolo de replicação baseado em Multi-Raft será usado para garantir alta consistência de dados. - **Cache multinível** – O volume de codificação Erasure suporta capacidade de aceleração de cache multinível para fornecer maior desempenho de acesso a dados para dados importantes: - Cache Local: O componente BlockCache pode ser implantado na máquina cliente como um cache local usando o disco local. Ele pode ler diretamente o cache local sem passar pela rede, mas a capacidade é limitada pelo disco local. - Cache Global: Um cache global distribuído criado com o componente de replicação DataNode. Por exemplo, um DataNode com SSD implantado no mesmo data center do cliente pode ser usado como cache global. Comparado com o cache local, ele precisa passar pela rede, mas tem maior capacidade e pode ser dimensionado dinamicamente, e o número de réplicas pode ser ajustado. ## Nativo da nuvem Baseado no padrão CSI [(Container Storage Interface](https://kubernetes.io/blog/2019/01/15/container-storage-interface-ga/?ref=sredevops.org) ), o CubeFS é facilmente integrado e implantado no Kubernetes. [Container Storage Interface (CSI) for Kubernetes GAThe Kubernetes implementation of the Container Storage Interface (CSI) has been promoted to GA in the Kubernetes v1.13 release. Support for CSI was introduced as alpha in Kubernetes v1.9 release, and promoted to beta in the Kubernetes v1.10 release. The GA milestone indicates that Kubernetes users may depend on the feature and its API without fear of backwards incompatible changes in future causing regressions. GA features are protected by the Kubernetes deprecation policy.![](https://kubernetes.io/icons/apple-touch-icon-256x256.png)Kubernetes![](https://kubernetes.io/images/blog-logging/2018-04-10-container-storage-interface-beta/csi-kubernetes.png)](https://kubernetes.io/blog/2019/01/15/container-storage-interface-ga/?ref=sredevops.org) ## Casos de uso e cenários Por ser uma plataforma de armazenamento distribuído nativa em nuvem, o CubeFS disponibiliza vários protocolos de acesso, para que você possa utilizá-lo em diversas situações, vamos listar: ### Análise de big data Compatível com o protocolo HDFS, o CubeFS fornece uma base de armazenamento unificada para o ecossistema Hadoop (como Spark e Hive), fornecendo espaço de armazenamento ilimitado e recursos de armazenamento de dados de alta largura de banda para mecanismos de computação. ### Aprendizado profundo/aprendizado de máquina Como um sistema de arquivos paralelo distribuído, o CubeFS suporta treinamento de IA, armazenamento e distribuição de modelos, aceleração de E/S e outros requisitos. ### Armazenamento compartilhado entre contêineres O cluster de contêiner pode armazenar os arquivos de configuração ou dados de carregamento de inicialização de imagens de contêiner no CubeFS e lê-los em tempo real ao carregar contêineres em lote. Vários PODs podem compartilhar dados persistentes por meio do CubeFS e um failover rápido pode ser executado em caso de falha do POD. ### Bancos de dados e middleware Fornece serviços de disco em nuvem de alta simultaneidade e baixa latência para aplicativos de banco de dados como MySQL, ElasticSearch e ClickHouse, alcançando separação completa entre armazenamento e computação. ### Serviços online Fornece serviços de armazenamento de objetos de alta confiabilidade e baixo custo para empresas on-line (como publicidade, fluxos de cliques e pesquisas) ou conteúdo gráfico, de texto, áudio e vídeo do usuário final. **Do NAS (Network Attached Storage) à nuvem** Ele substitui o armazenamento local tradicional e o NAS offline e facilita estratégias de adoção da nuvem. ### Fonte: [CubeFS | A Cloud Native Distributed Storage SystemCubeFS is a distributed file system and object storage service for cloud native applications.![](https://cubefs.io/icon/favicon.ico)A Cloud Native Distributed Storage System![](https://cubefs.io/images/github-small.svg)](https://cubefs.io/docs/master/overview/introduction.html?ref=sredevops.org) ### How can I store files in Kubernetes? CubeFS is an excellent option URL: https://www.sredevops.org/en/how-can-i-store-files-in-kubernetes-cubefs-is-an-excellent-option/ Last updated: 2026-01-04T05:28:57.000Z ## What is CubeFS? CubeFS is a cloud-native storage product, being one of the "Incubator" grade projects of the CNCF ( [Cloud Native Computing Foundation](https://www.cncf.io/projects/cubefs/?ref=sredevops.org) ). It supports several data access protocols, such as **S3, POSIX, and HDFS,** and supports two *storage engines* : multi-replica and [erasure code](https://blog.min.io/erasure-coding/?ref=sredevops.org) . It provides users with multiple functions such as multi-tenancy, multi-AZ deployment, and cross-region replication, and is widely used in scenarios such as big data, AI, container platforms, databases, middleware storage and computing separation, data sharing and data protection. ## Deployment Architecture ![](https://www.sredevops.org/content/images/2024/08/image-1.png) [CubeFS | A Cloud Native Distributed Storage SystemCubeFS is a distributed file system and object storage service for cloud native applications.![](https://cubefs.io/icon/favicon.ico)A Cloud Native Distributed Storage System![](https://cubefs.io/images/github-small.svg)](https://cubefs.io/docs/master/deploy/k8s.html?ref=sredevops.org#deployment-architecture) ## Why CubeFS? ### Multiprotocol Supports various access protocols such as S3, POSIX and HDFS, and access between protocols is interoperable. - **POSIX Compatible** : Compatible with the POSIX interface, making application development extremely simple for upper-layer applications, as convenient as using a local file system. Additionally, CubeFS relaxed the consistency requirements of POSIX semantics during implementation to balance the performance of file and metadata operations. - **S3 Compatible** – Supporting the AWS S3 object storage protocol, users can use the native Amazon S3 SDK to manage resources in CubeFS. - **Compatible with HDFS** : Compatible with the Hadoop FileSystem interface protocol, users can use CubeFS to replace the Hadoop file system (HDFS) without affecting the upper layer business. ### Multi-engine By supporting two engines: multi-replica and erasure coding, users can flexibly choose according to their business scenarios. - **Multi-replica storage engine** : Data between copies is in a mirror relationship, and data consistency between copies is ensured through a highly consistent replication protocol. Users can flexibly configure different numbers of copies according to their application scenarios. - **Erasure Coding Storage Engine** ：The erasure coding engine has the characteristics of high reliability, high availability, low cost, and supports ultra-large scale (EB). According to different AZ models, erasure coding modes can be flexibly selected. ### Multi-user Support multi-tenant management and provide detailed tenant isolation policies. ### Highly scalable You can easily build distributed storage services with PB or EB level scale, and each module can be scaled horizontally. ### High performance CubeFS supports multi-level caching to optimize access to small files and supports multiple high-performance replication protocols. - **Metadata Management** \- The metadata cluster uses in-memory metadata storage and uses two B-trees (inodeBTree and dentryBTree) to manage indexes and improve metadata access performance. - **Strong consistency replication protocol** ：CubeFS adopts different replication protocols according to the file writing mode to ensure data consistency between replicas. If the file is written sequentially, the primary-backup replication protocol is used to optimize I/O performance. If the file is randomly written to overwrite the contents of the existing file, a Multi-Raft based replication protocol is used to ensure high data consistency. - **Multi-level caching** – Erasure coding volume supports multi-level caching acceleration capability to provide higher data access performance for hot data: - Local Cache: The BlockCache component can be deployed on the client machine as a local cache using the local disk. It can directly read the local cache without going through the network, but the capacity is limited by the local disk. - Global Cache: A distributed global cache created with the DataNode replication component. For example, a DataNode with an SSD deployed in the same data center as the client can be used as a global cache. Compared with the local cache, it needs to go through the network, but it has a larger capacity and can be dynamically scaled, and the number of replicas can be adjusted. ## Cloud Native Based on the CSI [(Container Storage Interface](https://kubernetes.io/blog/2019/01/15/container-storage-interface-ga/?ref=sredevops.org) ) standard, CubeFS is easily integrated and deployed in Kubernetes. ## Use cases and scenarios As a cloud-native distributed storage platform, CubeFS provides multiple access protocols, so you can use it in different situations, let's list: ### Big data analysis Compatible with the HDFS protocol, CubeFS provides a unified storage foundation for the Hadoop ecosystem (such as Spark and Hive), providing unlimited storage space and high-bandwidth data storage capabilities for computing engines. ### Deep Learning/Machine Learning As a distributed parallel file system, CubeFS supports AI training, model storage and distribution, I/O acceleration, and other requirements. ### Shared storage between containers The container cluster can store the configuration files or initialization load data of container images in CubeFS, and read them in real time when batch loading containers. Multiple PODs can share persistent data through CubeFS, and rapid failover can be performed in case of POD failure. ### Databases and middleware Provides high-concurrency, low-latency cloud disk services for database applications such as MySQL, ElasticSearch, and ClickHouse, achieving complete separation between storage and compute. ### Online services Provides high-reliability, low-cost object storage services for online businesses (such as advertising, clickstreams, and searches) or end-user graphic, text, audio, and video content. ### From NAS (Network Attached Storage) to the cloud It replaces traditional local storage and offline NAS and facilitates cloud adoption strategies. ## Source: [https://cubefs.io/docs/master/overview/introduction.html](https://cubefs.io/docs/master/overview/introduction.html?ref=sredevops.org) [CubeFS | A Cloud Native Distributed Storage SystemCubeFS is a distributed file system and object storage service for cloud native applications.![](https://www.sredevops.org/content/images/icon/favicon-15.ico)A Cloud Native Distributed Storage System![](https://www.sredevops.org/content/images/thumbnail/github-small-2.svg)](https://cubefs.io/docs/master/overview/introduction.html?ref=sredevops.org) ### Rig.dev é uma plataforma de aplicativos de código aberto para simplificar a experiência dos desenvolvedores com Kubernetes URL: https://www.sredevops.org/br/rig-dev-e-uma-plataforma-de-aplicativos-de-codigo-aberto-para-simplificar-a-experiencia-dos-desenvolvedores-com-kubernetes/ Last updated: 2023-11-16T03:35:14.000Z Rig.dev oferece uma plataforma de aplicativos de código aberto para Kubernetes como uma solução auto-hospedada gratuita ou como uma plataforma gerenciada paga. O código-fonte está disponível em seus repositórios Github e é licenciado sob [licença Apache 2.0](https://www.sredevops.org/es/licencias-opensource-que-significan-y-como-puedo-utilizarlas/) . [GitHub - rigdev/rig: Rig.dev é uma plataforma de aplicativos centrada no desenvolvedor para Kubernetes ⛵Rig.dev é uma plataforma de aplicativos centrada no desenvolvedor para Kubernetes ⛵ - GitHub - rigdev/rig: Rig.dev é uma plataforma de aplicativos centrada no desenvolvedor para Kubernetes ⛵![](https://github.githubassets.com/assets/pinned-octocat-093da3e6fa40.svg)do GitHubRigdev![](https://opengraph.githubassets.com/916a3110c9133aa75a6e32b46f5b84cf1ff6ae41a59da6c4ac895b8515543cbd/rigdev/rig)](https://github.com/rigdev/rig?ref=sredevops.org) O objetivo é ajudar os desenvolvedores a trabalhar em seus próprios ambientes elevados com abstrações de aplicativos, ao mesmo tempo em que aproveitam a confiabilidade, portabilidade e escalabilidade do Kubernetes. Um dos principais recursos é um *mecanismo de implantação amigável ao desenvolvedor,* quesimplifica o processo de implantação, gerenciamento, depuração e dimensionamento de aplicativos. Além disso, possui **APIs básicas para gerenciamento de usuários, autenticação, armazenamento e integrações de banco de dados** . Todos os itens acima podem ser gerenciados através de um Dashboard, CLI, também possui vários pipelines de CI/CD que integram Rig.dev com GitHub Actions quase nativamente. A lógica está estruturada em “Cápsulas”, descrita como: > Uma Cápsula contém um pacote de recursos que serão implantados como uma unidade. Esses recursos são > > \- Uma imagem Docker > \- Variáveis ambientais > \- Configuração de rede (balanceador de carga/entrada) > \- Middleware de rede para lidar, por exemplo, com autenticação > \- Número de réplicas > > Se você estiver familiarizado com o Kubernetes, as cápsulas podem ser consideradas como contendo tudo (implantação, serviço, entrada, etc.) necessário para executar e gerenciar seu aplicativo. Verifique você mesmo seus documentos: [Guia de configuração |Instalação do cluster![](https://docs.rig.dev/img/favicon.ico)Logotipo da plataforma![](https://rig.dev/img/docusaurus-social-card.jpg)](https://docs.rig.dev/operator-manual/setup-guide/?ref=sredevops.org) ### Rig.dev it's an open source application platform to simplify developers experience with Kubernetes URL: https://www.sredevops.org/en/rig-dev-its-an-open-source-application-platform-to-simplify-developers-experience-with-kubernetes/ Last updated: 2024-10-25T13:35:45.000Z Rig.dev offers an open-source application platform for Kubernetes as a free self-hosted solution or as a paid managed platform. The source code is available in their Github repositories and it's licensed under [Apache 2.0 license](https://www.sredevops.org/es/licencias-opensource-que-significan-y-como-puedo-utilizarlas/). [GitHub - rigdev/rig: The DevEx & Application-layer for your Internal Developer Platform ⛵The DevEx & Application-layer for your Internal Developer Platform ⛵ - rigdev/rig![](https://github.githubassets.com/assets/pinned-octocat-093da3e6fa40.svg)GitHubrigdev![](https://opengraph.githubassets.com/a7393bfa3574ee3d55b2a1ce1ba0e782067db17c53ac974524da31da7214cae5/rigdev/rig)](https://github.com/rigdev/rig?ref=sredevops.org) The purpose is to help developers to work in their own environments with elevated application abstractions, while still leveraging Kubernetes's reliability, portability, and scalability. One of the key features is a *developer-friendly deployment engine,* whichsimplifies the process of rolling out, managing, debugging and scaling applications. Also, it has a foundational **APIs for user management, authentication, storage, and database integrations**. All of the above can be managed through a Dashboard, CLI, also has several CI/CD pipelines which integrate Rig.dev with GitHub Actions almost natively. The logic is structured under "Capsules", described as: > A Capsule contains a bundle of resources which will be deployed as a unit. Those resources are > > \- A Docker image > \- Environment variables > \- Networking configuration (load balancer/ingress) > \- Networking middleware to handle e.g. authentication > \- Number of replicas > > If you are familiar with Kubernetes, Capsules can be thought of as containing everything (deployment, service, ingress, etc.) needed to run and manage your application. [Read the docs](#), or just try it our using a local [KinD cluster](https://kind.sigs.k8s.io/docs/user/quick-start/?ref=sredevops.org) using their script: ```bash #!/usr/bin/env bash set -e parent_path=$( cd "$(dirname "${BASH_SOURCE[0]}")" ; pwd -P ) KIND="${KIND:=kind}" KUBECT="${KUBECTL:=kubectl --context kind-rig}" HELM="${HELM:=helm --kube-context kind-rig}" # Create kind cluster ${KIND} get clusters | grep "^rig$" || \ cat < ## Issue Details > > A security issue was identified in ingress-nginx where the nginx.ingress.kubernetes.io/configuration-snippet annotation on an Ingress object (in the `networking.k8s.io` or `extensions` API group) can be used to inject arbitrary commands, and obtain the credentials of the ingress-nginx controller. In the default configuration, that credential has access to all secrets in the cluster. > > \*\*This issue has been rated High \*\*(CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:L), and assigned CVE-2023-5043. > > ## Affected Components and Configurations > > This bug affects ingress-nginx. If you do not have ingress-nginx installed on your cluster, you are not affected. You can check this by running `kubectl get po -n ingress-nginx`. > > If you are running the “chrooted” ingress-nginx controller introduced in v1.2.0 (gcr.io/k8s-staging-ingress-nginx/controller-chroot), command execution is possible but credential extraction is not, so the High severity does not apply. > > Multi-tenant environments where non-admin users have permissions to create Ingress objects are most affected by this issue. > > ## Affected Versions > > > ## Versions allowing mitigation > > v1.9.0 > > ## Mitigation > > Ingress Administrators should set the --enable-annotation-validation flag to enforce restrictions on the contents of ingress-nginx annotation fields. > > ## Detection > > If you find evidence that this vulnerability has been exploited, please contact [secu...@kubernetes.io](mailto:secu...@kubernetes.io) > > ## Additional Details > > See ingress-nginx Issue #10571 for more details. > > ## Acknowledgements > > This vulnerability was reported by suanve > > \*Thank You, > > CJ Cullen on behalf of the Kubernetes Security Response Committee\* Fonte: [\[Aviso de segurança do Ingress-nginx\] CVE-2023-5043: A injeção de anotação nginx do Ingress causa execução arbitrária de comandos![](https://ssl.gstatic.com/images/branding/product/1x/groups_32dp.png)Grupos do Google![](https://lh3.googleusercontent.com/a-/ALV-UjWdDA3Er5e9jjvy_VnQzX-WFZUuFbqGiFS1L7mwV91bsXg=s40-c)](https://groups.google.com/g/kubernetes-announce/c/n5o0uQwykaw?ref=sredevops.org) ### Brecha crítica de seguridad, usada en miles de entornos, es revelada en nginx-ingress [CVE-2023-5043: annotation injection causes arbitrary command execution] URL: https://www.sredevops.org/es/brecha-critica-de-seguridad-usada-en-miles-de-entornos-es-revelada-en-nginx-ingress-cve-2023-5043-annotation-injection-causes-arbitrary-command-execution/ Last updated: 2026-01-08T02:36:19.000Z Si utilizas nginx como ingress controller y mantienes configuraciones via annottations, debes revisar esta alerta publicada en [Kubernetess "Official" Google Group:](https://groups.google.com/g/kubernetes-announce/c/n5o0uQwykaw?ref=sredevops.org), hoy 25 de Octubre 2023: > ## Issue Details > > A security issue was identified in ingress-nginx where the nginx.ingress.kubernetes.io/configuration-snippet annotation on an Ingress object (in the `networking.k8s.io` or `extensions` API group) can be used to inject arbitrary commands, and obtain the credentials of the ingress-nginx controller. In the default configuration, that credential has access to all secrets in the cluster. > > \*\*This issue has been rated High \*\*(CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:L), and assigned CVE-2023-5043. > > ## Affected Components and Configurations > > This bug affects ingress-nginx. If you do not have ingress-nginx installed on your cluster, you are not affected. You can check this by running `kubectl get po -n ingress-nginx`. > > If you are running the “chrooted” ingress-nginx controller introduced in v1.2.0 (gcr.io/k8s-staging-ingress-nginx/controller-chroot), command execution is possible but credential extraction is not, so the High severity does not apply. > > Multi-tenant environments where non-admin users have permissions to create Ingress objects are most affected by this issue. > > ## Affected Versions > > > ## Versions allowing mitigation > > v1.9.0 > > ## Mitigation > > Ingress Administrators should set the --enable-annotation-validation flag to enforce restrictions on the contents of ingress-nginx annotation fields. > > ## Detection > > If you find evidence that this vulnerability has been exploited, please contact [secu...@kubernetes.io](mailto:secu...@kubernetes.io) > > ## Additional Details > > See ingress-nginx Issue #10571 for more details. > > ## Acknowledgements > > This vulnerability was reported by suanve > > \*Thank You, > > CJ Cullen on behalf of the Kubernetes Security Response Committee\* Fuente: [\[Ingress-nginx Security Advisory\] CVE-2023-5043: Ingress nginx annotation injection causes arbitrary command execution![](https://ssl.gstatic.com/images/branding/product/1x/groups_32dp.png)Google Groups![](https://lh3.googleusercontent.com/a-/ALV-UjWdDA3Er5e9jjvy_VnQzX-WFZUuFbqGiFS1L7mwV91bsXg=s40-c)](https://groups.google.com/g/kubernetes-announce/c/n5o0uQwykaw?ref=sredevops.org) ### OpenTF agora é OpenTofu e faz parte da Linux Foundation, agora você pode usar o primeiro alfa! URL: https://www.sredevops.org/br/opentf-agora-e-opentofu-e-faz-parte-da-linux-foundation-agora-voce-pode-usar-o-primeiro-alfa/ Last updated: 2024-09-22T13:48:03.000Z Recentemente contamos por que o Terraform estava morto - pelo menos para a comunidade Open Source -, por que a confiança e a responsabilidade de todos os atores do ecossistema de código aberto são importantes. [Aqui você pode ver nosso post sobre a Morte do Terraform](https://www.sredevops.org/es/terraform-ha-muerto-larga-vida-a-opentf/) . [Terraform ha muerto, ¡Larga vida a OpenTF!(O del por qué es tan importante la comunidad Open Source) En este momento histórico, en que la tecnología está transformando rápidamente nuestro mundo, es fundamental que las personas y organizaciones se comprometan a promover prácticas éticas y sostenibles en su desarrollo y uso. Puedes ver klos detalles del roadmap![](https://www.sredevops.org/content/images/icon/Icon-App-76x76@2x.png)SREDevOps.orgNicolás Georger![](https://www.sredevops.org/content/images/thumbnail/on-dark.png)](https://www.sredevops.org/es/terraform-ha-muerto-larga-vida-a-opentf/) ### Vamos direto ao ponto Agora você pode experimentar a segunda versão alfa, verifique seu sistema operacional e arquitetura aqui: [Versão v1.6.0-alpha2 · opentofu/opentofuEi, muito tempo sem nos ver! Embora tenhamos tido nosso primeiro lançamento alfa ontem, foi relatado um problema que poderia ter impactado negativamente a capacidade da comunidade de testar o OpenTofu com…![](https://github.githubassets.com/pinned-octocat.svg)GitHubaberto![](https://opengraph.githubassets.com/d137974f4cfd78e0bbba575bad3c9e3224c6fa8a5f8440a58f94fdf13b9e90f0/opentofu/opentofu/releases/tag/v1.6.0-alpha2)](https://github.com/opentofu/opentofu/releases/latest?ref=sredevops.org) ### OpenTF ahora es OpenTofu y es parte de Linux Foundation, ¡ya puedes usar el primer alpha! URL: https://www.sredevops.org/es/opentf-ahora-es-opentofu-y-es-parte-de-linux-foundation-ya-puedes-usar-el-primer-alpha/ Last updated: 2026-01-08T02:36:35.000Z Hace poco te contábamos por qué Terraform estaba muerto -al menos para la comunidad Open Source-, el por qué es importante la confianza y la responsabilidad de todos los actores en el ecosistema de código abierto. [Aquí puedes ver nuestra publicación de la muerte de Terraform](https://www.sredevops.org/es/terraform-ha-muerto-larga-vida-a-opentf/). [Terraform ha muerto, ¡Larga vida a OpenTF!(O del por qué es tan importante la comunidad Open Source) En este momento histórico, en que la tecnología está transformando rápidamente nuestro mundo, es fundamental que las personas y organizaciones se comprometan a promover prácticas éticas y sostenibles en su desarrollo y uso. Puedes ver klos detalles del roadmap![](https://www.sredevops.org/content/images/icon/Icon-App-76x76@2x.png)SREDevOps.orgNicolás Georger![](https://www.sredevops.org/content/images/thumbnail/on-dark.png)](https://www.sredevops.org/es/terraform-ha-muerto-larga-vida-a-opentf/) ### Vamos al grano Ya puedes probar el segundo alpha release, revisa tu sistema operativo y arquitectura aquí: [Release v1.6.0-alpha2 · opentofu/opentofuHey, long time no see! Even though we’ve had our first alpha release just yesterday, there was an issue reported that could’ve negatively impacted the ability of the community to test OpenTofu with…![](https://github.githubassets.com/pinned-octocat.svg)GitHubopentofu![](https://opengraph.githubassets.com/d137974f4cfd78e0bbba575bad3c9e3224c6fa8a5f8440a58f94fdf13b9e90f0/opentofu/opentofu/releases/tag/v1.6.0-alpha2)](https://github.com/opentofu/opentofu/releases/latest?ref=sredevops.org) ### Segurança em CI/CD e Pipelines: 3 abordagens fáceis para "Segurança Contínua" URL: https://www.sredevops.org/br/seguranca-em-ci-cd-e-pipelines-3-abordagens-faceis-para-seguranca-continua-e-nao-diga-que-voce-foi-roubado/ Last updated: 2023-10-08T11:26:16.000Z A segurança de CI/CD é um tópico cada vez mais importante à medida que os pipelines de CI/CD se tornam mais complexos e seu uso se expande. Portanto **, as superfícies de ataque são dinâmicas** e exigem um foco cultural e técnico, não possuindo apenas processos tediosos e muitas vezes absurdos que apenas garantem que os equipamentos se desgastem rapidamente e as empresas paguem pelas próprias perdas e até as multipliquem. Para enfrentar esse cenário, as equipes – e não apenas as equipes de segurança – precisam adotar uma abordagem holística que **proteja todo o fluxo de CI/CD,** desde o código-fonte até a produção, por meio de nossos pipelines. Isso inclui: - **Segurança *no* pipeline** : certifique-se de que o código enviado para produção esteja livre de vulnerabilidades e configurações incorretas. Isto pode ser conseguido através do uso de ferramentas automatizadas de verificação de segurança, bem como de controles manuais, como revisões de código e, [particularmente, a abordagem "shift left" ou também conhecida como DevSecOps.](https://github.blog/2020-08-13-secure-at-every-step-a-guide-to-devsecops-shifting-left-and-gitops/?ref=sredevops.org) - ***Pipeline* Security (Security Of Pipeline)** : protege os sistemas e ferramentas que compõem o próprio pipeline contra ataques e vulnerabilidades. Isso inclui medidas como gerenciamento de permissões e políticas de acesso, monitoramento, alertas, rotação de credenciais e o princípio do “menor privilégio possível”. - **Segurança *em todo o pipeline*** : Compreender o fluxo do seu ciclo significa saber que todas as suas medições podem simplesmente *ser ignoradas* ou ignoradas, com o consequente “acesso direto” à produção. Você pode mitigar riscos implementando RBAC (Role Based Access Control), e de forma genérica, políticas de isolamento de rede e conectividade diferenciada, com monitoramento persistente/alertas de acesso e acima de tudo, implementar GitOps, evitando que seus ambientes de execução exijam acesso por diferentes funções, mas sim que esse ambiente não é o responsável por "buscar o recurso para implantar" em um ponto externo, geralmente um repositório git. modelagem de tráfego., a implementação de bastion hosts e o monitoramento de fluxos de tráfego atípicos. ![Segurança em CI/CD e Pipelines: 3 abordagens fáceis para "Segurança Contínua" e não diga que você foi "roubado"](https://dt-cdn.net/wp-content/uploads/2022/01/13429_ILL_DevOpsLoop_shiftleft_shiftright-1.jpg) O QUE é “deslocar para a esquerda” e “deslocar para a direita”? Fonte: [https://www.dynatrace.com/news/blog/what-is-shift-left-and-what-is-shift-right/](https://www.dynatrace.com/news/blog/what-is-shift-left-and-what-is-shift-right/?ref=sredevops.org) Uma abordagem holística à segurança de CI/CD requer a cooperação das equipes de segurança, desenvolvimento e operações, mas, acima de tudo, ter uma organização que apoie e compreenda o valor crítico que a cultura e o conhecimento de segurança representam nos negócios. **Aqui estão algumas dicas adicionais para melhorar a segurança de CI/CD:** - **Use uma estrutura de segurança CI/CD.** Existem várias estruturas disponíveis que podem ajudar as organizações a implementar uma abordagem holística à segurança de CI/CD. Essas estruturas fornecem uma série de controles e recomendações que podem ajudar as organizações a reduzir sua superfície de ataque. - **Implemente revisões de segurança automatizadas.** As revisões de segurança automatizadas podem ajudar as equipes a identificar e corrigir vulnerabilidades de forma rápida e eficiente. Essas revisões podem ser realizadas em código-fonte, artefatos de construção e arquivos de configuração. - **Monitore os fluxos de dados.** É importante monitorar os fluxos de dados através do pipeline de CI/CD para detectar anomalias que possam indicar um ataque. Isso pode ser feito usando sistemas de detecção de intrusão (IDS) e sistemas de detecção de malware (IDS). - **Implemente controles de acesso granulares.** É importante implementar controles de acesso granulares para restringir o acesso aos sistemas e ferramentas de CI/CD a usuários autorizados. Isso pode ajudar a impedir que invasores explorem vulnerabilidades para obter acesso ao pipeline. - **Segurança .** É importante educar os funcionários sobre os riscos de segurança do CI/CD e as medidas que podem tomar para se protegerem. Isso pode incluir treinamento sobre práticas recomendadas de segurança de código, gerenciamento de acesso e higiene de credenciais. Seguindo essas dicas, as organizações podem melhorar significativamente a segurança de seus pipelines de CI/CD e proteger seus aplicativos e cadeias de fornecimento de software contra ataques. ***Baseado na coluna de Bill Doerrfeld*** ![Segurança em CI/CD e Pipelines: 3 abordagens fáceis para "Segurança Contínua" e não diga que você foi "roubado"](https://devops.com/wp-content/uploads/2021/10/android-chrome-256x256-1-254x254.png) ### GNU completa 40 anos! 🎉... Mas quem é esse tal do Gnu? 🤔 Você já o conhece bem! URL: https://www.sredevops.org/br/gnu-completa-40-anos-mas-quem-e-esse-tal-do-gnu-voce-ja-o-conhece-bem/ Last updated: 2023-10-01T14:36:34.000Z Quarenta anos de GNU e o movimento do software livre GNU, o sistema operacional de software livre semelhante ao Unix, completa 40 anos este ano. Isso mesmo, 40 anos de liberdade para rodar, copiar, distribuir, estudar, alterar e melhorar nossos softwares! Para comemorar, a Free Software Foundation (FSF) realizará um evento especial em Biel, na Suíça, no dia 27 de setembro. Haverá apresentações de desenvolvedores GNU, sessões de hacking e muito mais. Então, seja você um hacker experiente ou um iniciante, junte-se a nós para comemorar o 40º aniversário do GNU! É um momento para refletir sobre o progresso que fizemos e olhar para o futuro do software livre. **GNU e Linux: uma breve introdução** GNU e Linux são dois componentes essenciais dos sistemas operacionais GNU/Linux, que são os sistemas operacionais mais populares do mundo. **GNU** é um sistema operacional semelhante ao Unix desenvolvido pelo Projeto GNU. É composto por uma grande coleção de programas de computador de software livre, incluindo um compilador, um editor de texto, um navegador web, um servidor web e muito mais. **Linux** é um kernel de sistema operacional de código aberto desenvolvido por Linus Torvalds. É um núcleo monolítico que gerencia recursos de hardware e fornece uma interface para os programas do usuário interagirem com o sistema. **Relação entre GNU e Linux** GNU e Linux são dois componentes essenciais dos sistemas operacionais GNU/Linux. GNU fornece a maioria das ferramentas e aplicativos que os usuários precisam para trabalhar em um sistema operacional, enquanto o Linux fornece o núcleo que gerencia o hardware e os aplicativos. Na prática, a maioria dos sistemas operacionais GNU/Linux são distribuídos como distribuições, que são pacotes de software que incluem GNU, Linux e outros programas de software. **Conclusões** GNU e Linux são dois projetos de software livre que revolucionaram a computação. Juntos, eles forneceram aos usuários um sistema operacional poderoso, flexível e gratuito. **Ligações** - GNU: [https://www.gnu.org/](https://www.gnu.org/?ref=sredevops.org) - Linux: [https://www.kernel.org/](https://www.kernel.org/?ref=sredevops.org) - GNU/Linux: [https://www.gnu.org/gnu/linux-and-gnu.html](https://www.gnu.org/gnu/linux-and-gnu.html?ref=sredevops.org) Não importa onde você esteja, junte-se a nós para comemorar o 40º aniversário do GNU! É um momento para refletir sobre o progresso que fizemos e olhar para o futuro do software livre. Prêmios de Software Livre: Nomeie aqueles que inspiram você até 21 de novembro — Free Software Foundation — Trabalhando juntos pelo software livre [https://www.fsf.org/blogs/community/free-software-awards-nominate-those-who-inspire-you-by-nov-21](https://www.fsf.org/blogs/community/free-software-awards-nominate-those-who-inspire-you-by-nov-21?ref=sredevops.org) ### Seguridad en CI/CD y Pipelines: 3 enfoques fáciles para la "Seguridad Continua" y que no digas que "te jakiaron" URL: https://www.sredevops.org/es/seguridad-en-ci-cd-y-pipelines-3-enfoques-faciles-para-la-seguridad-continua-y-que-no-digas-que-te-jakiaron/ Last updated: 2026-01-08T02:35:55.000Z ## **"me hackearon..."* \- Anónimo ## Introducción La seguridad de los procesos de Integración Continua y Entrega Continua (CI/CD) se ha convertido en un tema cada vez más importante a medida que los pipelines de CI/CD se vuelven más complejos y su uso se extiende. Estas superficies de ataque dinámicas requieren un enfoque cultural y técnico, no solo tener procesos tediosos y a menudo absurdos que solo garantizan que los equipos se desgasten rápidamente y las empresas paguen por sus propias pérdidas e incluso las multipliquen. ![](https://dt-cdn.net/wp-content/uploads/2022/01/13429_ILL_DevOpsLoop_shiftleft_shiftright-1.jpg) QUé es "shift left" y "shift right"? Fuente: [https://www.dynatrace.com/news/blog/what-is-shift-left-and-what-is-shift-right/](https://www.dynatrace.com/news/blog/what-is-shift-left-and-what-is-shift-right/?ref=sredevops.org) Para enfrentar este escenario, los equipos, y no solo los equipos de seguridad, necesitan adoptar un enfoque holístico que proteja todo el flujo de CI/CD, desde el código fuente hasta la producción, a través de nuestros pipelines. Esto incluye tres enfoques clave: ### Seguridad En-Pipeline (Security In-The-Pipeline) Asegurar que el código que se envía a producción esté libre de vulnerabilidades y configuraciones erróneas. Esto se puede lograr mediante el uso de herramientas de escaneo de seguridad automatizadas, así como controles manuales, como revisiones de código y el enfoque "shift left" o también conocido como DevSecOps. ### Seguridad Del-Pipeline (Security Of Pipeline) Proteger los sistemas y herramientas que componen el pipeline en sí mismo contra ataques y vulnerabilidades. Esto incluye medidas como la gestión de políticas de permisos y accesos, monitoreo, alertas, credenciales rotativas y el principio del "menor privilegio posible". ### Seguridad Alrededor-del-Pipeline (Security Around the Pipeline) Comprender el flujo de tu ciclo implica saber que todas tus medidas pueden simplemente ser eludidas o bypasseadas, con el consiguiente "acceso directo" a producción. Puedes mitigar riesgos implementando RBAC (Control de Acceso Basado en Roles), políticas de aislamiento de redes y conectividades diferenciadas, con monitoreo persistente/alertas de accesos y, sobre todo, implementar GitOps, evitando que tus entornos de ejecución requieran ser accedidos por distintos roles, sino que dicho entorno no sea quien se responsabiliza de "ir a buscar el recurso a desplegar" a un punto externo, generalmente un repositorio git. Un enfoque holístico para la seguridad de CI/CD requiere la cooperación de los equipos de seguridad, desarrollo y operaciones, pero, sobre todo, contar con una organización que respalde y comprenda el valor crítico que representa la cultura y el conocimiento de la seguridad en el negocio. Algunos consejos adicionales para mejorar la seguridad de CI/CD: - Utilizar un framework de seguridad de CI/CD. Hay varios frameworks disponibles que pueden ayudar a las organizaciones a implementar un enfoque holístico. - Implementar revisiones de seguridad automatizadas. Las revisiones de seguridad automatizadas pueden ayudar a los equipos a identificar y remediar vulnerabilidades de forma rápida y eficiente. - Monitorizar los flujos de datos. Es importante monitorizar los flujos de datos a través de la pipeline de CI/CD para detectar anomalías que puedan indicar un ataque. - Implementar controles de acceso granulares. Es importante implementar controles de acceso granulares para restringir el acceso a los sistemas y herramientas de CI/CD a los usuarios autorizados. - Educar a los empleados sobre los riesgos de seguridad de CI/CD y las medidas que pueden tomar para protegerse. Al seguir estos consejos, las organizaciones pueden mejorar significativamente la seguridad de sus pipelines de CI/CD y proteger sus aplicaciones y cadenas de suministro de software de los ataques. ***Basado en la columna de Bill Doerrfeld*** [Bill Doerrfeld Articles and InsightsBill Doerrfeld lends us insights and views on DevOps in the following articles![](https://devops.com/wp-content/uploads/2021/10/android-chrome-256x256-1-254x254.png)DevOps.comNatan Solomon![](https://devops.com/wp-content/uploads/2018/11/Profile-shot-recent.jpg)](https://devops.com/author/bill-doerrfeld/?ref=sredevops.org) ### ¡GNU cumple 40 años! 🎉... ¿Pero quién es ese tal Ñu? 🤔 Ya lo conoces bien! URL: https://www.sredevops.org/es/gnu-cumple-40-anos-pero-quien-es-ese-tal-nu-ya-lo-conoces-bien/ Last updated: 2026-01-08T02:36:39.000Z Cuarenta años de GNU y el movimiento del software libre GNU, el sistema operativo Unix-like de software libre, cumple 40 años este año. ¡Así es, 40 años de libertad para ejecutar, copiar, distribuir, estudiar, cambiar y mejorar nuestro software! Para celebrarlo, la Free Software Foundation (FSF) organiza un evento especial en Biel, Suiza, el 27 de septiembre. Habrá presentaciones de desarrolladores de GNU, sesiones de piratería y más. Entonces, ya seas un hacker experimentado o un principiante completo, ¡únete a nosotros para celebrar el 40 aniversario de GNU! Es un momento para reflexionar sobre el progreso que hemos logrado y para mirar hacia el futuro del software libre. **GNU y Linux: una breve introducción** GNU y Linux son dos componentes esenciales de los sistemas operativos GNU/Linux, que son los sistemas operativos más populares del mundo. **GNU** es un sistema operativo de tipo Unix desarrollado por el Proyecto GNU. Está compuesto por una gran colección de programas informáticos de software libre, incluyendo un compilador, un editor de texto, un navegador web, un servidor web, y mucho más. **Linux** es un núcleo de sistema operativo de código abierto desarrollado por Linus Torvalds. Es un núcleo monolítico que gestiona los recursos del hardware y proporciona una interfaz para que los programas de usuario interactúen con el sistema. **Relación entre GNU y Linux** GNU y Linux son dos componentes esenciales de los sistemas operativos GNU/Linux. GNU proporciona la mayoría de las herramientas y aplicaciones que los usuarios necesitan para trabajar en un sistema operativo, mientras que Linux proporciona el núcleo que gestiona el hardware y las aplicaciones. En la práctica, la mayoría de los sistemas operativos GNU/Linux se distribuyen como distribuciones, que son paquetes de software que incluyen GNU, Linux, y otros programas de software. **Conclusiones** GNU y Linux son dos proyectos de software libre que han revolucionado la informática. Juntos, han proporcionado a los usuarios un sistema operativo potente, flexible, y gratuito. **Links** - GNU: [https://www.gnu.org/](https://www.gnu.org/?ref=sredevops.org) - Linux: [https://www.kernel.org/](https://www.kernel.org/?ref=sredevops.org) - GNU/Linux: [https://www.gnu.org/gnu/linux-and-gnu.html](https://www.gnu.org/gnu/linux-and-gnu.html?ref=sredevops.org) No importa dónde estés, ¡únete a nosotros para celebrar el 40 aniversario de GNU! Es un momento para reflexionar sobre el progreso que hemos logrado y para mirar hacia el futuro del software libre.Free Software Awards: Nominate those who inspire you by Nov 21 — Free Software Foundation — Working together for free software [https://www.fsf.org/blogs/community/free-software-awards-nominate-those-who-inspire-you-by-nov-21](https://www.fsf.org/blogs/community/free-software-awards-nominate-those-who-inspire-you-by-nov-21?ref=sredevops.org) ### Terraform está morto, viva o OpenTF! URL: https://www.sredevops.org/br/terraform-esta-morto-viva-o-opentf/ Last updated: 2023-09-19T07:50:58.000Z *(Ou porque a comunidade Open Source é tão importante)* Neste momento histórico, em que a tecnologia está a transformar rapidamente o nosso mundo, **é essencial que os indivíduos e as organizações se comprometam a promover práticas éticas e sustentáveis no seu desenvolvimento e utilização** . Você pode ver os detalhes do roteiro e manifesto do OpenTF aqui: ![O Terraform está morto, viva o OpenTF!](https://opentf.org/favicons/android-chrome-512x512.png) E no modo simples, o que aconteceu? [Sebastian Gebski](https://no-kill-switch.ghost.io/author/sebastian-gebski/?ref=sredevops.org) explica muito bem: ![O Terraform está morto, viva o OpenTF!](https://no-kill-switch.ghost.io/content/images/size/w256h256/2022/09/nks_square_white.png) > quando as cartas já foram distribuídas > Isto provavelmente lhes custará caro: como alguém que já violou a confiança da comunidade uma vez, você não será mais visto como um parceiro confiável. O que eles deveriam fazer em vez disso? Bem, a primeira opção seria começar com uma licença menos permissiva (para evitar criar falsas expectativas), mas uma vez cometido o erro, o caminho mais razoável seria solidificar a fronteira entre o produto aberto e o wrapper gerenciado em torno dele, para enfatizar o valor único que a HC poderia fornecer por si só. HC não fez isso; o fosso revelou-se muito raso. > [a bifurcação do Terraform está se tornando real](https://opentf.org/announcement?ref=no-kill-switch.ghost.io) ### Licenças OpenSource, o que significam e como posso usá-las? URL: https://www.sredevops.org/br/licencas-opensource-o-que-significam-e-como-posso-usa-las/ Last updated: 2023-09-19T07:48:32.000Z Aqui mostramos um quadro resumido das 10 licenças mais utilizadas dentro do Open Source e quais são suas principais características quanto ao seu uso em nossos projetos. ## Licenças OpenSource: tabela comparativa | Nome da licença | Iniciais | Permissivo/Copyleft | Reuso? | Modificar? | Uso comercial? | Patentes | | --------------------------------------------------- | -------- | ------------------- | ------ | ---------- | -------------- | -------- | | Licença Apache 2.0 | Apache2 | Permissivo | Sim | Sim | Sim | Sim | | Licença MIT | MIT | Permissivo | Sim | Sim | Sim | Não | | Licença BSD de 3 cláusulas | BSD3 | Permissivo | Sim | Sim | Sim | Não | | Licença Pública Geral GNU v3.0 | GPLv3 | Copyleft | Sim | Sim | Sim | Sim | | Licença Pública Geral GNU v2.0 | GPLv2 | Copyleft | Sim | Sim | Sim | Sim | | Licença Pública Geral Menor GNU v3.0 | LGPLv3 | Copyleft | Sim | Sim | Sim | Não | | Licença Pública Geral Menor GNU v2.1 | LGPLv2.1 | Copyleft | Sim | Sim | Sim | Não | | Licença Pública Mozilla 2.0 | MPLv2 | Permissivo | Sim | Sim | Sim | Sim | | Licença Pública Eclipse 2.0 | EPLv2 | Permissivo | Sim | Sim | Sim | Não | | Licença Comum de Desenvolvimento e Distribuição 1.1 | CDDLv1.1 | Permissivo | Sim | Sim | Sim | Não | ## Notas - As licenças permissivas permitem que os usuários façam o que quiserem com o software, inclusive usá-lo em software proprietário. - As licenças Copyleft exigem que quaisquer trabalhos derivados do software sejam licenciados sob os mesmos termos. - Reutilizar significa que os usuários podem distribuir livremente o software. - Modificável significa que os usuários podem modificar livremente o software. - Patentes especifica se a licença cobre patentes. - Uso comercial significa que os usuários podem usar o software para fins comerciais. ### Licencias OpenSource, qué significan y cómo puedo utilizarlas? URL: https://www.sredevops.org/es/licencias-opensource-que-significan-y-como-puedo-utilizarlas/ Last updated: 2026-01-08T02:36:39.000Z Aquí te mostramos una tabla resumen de las 10 licencias más utilizadas dentro del Open Source y cuáles son sus principales características respecto a su uso en nuestros proyectos. ## Licencias OpenSource: Tabla comparativa ### *Notas:* - Las licencias permisivas permiten a los usuarios hacer lo que quieran con el software, incluso usarlo en software propietario. - Las licencias copyleft exigen que cualquier obra derivada del software se licencie bajo los mismos términos. - Reutilizar significa que los usuarios pueden distribuir libremente el software. - Modificable significa que los usuarios pueden modificar libremente el software. - Patentes especifica si la licencia cubre patentes. - Uso comercial significa que los usuarios pueden usar el software para fines comerciales. | Nombre licencia | Sigla | Es permisiva? | Reutilizar? | Modificar? | Uso comercial? | Patentes | | -------------------------------------- | -------- | ------------- | ----------- | ---------- | -------------- | -------- | | Apache License 2.0 | Apache 2 | Permisiva | Si | Si | Si | Si | | MIT License | MIT | Permisiva | Si | Si | Si | No | | BSD 3-Clause License | BSD 3 | Permisiva | Si | Si | Si | No | | GNU General Public License v3.0 | GPLv3 | Copyleft | Si | Si | Si | Si | | GNU General Public License v2.0 | GPLv2 | Copyleft | Si | Si | Si | Si | | GNU Lesser General Public License v3.0 | LGPLv3 | Copyleft | Si | Si | Si | No | | GNU Lesser General Public License v2.1 | LGPLv2.1 | Copyleft | Si | Si | Si | No | | Mozilla Public License 2.0 | MPLv2 | Permisiva | Si | Si | Si | Si | | Eclipse Public License 2.0 | EPLv2 | Permisiva | Si | Si | Si | No | ### repo.com/microservices-project/feat/display-birthday-in-cfg URL: https://www.sredevops.org/br/repo-com-microservices-project-feat-display-birthday-in-cfg/ Last updated: 2023-09-06T01:59:48.000Z > *"Ainda não entendo por que é tão difícil exibir a data de aniversário.* > *na página de configurações... Por que não podemos implementar esse recurso neste trimestre?*" **Imperdível se você ainda não viu ;)** ### Terraform ha muerto, ¡Larga vida a OpenTF! URL: https://www.sredevops.org/es/terraform-ha-muerto-larga-vida-a-opentf/ Last updated: 2026-01-08T02:36:19.000Z *(O del por qué es tan importante la comunidad Open Source)* En este momento histórico, en que la tecnología está transformando rápidamente nuestro mundo, **es fundamental que las personas y organizaciones se comprometan a promover prácticas éticas y sostenibles en su desarrollo y uso**. Puedes ver klos detalles del roadmap y manifesto para OpenTF aquí: [OpenTF FoundationSupporting an impartial, open, and community-driven Terraform.![](https://opentf.org/favicons/android-chrome-512x512.png)![](https://opentf.org/images/og.png)](https://opentf.org/?ref=sredevops.org) Y en modo simple, ¿Qué pasó? [Sebastian Gebski](https://no-kill-switch.ghost.io/author/sebastian-gebski/?ref=sredevops.org) lo explica bastante bien: [Sebastian Gebski - No Kill SwitchGeek, agilista, blogger, codefella, serial reader. In the daylight - I navigate & lead software engineering. #lean #design #aws #elixir #analytics. I speak here for myself only.![](https://no-kill-switch.ghost.io/content/images/size/w256h256/2022/09/nks_square_white.png)No Kill SwitchHome![](https://no-kill-switch.ghost.io/content/images/2021/06/nks_bground.png)](https://no-kill-switch.ghost.io/author/sebastian-gebski/?ref=sredevops.org) > "HC ha subestimado algo. Quizás el potencial de competencia que ha crecido en torno a los productos que han creado. Quizás les haya sorprendido el nivel de éxito de estos productos. Es posible que hayan tenido otros modelos de negocios comerciales en mente, pero no funcionó. Así que, al final, han decidido cambiar las reglas del juego para los jugadores cuando las cartas ya están repartidas . Esas empresas han invertido mucho en herramientas como Terraform y esperan competir de manera justa envolviendo el proyecto comunitario con algún valor único que creen. Pero eso no fue lo suficientemente bueno para HC, quien aparentemente todavía trata a Terraform como su propio activo, no como un proyecto comunitario. Cuál está mal. > Esto probablemente les costará caro: como alguien que ya ha violado la confianza de la comunidad una vez, ya no será percibido como un socio confiable. ¿Qué deberían hacer en su lugar? Bueno, la primera opción sería comenzar con una licencia menos permisiva (para evitar crear falsas expectativas), pero una vez cometido el error, el camino más razonable sería solidificar el límite entre el producto abierto y el envoltorio gestionado a su alrededor, para enfatizar valor único que la HC podría proporcionar por sí sola. HC no hizo eso; el foso resultó ser demasiado poco profundo. > Ahora parece demasiado tarde. Se han lanzado los dados, se han creado las bases, se ha anunciado el manifiesto y [la bifurcación de Terraform se está volviendo real](https://opentf.org/announcement?ref=no-kill-switch.ghost.io) . Con toda la simpatía y respeto previos hacia HashiCorp, por el bien futuro del modelo y la comunidad OSS, sería mejor si tuviera éxito." ### repo.com/microservices-project/feat/display-birthday-in-cfg URL: https://www.sredevops.org/es/microservicios/ Last updated: 2026-01-08T02:36:35.000Z > *Todavía no entiendo por qué es tan difícil mostrar la fecha de cumpleaños.* > *en la página de configuración... ¿Por qué no podemos implementar esta función este trimestre?* **Imperdible si aún no lo has visto ;)** ### Google NeXT 2023 ya comenzó, puedes ver aquí la conferencia URL: https://www.sredevops.org/es/google-next-2023-ya-comenzo-pueder-ver-aqui-la-conferenciagoogle-next-2023-ya-comenzo-puedes-ver-aqui-la-conferencia/ Last updated: 2026-01-08T02:36:36.000Z [Experience Google Cloud Next ’23Google Cloud Next ’23 is back - in person on August 29-31 in San Francisco! Connect with me and 15,000+ peers for product announcements, sneak peeks into future roadmaps, on-site demos with experts and partners, plus hands-on training & certification opportunities. g.co/cloudnext![](https://storage.googleapis.com/next21-assets/event-assets/favicon.png)Next CloudGoogle Cloud![](https://storage.googleapis.com/next21-assets/event-assets/social-share/social-share-23.png)](https://cloud.withgoogle.com/next?utm%5Fsource=copylink&utm%5Fmedium=social) [SREDevOpsOrgNoticias, Tutoriales, Información, Comunidad DevOps, Site Reliability Engineering (SRE) y Platform Engineering 🌎 🇨🇱 🇧🇷 🇪🇸![](https://www.youtube.com/s/desktop/fc8159e8/img/favicon_144x144.png)YouTube![](https://yt3.googleusercontent.com/XYp2mksvAZFTQIS5bEZBV8qKTBmAE_eNSEbxgHL2GpZjmnF3F6B-r3HJy2oVvFK5whBimnpsvQ=s900-c-k-c0x00ffffff-no-rj)](https://www.youtube.com/@sredevopsorg/?ref=sredevops.org) ### O que é Web Assembly (WASM) e para que serve? URL: https://www.sredevops.org/br/o-que-e-web-assembly-wasm-e-para-que-serve/ Last updated: 2024-07-02T07:29:01.000Z Você já ouviu falar em WebAssembly (Wasm)? **Resumindo: é uma nova forma de onde e como o código-fonte é processado, movendo a carga das instâncias da nuvem (ou ser vidores, etc.) para o navegador do usuário final através de “micro sandboxes” que irão compilar o aplicativo.** Imagine que Wasm é um ator que pode se comunicar nativamente com os navegadores atuais. Uma espécie de tradutor que permite que certas linguagens de programação *– como C/C++, C# e Rust –* falem a “linguagem da web”. O interessante é que ele faz isso de forma muito eficiente, rodando na velocidade que o navegador permite. Além disso, Wasm é um agente *muito cuidadoso* . Quando está em ação, garante que não atrapalhe ou cause conflitos com o navegador. Ele fica em seu próprio espaço, como se estivesse em sua própria bolha, teoricamente isolado do restante do sistema (sandbox). E o que isso tem a ver com o mundo “Cloud Native”? Permite que aplicações em nuvem deleguem custos (tempo, recursos, tráfego... sim, também faturamento) contribuindo para aplicações mais eficientes, seguras e fáceis de gerenciar tanto para os usuários quanto para todos nós que sofremos com pipelines, implantações e blablabla. Vamos falar de eficiência. Era uma Fórmula 1? Bem, é isso que Wasm faz. Converte programas em um formato especial que pode ser executado diretamente pela máquina, sem desvios desnecessários. Quando se trata de segurança, Wasm é como alguém que se sente mais confortável em sua própria casa. Ele não sai de sua área e não vai bisbilhotar onde não deveria. Isso significa que ele não mexe com o sistema operacional nem causa problemas no navegador. Tranquilidade total. E em termos de escalabilidade, Wasm é como aquela peça versátil que você pode usar em qualquer ocasião. Funciona em qualquer lugar que aceite WebAssembly. Você precisa que seu aplicativo cresça? Wasm pode se adaptar às mudanças. Finalmente, aqui estão exemplos concretos de como o Wasm é usado em aplicações Cloud Native: - **Microsserviços:** pense nos microsserviços como pequenos ajudantes que realizam tarefas específicas. Wasm oferece treinamento especial para serem eficientes e seguros no mundo da nuvem. - **Micro front-ends:** São como capítulos de um livro, mas para aplicativos. Wasm os torna portáteis para funcionar em qualquer navegador. Assim de simples. - **Inteligência Artificial e Aprendizado de Máquina:** Você se lembra dos filmes em que as máquinas parecem pensar? Wasm permite que modelos de aprendizado de máquina façam sua mágica na nuvem. Resumindo, Wasm é como um vislumbre do futuro dos aplicativos em nuvem. Mas atenção... ## Riscos e ameaças O último risco para o WebAssembly que gostaria de apontar me preocupa e me assusta porque já vi isso acontecer com muita frequência. Isso me assusta porque o ego, as más práticas, o *“não tocar porque não”,* o **sigilo e o desprezo pelos outros podem levar a isso** . E isso me assusta porque o pensamento da velha escola em **"capturar um mercado" (olá Microsoft),** muitas vezes resulta em seguir um curso de ação que resulta em... > **Fragmentação.** Isto ocorre quando uma tecnologia central é cooptada por muitas partes, cada uma tentando tornar a sua implementação incompatível com as outras. Às vezes, a incompatibilidade é feita “em nome da rapidez” ou do cumprimento de critérios de curto prazo. *"Precisávamos sair do padrão para atender à demanda dos clientes."* Outras vezes, surge como uma resposta aos concorrentes: *“Decidimos não compartilhar o código-fonte para obter vantagem competitiva”.* Infelizmente, por vezes é simplesmente devido à ignorância e à falta de envolvimento da comunidade. ### Qué es Web Assembly (WASM) y para qué sirve? URL: https://www.sredevops.org/es/que-es-web-assembly-wasm-y-para-que-sirve/ Last updated: 2026-01-08T02:36:40.000Z ¿Has oído hablar de WebAssembly (Wasm)? **En simple: Es una nueva forma de dónde y cómo se procesa el código fuente, moviendo la carga desde cloud instances (o servidores, etc) hacia el navegador del usuario final a través de "micro sandboxes" que compilarán la app.** Imagina que Wasm es un actor que puede comunicarse con los navegadores actuales nativamente. Una suerte de traductor que permite que ciertos lenguajes de programación *\-como C/C++, C# y Rust-*, hablen el "idioma de la web". La parte interesante es que lo hace de manera muy eficiente, corriendo tan rápido como lo permita el navegador. Además, Wasm es un agente *muy cuidadoso*. Cuando está en acción, se asegura de que no mete la pata ni causa conflictos con el navegador. Se mantiene en su propio espacio, como si estuviera en su propia burbuja, teóricamente aislado del resto del sistema (sandbox). ### ¿Y qué tiene que ver esto con el mundo "Cloud Native"? Permite que aplicaciones en la nube deleguen costos (tiempo, recursos, tráfico... si, también billing) contribuyendo a aplicaciones más eficientes, seguras y fáciles de manejar tanto a usuarios como a todos nosotros que sufrimos con los pipelines, deployments y blablabla. ### Hablemos de eficiencia ¿Wasm un Formula 1? Bueno, eso es lo que Wasm hace. Convierte los programas en un formato especial que puede ser ejecutado directamente por la máquina, sin dar rodeos innecesarios. ### Y respecto a la seguridad? Wasm es como alguien que se siente más cómodo en su propia casa. No sale de su zona y no anda husmeando donde no debe. Eso significa que no se mete con el sistema operativo ni causa problemas en el navegador. Tranquilidad total. ### Y en términos de escalabilidad? Wasm es como esa prenda versátil que puedes usar en cualquier ocasión. Funciona en cualquier lugar que acepte WebAssembly. ¿Necesitas que tu aplicación crezca? Wasm puede adaptarse al cambio. Por último, aquí tienes ejemplos concretos de cómo Wasm se usa en aplicaciones Cloud Native: - **Microservicios:** Imagina microservicios como pequeños ayudantes que hacen tareas específicas. Wasm les da un entrenamiento especial para que sean eficientes y seguros en el mundo en la nube. - **Micro front-ends:** Son como capítulos de un libro, pero para aplicaciones. Wasm los hace portátiles para que funcionen en cualquier navegador. Así de sencillo. - **Inteligencia Artificial y Machine Learning:** ¿Recuerdas las películas donde las máquinas parecen pensar? Wasm permite que los modelos de aprendizaje automático hagan su magia en la nube. En resumen, Wasm es como un vistazo al futuro de las aplicaciones en la nube. Pero atención... ### Riesgos y amenazas de Wasm El principal riesgo para WebAssembly que me gustaría señalar, me preocupa y asusta porque lo he visto ocurrir con demasiada frecuencia. Me asusta porque el ego, las malas prácticas, el *"no tocar por que no",* el **secretismo y el desprecio por los demás pueden llevar a esto**. Y me asusta porque el pensamiento vieja escuela acerca de **"capturar un mercado" (hola Microsoft),** a menudo resulta en seguir un curso de acción que resulta en.... > **Fragmentación.** Esto ocurre cuando una tecnología central es cooptada por muchas partes, cada una de las cuales intenta hacer que su implementación sea incompatible con las demás. A veces, la incompatibilidad se hace "en nombre de la velocidad" o el cumplimiento de criterios cortoplacistas. *"Necesitábamos salir del estándar para cumplir con la demanda del cliente".* Otras veces, surge como una respuesta a los competidores: *"Decidimos no compartir el código fuente para poder obtener una ventaja competitiva"*. Lamentablemente, a veces se debe simplemente a la ignorancia y la falta de involucramiento con la comunidad. ### O que é Engenharia de Plataforma? O que é isso para mim? O que aconteceu com o DevOps? URL: https://www.sredevops.org/br/o-que-e-engenharia-de-plataforma-o-que-e-isso-para-mim-o-que-aconteceu-com-o-devops/ Last updated: 2024-06-30T22:12:23.000Z Você tem ouvido e lido sobre Engenharia de Plataforma em toda a web ultimamente... mas **nós realmente entendemos o que é Engenharia de Plataforma?** Todos parecem convencidos e empolgados, mas **você consegue ver como é diferente do DevOps?** Tentaremos fazer um resumo geral com base no material que a Platform Engineering Community está compartilhando. Luca, da [Platform Engineering Community](https://community.platformengineering.org/?ref=sredevops.org) , resume algumas ideias para nós neste vídeo. Neste vídeo, vamos esclarecer tudo sobre a emergente disciplina de Engenharia de Plataforma. Daremos uma definição precisa, explicaremos como ele se encaixa no ecossistema nativo da nuvem e quais são suas principais diferenças com o DevOps. Também discutiremos o valor da engenharia de plataforma para SREs/DevOps e desenvolvedores e como ela se conecta a uma plataforma de desenvolvedor interna. Por fim, abordaremos os principais desafios enfrentados pelos engenheiros de plataforma e ofereceremos algumas dicas e práticas recomendadas. Portanto, se você estiver pronto para aprender mais sobre essa nova fronteira das operações em nuvem, vamos começar. ### **O que é Engenharia de Plataforma?** Platform Engineering é a arte de combinar todas as diferentes tecnologias e ferramentas que compõem o seu "caminho de ouro". Esses caminhos permitem que os desenvolvedores façam o autoatendimento e reduzam a carga sobre as pessoas em uma organização. A soma desses caminhos é conhecida como plataforma de desenvolvimento interno ou IDP (Internal Developer Platform). O IDP é construído por uma equipe de Engenharia de Plataforma, seguindo uma abordagem de "plataforma como produto". Isso significa que a equipe da plataforma deve tratar os desenvolvedores como seus próprios clientes internos. ### **Por que tanto barulho?** A engenharia de plataforma é a resposta para organizações de engenharia de alto desempenho para evitar as armadilhas da realidade atual do DevOps. Embora o conceito "You-Build-It-You-Run-It" seja ótimo em teoria, a prática diária do DevOps está falhando. Os desenvolvedores estão sobrecarregados com as tecnologias nativas da nuvem e precisam confiar nas operações para fazer qualquer coisa além de uma simples atualização de imagem. É por isso que empresas como Airbnb e Spotify, que precisavam adicionar centenas de desenvolvedores todos os meses, rapidamente perceberam que a única maneira de permitir o autoatendimento dos desenvolvedores e o verdadeiro "você constrói, você executa" era construir uma camada de plataforma entre desenvolvedores e operações. ### **Benefícios** Essa camada é o que chamamos de Internal Developer Platform (IDP) e é o produto final da Platform Engineering. Vejamos as vantagens que oferece: - Para a equipe de operações: você não ficará mais sobrecarregado com tíquetes de operações e terá mais tempo livre para trabalhar em iniciativas estratégicas, em vez de reagir constantemente a problemas e solicitações de desenvolvedores. Além disso, sua configuração de entrega estará em conformidade, segura e com serviços e infraestrutura altamente padronizados, o que facilitará a manutenção e reduzirá as taxas de falha de alteração. - Para desenvolvedores: agora você poderá enviar alterações com mais rapidez, atendendo suas dependências de carga de trabalho, sem depender de operações. Eles poderão criar facilmente ambientes de RP, novos serviços e recursos sem ter que lidar com ferramentas complexas como Terraform ou Helm. Além disso, eles não precisarão mais escrever e manter configurações, permitindo que os desenvolvedores seniores se concentrem no que chamamos de "operações de sombra". ### **Desafios** Embora a Engenharia de Plataforma tenha grandes vantagens, ela ainda está em um estágio inicial e apresenta desafios que precisam ser enfrentados. O principal desafio é a comunicação. Muitas equipes de plataforma falham porque não colaboram o suficiente com os desenvolvedores para permitir que iterem rapidamente nos recursos da plataforma de desenvolvimento interna. Além disso, muitas vezes eles não comunicam claramente o retorno sobre o investimento (ROI) da iniciativa da plataforma aos executivos. É por isso que é importante conhecer outros engenheiros de plataforma e compartilhar as melhores práticas. O site [Platform Engineering](https://community.platformengineering.org/?ref=sredevops.org) ultrapassou recentemente 10.000 membros e a comunidade continua crescendo, mostrando que estamos tocando em um tema importante na indústria de DevOps. ### Corrupção? Burocracia? Estaca? Existe uma solução: Blockchain. URL: https://www.sredevops.org/br/corrupcao-burocracia-estaca-existe-uma-solucao-blockchain/ Last updated: 2024-06-30T22:09:42.000Z Blockchain é uma tecnologia que está revolucionando o mundo, e o governo não é exceção. Essa tecnologia tem potencial para **resolver conflitos sociais e políticos** , como **corrupção, burocracia e falta de participação cidadã** . ## Como blockchain pode ser usado no governo? A Blockchain pode ser utilizada no governo de diversas formas, dentro da ideia central de “accountability”, algumas formas são: - **Para armazenar, distribuir e armazenar atos administrativos:** Blockchain pode ser usado para registrar e gerenciar documentos governamentais, como certidões de nascimento, registros de propriedade e registros de votação. Isso pode ajudar a reduzir a corrupção e garantir que os documentos sejam precisos, públicos, transparentes e seguros. - **Para melhorar a eficiência do governo:** Blockchain pode ser usado para melhorar a eficiência do governo automatizando processos e eliminando a necessidade de intermediários. Isso pode economizar recursos públicos, simplificar os procedimentos para os cidadãos e garantir a confiabilidade desses processos. - **Para aumentar a participação cidadã:** Blockchain pode ser usado para aumentar a participação cidadã ao permitir que todas as pessoas façam parte do controle, tanto em recursos quanto no cumprimento de promessas de campanha, acessem e participem de processos governamentais de forma simples e notavelmente eficiente. Isso pode ajudar a tornar os governos e o Estado mais transparentes e responsáveis perante os cidadãos. ## Por que é conveniente para empresas, governos e principalmente cidadãos? - **Transparência:** Blockchain é uma tecnologia transparente, o que significa que todas as transações são registradas e armazenadas publicamente. Isso pode ajudar a prevenir a corrupção e garantir que as transações sejam justas. - **Segurança:** Blockchain é uma tecnologia segura, pois usa criptografia para proteger os dados. Isso pode ajudar a evitar fraudes e roubo de dados. - **Eficiência:** Blockchain é uma tecnologia eficiente, pois pode automatizar processos e eliminar a necessidade de intermediários, ou seja, papelada e burocracia. ## Atualmente, existem exemplos em que já é usado? Blockchain já está sendo usado no governo de várias maneiras, incluindo: - **🇪🇪 Estônia:** A Estônia é um dos países líderes no uso de blockchain no governo. O governo da Estônia usa blockchain para registrar e gerenciar documentos do governo, como certidões de nascimento, registros de propriedade e registros de votação. - **🇦🇪 Dubai:** Dubai é outro país que está adotando o blockchain no governo. O governo de Dubai planeja usar o blockchain para criar uma cidade inteligente, onde os cidadãos possam acessar os serviços do governo com segurança e eficiência. - **🇺🇸 Estados Unidos:** Diferentes governos locais, assim como o federal nos Estados Unidos, estão usando blockchain para registrar e gerenciar registros de propriedade, contratos governamentais e registros de votação. ## Se eu sou um desenvolvedor, como posso me especializar em blockchain? - **Aprenda sobre o funcionamento interno do blockchain.** Isso inclui entender como os blocos, cadeias e criptografia funcionam. Se você estiver interessado em fazer casos de exemplo, [escreva-nos e podemos fazer hackathons em nossa comunidade Discord](https://discord.com/invite/bK9rXFTvpk?ref=sredevops.org) . - **Crie projetos de blockchain.** Esta é uma das melhores maneiras de aprender sobre tecnologia e desenvolver suas habilidades. Existem muitos projetos diferentes que você pode criar, como aplicativos descentralizados, redes de pagamento e plataformas de contratos inteligentes. - **Junte-se a comunidades de blockchain.** Existem muitas comunidades online e pessoalmente onde você pode se conectar com outros desenvolvedores de blockchain. Essas comunidades podem ser uma grande fonte de apoio e aprendizado. - **Mantenha-se atualizado com as últimas notícias do blockchain.** A tecnologia Blockchain está em constante evolução, por isso é importante acompanhar as últimas notícias. Você pode fazer isso lendo postagens de blog, assistindo a vídeos e participando de conferências. ## Se eu for um funcionário público, como posso entender e promover melhor o uso do blockchain? - **Conheça os benefícios do blockchain.** Blockchain tem o potencial de melhorar a eficiência, transparência e segurança de muitos processos governamentais. Você pode aprender sobre os benefícios lendo livros, artigos e assistindo a vídeos. - **Conecte-se com outros funcionários públicos interessados em blockchain.** Existem muitas comunidades online e pessoalmente onde você pode se conectar com outros funcionários públicos interessados em blockchain. Essas comunidades podem ser uma grande fonte de apoio e aprendizado. - **Desenvolva uma estratégia para o uso de blockchain em seu governo.** Depois de entender os benefícios do blockchain, você pode começar a desenvolver uma estratégia para seu uso em seu governo. Esta estratégia deve ser específica para o seu governo e deve levar em consideração os desafios e oportunidades únicos em sua comunidade. - **Implemente blockchain em seu governo.** Depois de ter uma estratégia, você pode começar a implementar o blockchain em seu governo. Isso pode envolver o trabalho com desenvolvedores para criar aplicativos blockchain ou pode envolver o trabalho com outros funcionários públicos para mudar os processos do governo. Devemos fazer parte da solução, convidamos você a propor ideias e participar conosco do Discord, todos podemos aprender, você não precisa ser um especialista. [Blockchain en la Administracion Publica (es)](https://www.sredevops.org/content/files/2023/08/Blockchain%5Fen%5Fla%5Fadministracion%5Fpublica.pdf) ![Corrupção? Burocracia? Estaca? Existe uma solução: Blockchain.](https://www.sredevops.org/content/images/2023/08/blockchain-graphic-g2--1-.jpg) ### Blockchain es una solución a la burocracia, corrupción y transparencia de los Estados y Gobiernos. ¿Cómo podemos aprovecharla? URL: https://www.sredevops.org/es/corrupcion-burocracia-participacion-hay-una-solucion-blockchain/ Last updated: 2026-01-08T02:36:12.000Z Blockchain es una tecnología que está revolucionando el mundo, y el gobierno no es la excepción. Esta tecnología tiene el potencial de **resolver los conflictos sociales y políticos**, como la **corrupción, la burocracia y la falta de participación ciudadana**. ## Tabla de contenidos: - **Cómo blockchain se puede usar en el gobierno?** - **Por qué es conveniente para empresas, gobiernos y principalmente la ciudadanía?** - **Existe actualmente ejemplos donde ya se utilice?** - **Si soy desarrollador, de qué forma puedo especializarme en blockchain?** - **Si soy funcionario público, cómo puedo entender mejor y promover el uso de blockchain?** ## Cómo blockchain se puede usar en el gobierno? Blockchain se puede usar en el gobierno de muchas maneras, dentro de la idea central de "accountability",, algunas formas son: - **Para almacenar, distribuir y almacenar actos administrativos:** Blockchain puede ser utilizado para registrar y gestionar documentos gubernamentales, como actas de nacimiento, registros de propiedad y registros de votación. Esto puede ayudar a reducir la corrupción y garantizar que los documentos sean precisos, públicos, transparentes y seguros. - **Para mejorar la eficiencia del gobierno:** Blockchain puede ser utilizado para mejorar la eficiencia del gobierno al automatizar procesos y eliminar la necesidad de intermediarios. Esto puede ahorrar recursos públicos, simplificar trámites a la ciudadanía y garantizar confiabilidad en dichos procesos. - **Para aumentar la participación ciudadana:** Blockchain puede ser utilizado para aumentar la participación ciudadana al permitir que todas las personas sean parte del control, tanto en los recursos , como en los cumplimientos de promesas de campañas, acceder y participar en procesos gubernamentales de manera simple y notoriamente eficiente. Esto puede ayudar a hacer que los gobiernos y el Estado sea más transparente y responsable ante la ciudadanía. ## Por qué es conveniente para empresas, gobiernos y principalmente la ciudadanía? - **Transparencia:** Blockchain es una tecnología transparente, lo que significa que todas las transacciones se registran y almacenan de forma pública. Esto puede ayudar a prevenir la corrupción y garantizar que las transacciones sean justas y equitativas. - **Seguridad:** Blockchain es una tecnología segura, ya que utiliza criptografía para proteger los datos. Esto puede ayudar a prevenir el robo de datos y el fraude. - **Eficiencia:** Blockchain es una tecnología eficiente, ya que puede automatizar procesos y eliminar la necesidad de intermediarios, es decir trámites y burocracia. ## Existe actualmente ejemplos donde ya se utilice? Blockchain ya se está utilizando en el gobierno de varias formas, incluyendo: - **🇪🇪 Estonia:** Estonia es uno de los países líderes en el uso de blockchain en el gobierno. El gobierno estonio utiliza blockchain para registrar y gestionar documentos gubernamentales, como actas de nacimiento, registros de propiedad y registros de votación. - **🇦🇪 Dubai:** Dubai es otro país que está adoptando blockchain en el gobierno. El gobierno de Dubai planea utilizar blockchain para crear una ciudad inteligente, donde los ciudadanos puedan acceder a los servicios gubernamentales de manera segura y eficiente. - **🇺🇸 Estados Unidos:** Distintos gobiernos locales, tanto como el federal en Estados Unidos están utilizando blockchain para registrar y gestionar registros de propiedad, contratos gubernamentales y registros de votación. ## Si soy desarrollador, de qué forma puedo especializarme en blockchain? - **Aprende sobre el funcionamiento interno de blockchain.** Esto incluye entender cómo funcionan los bloques, las cadenas y la criptografía. Si estás interesado en realizar casos de ejemplo, [escríbenos y podremos realizar hackathons en nuestra comunidad Discord](https://discord.com/invite/bK9rXFTvpk?ref=sredevops.org). - **Construye proyectos de blockchain.** Esto es una de las mejores maneras de aprender sobre la tecnología y desarrollar tus habilidades. Hay muchos proyectos diferentes que puedes construir, como aplicaciones descentralizadas, redes de pagos y plataformas de contratos inteligentes. - **Únete a comunidades de blockchain.** Hay muchas comunidades en línea y en persona donde puedes conectarte con otros desarrolladores de blockchain. Estas comunidades pueden ser una gran fuente de apoyo y aprendizaje. - **Mantente al día con las últimas noticias de blockchain.** La tecnología blockchain está en constante evolución, por lo que es importante mantenerse al día con las últimas noticias. Puedes hacerlo leyendo publicaciones de blog, viendo videos y asistiendo a conferencias. ## Si soy funcionario público, cómo puedo entender mejor y promover el uso de blockchain? - **Aprende sobre los beneficios de blockchain.** Blockchain tiene el potencial de mejorar la eficiencia, la transparencia y la seguridad de muchos procesos gubernamentales. Puedes aprender sobre los beneficios leyendo libros, artículos y viendo videos. - **Conecta con otros funcionarios públicos que están interesados en blockchain.** Hay muchas comunidades en línea y en persona donde puedes conectarte con otros funcionarios públicos que están interesados en blockchain. Estas comunidades pueden ser una gran fuente de apoyo y aprendizaje. - **Desarrolla una estrategia para el uso de blockchain en tu gobierno.** Una vez que entiendas los beneficios de blockchain, puedes empezar a desarrollar una estrategia para su uso en tu gobierno. Esta estrategia debe ser específica para tu gobierno y debe tener en cuenta los desafíos y oportunidades únicos de tu comunidad. - **Implementa blockchain en tu gobierno.** Una vez que tengas una estrategia, puedes empezar a implementar blockchain en tu gobierno. Esto puede implicar trabajar con desarrolladores para construir aplicaciones de blockchain, o puede implicar trabajar con otros funcionarios públicos para cambiar los procesos gubernamentales. Debemos ser parte de la solución, te invitamos a proponer ideas y participar con nosotros en Discord, todos podemos aprender, no necesitas ser experta/o. [BLOCKCHAIN EN LA ADMINISTRACIÓN PÚBLICA: ¿Mucho ruido y pocos bloques?Banco Interamericano de DesarrolloBlockchain\_en\_la\_administracion\_publica.pdf683 KBdownload-circle](https://www.sredevops.org/content/files/2023/08/Blockchain%5Fen%5Fla%5Fadministracion%5Fpublica.pdf "Download") ![](https://www.sredevops.org/content/images/2023/08/blockchain-graphic-g2--1-.jpg) ### Albert-László Barabási: las redes subyacentes y ocultas detrás de toda nuestra realidad URL: https://www.sredevops.org/es/albert-laszlo-barabasi-las-redes-subyacentes-y-ocultas-detras-de-toda-nuestra-realidad/ Last updated: 2026-01-08T02:36:20.000Z En nuestro mundo abundan los datos. **Albert-László Barabás**i, científico, matemático, pionero en **data science,** plantea que es crucial comprender las estructuras subyacentes y las relaciones entre sistemas complejos. Las investigaciones de Barabási han puesto en entredicho la noción de conexiones aleatorias y han permitido descubrir una representación más exacta de cómo se organizan estos sistemas. La exploración de Barabási comenzó en el comienzo de Internet y la World Wide Web. Sorprendentemente, descubrió que la intrincada red de conexiones no seguía patrones aleatorios, sino una distribución de la carga de energía. Llamó a estas redes "redes sin escala". El revolucionario trabajo de Barabási revela que las nuevas conexiones en nuestras redes tienden a formarse con elementos ya bien conectados. Las redes sin escala existen en varios sistemas complejos, como las interacciones celulares y las redes sociales. Este descubrimiento es un paso importante hacia la comprensión de la notable complejidad que surge de las innumerables interacciones entre los numerosos componentes del mundo. ### Cómo puedo almacenar archivos en Kubernetes? CubeFS es una excelente opción URL: https://www.sredevops.org/es/como-puedo-almacenar-archivos-en-kubernetes-cubefs-es-una-excelente-opcion/ Last updated: 2026-01-08T02:36:28.000Z ## ¿Qué es CubeFS? CubeFS es un producto de almacenamiento cloud-native, siendo uno de los proyectos en grado "Incubator" de la CNCF ( [Cloud Native Computing Foundation](https://www.cncf.io/projects/cubefs/?ref=sredevops.org)). Es compatible con varios protocolos de acceso a datos, como **S3, POSIX y HDFS,** y admite dos *motores de almacenamiento*: múltiples réplicas y [erasure code](https://blog.min.io/erasure-coding/?ref=sredevops.org). Brinda a los usuarios múltiples funciones, como multiusuario, implementación multi-AZ y replicación entre regiones, y se usa ampliamente en escenarios como big data, IA, plataformas de contenedores, bases de datos, almacenamiento de middleware y separación informática, uso compartido de datos y protección de Datos. ![image](https://cubefs.io/assets/k8s-component.d9c57140.png) [CubeFS | A Cloud Native Distributed Storage SystemCubeFS is a distributed file system and object storage service for cloud native applications.![](https://www.sredevops.org/content/images/icon/favicon-10.ico)A Cloud Native Distributed Storage System![](https://www.sredevops.org/content/images/thumbnail/github-small.svg)](https://cubefs.io/docs/master/deploy/k8s.html?ref=sredevops.org#deployment-architecture) ## ¿Por qué CubeFS? ### Multiprotocolo Compatible con diversos protocolos de acceso como S3, POSIX y HDFS, y el acceso entre protocolos es interoperable. - **Compatible con POSIX**: Compatible con la interfaz POSIX, lo que hace que el desarrollo de aplicaciones sea extremadamente simple para aplicaciones de capa superior, tan conveniente como usar un sistema de archivos local. Además, CubeFS relajó los requisitos de coherencia de la semántica POSIX durante la implementación para equilibrar el rendimiento de las operaciones de archivos y metadatos. - **Compatible con S3**: compatible con el protocolo de almacenamiento de objetos de AWS S3, los usuarios pueden usar el SDK nativo de Amazon S3 para administrar recursos en CubeFS. - **Compatible con HDFS**: Compatible con el protocolo de interfaz Hadoop FileSystem, los usuarios pueden usar CubeFS para reemplazar el sistema de archivos Hadoop (HDFS) sin afectar el negocio de capa superior. ### Multimotor Al admitir dos motores: múltiples réplicas y codificación de borrado, los usuarios pueden elegir de manera flexible de acuerdo con sus escenarios comerciales. - **Motor de almacenamiento de múltiples réplicas**: los datos entre copias están en una relación de espejo y la coherencia de los datos entre copias se garantiza a través de un protocolo de replicación muy coherente. Los usuarios pueden configurar de manera flexible diferentes números de copias según los escenarios de su aplicación. - **Motor de almacenamiento de codificación de borrado**：El motor de codificación de borrado tiene las características de alta confiabilidad, alta disponibilidad, bajo costo y admite escala ultra grande (EB). De acuerdo con los diferentes modelos AZ, los modos de codificación de borrado se pueden seleccionar de manera flexible. ### Multiusuario Apoyar la administración de múltiples inquilinos y proporcionar políticas detalladas de aislamiento de inquilinos. ### Altamente escalable Puede construir fácilmente servicios de almacenamiento distribuido con escala de nivel PB o EB, y cada módulo se puede escalar horizontalmente. ### Alto rendimiento CubeFS admite el almacenamiento en caché de varios niveles para optimizar el acceso a archivos pequeños y admite múltiples protocolos de replicación de alto rendimiento. - **Gestión de metadatos**: el clúster de metadatos usa almacenamiento de metadatos en memoria y utiliza dos árboles B (inodeBTree y dentryBTree) para administrar índices y mejorar el rendimiento del acceso a los metadatos. - **Protocolo de replicación de consistencia sólida**：CubeFS adopta diferentes protocolos de replicación de acuerdo con el modo de escritura del archivo para garantizar la consistencia de los datos entre las réplicas. Si el archivo se escribe secuencialmente, se utiliza el protocolo de replicación principal-respaldo para optimizar el rendimiento de E/S. Si el archivo se escribe aleatoriamente para sobrescribir el contenido del archivo existente, se utiliza un protocolo de replicación basado en Multi-Raft para garantizar una gran coherencia de los datos. - **Almacenamiento en caché de niveles múltiples**: el volumen de codificación de borrado admite la capacidad de aceleración de almacenamiento en caché de niveles múltiples para proporcionar un mayor rendimiento de acceso a datos para datos calientes: - Caché local: el componente BlockCache se puede implementar en la máquina cliente como un caché local utilizando el disco local. Puede leer directamente la memoria caché local sin pasar por la red, pero la capacidad está limitada por el disco local. - Caché global: una caché global distribuida creada con el componente de réplica DataNode. Por ejemplo, un DataNode con un disco SSD implementado en el mismo centro de datos que el cliente se puede usar como caché global. En comparación con el caché local, debe pasar por la red, pero tiene una mayor capacidad y se puede escalar dinámicamente, y se puede ajustar la cantidad de réplicas. ## Cloud Native Basado en el standard CSI [(Container Storage Interface](https://kubernetes.io/blog/2019/01/15/container-storage-interface-ga/?ref=sredevops.org)) , CubeFS se integra y despliega fácilmente en Kubernetes. ![](https://www.sredevops.org/content/images/2025/03/image-1.png) **CubeFS Architecture* ## Casos y escenarios de uso Como plataforma de almacenamiento distribuido nativa de la nube, CubeFS proporciona múltiples protocolos de acceso, por lo que puedes utilizarlo en distintas situaciones, enumeremos: ### Análisis de grandes datos Compatible con el protocolo HDFS, CubeFS proporciona una base de almacenamiento unificado para el ecosistema Hadoop (como Spark y Hive), proporcionando espacio de almacenamiento ilimitado y capacidades de almacenamiento de datos de gran ancho de banda para motores informáticos. ### Deep Learning/Machine Learning Como sistema de archivos paralelos distribuidos, CubeFS es compatible con el entrenamiento de IA, el almacenamiento y la distribución de modelos, la aceleración de E/S y otros requisitos. ### Almacenamiento compartido entre contenedores El clúster de contenedores puede almacenar los archivos de configuración o los datos de carga de inicialización de las imágenes de contenedores en CubeFS, y leerlos en tiempo real cuando se cargan contenedores por lotes. Múltiples PODs pueden compartir datos persistentes a través de CubeFS, y se puede realizar una rápida conmutación por error en caso de fallo del POD. ### Bases de datos y middleware Proporciona servicios de disco en nube de alta concurrencia y baja latencia para aplicaciones de bases de datos como MySQL, ElasticSearch y ClickHouse, consiguiendo una separación completa entre almacenamiento e informática. ### Servicios en línea Proporciona servicios de almacenamiento de objetos de alta fiabilidad y bajo coste para negocios en línea (como publicidad, secuencias de clics y búsquedas) o contenidos gráficos, de texto, audio y vídeo de usuarios finales. ### De NAS (Network Attached Storage) a la nube Sustituye el almacenamiento local tradicional y el NAS sin conexión y facilita estrategias en cloud adoption. Fuente: [https://cubefs.io/docs/master/overview/introduction.html#database-middleware](https://cubefs.io/docs/master/overview/introduction.html?ref=sredevops.org#database-middleware) [CubeFS | A Cloud Native Distributed Storage SystemCubeFS is a distributed file system and object storage service for cloud native applications.![](https://www.sredevops.org/content/images/icon/favicon-11.ico)A Cloud Native Distributed Storage System![](https://www.sredevops.org/content/images/thumbnail/github-small-1.svg)](https://cubefs.io/docs/master/overview/introduction.html?ref=sredevops.org#database-middleware) ### ¿Qué es DVC (Data Version Control) y cómo puede ayudar en tus proyectos de datos? URL: https://www.sredevops.org/es/que-es-dvc-data-version-control-y-como-puede-ayudar-en-tus-proyectos-de-datos/ Last updated: 2026-01-08T02:36:36.000Z DVC es una herramienta gratuita y de código abierto para el control de versiones de datos. Te ayuda a administrar, rastrear y compartir conjuntos de datos a lo largo de su ciclo de vida. DVC se puede utilizar para almacenar conjuntos de datos en cualquier formato, incluidos archivos CSV, JSON, HDF5 y formatos de almacenamiento de imágenes. También puedes usar DVC para rastrear cambios en tus conjuntos de datos, lo que facilita la comparación de versiones y la identificación de cambios. *Podría decirse que DVC es un equivalente a Git, focalizado en data science.* DVC se puede usar en una variedad de escenarios y áreas, incluyendo MLOps, data pipelines, investigación, desarrollo, ingeniería, bases de datos, etc. Es una herramienta poderosa que puede ayudarte a administrar y compartir tus datos de manera más eficiente. [Data Version Control · DVCOpen-source version control system for Data Science and Machine Learning projects. Git-like experience to organize your data, models, and experiments.![](https://dvc.org/apple-touch-icon-512x512.png?v=dfbc4a93a926127fc4495e9d640409f8)Data Version Control · DVC![](https://dvc.org/social-share.png)](https://dvc.org/?ref=sredevops.org#use-cases) Sitio web ### **Beneficios de usar DVC** Hay muchos beneficios de usar DVC, incluidos: - **Gestión de datos centralizada:** DVC te permite almacenar todos tus conjuntos de datos en un solo lugar. Esto facilita la búsqueda de los datos que necesitas y la colaboración con otros. - **Seguimiento de cambios:** DVC rastrea los cambios en tus conjuntos de datos. Esto facilita la comparación de versiones y la identificación de cambios. - **Compartición de datos:** DVC te permite compartir tus conjuntos de datos con otros de manera segura y eficiente. - **Automatización:** DVC se puede utilizar para automatizar tareas relacionadas con datos, como la generación de informes y la validación de datos. ### **Cómo comenzar con DVC** Para comenzar con DVC, primero deberás instalarlo. DVC está disponible para Windows, macOS y Linux. Una vez que hayas instalado DVC, puedes comenzar a almacenar tus conjuntos de datos. Para almacenar un conjunto de datos, usa el comando `dvc init`. Este comando creará un directorio para tu conjunto de datos y agregará un archivo de configuración `.dvc`. El archivo de configuración `.dvc` contiene información sobre tu conjunto de datos, como su nombre, formato y tamaño. [GitHub - iterative/dvc: 🦉 Data Version Control | Git for Data & Models | ML Experiments Management🦉 Data Version Control | Git for Data & Models | ML Experiments Management - GitHub - iterative/dvc: 🦉 Data Version Control | Git for Data & Models | ML Experiments Management![](https://github.com/fluidicon.png)GitHubiterative![](https://repository-images.githubusercontent.com/83878269/a5c64400-8fdd-11ea-9851-ec57bc168db5)](https://github.com/iterative/dvc?ref=sredevops.org) Repo en Github Una vez que hayas almacenado tus conjuntos de datos, puedes comenzar a rastrearlos. Para rastrear un conjunto de datos, usa el comando `dvc add`. Este comando creará un registro de cambios para tu conjunto de datos. El registro de cambios contiene información sobre los cambios que has realizado en tu conjunto de datos, como la fecha, la hora y el autor del cambio. Puedes usar DVC para compartir tus conjuntos de datos con otros. Para compartir un conjunto de datos, usa el comando `dvc push`. Este comando cargará tu conjunto de datos en un repositorio DVC. Un repositorio DVC es un almacén para conjuntos de datos DVC. Puedes usar un repositorio DVC para almacenar tus conjuntos de datos de forma segura y eficiente. ### **Conclusión** DVC es una herramienta poderosa que puede ayudarte a administrar y compartir tus datos de manera más eficiente. Si estás trabajando con datos, DVC es una herramienta que debes considerar usar. ### Google anuncia la "supremacía cuántica": presenta Sycamore, el procesador de 70 qubits que deja en ridículo a los supercomputadores actuales URL: https://www.sredevops.org/es/google-anuncia-la-supremacia-cuantica-presenta-sycamore-el-procesador-de-70-qubits-que-deja-en-ridiculo-a-los-supercomputadores-actuales/ Last updated: 2026-01-08T02:36:20.000Z Google ha anunciado que ha alcanzado la "supremacía cuántica", lo que significa que ha creado un sistema informático basado en qubits, que puede realizar una tarea prácticamente imposible de resolver para cualquier computador clásico. El "hardware cuántico" previo de Google, llamado Sycamore, estaba compuesto por 53 *qubits*, *bits cuánticos* que pueden estar en dos estados al mismo tiempo (Un bit normal puede tener sólo 1). Sycamore se utilizó para resolver un problema de muestreo de circuitos aleatorios, un problema exponencialmente difícil de resolver (Más abajo explicamos en detalle). 💡 **We conclude by presenting an RCS experiment with 70 qubits at 24 cycles. We estimate the computational cost against improved classical methods and demonstrate that* ***our experiment is beyond the capabilities of existing classical supercomputers.** [Phase transition in Random Circuit SamplingQuantum computers hold the promise of executing tasks beyond the capability of classical computers. Noise competes with coherent evolution and destroys long-range correlations, making it an outstanding challenge to fully leverage the computation power of near-term quantum processors. We report Rando…![](https://static.arxiv.org/static/browse/0.3.4/images/icons/apple-touch-icon.png)arXiv.orgA. Morvan![](https://static.arxiv.org/static/browse/0.3.4/images/arxiv-logo-fb.png)](https://arxiv.org/abs/2304.11119?ref=sredevops.org) Aquí puedes leer el pre-print del paper **¿Qué significa la supremacía cuántica para nosotros?** La supremacía cuántica podría tener un impacto significativo en una amplia gama de industrias, incluyendo: - **Criptografía:** Los sistemas cuánticos podrían usarse para romper los sistemas de seguridad actuales, lo que podría tener un impacto significativo en la industria financiera. - **Salud:** Los sistemas cuánticos podrían usarse para desarrollar nuevos tratamientos para enfermedades, como el cáncer. - **Materiales:** Los sistemas cuánticos podrían usarse para desarrollar nuevos materiales con propiedades mejoradas, como materiales más ligeros y más fuertes. - **Transporte:** Los sistemas cuánticos podrían usarse para desarrollar nuevos sistemas de transporte, como coches autónomos y aviones más eficientes. El logro de Google es un paso importante hacia el desarrollo de la computación cuántica, y es probable que tenga un impacto significativo en nuestra vida diaria en los próximos años. **¿Cuáles son los próximos pasos?** El logro de Google es un hito importante, pero no es el final del camino. Los investigadores aún necesitan desarrollar sistemas cuánticos más grandes y más poderosos. También necesitan desarrollar nuevos algoritmos cuánticos que sean más eficientes que los algoritmos clásicos. El desarrollo de la computación cuántica es un proceso lento y gradual, pero tiene el potencial de revolucionar nuestra forma de vida. [Quantum Supremacy Using a Programmable Superconducting Processor![](https://ai.googleblog.com/favicon.ico)Google Research![](https://1.bp.blogspot.com/-BkfEqVH_52c/Xa9u3IgAocI/AAAAAAAAE00/0eUDUl5YhJ4pDTKO3QNOkCJHpxbbnZ-EQCLcBGAsYHQ/w1200-h630-p-k-no-nu/image7.png)](https://ai.googleblog.com/2019/10/quantum-supremacy-using-programmable.html?ref=sredevops.org) Publicación de Google respecto al hito anterior ## Qué significa la computación cuántica? Qué significa Phase transition? Qué es Random Circuit Sampling? ### **Muestreo de circuitos aleatorios y transición de fase** El muestreo de circuitos aleatorios (Random Circuit Sampling, RCS) es un problema de computación cuántica que implica encontrar el estado de un sistema cuántico después de que se le haya aplicado un circuito aleatorio. Este problema es difícil de resolver para sistemas grandes, pero tiene aplicaciones en áreas como la criptografía y la inteligencia artificial. Una transición de fase *(Phase transition)* es un punto en el que las propiedades de un sistema cambian dramáticamente. En el caso del RCS, la transición de fase ocurre cuando el tamaño del circuito aumenta más allá de cierto punto. Por debajo de la transición de fase, el estado del sistema es fácil de muestrear, pero por encima de la transición de fase, el estado del sistema se vuelve mucho más difícil de muestrear. La transición de fase en el RCS ha sido estudiada por muchos investigadores, pero aún no se comprende completamente. Sin embargo, se ha demostrado que la transición de fase es un fenómeno universal que ocurre en una amplia variedad de sistemas cuánticos. La transición de fase en el RCS tiene implicaciones importantes para el diseño de algoritmos cuánticos. Por ejemplo, los algoritmos que se basan en el RCS pueden ser mucho más eficientes debajo de la transición de fase que por encima de la transición de fase. La investigación de la transición de fase en el RCS es un área activa de investigación en la computación cuántica. Con un mayor entendimiento de la transición de fase, es posible desarrollar nuevos algoritmos cuánticos que sean más eficientes y más poderosos que los algoritmos clásicos. ### Aplicaciones El RCS tiene una serie de aplicaciones potenciales, que incluyen: - **Cálculo cuántico:** el RCS se puede utilizar para calcular la función de partición de un sistema cuántico, lo que puede ser útil para resolver problemas en química, física y materiales. - **Criptografía:** el RCS se puede utilizar para romper sistemas de criptografía cuántica, como el protocolo de Shor. - **Inteligencia artificial:** el RCS se puede utilizar para entrenar modelos de aprendizaje automático, como redes neurales. ### ### Pipedream, uno de los mejores servicios para automatizaciones, anuncia soporte para Node v18 URL: https://www.sredevops.org/es/pipedream-uno-de-los-mejores-servicios-para-automatizaciones-anuncia-soporte-para-node-v18/ Last updated: 2026-01-08T02:36:28.000Z Pipedream ahora utiliza Node v18 como su entorno de ejecución predeterminado. Esta actualización brinda a los desarrolladores una serie de mejoras y características nuevas para potenciar sus flujos de trabajo. Veamos más detalles al respecto. ## Node v18: Potencia y estabilidad para los flujos de trabajo en Pipedream Desde la implementación de flujos de trabajo existentes hasta la creación de nuevos, Pipedream garantiza que todas estas tareas ahora se realicen en un entorno de ejecución basado en Node 18\. Esta actualización es sinónimo de estabilidad y eficiencia, ya que los principales paquetes de npm han sido compatibles con Node 18 durante un tiempo considerable. Por lo tanto, se espera que los usuarios experimenten una transición fluida sin enfrentar problemas o cambios significativos al actualizar a esta nueva versión. Una de las mejoras más destacadas es la compatibilidad de paquetes que previamente no funcionaban correctamente en el entorno de ejecución v14, como discord.js. Con Node 18, estos paquetes ahora deberían funcionar sin contratiempos, lo que amplía enormemente las posibilidades de desarrollo. Además, Node 18 introduce una nueva API de búsqueda nativa que brinda a los desarrolladores aún más herramientas y opciones para sus flujos de trabajo. Para obtener más detalles sobre las características y mejoras específicas, se recomienda consultar los registros de cambios de Node 16 y Node 18. Node.js sigue siendo el entorno de ejecución más popular en Pipedream, y los desarrolladores pueden aprovecharlo al máximo. La plataforma permite escribir código en Node.js y utilizar cualquier paquete de npm necesario para personalizar los flujos de trabajo. Asimismo, se brinda la posibilidad de controlar completamente los flujos de trabajo, permitiendo finalizarlos, retrasarlos o reintentarlos de forma programática según las necesidades específicas de cada proyecto. Para obtener información adicional sobre cómo aprovechar al máximo Node.js en Pipedream, los usuarios pueden consultar la documentación correspondiente. ## Diversidad de opciones: Python, Bash y Go Además de su enfoque en Node.js, Pipedream también valora la diversidad y ofrece soporte para otros lenguajes de programación populares, como Python, Bash y Go. Lo más interesante es que estos lenguajes pueden ser utilizados en conjunto dentro del mismo flujo de trabajo. Esta flexibilidad brinda a los desarrolladores la capacidad de combinar las fortalezas de diferentes lenguajes en una sola aplicación. Por ejemplo, se pueden aprovechar las capacidades de transformación de datos de Node.js junto con las poderosas capacidades de análisis de la biblioteca pandas de Python, o utilizar Bash o Go para tareas específicas según sea necesario. Las posibilidades son infinitas y dependen de la creatividad y las necesidades del proyecto. ## La opinión de los usuarios es importante Pipedream está comprometido con el código abierto [*\-incluso quien escribe tiene un pequeño pull request aprobado-*](https://github.com/PipedreamHQ/pipedream/pull/7031?ref=sredevops.org) y se alienta a los desarrolladores a brindar comentarios, hacer sugerencias o plantear preguntas sobre las actualizaciones recientes o cualquier otro aspecto relacionado con Pipedream. El equipo de la plataforma está comprometido en brindar un soporte de calidad y se encuentra disponible para ayudar en todo lo necesario. Además, se invita a los usuarios a unirse a la comunidad de Pipedream, donde podrán interactuar con otros desarrolladores, compartir conocimientos y obtener respuestas a sus inquietudes. En resumen, la incorporación de Node v18 como entorno de ejecución predeterminado en Pipedream supone una mejora significativa para los flujos de trabajo, ofreciendo mayor potencia, estabilidad y opciones de desarrollo. Ya sea que los desarrolladores prefieran trabajar con Node.js, Python, Bash o Go, Pipedream proporciona las herramientas necesarias para llevar los proyectos al siguiente nivel. Github: [GitHub - PipedreamHQ/pipedream: Connect APIs, remarkably fast. Free for developers.Connect APIs, remarkably fast. Free for developers. - GitHub - PipedreamHQ/pipedream: Connect APIs, remarkably fast. Free for developers.![](https://github.com/fluidicon.png)GitHubPipedreamHQ![](https://opengraph.githubassets.com/a9e5c3c7702d6f99c4b5944095430ba413e81fcbd79f239063a7e873f37edd5d/PipedreamHQ/pipedream)](https://github.com/PipedreamHQ/pipedream?ref=sredevops.org) ### No más bastiones en AWS: Con EC2 Instance Connect llegas a tu instancia sin IP pública URL: https://www.sredevops.org/es/no-mas-bastiones-en-aws-con-ec2-instance-connect-conectar-a-tu-instancia-sin-ip-publica/ Last updated: 2026-01-08T02:36:29.000Z Desde hoy puedes conectarte a un servidor EC2 en Amazon Web Services (AWS) utilizando "EC2 Instance Connect", sin necesidad de una IP pública ni un host bastión . Este artículo te ayudará a entender cómo configurar correctamente tu endpoint y obtener una conexión segura a tu servidor EC2 en AWS. Para comenzar, debes tener una cuenta AWS activada y creada para poder utilizar los recursos de su nube. Después, debes crear una instancia en el servicio EC2 de AWS. Una vez que tienes tu instancia creada, es hora de configurar tu instance endpoint, asi podrás dejar de utilizar una IP pública y/o no usar un bastión. [Conéctese a las instancias sin necesidad de una dirección IPv4 pública mediante el punto de conexión de EC2 Instance Connect - Amazon Elastic Compute CloudUso del punto de conexión de EC2 Instance Connect para conectarse a las instancias sin necesidad de una dirección IPv4 pública.![](https://docs.aws.amazon.com/assets/images/favicon.ico)Amazon Elastic Compute Cloud![](https://docs.aws.amazon.com/es_es/AWSEC2/latest/UserGuide/images/ec2-instance-connect-endpoint.png)](https://docs.aws.amazon.com/es%5Fes/AWSEC2/latest/UserGuide/Connect-using-EC2-Instance-Connect-Endpoint.html?ref=sredevops.org) El instance endpoint es un identificador que se utiliza para conectar un cliente fuera de la red VPC a una instancia en AWS. Este endpoint consiste en una dirección IP y un puerto específico asignados por AWS al servidor EC2\. Para obtener tu endpoint de instancia, debes ir a la página de configuración del servicio EC2 en AWS y buscar el apartado "Endpoints". Allí encontrarás una lista de endpoints para cada instancia creada en tu cuenta de AWS. [Creación de un punto de conexión de EC2 Instance Connect - Amazon Elastic Compute CloudPuede crear un punto de conexión de EC2 Instance Connect en una subred de la VPC. A continuación, puede usar el punto de conexión de EC2 Instance Connect para conectarse a instancias en la VPC sin necesidad de que la instancia tenga una dirección IPv4 pública.![](https://docs.aws.amazon.com/assets/images/favicon.ico)Amazon Elastic Compute Cloud![](https://docs.aws.amazon.com/es_es/AWSEC2/latest/UserGuide/images/ec2-instance-connect-endpoint-create.png)](https://docs.aws.amazon.com/es%5Fes/AWSEC2/latest/UserGuide/create-ec2-instance-connect-endpoints.html?ref=sredevops.org) Una vez que tienes tu endpoint, es hora de configurarlo en tu código o aplicación. Para hacer esto, debes utilizar un cliente o biblioteca (librería/library) con soporte de protocolos TCP, UDP, o HTTP. Después, debes especificar el nombre del servicio y la dirección IP asignada por AWS al endpoint provisto por AWS. Una vez que tienes tu endpoint configurado correctamente en tu código, podrás conectarte a tu servidor EC2 en AWS de manera segura. ### Qué es Platform Engineering? Para qué me sirve? Qué pasó con DevOps? URL: https://www.sredevops.org/es/que-es-platform-engineering-para-que-me-sirve-que-paso-con-devops/ Last updated: 2026-01-08T02:36:31.000Z ¿Has estado escuchando y leyendo sobre Platform Engineering (ingeniería de plataformas) en toda la web últimamente... pero **¿realmente entendemos qué es Platform Engineering?** Todo el mundo parece estar convencido y entusiasmado, pero **¿puedes ver en qué se diferencia de DevOps?** Intentaremos dar un resumen general apoyándonos en el material que la Comunidad Platform Engineering está compartiendo. Luca, de la [Comunidad Platform Engineering](https://community.platformengineering.org/?ref=sredevops.org), nos resume en este video algunas ideas. En este video, vamos a aclarar todo sobre la disciplina emergente de Platform Engineering. Te daremos una definición precisa, explicaremos cómo encaja en el ecosistema cloud native y cuáles son sus principales diferencias con DevOps. También hablaremos del valor de Platform Engineering tanto para SREs/DevOps como para desarrolladores y cómo se conecta con una plataforma interna para desarrolladores. Por último, abordaremos los principales retos a los que se enfrentan los ingenieros de plataformas y ofreceremos algunos consejos y buenas prácticas. Así que, si estás listo para aprender más sobre esta nueva frontera de las operaciones en la nube, empecemos. ### **¿Qué es Platform Engineering?** Platform Engineering es el arte de combinar todas las diferentes tecnologías y herramientas que componen tu "golden path" o "ruta ideal". Estos caminos permiten a los desarrolladores el autoservicio y reducen la carga de las personas en una organización. La suma de estos caminos se conoce como plataforma interna de desarrollo o IDP (Internal Developer Platform), por sus siglas en inglés. La IDP es construida por un equipo de Platform Engineering, siguiendo un enfoque de "plataforma como producto". Esto significa que el equipo de la plataforma debe tratar a los desarrolladores como sus propios clientes internos. ### Documentación IDP [Internal Developer PlatformInternal Developer Platform # Everything the WWW has around Internal Developer Platforms in one curated space. It helps you understand the why, how, what and who. A modern way to run engineering teams # While self-built IDPs have been around in elite teams for around 5 years, they’re now going mains…![](https://internaldeveloperplatform.org/favicon.png)Internal Developer Platform![](https://internaldeveloperplatform.org/full_logo.png)](https://internaldeveloperplatform.org/?ref=sredevops.org) ### **¿Por qué tanto revuelo?** La ingeniería de plataforma es la respuesta de las organizaciones de ingeniería de alto rendimiento para evitar las trampas de la realidad actual de DevOps. Aunque el concepto de "You-Build-It-You-Run-It" es genial en teoría, la práctica diaria de DevOps está fallando. Los desarrolladores se ven abrumados por las tecnologías nativas de la nube y necesitan depender de operaciones para hacer cualquier cosa más allá de una simple actualización de una imagen. Es por eso que empresas como Airbnb y Spotify, que necesitaban añadir cientos de desarrolladores cada mes, se dieron cuenta rápidamente de que la única forma de permitir a los desarrolladores el autoservicio y el verdadero "tú lo construyes, tú lo manejas" era construyendo una capa de plataforma entre los desarrolladores y las operaciones. ### **Beneficios** Esa capa es lo que llamamos Plataforma Interna de Desarrolladores (IDP), y es el producto final de Platform Engineering. Veamos qué ventajas ofrece: - Para el equipo de operaciones: Ya no están abrumados con tickets de operaciones y tendrán más tiempo libre para trabajar en iniciativas estratégicas en lugar de reaccionar constantemente a los problemas y solicitudes de los desarrolladores. Además, su configuración de entrega será conforme, segura y con servicios e infraestructura altamente estandarizados, lo que facilitará el mantenimiento y reducirá la tasa de fallos en los cambios. - Para los desarrolladores: Ahora podrán enviar cambios más rápidamente mediante el autoservicio de sus dependencias de carga de trabajo, sin depender de operaciones. Podrán crear fácilmente entornos de PR, nuevos servicios y recursos sin tener que lidiar con herramientas complejas como Terraform o Helm. Además, ya no tendrán que escribir y mantener configuraciones, permitiendo a los desarrolladores senior enfocarse en lo que llamamos "operaciones en la sombra". ### **Desafíos** Aunque Platform Engineering tiene grandes ventajas, aún está en una etapa temprana y presenta desafíos que deben abordarse. El principal desafío es la comunicación. Muchos equipos de plataformas fracasan porque no colaboran lo suficiente con los desarrolladores para permitirles iterar rápidamente sobre las características de la plataforma interna de desarrollo. Además, a menudo no comunican claramente el retorno de inversión (ROI) de la iniciativa de la plataforma a los ejecutivos. Es por eso que es importante conocer a otros ingenieros de plataformas y compartir las mejores prácticas. El sitio [Platform Engineering](https://community.platformengineering.org/?ref=sredevops.org) ha superado recientemente los 10.000 miembros y la comunidad sigue creciendo, lo que demuestra que estamos tocando un tema importante en la industria de DevOps. [platformengin-b0m7058 #chaosPlatform engineering is the discipline of designing and building toolchains and workflows that enable self-service capabilities for software engineering organizations in the cloud-native era. platformengin-b0m7058 #chaos Latest![](https://www.linen.dev/favicon.ico)platformengin-b0m7058 #chaos![](https://static.main.linendev.com/platform-engineering-logo.svg)](https://community.platformengineering.org/?ref=sredevops.org) ### Kernel Linux 6.4 ya disponible, incluye soporte para Macs Silicon M2 URL: https://www.sredevops.org/es/kernel-linux-6-4-ya-disponible/ Last updated: 2026-01-08T02:36:31.000Z Llega unos meses después del lanzamiento de Linux Kernel 6.3, acorde a lo planificado. Esta versión ofrece muchas mejoras, como la compatibilidad inicial con Apple Silicon M2 (ARM64), mejoras en el almacenamiento, mejor monitoreo de sensores y más. Aunque no se trata de una actualización importante para los usuarios habituales, está dirigida a un grupo específico de usuarios que desean aprovechar el mejor soporte de hardware/software que se ofrece. La versión 6.3 del Kernel de Linux se prepara para el futuro hardware de Intel y mejora el soporte de chips AMD ## **Kernel Linux 6.4: ¿Qué mejoras trae?** Recuerda que esta es una versión no-LTS, por lo que no todo el mundo necesita actualizar a esto a menos que se enfrentan a un problema específico que esta versión del kernel corrige o por el simple gusto del *bleeding edge* En fin, sigamos. Esta versión presenta muchas mejoras; algunas notables incluyen: - Soporte inicial para Apple M2 - Monitorización de sensores mejorada - Modo autónomo guiado por AMD P-State - Mejoras en el almacenamiento El Kernel Linux 6.4 presenta soporte inicial para el SoC M2 de Apple, y se le agregaron los archivos DeviceTree para los actuales sistemas MacBook Air, Pro y Mac Mini. Aunque el soporte es similar al Apple M1, algunos problemas impiden la salida de pantalla para el Apple M2 Mac Mini, y el soporte para el teclado y el trackpad para los portátiles Apple más recientes no es funcional. Puedes esperar que esto mejore mucho cuando llegue Linux Kernel 6.5. ## Monitorización de sensores mejorada Similar a la anterior versión del kernel, Linux Kernel 6.5 cuenta con monitorización de sensores para más de 100 placas base ASUS. Se trata de variantes tanto Intel como AMD. Las placas PRIME, ROG, TUF, Pro, ProArt y más ahora soportan la monitorización de sensores en Linux. Puedes consultar el pull request para saber más. Modo autónomo guiado AMD P-State Después de muchos esfuerzos, el Modo Autónomo Guiado de AMD fue integrado en el Kernel de Linux, resultando en un mejor rendimiento y eficiencia energética para los procesadores AMD EPYC y AMD Ryzen. Para más detalles sobre esta característica, puedes consultar este commit. Mejoras en el almacenamiento Linux Kernel 6.4 también presenta bastantes mejoras de almacenamiento que incluyen: Mejoras en EROFS, que ahora permite el soporte de bloques subpágina que va bien con la arquitectura AArch64. También hay varias optimizaciones de rendimiento para EXT4 y pequeños ajustes para NTFS, que ahora elimina la opción "Sin reglas de acceso". Además, Btrfs y F2FS también han recibido algunas mejoras bastante interesantes, lo que se traduce en un mejor rendimiento para varios casos de uso. ## Otros cambios y mejoras Aparte de los cambios mencionados, aquí hay algunos que vale la pena destacar: - Soporte para Intel Linear Address Masking. - Se ha eliminado la compatibilidad con Intel Thunder Bay. - Varias optimizaciones para LoongArch. - Soporte para Intel Lunar Lake HD Audio. - Mejora del rendimiento de VDUSE. - Es posible que desee ir a través del anuncio de la versión para ir a través de la lista de cambios. ## ¿Cómo instalar el Kernel Linux 6.4? Si está actualizando usando Arch, Fedora, o una distribución rolling-release, será un asunto bastante sencillo para usted. Sólo tiene que esperar la actualización del Kernel. Pero, si está usando otras distribuciones (Pop!\_OS y Linux Lite pueden ser excepciones hasta cierto punto), no recibirá una actualización ahora. Normalmente utilizan la versión de Soporte a Largo Plazo del Kernel de Linux. ## Instalar la última versión del Kernel Linux Mainline en Ubuntu Este artículo muestra cómo actualizar a la última versión del Kernel de Linux en Ubuntu. Hay dos métodos discutidos. Uno es instalar manualmente un nuevo Kernel y el otro utiliza una herramienta GUI que proporciona una manera aún más fácil. Guía: (y origen de este artículo): ![](https://itsfoss.com/content/images/size/w256h256/2022/12/android-chrome-192x192.png) ### Inteligencia Artificial vs Bomba Atómica: Oppenheimer y el mensaje de Nolan URL: https://www.sredevops.org/es/inteligencia-artificial-vs-bomba-atomica-oppenheimer-y-el-mensaje-de-nolan/ Last updated: 2026-01-08T02:36:13.000Z *En cuanto a la IA, el director plantea *una preocupación más profunda sobre IA*: atribuirle características divinas que nos eximan de la responsabilidad de nuestros actos. “Si respaldamos la opinión de que la IA es todopoderosa, estamos respaldando la opinión de que puede eximir a las personas de la responsabilidad de sus actos militarmente, socioeconómicamente, lo que sea”, afirma.* En el marco del estreno de Oppenheimer el próximo 20 de julio, nueva película de Christopher Nolan, el director ha establecido una analogía entre el momento de creación de la bomba atómica y el avance de la inteligencia artificial. La historia del científico contiene grandes lecciones para nuestros tiempos. El reconocido director de cine **Christopher Nolan**, junto con su productora y esposa Emma Thomas, ha despertado **gran expectación con su próxima película biográfica sobre J. Robert Oppenheimer**, el científico clave en el desarrollo de la bomba atómica. En una entrevista exclusiva para[ WIRED](https://www.wired.com/story/christopher-nolan-oppenheimer-ai-apocalypse?ref=sredevops.org), Christopher Nolan compartió **sus pensamientos sobre la época que vivimos** y su visión de la inteligencia artificial (IA) tanto en su avance y posibles problemas en el mundo, su potencial en la [industria armamentística](https://computerhoy.com/noticias/life/inteligencia-artificial-crea-40000-armas-quimicas-6-horas-1030647?ref=sredevops.org), y sus posibles [aplicaciones en el cine](https://computerhoy.com/entretenimiento/indiana-jones-5-mostrara-harrison-ford-30-anos-durante-primeros-25-minutos-1236514?ref=sredevops.org). Nolan, conocido por su pasión por la ciencia y el cine, destaca la importancia de Oppenheimer y cómo su historia personal se relaciona con los desafíos actuales. “Es una idea increíble: gente que hace esos cálculos y observa la relación entre la teoría y el mundo real, y decide que hay una posibilidad muy pequeña de que destruyan el mundo entero. Y aun así pulsaron el botón”, expresó el director. Cuando se le mencionó la comparación entre el desarrollo de la bomba atómica y el crecimiento de la IA generativa, Nolan admitió que existe una analogía interesante en cuanto a los peligros de desencadenar irreflexivamente una nueva tecnología en el mundo. Sin embargo, también señaló que la bomba atómica es una tecnología única en su capacidad de cambiar y poner en peligro el mundo. En cuanto a la IA, el director plantea una preocupación más profunda sobre IA: atribuirle características divinas que nos eximan de la responsabilidad de nuestros actos. “Si respaldamos la opinión de que la IA es todopoderosa, estamos respaldando la opinión de que puede eximir a las personas de la responsabilidad de sus actos militarmente, socioeconómicamente, lo que sea”, afirma. “No sé cuáles son los fundamentos mitológicos de esto, pero a lo largo de la historia los seres humanos hemos tendido a crear falsos ídolos, a moldear algo a nuestra propia imagen y decir que tenemos poderes divinos por haberlo hecho”, reflexiona. “Con estos grandes modelos lingüísticos, las máquinas podrían incluso ser capaces de enseñarse a sí mismas el siguiente paso”. “Tenemos que verla como una herramienta. La persona que la maneja aún tiene que mantener la responsabilidad de manejar esa herramienta, concedemos a la IA el estatus de un ser humano, como en algún momento hicimos legalmente con las empresas, entonces sí, vamos a tener enormes problemas”, responde. En relación con la regulación en inteligencia artificial, Nolan cuestiona la idea de un órgano de gobierno o una agencia internacional, destacando la compleja relación entre la ciencia y gobierno. En este sentido, hizo referencia a la historia de Oppenheimer, quien intentó trabajar desde dentro del establishment para regular el poder nuclear, pero finalmente fue aplastado. “Es el truco político más viejo de las empresas tecnológicas. ¿Verdad? Zuckerberg lleva años pidiendo que le regulen. Es el truco político más antiguo. Saben que nuestros cargos electos no pueden entender estos temas”, afirma. Una lección más en la vida de Oppenheimer que: “consideraba que el papel de los científicos en la posguerra era ser los expertos que tenían que averiguar cómo regular este poder en el mundo. Y cuando ves lo que le ocurrió, comprendes que nunca se iba a permitir que eso sucediera”. “Intentó trabajar desde dentro del establishment. Fue muy práctico en su enfoque, pero aun así le aplastaron. Es muy complejo, y creo que para nuestros inventores de ahora es muy poco sincero que digan que necesitan que los regulen”. La sombra del holocausto nuclear sigue vigente Para el director hay una diferencia fundamental entre los años 40 y hoy: “los científicos que se ocupaban de la división del átomo intentaban explicar al gobierno que la bomba atómica era un hecho de la naturaleza” “Dios lo ha hecho, decía, o el creador o quien quieras que sea. Esto es la Madre Naturaleza. Y así, inevitablemente, es solo conocimiento de la naturaleza. Va a ocurrir. No se puede ocultar. No nos pertenece. No la hemos creado. Ellos lo veían así.”, explica. En la juventud del director, la sombra de la destrucción nuclear aún perduraba: “Sería muy difícil argumentar lo mismo sobre la IA. Seguro que algunos lo harán. Pero yo crecí en los 80 en el Reino Unido, con la Campaña para el Desarme Nuclear. La gente estaba muy, muy concienciada. Cuando tenía 13 años, mis amigos y yo estábamos convencidos de que moriríamos en un holocausto nuclear”. La utilización de IA en el cine El aprendizaje automático aplicado a la tecnología deepfake ofrece avances extraordinarios en efectos visuales y audio. Según Nolan, estas herramientas serán poderosas a largo plazo para crear entornos, construir objetos y recopilar datos sobre la interacción de la luz y los materiales. “Puede que la IA por fin rompa la barrera entre animación y fotografía. Porque es un híbrido. Si le dices a un artista que, por ejemplo, haga un dibujo de un astronauta, está inventando de memoria o buscando referencias. Con la IA, se trata de un enfoque diferente, en el que utilizas toda la historia de las imágenes”, analiza. Sin embargo, el director, que busca proporcionar una realidad completa a sus actores, tiene una postura selectiva hacia la tecnología. Considera utilizarla en situaciones peligrosas, como acrobacias, donde se pueden utilizar cables visibles y luego ocultarlos digitalmente, por ejemp lo. “Saldrán cosas maravillosas, a más largo plazo, en cuanto a entornos, en cuanto a reunir los datos masivos de cómo son las cosas y cómo reacciona la luz a los materiales. Esas cosas van a ser herramientas enormemente poderosas, pero yo, soy un viejo cineasta analógico”, concluye. Fuente: [https://computerhoy.com/entretenimiento/christopher-nolan-afirma-regulacion-ia-truco-1264500](https://computerhoy.com/entretenimiento/christopher-nolan-afirma-regulacion-ia-truco-1264500?ref=sredevops.org) ### TED Talks: Cuál será la próxima superpotencia global? Está mucho mas cerca de ti de lo que imaginas URL: https://www.sredevops.org/es/ted-talks-cual-sera-la-proxima-superpotencia-global-esta-mucho-mas-cerca-de-ti-de-lo-que-imaginas/ Last updated: 2026-01-08T02:36:29.000Z Nuestros roles necesitan comprender sus contextos y el factor político, social y cultural es tan impoortante como el técnico., y cómo los cambios del, entorno o nuestras acciones hoy son parte de una -lametablemente- elite de personas que tienen algunas herrmientas para entender mejor el mundo actual. Google, Microsoft, Alibaba, Amazon, Apple, etc; son organizaciones tanto o más poderosas que la mayoría de nuestros paísess, y frente a ello, como profesionales que se especializan -entre otras- en implementar desarrollar mantener sus servicios, tecnologías, plataformas (etc), nunca está de más aprender un poco más. El expositor concluye: > > > **¿Están bien con eso?** > **¿O van a hacer algo al respecto?** Dale una oportunidad ☺️ Transcripción: #### Transcipción del audio (auto traducido) ### Cómo desplegar Ghost (CMS/Blog) en Kubernetes URL: https://www.sredevops.org/es/como-desplegar-ghost-en-kubernetes/ Last updated: 2026-01-08T02:35:53.000Z ## Ghost en Kubernetes (v6.x) por SREDevOps.Org Despliega la principal plataforma de publicación de código abierto, **Ghost**, en Kubernetes con la máxima **seguridad** y **eficiencia** utilizando una imagen de contenedor endurecida y multi-arquitectura. Mantenido por [***SREDevOps.org***](https://www.sredevops.org/)*: SRE, DevOps, Linux, Hacking Ético, IA, ML, Código Abierto, Cloud Native, Platform Engineering en Inglés, Español y Portugués (Brasil).* [GitHub - sredevopsorg/ghost-on-kubernetes: Ghost on Kubernetes by SREDevOps.org - Deploy Ghost v6 on Kubernetes (k8s, k3s, etc) with our hardened distroless non root custom image.Ghost on Kubernetes by SREDevOps.org - Deploy Ghost v6 on Kubernetes (k8s, k3s, etc) with our hardened distroless non root custom image. - sredevopsorg/ghost-on-kubernetes![](https://www.sredevops.org/content/images/icon/pinned-octocat-093da3e6fa40-22.svg)GitHubsredevopsorg![](https://www.sredevops.org/content/images/thumbnail/395b82c9-df81-4aee-95a5-4269616a550f)](https://github.com/sredevopsorg/ghost-on-kubernetes?ref=sredevops.org) ### **Aspectos Destacados: Seguridad y Eficiencia** Este repositorio implementa Ghost CMS v6.xx.x de [@TryGhost (Oficial)](https://github.com/TryGhost/Ghost?ref=sredevops.org) en Kubernetes con una imagen personalizada, que ofrece mejoras significativas para el uso en producción y características de seguridad en Kubernetes. ### **Seguridad Mejorada** - **Ejecución Sin Root:** Tanto los componentes de Ghost como los de MySQL se ejecutan exclusivamente como un **usuario sin privilegios (non-root)** (UID/GID 65532) en Kubernetes, previniendo posibles ataques de escalada de privilegios. - **Tiempo de Ejecución Distroless:** Utilizamos **Google Container Tools Distroless Debian 13 - NodeJS 22** como el entorno de tiempo de ejecución final. Las imágenes **Distroless** contienen solo las dependencias de la aplicación y el lenguaje requeridas, **excluyendo shells y gestores de paquetes**, lo que las hace sustancialmente más seguras y reduce la superficie de ataque. - **Reducción de Vulnerabilidades:** Al reemplazar `gosu` con un flujo de ejecución de contenedor nativo y adoptar Distroless, eliminamos varias vulnerabilidades críticas reportadas en la imagen original de Ghost: - **Resultado:** Solo este cambio redujo **6 vulnerabilidades críticas** y **34 vulnerabilidades altas** reportadas por Docker Scout en la imagen oficial. **Ejemplo de Reportes de Seguridad:** | Imagen Oficial de Ghost | Imagen de Ghost en Kubernetes | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Escaneo de ejemplo para la [Imagen Oficial de Ghost](https://hub.docker.com/%5F/ghost/tags?ref=sredevops.org): ![Reporte de Docker Scout - Imagen Oficial de Ghost](https://raw.githubusercontent.com/sredevopsorg/ghost-on-kubernetes/main/docs/images/dockerhub-ghost.png) | Ejemplo de nuestra [Imagen de Ghost en Kubernetes en Docker Hub](https://hub.docker.com/r/ngeorger/ghost-on-kubernetes/tags?ref=sredevops.org): ![Reporte de Docker Scout - Imagen de Ghost en Kubernetes](https://raw.githubusercontent.com/sredevopsorg/ghost-on-kubernetes/main/docs/images/dockerhub-ngeorger.png) | ### **Rendimiento y Arquitectura** - **Artefactos de Build Personalizados:** Mantenemos dos Dockerfiles distintos para producción y desarrollo: - **Imagen de Producción:** La imagen principal construida utilizando nuestro proceso de construcción endurecido y multi-etapa. Ver el [Dockerfile](https://github.com/sredevopsorg/ghost-on-kubernetes/blob/main/Dockerfile?ref=sredevops.org). - **Imagen de Desarrollo:** Una variante adaptada para pruebas, que incluye soporte para SQLite. Ver el [Dockerfile-dev](https://github.com/sredevopsorg/ghost-on-kubernetes/blob/main/Dockerfile-dev?ref=sredevops.org). - **Soporte Multi-Arquitectura:** Las imágenes están construidas para las arquitecturas **amd64** y **arm64**. - **Build Multi-Etapa:** Utilizamos la imagen oficial de Node 22 Jod LTS para la construcción, lo que reduce significativamente el tamaño final de la imagen y mejora la seguridad al eliminar componentes de construcción innecesarios. - **Ghost v6 y NodeJS 22 LTS Actualizados:** Utilizando las últimas versiones estables para seguridad y rendimiento. - **Punto de Entrada Robusto (entrypoint.js):** Un script de punto de entrada **Node.js** personalizado, ejecutado por el usuario sin privilegios, maneja las operaciones de tiempo de ejecución necesarias, como la actualización de temas predeterminados, antes de iniciar la aplicación Ghost. El script se puede revisar aquí: [entrypoint.js](https://github.com/sredevopsorg/ghost-on-kubernetes/blob/main/entrypoint.js?ref=sredevops.org). - **Contenedor Init Dedicado:** El despliegue incluye un **initContainer** para manejar la creación de directorios, la propiedad correcta (UID/GID 65532) y la configuración de permisos antes del lanzamiento del contenedor principal de Ghost, asegurando una operación fluida dentro del contenedor Distroless. ## **Resumen de la Arquitectura de Despliegue** Este proyecto proporciona archivos manifest completos de Kubernetes (`deploy/`) para ejecutar una instancia de Ghost lista para producción, respaldada por una base de datos **MySQL**. | Recurso | Componentes | Detalles | | -------------------------------- | -------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Namespace** | ghost-on-kubernetes | Proporciona aislamiento lógico para todos los componentes. (Archivo: [00-namespace.yaml](https://github.com/sredevopsorg/ghost-on-kubernetes/blob/main/deploy/00-namespace.yaml?ref=sredevops.org)) | | **StatefulSet** | ghost-on-kubernetes-mysql | Gestiona la base de datos MySQL 8, asegurando red estable y almacenamiento persistente. (Archivo: [05-mysql.yaml](https://github.com/sredevopsorg/ghost-on-kubernetes/blob/main/deploy/05-mysql.yaml?ref=sredevops.org)) | | **Deployment** | ghost-on-kubernetes | Gestiona los pods de la aplicación Ghost v6\. (Archivo: [06-ghost-deployment.yaml](https://github.com/sredevopsorg/ghost-on-kubernetes/blob/main/deploy/06-ghost-deployment.yaml?ref=sredevops.org)) | | **Services** | ghost-on-kubernetes-service, ghost-on-kubernetes-mysql-service | Expone Ghost (2368) y MySQL (3306) internamente dentro del clúster. (Archivo: [03-service.yaml](https://github.com/sredevopsorg/ghost-on-kubernetes/blob/main/deploy/03-service.yaml?ref=sredevops.org)) | | **PersistentVolumeClaims (PVC)** | k8s-ghost-content, ghost-on-kubernetes-mysql-pvc | Solicita almacenamiento persistente para el contenido de Ghost (temas, imágenes) y los datos de MySQL. (Archivo: [02-pvc.yaml](https://github.com/sredevopsorg/ghost-on-kubernetes/blob/main/deploy/02-pvc.yaml?ref=sredevops.org)) | | **Secrets** | ghost-config-prod, ghost-on-kubernetes-mysql-env, tls-secret | Almacena de forma segura la configuración de Ghost, las credenciales de la base de datos y los certificados TLS (opcional). (Archivos: [01-mysql-config.yaml](https://github.com/sredevopsorg/ghost-on-kubernetes/blob/main/deploy/01-mysql-config.yaml?ref=sredevops.org), [04-ghost-config.yaml](https://github.com/sredevopsorg/ghost-on-kubernetes/blob/main/deploy/04-ghost-config.yaml?ref=sredevops.org), [01-tls.yaml](https://github.com/sredevopsorg/ghost-on-kubernetes/blob/main/deploy/01-tls.yaml?ref=sredevops.org)) | | **Ingress** | ghost-on-kubernetes-ingress | Expone la aplicación Ghost al mundo exterior a través de HTTP/HTTPS (requiere un TLD). (Archivo: [07-ingress.yaml](https://github.com/sredevopsorg/ghost-on-kubernetes/blob/main/deploy/07-ingress.yaml?ref=sredevops.org)) | *Nota*: Puedes alojar múltiples instancias de Ghost reemplazando la especificación de Namespace en cada archivo manifest. ## **Instrucciones de Instalación (Producción)** Sigue estos pasos para desplegar Ghost en tu clúster de Kubernetes. ### **Prerrequisitos** 1. Un clúster de Kubernetes en funcionamiento (`kubectl` configurado). 2. Un StorageClass provisionado (requerido para los PVCs). ### **0\. Clonar (o hacer fork) del Repositorio** ```bash ## Clonar el repositorio git clone https://github.com/sredevopsorg/ghost-on-kubernetes.git --depth 1 --branch main --single-branch --no-tags ## Cambiar de directorio cd ghost-on-kubernetes ``` ### **1\. Revisar y Configurar** Revisa los archivos de configuración de ejemplo y modifica los manifests en la carpeta `deploy/` para adaptarlos a tu entorno (ej. clase de almacenamiento, nombre de dominio, valores de secretos). - **Configuraciones:** Revisa los archivos de configuración de ejemplo en el directorio [examples/](https://github.com/sredevopsorg/ghost-on-kubernetes/blob/main/examples/?ref=sredevops.org): - `config.production.sample.yaml`: Configuración recomendada usando MySQL 8\. Requiere un **dominio de nivel superior (TLD)** válido para el campo `url` y la configuración de Ingress. - `config.development.sample.yaml`: Utiliza SQLite para entornos de prueba. - **Documentación Oficial de Ghost:** Consulta la [documentación oficial de Ghost](https://ghost.org/docs/config/?ref=sredevops.org#custom-configuration-files) para opciones de configuración detalladas. ### **2\. Secuencia de Despliegue** Es **crucial** aplicar los manifests en el orden correcto para asegurar la resolución de dependencias (especialmente los componentes de la base de datos). 1. **Crear el Namespace:**`kubectl apply -f deploy/00-namespace.yaml` **Exponer Ghost con Ingress (Opcional/Recomendado):** ```bash # Enruta el tráfico externo al Service de Ghost kubectl apply -f deploy/07-ingress.yaml ``` **Desplegar la Aplicación Ghost (Deployment):** ```bash # Espera a que MySQL esté listo antes de comenzar kubectl apply -f deploy/06-ghost-deployment.yaml ``` **Desplegar la Base de Datos MySQL (StatefulSet):** ```bash # Espera a que el PVC de MySQL esté enlazado kubectl apply -f deploy/05-mysql.yaml ``` **Crear Almacenamiento Persistente y Services:** ```bash kubectl apply -f deploy/02-pvc.yaml kubectl apply -f deploy/03-service.yaml ``` **Crear Secrets (Credenciales y Configuración):** ```bash # IMPORTANTE: Personaliza estos secretos antes de aplicarlos kubectl apply -f deploy/01-mysql-config.yaml kubectl apply -f deploy/04-ghost-config.yaml kubectl apply -f deploy/01-tls.yaml ``` ## **¡Tu Blog Ghost está Desplegado!** ¡Felicidades! Has desplegado una instancia de Ghost v6 altamente segura y escalable en Kubernetes. ### **Acceso Sin Nombre de Dominio (Pruebas)** Para previsualizar el sitio web sin configurar Ingress o un TLD, puedes usar el *port forwarding*: 1. Configura temporalmente las URL `url` y `admin` en tu Secret `config.production.json` para usar `http://localhost:2368/`. 2. Reinicia el/los pod(s) de Ghost después de actualizar el Secret. 3. Ejecuta el comando de *port-forwarding*: ```bash kubectl port-forward -n ghost-on-kubernetes services ghost-on-kubernetes-service 2368:2368 ``` ## Contribuciones ¡Damos la bienvenida a las contribuciones de la comunidad! Por favor, revisa el archivo [CONTRIBUTING.md](https://github.com/sredevopsorg/ghost-on-kubernetes/blob/main/CONTRIBUTING.md?ref=sredevops.org) para obtener más información sobre cómo contribuir a este proyecto. ## Licencia y Créditos - Este proyecto está licenciado bajo la **Licencia MIT**. Por favor, revisa el archivo [LICENSE](https://github.com/sredevopsorg/ghost-on-kubernetes/blob/main/LICENSE?ref=sredevops.org) para obtener más información. - Ghost CMS está licenciado bajo la [Licencia MIT](https://github.com/TryGhost/Ghost/blob/main/LICENSE?ref=sredevops.org). - La imagen de node y la imagen Distroless están licenciadas por sus respectivos propietarios. ## Historial de Estrellas ![Star History Chart](https://api.star-history.com/svg?repos=sredevopsorg/ghost-on-kubernetes&type=Date&theme=dark) ### Enlaces [GitHub - sredevopsorg/ghost-on-kubernetes: Ghost on Kubernetes by SREDevOps.org - Deploy Ghost v6 on Kubernetes (k8s, k3s, etc) with our hardened distroless non root custom image.Ghost on Kubernetes by SREDevOps.org - Deploy Ghost v6 on Kubernetes (k8s, k3s, etc) with our hardened distroless non root custom image. - sredevopsorg/ghost-on-kubernetes![](https://www.sredevops.org/content/images/icon/pinned-octocat-093da3e6fa40-23.svg)GitHubsredevopsorg![](https://www.sredevops.org/content/images/thumbnail/395b82c9-df81-4aee-95a5-4269616a550f-1)](https://github.com/sredevopsorg/ghost-on-kubernetes?ref=sredevops.org) ### groundcover: monitorea tus apps en kubernetes con menor costo, basado en eBPF URL: https://www.sredevops.org/es/groundcover-monitorea-tus-apps-en-kubernetes-con-menor-costo-basado-en-ebpf/ Last updated: 2026-08-01T15:22:47.000Z [groundcover](https://docs.groundcover.com/docs/welcome/what-is-groundcover?ref=sredevops.org) es un servicio pensado para entornos dinámicos y distribuidos, que permite a los equipos monitorear instantáneamente todo lo que construyen y ejecutan en la nube sin necesariamente comprometer el costo, la granularidad o la escala. Al utilizar eBPF *(*[*¿qué es eBPF y por qué debo saberlo?*](https://ebpf.io/what-is-ebpf/?ref=sredevops.org)*)* groundcover logra "observabilidad completa" a nivel nativo en k8s (kubernetes), desde la infraestructura hasta la aplicación, en un solo servicio. Te permite acceder a todos los registros de aplicaciones, métricas, seguimientos y eventos, en un solo lugar y con mayor eficiencia. ### Costos **Te permite manejar tu presupuesto, evitando repentinas alzas inesperados en el costo con un precio fijo y predecible** . Dejas de tener la obligación de decidir qué área o feature terndrá observabilidad en tu stack y cuál no, gracias a eBPF y la arquitectura de groundcover. ### Instalación La instalación de groundcover es rápida y parametrizable, tomando alrededor de 1 a 5 minutos. Ofrece un free-tier, suscribiéndote obtienes tu token para el deploy. \- Paso 1: [Suscríbete a Groundcover](https://app.groundcover.com/?ref=sredevops.org) \- Paso 2: Revisa nuestro video: Más info: [What is groundcover? - docsMonitor everything you run in K8s without compromising on cost, granularity, or scale.![](https://4171490747-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FUHgqKYgCiRKdOpWQdi52%2Ficon%2FjxoI1UDP9HuBggh7z7tK%2FFavicon2.png?alt=media&token=ff8d9b24-a9d8-4bef-9129-c8bfb6a613c5)docs![](https://www.gitbook.com/cdn-cgi/image/width=256,dpr=2,height=40,fit=contain,format=auto/https%3A%2F%2F4171490747-files.gitbook.io%2F~%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%2FUHgqKYgCiRKdOpWQdi52%2Flogo%2FClSIXrVnrAMmCZeloO45%2Fgroundcover.png%3Falt%3Dmedia%26token%3D8a700e1d-edb7-4e4c-9049-d7a502375c82)](https://docs.groundcover.com/?ref=sredevops.org) ### PlatformCon 2023: 8 y 9 de Junio, ¡participa! URL: https://www.sredevops.org/es/platformcon-2023/ Last updated: 2026-01-08T02:36:31.000Z PlatformCon 2023, es un evento en línea que reúne a profesionales y entusiastas de la tecnología en torno a los conceptos de "Platform Engineering", Site Reliability Engineering y el mundo del cloud computing. Durante este evento, podrás explorar las últimas tendencias en tecnología, aprender y descubrir sobre cómo fomentar la colaboración y la innovación en los equipos de desarrollo. Además, tendrás la oportunidad de conectarte con comunidades apasionadas y establecer contactos valiosos con empresas líderes en la industria. No te pierdas esta experiencia educativa y de networking, regístrate ahora en el sitio web oficial de PlatformCon 2022 y únete a la comunidad virtual! Puedes ver el programa completo de PlatformCon 2023 y registrarte en el siguiente link: [The global home for Platform EngineersJoin the #1 platform engineering community. Learn from leading DevOps and cloud native experts. Connect with fellow platform practitioners.![](https://assets.website-files.com/6489de99f6259b6eef4fae4f/6491926133ee9252f3d86b22_favicon-pe.png)Luca GalanteProduct Humanitec![](https://assets.website-files.com/6489de99f6259b6eef4fae4f/64ba7a89996fdf73d1cba081_Home-open-graph.jpg)](https://platformengineering.org/?ref=sredevops.org) ### Nhost: Plataforma opensource alternativa a Firebase URL: https://www.sredevops.org/es/nhost-alternativa-opensource-a-firebase-graphql/ Last updated: 2026-01-08T02:35:57.000Z *¿Te gustaría tener una plataforma para desarrollar aplicaciones web sin complicaciones? ¡Nhost es tu respuesta! Con Nhost, olvídate de preocuparte por la infraestructura y céntrate en la creación de tu aplicación.* Una de las cosas *bacanes* de Nhost es que te ofrece una base de datos PostgreSQL lista para usar. ¡Adiós a las complicaciones de configurar y mantener una base de datos! Además, Nhost cuenta con una API fácil de usar, lo que significa que puedes comunicarte con tu base de datos de forma rápida y sencilla, y eso que aún no llegamos a la integración nativa con GraphQL. *Y por si fuera poco...*. Nhost también te brinda más de 10 opciones para implementar providers de autenticación segura para tus usuarios. Puedes implementar fácilmente funciones de inicio de sesión, registro y gestión de usuarios en tu aplicación sin tener que lidiar con la seguridad tú mismo. oAuth2 desde Github, Auth0, Google, entre otros. ¿Recuerdas las veces que tu aplicación se caía por tráfico? Nhost (versión cloud) ofrece escalabilidad automática, lo que significa que tu aplicación se ajustará a cualquier cantidad de usuarios sin que se caiga ni tee deje *con más lag que manco con VTR.* Y si eres fanático del desarrollo frontend moderno, Nhost también tiene algo para ti. Puedes utilizar Next.js y React Native para crear tu interfaz de usuario, y Nhost se encargará de la parte del backend. ¡La combinación perfecta para una experiencia de desarrollo fluida! Así que ahí lo tienes, Nhost es la plataforma perfecta para desarrollar aplicaciones web de manera sencilla y sin preocupaciones. Con su base de datos lista para usar, autenticación segura, escalabilidad automática y soporte para frontend moderno, tendrás foco en tu proyecto y en tu código. Mención aparte, es que puedes usar un free tier razonable y mencoón aparte para esos SRE que están leyendo, ofrece opción *self managed* a través de containers y docker-compose, pero el trabajo de migrar hacia un deployment acorde a tu necesidad, queda a tu disposición. [GitHub - nhost/nhost: The Open Source Firebase Alternative with GraphQL.The Open Source Firebase Alternative with GraphQL. - GitHub - nhost/nhost: The Open Source Firebase Alternative with GraphQL.![](https://github.com/fluidicon.png)GitHubnhost![](https://repository-images.githubusercontent.com/337414495/136c2bf7-b665-4f16-a20d-3c821cb89072)](https://github.com/nhost/nhost.git?ref=sredevops.org) nhost repositorio en Github ### Por fin... una playlist para Kubernetes URL: https://www.sredevops.org/es/por-fin-una-playlist-para-kubernetes/ Last updated: 2026-01-08T02:36:32.000Z ¿Quién no ha sentido más de alguna vez el espíritu de la última canción? Visto en [nixCraft](https://web.facebook.com/nixcraft/posts/pfbid02DeWDUgyR6g7WZbsjuxfF1DZmVYvSVkn9fgm6SMaybV5o7ivsU9Vbtq3przwXPi4Ll?ref=sredevops.org) ### Nauticus: Administrar kubernetes en "modo fácil" URL: https://www.sredevops.org/es/nauticus-administrar-kubernetes-en-simple/ Last updated: 2026-01-08T02:36:00.000Z [GitHub - edixos/Nauticus: Simplifying Kubernetes cluster management with fully-managed SpacesSimplifying Kubernetes cluster management with fully-managed Spaces - GitHub - edixos/Nauticus: Simplifying Kubernetes cluster management with fully-managed Spaces![](https://github.com/fluidicon.png)GitHubedixos![](https://repository-images.githubusercontent.com/588581536/dae1e35a-4fcf-4ac1-bbd9-0c5c7f0ad11c)](https://github.com/edixos/Nauticus?ref=sredevops.org) Repositorio Nauticus en Github ## Contexto A medida que abrazamos la era de la contenerización, Kubernetes ha tomado el centro de atención, revolucionando la forma en que orquestamos y gestionamos aplicaciones en contenedores. Su amplia adopción es un testimonio de su poder y flexibilidad. Sin embargo, con esta flexibilidad también llega la complejidad. Gestionar los espacios de Kubernetes, asegurar una asignación eficiente de recursos y mantener políticas de seguridad puede ser una tarea desafiante. Nauticus, un controlador de Kubernetes diseñado para simplificar la gestión de espacios de Kubernetes. Esta innovadora herramienta está lista para hacer que la gestión de Kubernetes sea más accesible y eficiente. Aquí tienes una inmersión profunda en cómo Nauticus está redefiniendo la gestión de Kubernetes. ## Introducción a Nauticus Nauticus es un controlador de Kubernetes de código abierto que simplifica la gestión de espacios (namespaces con características mejoradas) dentro de tu clúster. Introduce un nuevo nivel de abstracción, lo que facilita a los desarrolladores y administradores gestionar recursos y políticas. Nauticus ofrece varias características poderosas: - Gestión de Espacios: Crea, actualiza y elimina espacios fácilmente, similar a la gestión de namespaces de Kubernetes pero con mayor control. - Gestión de Recursos: Asigna cuotas de recursos para garantizar una utilización eficiente de los recursos dentro de un espacio y evitar el consumo excesivo de recursos. - Gestión de Políticas de Seguridad: Habilita el modo estricto por defecto para las políticas de red, aislando eficazmente los recursos dentro de un clúster de Kubernetes. - Vinculación Adicional de Roles: Asigna roles y permisos específicos a usuarios o cuentas de servicio dentro del espacio, brindando un nivel de control de acceso más detallado. - Rangos de Límites: Establece restricciones en los recursos que pueden ser solicitados y consumidos por los contenedores en un espacio. - Creación de Cuenta de Servicio: Crea una cuenta de servicio de Kubernetes vinculada al IAM específico de la nube, eliminando la molestia de la anotación manual. ## ¿Por qué Nauticus? Gestionar los recursos de Kubernetes, especialmente en entornos de múltiples inquilinos, puede ser complejo. Asegurar que cada equipo tenga acceso a los recursos que necesita, al mismo tiempo que se previene el acceso no autorizado y el consumo excesivo, requiere una vigilancia constante. Nauticus simplifica este proceso al proporcionar una herramienta centralizada y fácil de usar que gestiona los espacios y sus recursos asociados. Ofrece a los administradores la capacidad de asignar roles y permisos, gestionar políticas de red y asignar recursos, todo desde un único lugar. Además, con Nauticus, puedes implementar un enfoque de "Namespace como un servicio", que permite a los desarrolladores gestionar sus propios namespaces, reduciendo la carga de trabajo de los administradores del clúster. Este enfoque mejora el flujo de trabajo general, fomenta ciclos de desarrollo más rápidos y reduce las posibilidades de error. ## Nauticus no es En el panorama de herramientas de Kubernetes, es importante entender que diferentes soluciones están diseñadas con áreas de enfoque específicas en mente, y eso ciertamente es cierto para Nauticus. Nauticus se especializa en proporcionar soluciones sólidas para gestionar espacios y optimizar los recursos de Kubernetes, centrándose en particular en facilitar la carga de trabajo de administración relacionada con el aprovisionamiento. Sin embargo, Nauticus no se enfoca en el enfoque de autoservicio que a menudo se adopta en entornos de Kubernetes. El término "autoservicio" en el contexto de Kubernetes se refiere a una configuración en la que los equipos o usuarios individuales pueden crear y gestionar sus propios recursos, sin necesidad de intervención directa de los administradores del clúster. El objetivo de este enfoque es fomentar una mayor agilidad y despliegues más rápidos, ya que los desarrolladores pueden controlar de manera autónoma sus entornos sin crear dependencias o cuellos de botella. Los espacios de Nauticus son recursos de alcance de clúster, lo que significa que no están diseñados para encajar en un enfoque de autoservicio. La decisión de diseñar Nauticus de esta manera no es una limitación, sino una elección estratégica centrada en ofrecer una solución más eficaz para los desafíos a los que se enfrentan los administradores de Kubernetes durante el proceso de aprovisionamiento. Dicho esto, si tu objetivo es adoptar un enfoque de autoservicio dentro de tu entorno de Kubernetes, te recomendamos que eches un vistazo a Capsule. Capsule es otra herramienta de Kubernetes diseñada específicamente para facilitar un enfoque de autoservicio, proporcionando características como multitenencia, aislamiento, políticas de red y más. Puedes obtener más información sobre Capsule en su sitio web oficial: Capsule. [Mastering Kubernetes Spaces with NauticusExplore Nauticus: the future of Kubernetes administration. Simplify and optimize your DevOps workflow today!![](https://cdn-static-1.medium.com/_/fp/icons/Medium-Avatar-500x500.svg)MediumIsmail KABOUBI![](https://miro.medium.com/v2/resize:fit:328/1*R4vTTYsn5rfXpV4E2dmg1g.png)](https://medium.com/@ikaboubi/mastering-kubernetes-spaces-with-nauticus-52d349d98ea8?ref=sredevops.org) Fuente: Ismail Kaboubi en Medium ### 9 escenarios donde implementamos cultura DevOps URL: https://www.sredevops.org/es/9-escenarios-donde-implementamos-devops/ Last updated: 2026-01-08T02:36:04.000Z "El arte de DevOps" reconoce 9 escenarios en las que podemos implementar cultura DevOps: 1- Planificar 2- Codificar/Desarrollar 3- Construir (Building) 4- Probar/Testing 5- Liberar (Release) 6- Implementar 7- Operar 8- Monitorizar 9- Pipeline CI/CD [The Art of DevOps — The 9 SituationsChapter 11 — Phases of the DevOps lifecycle![](https://cdn-static-1.medium.com/_/fp/icons/Medium-Avatar-500x500.svg)Level Up CodingGreg Billington![](https://miro.medium.com/v2/resize:fit:544/1*keqRPPTgeufCZ_kx-4U3_w.png)](https://levelup.gitconnected.com/the-art-of-devops-the-9-situations-74d534bc058a?ref=sredevops.org) Original en Inglés por Greg Billington, traducido con el soporte de OpenAI **Planificar** es el arte de describir la secuencia ideal de eventos y predecir la duración de esos eventos, de manera que el líder técnico (con cierta certeza) conozca la fecha de la fiesta de celebración una vez que el lanzamiento se haya realizado. **Codificar/Desarrollar** es la etapa de crear los scripts del pipeline CI/CD para ensamblar y compilar el código de los desarrolladores en un servidor central. Esto también requiere agregar tantas herramientas de verificación y equilibrio como sea posible, como el famoso "lint" o sonarcloud. La construcción es la fase en la que el ingeniero ejecuta los scripts y plantillas para configurar o instanciar un entorno construido a partir de infraestructura real o virtual. La prueba es donde el ingeniero verifica que el script se haya ejecutado correctamente y haya creado todos los recursos y elementos deseados, y los haya conectado mediante una red apropiada para que exista un entorno completo y operativo. La implementación es donde el pipeline CI/CD construye un entorno e implementa el software de la aplicación en él, con una alta probabilidad de que funcione como se ha probado anteriormente. La operación es donde el entorno y la aplicación se ejecutan para realizar la función requerida. El sistema también debe realizar tareas ocultas durante esta fase en preparación para cualquier contraataque que requiera la intervención de los señores de la Continuidad del Negocio o la Recuperación ante Desastres. La monitorización es donde se observa el entorno y la aplicación para asegurarse de que estén funcionando dentro de límites aceptables; de lo contrario, se generará una alerta y se notificará al ingeniero de DevOps del evento de alarma. El ingeniero puede investigar más a través del uso de los registros del sistema operativo y de la aplicación, que son registros de una precisión y virtud incuestionables. CI/CD no es una fase, sino un pegamento global significativo y magnífico llamado "el pipeline" que controla el flujo de los sistemas de construcción, prueba e implementación como el agua en un canal que solo tiene un camino a seguir. Esta es una tubería que se debe usar con frecuencia y cuanto más rápido fluya el agua a través de ella, mejor. Aquellos que no conocen la abreviatura CI/CD temblarán ante su gran poder e influencia. Realiza incursiones para abastecer a tu equipo cuando haya terrenos fértiles en abundancia. Dales las mejores laptops, equipadas con montañas de memoria, discos rápidos y pantallas de sobra. Sus viejas y confiables armas pueden ser entregadas a otros que no estén en la vanguardia de la batalla y solo usen aplicaciones de oficina. Los ingenieros, en momentos desesperados, pierden el sentido del miedo. Pueden estar abiertos a cambios repentinos y temerarios en los sistemas de producción, lo cual puede ayudar, pero debe usarse con precaución y solo si la situación es grave. Prohíbe la interpretación de presagios y las dudas sobre el futuro; que no haya: Ningún *"TO-DO" (pendiente, por hacer* sin completar en los scripts. Bloques de código comentados porque la función ha sido eliminada pero se han dejado como madera muerta para aquellos que siguen. Cualquier comentario que ponga en duda a aquellos ingenieros que codificaron esta monstruosidad en tiempos anteriores. Firewalls con puertos abiertos. Certificados autofirmados debido a la falta de cuidado o tiempo para obtener uno real. El principio para gestionar un equipo y construir un sistema es establecer un estándar que todos deben alcanzar. Al construir tu solución: Hazla frágil y susceptible de romperse y detenerse en cualquier oportunidad inesperada. Libera información sobre cualquier error y registra los registros con la máxima definición. Esto se conocerá como la "etapa de desarrollo". Hazla resistente para la batalla, robusta para continuar cuando todo a su alrededor falle y flaque. Oculta al enemigo cualquier motivo de preocupación y continúa usando el mejor camino disponible; solo registra los errores más graves para que los registros no se llenen demasiado rápido. Esto se conocerá como "Producción". Cuando viajes desde la tierra del Desarrollo a la Producción, puede haber otras tierras intermedias. Cuantas más tierras, mejor, ya que cada una tiene sus propiedades que facilitan su recorrido. Estas tierras pueden incluir entornos de Prueba de Características, Prueba de Sistema, Prueba Unitaria, Demostración al Cliente, Prueba de Aceptación del Cliente, Preproducción, Producción. Prueba de Características: debe centrarse en una sola cosa. Prueba de Sistema: debe asegurarse de que todas las partes del producto funcionen correctamente según la ley moral. Prueba Unitaria: debe comprobar que un solo método cumpla con sus obligaciones. Demostración al Cliente: debe incluir conjuntos de datos de fácil uso para el cliente, tener la capacidad de mostrar todas las características (adornos y detalles llamativos) y tener un aspecto visualmente atractivo, llevando la marca del cliente para obtener puntos extra. Por encima de todo, esto debe funcionar cuando se le solicite. Prueba de Aceptación del Cliente: esto debe funcionar sin problemas, ya que el pago de recompensas y hitos depende de ello. Producción: este debe ser el entorno más rápido y robusto de todos, debe ser seguro, estar siempre en funcionamiento y protegido de intromisiones accidentales. Los planes deben ser flexibles y adaptables, y el equipo debe agregar un panel de control a su herramienta de observabilidad. Comparte este panel de control (o una versión simplificada) con los maestros y las partes interesadas. El libro de ejecución es un almanaque del mago y debe ser protegido para que solo aquellos que entienden y creen puedan verlo. Si el enemigo, que son los "errores", deja una puerta abierta, debes entrar rápidamente y solucionarlos. Evita un lanzamiento defectuoso asegurándote de tener el control del cliente y adaptándote al problema hasta que puedas luchar con un nuevo lanzamiento decisivo; de lo contrario, implementa un parche rápido. ### La edad, tu género, raza, o cualquier factor no es impedimento para cambiar de profesión URL: https://www.sredevops.org/es/la-edad-tu-genero-raza-o-cualquier-factor-no-es-impedimento-para-cambiar-de-profesion/ Last updated: 2026-01-08T02:36:30.000Z [YouTube![](https://www.youtube.com/favicon.ico)](https://www.youtube.com/embed/CS23-z-xUFw?clip=UgkxRCa8LopPKGi42UV1pkYwuVYO71pMA79s&clipt=EIqkNBj46DU&ref=sredevops.org) ### Kubernetes lanza versión 1.27, aquí puedes ver los cambios URL: https://www.sredevops.org/es/kubernetes-lanza-version-1-27-aqui-puedes-ver-los-cambios/ Last updated: 2026-01-08T02:36:40.000Z Fuente: [Kubernetes 1.7: Security Hardening, Stateful Application Updates and Extensibility](https://kubernetes.io/blog/2017/06/kubernetes-1-7-security-hardening-stateful-application-extensibility-updates/?ref=sredevops.org) Se ha anunciado Kubernetes 1.7, una versión que incluye características de seguridad, almacenamiento y extensibilidad para responder a la producción generalizada en entornos empresariales de gran demanda. En cuanto a la seguridad, la versión incluye mejoras como secreciones cifradas, política de red para la comunicación entre pods, autorizador de nodo para limitar el acceso de kubelet y la rotación de certificados TLS de cliente/servidor. Para aquellos que ejecutan bases de datos escalables en Kubernetes, la nueva versión tiene una característica importante que agrega actualizaciones automáticas a los StatefulSets y mejora las actualizaciones para los DaemonSets. También se anuncia el soporte alfa para almacenamiento local y un modo de ráfaga para escalar StatefulSets más rápido. Además, la agregación de API permite que los servidores API proporcionados por el usuario se sirvan junto con el resto de la API de Kubernetes en tiempo de ejecución. Otras características destacadas incluyen soporte para controladores de admisión extensibles, proveedores de nube enchufables y mejoras en la interfaz de tiempo de ejecución de contenedores (CRI). Entre las nuevas características, destacan: - Mejoras en la seguridad: la política de red API es promovida a estable, se añade un autorizador de nodo y plugin de control de admisión, se puede encriptar secreciones y otros recursos en etcd y Kubelet TLS ahora admite la rotación de certificados TLS de cliente y servidor. - Cargas de trabajo estables: StatefulSet Updates es una nueva función beta en 1.7, permitiendo actualizaciones automáticas de aplicaciones estables como Kafka, Zookeeper y etcd, usando una variedad de estrategias de actualización que incluyen actualizaciones continuas. - Extensibilidad: se agrega API aggregation, que permite a los usuarios añadir APIs pre-construidas, de terceros o creadas por el usuario a su clúster. - Características adicionales: se introduce soporte alfa para controladores de admisión externos, Federated Resource Placement basado en políticas y el complemento de volumen StorageOS. La versión 1.7 de Kubernetes es posible gracias a la vasta y abierta comunidad, que ha contribuido con más de 50,000 compromisos en solo tres años. [Release Kubernetes v1.27.4 · kubernetes/kubernetesSee kubernetes-announce@. Additional binary downloads are linked in the CHANGELOG. See the CHANGELOG for more details.![](https://github.com/fluidicon.png)GitHubkubernetes![](https://opengraph.githubassets.com/6d29d039c95ba3e66abe55e7c042c2aeb52a9d6192231bed08f64132b5a4f55d/kubernetes/kubernetes/releases/tag/v1.27.4)](https://github.com/kubernetes/kubernetes/releases/tag/v1.27.4?ref=sredevops.org) ### Qué es y cómo funciona un Equipo de Plataforma? URL: https://www.sredevops.org/es/que-es-y-como-funciona-un-equipo-de-plataforma/ Last updated: 2026-01-08T02:36:13.000Z > *Combinamos métodos Site Reliability Engineering, DevOps, y DevSecOps, junto a una con una sólida formación técnica, continua y colectiva, que busca *entregar valor* a través del análisis sistémico y contextual, capaz de comprender tanto los productos y desarrollo, la infraestructura que permite las operaciones, tanto como el "core" del negocio, en su ámbito técnico, social y comercial.* Este documento es una guía colaborativa y sus principios deben ser utilizados como una referencia obligatoria para cualquier decisión relacionada con áreas Cloud, SRE, DevOps, etc. Es un documento abierto y puede ser actualizado por cualquier actor dentro del ámbito Open Source. Tus Pull Requests son más que bienvenidos. Aquí buscamos brindar orientación a alto nivel -es decir, general-, respecto a cómo trabaja un equipo de plataforma, sus principios y prácticas. ## ¿Qué hacemos? ### Proporcionamos - **Herramientas y servicios** a los equipos de desarrollo. ### Para qué? - **Facilitar, acelerar y automatizar el ciclo de Integración Continua** ### Cómo? - Con la provisión de entornos de ejecución seguros, confiables y de alta calidad con capacidad de **monitorear y operar sus productos** dentro de un enfoque de **autoservicio, automatización, escalamiento y transparencia**. ## Nuestros principios - Global First: Generamos frameworks y herramientas que puedan ser utilizadas por cualquier equipo de desarrollo. - Orientado a eventos: Nuestros servicios y plataformas deben ser capaces de responder a eventos de forma rápida y eficiente. - Rol activo en arquitectura, planificación, diseño y soporte al desarrollo. - Legacy, como ciudadano de primera clase. Nuestros servicios y plataformas deben ser capaces de soportar la migración de sistemas legados. - Cloud-first, cada sistema, plataforma y herramienta es cloud native y cumple con lógica de Infraestructura como Código. - Open source, cada sistema, plataforma y herramienta desarrollada y adoptada, debe ser parte del ecosistema Open Source. - Infraestructura como código, cada plataforma, sistema y herramienta debe ser implementada utilizando un enfoque de IaC. - Documentación permanente sobre frente a cada iteración, evento o desarrollo, nos esforzamos en el uso de diagramas como código, documentación como código, portales para desarrolladores, etc. - Tareas manuales, nuestro enemigo. Nos esforzamos por la automatización de tareas, procesos y operaciones. - Revisión continua, cada principio está sujeto a cambios, mejoras y actualizaciones. - Solución como valor: Disposición nativa al cambio en pro de la mejora continua. - TVP (Thinnest Viable Platform) tener exactamente lo que necesitamos, nada más, tampoco menos. No hay que pagar por lo que no se usa. - Prioridad y enfoque sobre métricas de usuario final por sobre métricas técnicas. Visualizamos la lógica del negocio dentro de la plataforma. - DevSecOps, entendiendo que la seguridad parte desde la cultura y el conocimiento de las propias vulnerabilidades. - Shift left Security, empoderando a los equipos para implementar seguridad desde el primer día en sus productos. Proporcionamos un entorno sin fisuras para hacerlo. [(Leer más sobre shift left)](https://snyk.io/learn/shift-left-security/?ref=sredevops.org) - DevFirst, nuestra preocupación son los desarrolladores, no los administradores de sistemas. ## Cómo trabajamos Combinamos métodos Site Reliability Engineering, DevOps, y DevSecOps, junto a una sólida formación técnica, continua y colectiva, que busca **entregar valor** a través del análisis sistémico y contextual, capaz de comprender tanto los productos y desarrollo, la infraestructura que permite las operaciones, tanto como el "core" del negocio, en su ámbito técnico, social y comercial. Creemos que cada pieza de software que desarrollamos debe contar con estándares de alta calidad y seguridad. Trabajamos basados en la definición de [Plataformas impulsadas por la comunidad](https://www.redhat.com/en/blog/understanding-open-source-governance-models?ref=sredevops.org). [Understanding open source governance modelsOpen source projects usually operate according to rules, customs, and processes that determine which contributors have the authority to perform certain tasks. Understanding those rules can increase your chances of contributing successfully and positively to a project.![](https://www.sredevops.org/content/images/icon/favicon-16.ico)Red HatDave Neary![](https://www.sredevops.org/content/images/thumbnail/red-hat-social-share.jpg)](https://www.redhat.com/en/blog/understanding-open-source-governance-models?ref=sredevops.org)