 Buenos días, buenas tardes, buenas noches a todos los que de nuevo se conectan a OpenShift Commons en vivo. Estoy muy contenta de estar con ustedes otra vez. Mi nombre es María Bracho, se gerente de productos de Cloud Platforms para Verhead. Y conmigo hoy se encuentra Juan. Juan, cuéntanos qué haces tú y de qué halegme. Bueno, buenas. Mi nombre es Juan Antonio Sobio Robles. Mucha gente lo encuentra muy largo, entonces me dicen Os por mi apellido. Y soy un ingeniero de software en Red Hat. Me dedico a seguridad y cumplimiento o compliance en OpenShift. Muy bien, sí. Bueno, yo soy María Angelica Bracho Pacheco, pero ya tantos años en Estados Unidos, perdí un poco la identidad. Yo soy venezolana, vivo en Estados Unidos. Ahora estoy en Japón. Juan, cuéntanos de dónde eres tú y dónde estás. Ah, bueno, yo soy de México. El norte de México, en Coahuila. Y estoy en Finlandia. Yo voy a ocho años aquí y pues, y estamos. Superglobal, pero bueno, nos uné el español, el castellano. Y muy contento hoy de hablar de seguridad y cumplimiento, que cuando yo escuché, vamos a hablar de cumplimiento. Me costó, me costó. Me costó entender de qué estábamos hablando. Cuéntanos qué cumplimiento antes de empezar. Sí, sí, está un poquito. Cuando le hablo a la gente de lo que hago es, no es el trabajo más atractivo, en cierto aspecto, pero cumplimiento es asegurarse de que el software que nosotros probemos a los clientes sea capaz de cumplir reglas y regulaciones de los países donde va a correr a fin de cuentas. Cada país tiene sus propias reglas, cada país tiene ciertas requisitos que deben detener para poder correr lo que necesita correr. Entonces, por ejemplo, en Estados Unidos, dependiendo de lo que vayas a hacer, tiene ciertas reglas de cumplir. Por ejemplo, si vas a trabajar con datos de tarjetas de crédito, tienes que seguir PCI-DSS. Si vas a trabajar con gobierno, vas a hacer FedRAMP. Y hay muchas, muchas cosas que cumplirlo. Entonces, nosotros nos dedicamos a ayudar a que se puedan cumplir tales reglas en OpenShift. Muy bien. Entonces, en este episodio vamos a hablar de seguridad. Un tema muy prominente en las noticias, casi siempre no por buenas razones. Así que el lema quiere ser bastante proactivos, estar bastante listos y chévere porque con un producto como OpenShift, aunque estemos haciendo mejoras para un cierto tipo de clientes, usuarios, etcétera, digamos, es open source y todos los demás se benefician. Así que esto siempre es un trabajo que es agregado y va creciendo exponencialmente. Vamos a hablar también sobre la diferencia entre qué es seguridad y qué es cumplimiento o compliance en inglés. Así como también las maneras en las que Red Hat OpenShift es parte de la estrategia de seguridad y cumplimiento para varias empresas en distintos mercados, en los distintos países en los que operan, que generalmente no es el país donde están establecidos. Y incluimos también en esta presentación un demo de el operador de cumplimiento en OpenShift, que Juan va a hacer para nosotros. Pero antes hablemos un poquito de seguridad y cumplimiento dentro del roadmap de OpenShift. Así que vamos a la siguiente slide, Juan. Si tienes un Product Manager en el género del producto, siempre hay que hablar del roadmap de qué es lo que estamos planeando y dónde nos ubicamos. Entonces OpenShift tiene muchísimas áreas que cubrir, la área de desarrolladores, de la aplicación, de la plataforma y en la parte de OpenShift Managed o los servicios que ofrece Red Hat East y nuestros partners en donde damos OpenShift completamente listo para nuestros clientes. En 4.6 aquí ven en círculo el Compliance Operator que vino en 4.6, que es la versión que está actualmente disponible. En el 4.7, 4.8 vamos a hablar sobre OpenShift dedicated y la certificación PCI, así como también o otra certificación más allá en OpenShift más adelante, como lo son Amro y FedRAM. Así que seguimos el siguiente slide. Como ven, hablamos de certificaciones que son, digamos, específicas para ciertos países o ciertas cosas, pero en realidad todo este tipo de trabajo, todo este digamos en due diligence, todo este trabajo que estamos haciendo puede ser beneficioso para cualquier tipo de empresa. Así que, bueno, empecemos con la primera pregunta. Como vemos la parte de Compliance y de cumplimiento y de seguridad está en varios niveles de OpenShift, pero Juan, cuéntame cuál es la diferencia entre cumplimiento y seguridad y qué es cada una? Claro, cumplimiento y seguridad son términos que están muy relacionados, pero realmente no son lo mismo y hay una diferencia muy sutil en ellos. Seguridad se dedica, claro, a proteger a tu organización de riesgos y de, pues, atacadores que lleguen a tratar de hackearte, robar datos o cosas así, mientras que el cumplimiento o Compliance se dedica generalmente a proteger cierto tipo de datos. Pues, entonces, están relacionados, pero hay una diferencia sutil, como dije. Aquí me refiero con datos. Pues, PCI DSS, que mencioné un poquito antes, se dedica a proteger datos de financieros de tus clientes. Pues, HIPAA se dedica a proteger datos de salud. Pues, entonces, todas estas regulaciones tienen reglas y esas reglas tienen controles y los controles son formas o recomendaciones de cómo proteger este tipo de datos. Entonces, si sigues estas reglas, que algunos países, pues, claro, es obligatorio seguirlas, por ende, puede ser más seguro. Pero, claro, el hecho de que tengas cumplimiento no quiere decir que tu organización esté segura, ¿no? Claro, tienes que seguir, dar el siguiente paso y seguir monitoreando y seguir, pues, fortaleciendo todas las defensas de tu deployment, pues, a fin de cuentas. Claro, y la otra cosa que hay que tener en cuenta es que para tener cumplimiento, generalmente, tienes que tener una auditoría y cada país tiene sus propias reglas de eso, ¿no? Y eso es un proceso larguísimo también, pero nosotros, claro, tratamos de ayudar. Entonces, esa sería la diferencia. Muy bien. Entonces, yo también estaba preguntando algo un poco relacionado con lo que tú hablabas de por qué es importante cumplir con estas regulaciones y hablamos que son diferentes para cada país y diferente también para cada industria, o sea, también sé que, por ejemplo, bancos con los que no trabajamos están enfocados en ciertas regulaciones, también trabajamos con el sector público, tiene diferentes regulaciones que cada país ha hecho para su sector público. Pero cómo hacerlo con OpenShift y qué regulaciones de cada, digamos, país, qué similitud pueden tener entre ellas y qué significa estar certificado a acepto nivel. Bueno, este es muy difícil seguir todas las regulaciones y reglas de todos los países, pero tienen varias similitudes y hay ciertos estándares que son seguidos por muchos países, en de cuentas, ¿no? Que no te lo van a aplicar directamente, pero si saben que está certificado en cierta cosa, es generalmente aceptado en varios países. Lo PCI-DSS es un estándar muy, muy común y conocido. Entonces, si tienes protecciones y controles de PCI en otros países, pues claro, están felices de que lo tengas, ¿no? Entonces, te van a aceptar. Otra, por ejemplo, es FedRAMP que sigue los requerimientos puestos por NIST y NIST tiene ciertas bases, ¿no? Entonces, tienen bajo, moderado y alto. Si estás en moderado y alto en otros países, claro, se puede mapear directo de los requisitos de NIST a lo que te pide cierto país. Y sí, bueno, entonces, lo que en OpenShift, por ejemplo, no te vamos a dar un sistema específicamente certificado. Claro, te lo vamos a vender. Puede certificarse, pero la certificación depende de cada implementación. Entonces, no certificas un producto, certificas una implementación del producto. Entonces, tú como cliente vas a instalar OpenShift, vas a tener todos los detalles de tu implementación, y va a llegar una auditoria y lo va a checar. Entonces, no nos checan a nosotros en Red Hat, pero nosotros ayudamos a que puedas cumplir con esos requerimientos. O sea, básicamente el trabajo de nosotros en Red Hat es también conocer este tipo de regulaciones, saber. Así es. Bueno, digamos, para que tengamos una idea de exactamente qué es lo que es, básicamente una base de datos de Excel grandísima de un montón de reglas que hay que cumplir y saber cómo OpenShift cada vez más está acercándose más a todas esas regulaciones. Y también tener, digamos, una idea de cómo implementarlo, porque si bien al comprar OpenShift o al instalar OpenShift no estás listo, pues tienes también un poco lo que es la experiencia de Red Hat de haber hecho este tipo de certificaciones con otros clientes, ¿verdad? Que aunque no sea un mapeo uno a uno, pues ya es experiencia que hemos ganado en el equipo de seguridad de Red Hat para poder seguir ayudando y ofreciendo guías o patrones a seguir a nuestro cliente. Cuéntame que cuáles son las, no sé si tienes como anécdotas de las, digamos, lineamientos de seguridad más difíciles de cumplir o unos que ya hayamos cumplido con algún cliente o algún cambio que hayamos hecho antes en el producto para ir mejorándolo hasta tener un cierto tipo de compliance. Claro, por ejemplo, uno muy sencillo son los, los logs de auditoría de OpenShift que en versiones anteriores no, pues el sistema no hace nada con ellos, ¿no? Y nosotros vimos que había un problema ahí, nos metimos con el equipo, ayudamos y gracias a ese trabajo ahora hay una forma muy sencilla de decirle OpenShift y tomar las reglas de los logs o de auditoría y mándalos a otro lado, ¿no? Entonces, eso es muy común porque si tienes algún problema de que alguien se mete a tu sistema tienes que en ciertos sectores tienes que ir a corte a veces incluso y presentar la evidencia, ¿no? Entonces, esa evidencia tiene que guardarse en algún sistema externo o ya sea el last Explon que hay mucho IBM tiene su propio CM, hay muchas implementaciones, pero bueno, tienes que guardarlas ahí y presentarlo para auditoría y para como evidencia, pues entonces hay muchas cosas muy importantes no solo porque te ayuda a certificarte, pero también te ayuda en un ámbito legal. Ese sería un ejemplo muy, muy sencillo. Y digamos estas regulaciones, digamos, te dice qué es lo que tienes que tener. O sea, por ejemplo, necesitas tener logs y poder y esos logs tienen que enviarse a un sitio y tienen que ser auditables, pero no te dice cómo hacerlo. Ese how, ese cómo implementarlo, queda a cada tipo de implementación, pero digamos tienes que tenerlo, ¿no? Así es, exactamente, la regla es un generalmente un poquito abstractas, pero tiene una razón de ser, ¿no? No se supone que deben aplicar a sistemas en general, en vez de decirte exactamente cómo hacerlo, porque si lo hicieran así sería demasiado estricto y con los años se deterioraría, pues. Incluso todavía pasa ahorita con algunas de esas reglas, pero en la mayoría de los casos hay muchas reglas de regulaciones y de cumplimiento que son aplicables a cualquier sistema, tener audit logs, tener cierto tipo de quitación, tener la habilidad de, bueno, tener RBAC puestos, o sea, tener reglas para que ciertos usuarios puedan tener ciertas acciones y otros no. Son cosas muy generales, pero que aplican, por ejemplo, a OpenStack, a OpenShift, a Red Hat Virtualization. Entonces, muy general. Sí, acceso basado en diferentes roles. O sea, la parte de seguridad y compliance en realidad está en todas estas partes de la plataforma, digamos. Todas esas lineamientos, tú tienes que estar consciente y trabajar tanto al nivel de sistema operativo, como a nivel Kubernetes, como a nivel de los servicios de Cluster, como a nivel de la aplicación y data hasta el Multicluster Manager. Tienes que saber un poco de todos los niveles de la implementación. Así que esta parte me parece bien interesante. Es muy interesante y entretenido de esta área, ¿no? Porque tienes que ver cómo funciona todo. Tienes que meterte tanto el sistema operativo como al Multicluster Manager y se sigue expandiendo, ¿no? Vamos a, bueno, ya sacamos OpenShift Virtualization y también vamos a estar viendo eso, ¿no? Entonces, hay muchos, muchos temas. Hay muchas cosas que ver. Entonces, es muy, muy interesante en ese aspecto. Y también, ¿en dónde está el, ¿quiere decir deployment? Pero no sé la palabra en español. Despliegue. El despliegue. Perdón, gracias. El despliegue de OpenShift, porque también si estamos hablando de un despliegue en, por ejemplo, OpenShift Virtualization en un ambiente físico en un Data Center, tiene que tener ciertos lineamientos de seguridad. Si lo quieres tener en una nube pública, pues ya hay ciertos lineamientos que por diseño no se cumplen, porque estás en una nube pública, tienes diferentes accesos, etcétera. Así que poder cumplir con todos los lineamientos, dependiendo de dónde cada despliegue, es interesante. Y también me parece que toda esta estrategia de nube híbrida, ese nombre también me parece súper extraño, porque es de Hybrid Cloud, pero la nube híbrida que ayuda también a resolver que de repente no en todos los aspectos de las cargas que estés corriendo necesitan tener todo, pueden correr libremente en la nube pública, por ejemplo, de repente necesitas algunas que tienen que cumplir ciertos otros lineamientos, tienes que decir, sí, hacerlo en un ambiente físico con cierto tipo de controles, o si va a ser en una nube pública, pues en algo que sea específicamente para el sector público que cubra una vela virilizón, una zona de habilidad de disponibilidad, que tenga ciertos lineamientos para poder cumplir todos los requisitos de seguridad. Así que, bueno, para mí súper interesante y de verdad que no es un área en la que trabajo mucho, es una área en la que si me llego a enterar es porque hay un problema. Entonces, como digo, es un trabajo de ser bastante proactivo y también tener asesoría para poder cumplirlo. Y la ventaja con Open Source o con este software libre es que todas las mejoras que se hacen en Kubernetes, en OpenShift para un cliente o para un tipo de usuario, pues llegan a beneficiar a todos y todos esos cambios pues siguen aumentando o no. Así que, bueno, si nos vamos a la siguiente slide, hablamos sobre el Compliance Operator o el Operator de Complimiento. ¿Qué nos puedes contar sobre este? Bueno, pues ese es un proyecto en el que trabajamos por bastante tiempo y por fin salió en 4.6. Bueno, aquí justamente estamos mostrando un poquito de cómo se ve la documentación. Pero es un operador que, bueno, como ustedes conocerán, los operadores en OpenShift son una manera de automatizar ciertas acciones que tendría que hacer algún operador. Bueno, tenemos algo para el cumplimiento. Y lo que hace es tratar de automatizar y hacer la vida más fácil cuando tienes que hacer escaneos de seguridad en tu sistema, en contra de cierto perfil de seguridad, pues. Entonces, tiene la manera de correr escaneos periódicos o constantes y te va a decir si tienes algún problema, como arreglarlo, incluso puede arreglar ciertas cosas automáticamente, incluso, que no aplican a todos los despliegues, pues. Y sí, pues estoy muy emocionado porque estoy mucho tiempo trabajando en esto y creemos que va a ser muy útil para los clientes, pues. O sea, que el cumplimiento no es algo que es el primer día de despliegue, ya Day 1 hace todo el despliegue, queda todo perfecto, tienen los auditores, todo el mundo chequea muy bien. Y después te olvidas del cumplimiento. Así no funciona. Necesitas seguir monitoreando y haciendo y teniendo logs y tal. Y este operator te ayuda también a automatizar cierto tipo de policies. Sí, de políticas o escaneos. Pero sí, exactamente como dices. No, es un proceso constante. Es un proceso que tienes que seguir y es un proceso complicado. Entonces, tratamos de hacer la vida más fácil y justamente es por lo que existe este operador, pues. Y también el operador te ayuda a que sea algo que puedes correr, digamos, constantemente, pero también consistentemente. O sea, no es que haces un solo chequeo y ya y la siguiente vez lo hace otra persona y se lo olvido hacer esta otra marquita, sino al correr el operador, pues tienes un tipo de consistencia en cada vez que haces los chequeos, que es importante, porque pues no todo el mundo se queda trabajando en todas las compañías toda la vida. Claro, así es. Y por otro lado, como dices, tú tienes que ser algo sencillo, algo fácil de hacer. Entonces, está en Operator Hub, es algo muy sencillo de instalar en esta muestra de pantalla y ya está instalado en el sistema incluso. Pero sí, o sea, lo instala uno, corres los escanados que tienes que correr y puedes guardar como en cualquier otro objeto en Kubernetes. Puedes guardarlo en Git incluso y tenerlo ahí y tener otro sistema como Advanced Cluster Manager que lo corra en todos estos despliegues. Abre muchas puertas para tener una historia mucho más sencilla de cumplimiento. Y digamos, así no estés tratando de seguir algún tipo de lineamiento de cumplimiento o algún tipo de certificación o FedRAM o otro. Básicamente como un operador de la nube es, digamos, más información que te ayuda a saber cómo está funcionando tu ambiente y saber qué hay consistencia en no solamente en el performance, pero también en cómo estás cumpliendo el diseño de tu ambiente. Así que, súper, pues ya estoy emocionada que me muestres cómo funciona. Así que va más a la hora. Claro, claro. Aquí tenemos, bueno, tengo un sistema. Lo tenía en desarrollo, pues, porque estoy escribiendo justamente más contenido. Entonces, esperemos que todo funcione muy bien, porque todo está en desarrollo. Pero bueno, hay una versión estable que está en Operator Hub. Pero, bueno, aquí te muestro lo que tenemos. Tengo una versión ahorita 4.7 que apenas va a salir. Está basada en Kubernetes 1.19. Y ya estoy justamente en el namespace o el proyecto de Open Chef Compliance. El operador está corriendo y todo está bien. El operador ya te da algunos perfiles que puedes tomar, que son probados y redhead los, te los proveen. Entonces, oh, sí, ya está. Oh, padre. Y, pues, como ves, son varios, ¿no? Entonces, un perfil que es muy peido por los clientes y que es muy conocido es el CIS Benchmark. Y aquí lo tenemos, pues, vamos a correrlo. Entonces, también tenemos un plugin, oh, sí, Compliance, que te ayuda a tener las cosas más sencillas, pero vamos a verlo. Oh, sí, Compliance Bind. Si le da Most Dry Run, te muestra cómo se vería lo que tienes que hacer. Y es un objeto en Kubernetes muy similar a otras cosas que has visto, ¿no? Tienes el perfil de OCP4 CIS y el CIS Node, que son muy, muy similares. Uno te va a checar la configuración de tu despliegue de OpenShift y el otro va a checar la configuración de los nodes en ColorOS. Y te podemos tener ciertos settings, ciertas, como lo diría en español. Configuración. Bueno, vamos a verlos. Configuraciones, ciertas configuraciones. ¿Qué es lo que me está revisando en los nodes de ColorOS, por ejemplo? Ah, bueno, lo que checamos en ColorOS son cosas muy sencillas de, bueno, tienen tus archivos, tienen el modo correcto, los permisos correctos que no tengan ciertos que, por ejemplo, pues es muy sencillo que alguien mueva una configuración nada más por hacer debugging y modifique un archivo para que sea visto por todos los usuarios en el sistema. Esto generalmente está mal. Entonces, checamos que todo esté en el estado correcto para que no haya vulnerabilidades. Son cosas que checamos, por ejemplo. Puedes tener ciertas configuraciones para los escaneos. Por ejemplo, en este caso, para guardar los resultados, tenemos cierto storage puesto. Puedes poner incluso cuando quieres correr los escaneos. En este caso, lo corro cada día a la una y la mañana, pero se puede correr cada media hora, cada hora. Toleraciones que debas de tener. En fin, esto es lo que lo que te ofrecemos por default. Si no le doy el driver. Sí, lo corres cada día. Es decir, que lo corres cada día que hace con el resultado. Te mando el div, te hace una alarma, te lo corre. Te mando eventos de que haya un resultado puesto. Va guardando los resultados en objetos de cubernetes y, aparte, va guardando los resultados por día en un volumen que puedes bajar y puedes mandarlo a un auditor, que es lo que los audidores suelen ver. Pero puedes incluso checarlo todo por cubernetes en sí. Por ejemplo, lo que vamos a hacer ahorita es correr el perfil de si a es. Y lo único que le decimos a cubernetes es quiero que este objeto exista y ya. Entonces, o sí, get compliance suite. Tienes el Scancering Binding, que es hace un binding de los configuración del escaneo hacia los perfiles que quieres correr y para seguir los resultados en vivo puedes usar algo que se llama compliance suite. Entonces, vamos a seguirlo y te dice, ah, bueno, tengo si a es, ya está corriendo, pero todavía no hay resultado. Va a seguir corriendo y en un momento va a decirnos cómo está nuestra despliegue. ¿Cuál es tu despliegue que tienes ahora? ¿Tienes un master, cuántos workers? Ah, bueno, es un sistema muy, muy común. Nada más voy a seguir ahorita ya. Ya casi nos da los resultados, pero son tres masters y tres workers. Nada fuera de lo común. Aquí. ¿Nos? Y no hubo nada. No sé, 30 segundos, 20 segundos de repente, bueno. Claro, depende del perfil. El benchmark de si a es, bueno, tiene bastantes resultados, pero no son tantos. Algo como Fedron moderate tiene más de 500 chequeos que hacen tu sistema de todo tipo. Entonces, ese si te, se tarda un poquito más. Pero en este caso no es mucho, este, podemos ver los resultados como un sigues compliance. Dos, dos. Y te dice todo, ¿no? Tienes, bueno, sí son bastantes chequeos, pero generalmente está pasando todo. Te dice, pues, si te tienes que alarmar o no. O sea, si es algún encuentro medio o alto. Entonces, bueno, claro, en este caso son muchos y queremos filtrarlos, pues tenemos también un label en Kubernetes para hacerlo. Y ya me dice, ah, oye, fallaron estos dos chequeos que podemos hacer. Y quién, o sea, quién, tú, alguien del equipo de seguridad. Cada uno de estos chequeos de alguna manera, digamos, mapea uno a uno a algún compliance, a algún requerimiento de cumplimientos de si a es o de. Así es. Que trabajo. En este caso el benchmark, si ahí lo estamos escribiendo todavía, entonces no te va a aparecer formalmente todavía el control. Pero cuando lo saquemos, ya va a aparecer, no. Entonces, este, por ejemplo, con los chequeos de FedRAM moderate que estamos escribiendo también ahí si sale todo. Bueno, tienes el chequeo de NIST a U17. Entonces, todo te va a salir ahí. ¿Quieres ver algún control? También con un plugin podemos ver cuando el control el resultado result. Lo que me pongo a pensar es que, digamos, alguien puede hacer esto sin el compliance operator, pero, aha, primero, tienes que leer el mega manual de FedRAM, puedo decir. Después, si no te dormiste o no te olvidaste, tienes que empezar a ver cómo son todos estos chequeos y hacer, digamos, este chequeo manual. Y es lo que te digo, es no solamente la de hacerlo constantemente, sino consistentemente, ¿no? Que no te peles un chequeo antes. Eso es lo que me parece que es el valor de este tipo de operator, de poder automatizar este trabajo. Es, uf, súper. Claro. Bueno, justamente como dices, ahorita estoy viendo el resultado de un control y te dice de qué trata, te da una descripción, te dice por qué es importante checarlo e incluso te dice que control. En este caso, me dio el de FedRAM también, porque toda la información está ahí. Pero me dice que control se está cumpliendo específicamente, que es algo muy importante cuando estás checando los resultados, ¿no? También te dice si hay alguna remediación, porque puede remediar automáticamente. Y te dice, pues, bueno, cuál fue la regla que tenías que cumplir y demás. Entonces, en este caso, por ejemplo, el que estoy viendo es chequea si estás mandando tus logs de auditoría a otro sistema. No tenemos una remediación automática, porque no queremos decirte a dónde mandarlo, ¿no? Todo, cada despliegue es diferente. Algunos son clientes de Elástica, algunos son clientes de Splunk. Entonces, damos la oportunidad. Bueno, pues, manda lo donde quieras, pero manda los. Entonces, eso es lo que checamos. Por ejemplo, aquí tengo un pequeño ejemplo que vamos a ver. Osquit, menos f, osquit resources. Nosotros tenemos el cluster login operator también. Bueno, no es de mi equipo, ¿no? Pero otro equipo lo tiene, a fin de cuentas. Y este operador te ayuda a mandar los logs otro lado. Entonces, primero lo vamos a instalar. Vamos a esperar un poquito que se instale. Y lo que vamos a hacer es lo siguiente. Vamos a. O sea, maravilloso. El operador de cumplimiento se dio cuenta que no estás mandando los logs. Y ahora tuco. Así es. Entonces, ajá, ¿y cómo manda logs? Bueno, resulta que hay otro operador que hace que pueda mandar logs y simplemente lo estás instalando para poder mandarlo. Así es. Entonces, lo que vamos a hacer es algo muy sencillo. Nada más vamos a decirle al operador. Bueno, a instalar el operador, que también no se checa. Claro, eso es mucho más sencillo que tener que ir y instalar un help chart o algo similar. Entonces, vamos a instalar estos dos cosas. No hubo una instancia de cluster logging, que es todo el sistema de fluente y elástica y demás. Y que corre a tu sistema. Y el otro de log forwarder que lo único que hace es mandar en esta instancia, manda todos los logs de aplicación, auditoría, infraestructura, al default. O sea, lo manda a la instancia de elástica que cluster logging operator te da. Entonces, es bastante sencillo en ese aspecto. Entonces, vamos a ver si ya lo tenemos. O si, ¿qué es? O si, o si. Vamos a instalar la instancia. Ya la creo. Y vamos a instalar el forwarder. Y ya. Entonces, bueno, si corremos otra vez el operar el escaneo, ya te diría, ah, bueno, ya, ya eres, ya cumples pues. Ya estás haciendo algo. El forwarder es parte del operator de cluster logging operator? Así es. Entonces, ya no tienes que correr reglas de fluendique, costum, pues ya no tienes que hacerlo tú. El operador lo hace por ti. Otra cosa es que tenemos tiempo de instalar el de cumplimiento, también instalar el de logging, asegurarse que este flow, digamos, trabaja en unísono y que puede aplicar para cualquier instalación de OpenShift. Maravilloso. Así es. Por ejemplo, tenemos otro tipo de cosas que, bueno, en ciertos tipos de chequeos es muy fácil saber si, bueno, saber cómo arreglar el problema, porque es nada más, hay una solución. Por ejemplo, si es benchmark, te dice, bueno, tienes que encryptar tu instancia de Ed City. Y en OpenShift eso es algo muy sencillo. Hay una manera de hacerlo. Entonces, podemos tener una remediación para eso. Entonces, si vemos OZ compliance mediations, va a crear una que dice, OZ, bueno, server encryption provider config, la podemos ver así. Y lo que va a hacer esto es aplicar al API server este tipo de encryptación. El operador lo puede aplicar también. Entonces, OZ edit compliance remediations. Y lo que queremos es que se aplique y listo. El operador va a hacer lo suyo y va a asegurarse de que este objeto esté en el estado correcto. Y listo, vamos a cumplir. Esto suele tardar un poquito. Entonces, podemos tomar un poquito más de plática por mientras. Y esta remediación también funcionan para otro tipo de compliance que no, digamos, otro error que me haya dado el CIS. Ah, claro. En este caso nada más me dio una. No, entonces, ese es el único problema que había. Pero otros perfiles van a tener otras remediaciones. Por ejemplo, en Federal moderate hay muchas cosas de tienes que tener ciertos tipos de reglas de auditoría para auditi en CoreOS. Generalmente no queremos habilitar esas por default, pues, desde la caja. Porque, bueno, eso te va a hacer el despliego un poco más lento, ¿no? Entonces, no todos los clientes quieren ese tipo de reglas en la auditoría, no necesitan tanto. Y por eso no es el default. Pero, bueno, el compliance operator te ayuda a que tengas todo lo que necesitas en ese aspecto. También hay ciertos parámetros del kernel que hay que habilitar para Federal moderate específicamente. Entonces, todo ese tipo de cosas se puede hacer en automático con el compliance operator. Puedes hacerlo como lo hice ahorita. Cambiando un flag que dice apply true, pero también en los settings. Yes, can settings. Bueno, si damos OC explain, podemos ver que hay una opción para aplicar automáticamente las remediaciones. Entonces, si corres un escaneo con esta opción habilitada, automáticamente va a arreglar todo. Obviamente este, digamos que tienes que tener más confianza en el sistema, saber lo que estás haciendo y ser, digamos, un problema que generalmente esté remediando para hacerlo con confianza. Pero creo que también uno de las cosas que estoy aprendiendo es que cuando corres el operador de cumplimiento para un cierto tipo de área, el hecho de que sea falso o que te de ciertas alertas no quiere decir que necesariamente tengas un problema. Puede ser que, digamos, por parte del diseño, este despliegue en particular nunca va a cumplir ese objetivo, pero, pues, está bien. Digamos que un check. También saber por qué no se cumple es importante. Ah, claro. Y también el operador tiene la opción de modificar perfiles. Porque, como dices, hay algunos chequeos que no aplican a ciertos perfiles por cuestiones de performance o por cualquier cuestión, que tienes algún otro solución que sea única para tu despliegue. Entonces, también se puede hacer algo que se llama tailoring, que es como un sastre, no? Uno modifica un perfil y, pues, bueno, sería único para tu despliegue. El operador también puede hacer ese tipo de cosas. Vas a ir dando tu la razón por la que estás cambiando el perfil y, listo, te ya podrías correrlo y cumplir, pues. Tailoring de desastre, o sea, puedo, como un operador, yo, digamos, cambiar el rango de los valores que son aceptables, o puedo yo definir nuevo valor, o puedo yo definir también, no? Mira, ahora quiero que haga este otro chequeo. ¿Qué tan citados? Así es, de las dos. OK. Justamente. Entonces, puedes dar una lista de quiero que deshabilites estos chequeos completamente. O quiero que agregues estos otros chequeos, porque nuestro equipo de seguridad ha definido que son importantes y se necesitan checar también. Ah, bueno, puedes hacer esas dos cosas. También en ciertos valores que, bueno, sabes que quiero checar que este valor para el buffer de auditoría sea en vez de 8000, sea 10,000. Ah, bueno, puedes hacerlo también. ¿Y qué tal? ¿Y cómo hago para cambiarlo? O sea, ¿qué tal si quiero agregar otro chequeo? ¿Puedo crear mi propio operador? ¿Puedo editar el operador de compliance? ¿Cuál es la mejor manera o como has visto que esto pueda suceder? Ah, bueno, este para eso hay un objeto específico llamado Taylor Profile. Piaos y explain Taylor Profiles. Y este objeto extendería a otro perfil. Por ejemplo, si damos aquí en el spec del Taylor Profile, le puedes decir, bueno, extiende a este perfil, agrega estas reglas, quita estas reglas, pon estos valores de este modo. Quiero que pongas esta descripción, este título, para que se entienda exactamente qué estamos haciendo. Entonces, todo ese tipo de cosas se pueden hacer. Y chévere, porque no tengo que ir a crear mi propio operador y inventarme otra cosa, digamos, externa, sino también seguir agregando a esto. Y una vez que corras el compliance operator, pues, agregas estas nuevas, esos nuevos perfiles. Super. Así es. Entonces, ya para concluir, este podemos dar o si compliance me run now, o sea, córrelo otra vez. Porque en este caso no estoy teniendo un chequeo continuo. Digo, eso se puede hacer también modificando el tello. Pero en este caso lo puedo correr al hoc. Entonces, quiero correrlo ya, se corre ya y listo. Entonces, ahora, o sí, está. Y como vemos, ya está corriendo otra vez y nos va a dar los resultados dentro de poco. En realidad, es súper como intuitivo. No va a decir sencilla, pero sí es intuitivo lo que estás haciendo que esto es lo mejor para para los usuarios de edad. Claro, nos tratamos de enfocar mucho en eso. En especial, porque en el pasado, al correr este tipo de aplicaciones directo, tienes que saber exactamente el ID y leer XML. Entonces, tienes que ponerle todos los datos y la gente se suele equivocar mucho. Entonces, teniendo ya perfiles hechos, teniendo objetos que nada más. Pues crea uno y Kubernetes los pones en guites un poquito más sencillo. Tratamos de hacer la vida más fácil para cumplir con estas reglas, ¿no? Entonces, ya como vimos, se corrió el perfil y arreglamos los problemas y ya te dice, bueno, ya cumples. Si quieres bajar los resultados, también se puede hacer. Entonces, o sí, client, fetch, raw, bajar el de CIS y lo vamos a poner en. Entonces, como mencioné antes, los resultados se guardan en un volumen en Kubernetes. Ese volumen va a estar en tu nube. Y en este caso, lo que vamos a hacer es bajarlo. Y estos son los resultados que muchos auditores ya están acostumbrados a ver. Pueden ver, claro, los objetos en Kubernetes si quieren, pero si ya tienen ciertos utilidades o programas para ver y auditar todo esto, pues los pueden usar también. Entonces, no estamos cambiando nada. Todos son estándares que se siguen en la industria. Entonces, en este caso, bueno, pues está creando un pod, bajando todos los resultados, poniéndolos en donde quieres. Y vamos a verlo ahorita. Y este fetch, que este fetch raw que haces, puedes también hacerlo parte del schedule, digamos. Si lo corro cada día, cada 15 días, cada tiempo que te mandalo también a este lugar. Y luego, el login operator es el que se encarga de decir cuánto tiempo tiene que estar eso ahí, cada cuánto haces un purge, cada cuánto lo mandas a otro archivo para que no. Porque también la parte del login es como saber cuándo parar de buscar cosas o cuándo pedir más storage o. Claro, bueno, en este caso, estos son, no son logs en sí, son resultados y un archivo, este raw, bueno, pues lo que openscap generalmente haría. Entonces, en este caso, bueno, ya te da el reporte que muchos audidores ya están acostumbrados a ver y te dice, bueno, decía es, esto fue lo que checamos en general en tu despiegue, también te da el XML, porque también hay otras utilidades para leerlo. Pero bueno, para los masternodes, esto fue lo que checamos y para todos los, para todos los nodos, pues en el sistema va a ser diferentes chequeos y en este caso, bueno, 89 reglas para cada nodo, este, y sí. O sea, Juan, este resultado es lo que le mandas a los audidores, aparte de otro, digamos, una hoja de presentación, pero básicamente, esto es lo que se le manda a los audidores, excelente. Así es. Super excelente. Y bueno, eso es todo por el demo que tenía para el operador de compliance. Me encantó. Me encantó, porque me encanta autorizar de hacer la vida más fácil a los operadores, este, y saber que esto es algo, no solamente lo que estamos trabajando ahora, sino que, digamos, cada vez lo estamos mejorando más y más, entonces, pues, digamos, siempre vamos a seguir hacia adelante. Muchas gracias, Juan. Sigamos al próximo slide. La próxima semana, en nuestro próximo episodio, vamos a hablar de OpenShift en OpenStack. Y va a estar también Ramón Acedo, que habla sobre OpenShift en OpenStack, tiene súper experiencia en este tipo de despliegue. Y vamos a hablar qué herramientas se han utilizado para mejorar el despliegue de OpenStack en ambientes desconectados, también con OpenShift, y cómo funciona OpenShift, digamos, en este despliegue. El fin de esto, digamos, es correr en el mismo ambiente, tanto en máquinas virtuales como contenedores. También tenemos OpenShift Virtualization, pero, digamos, si no tienes OpenShift Virtualization, puedes correr máquinas virtuales en OpenStack, que es lo que hacemos por años de años, y contenedores también. Pero también, o ver, entonces, puedes tenerlo en OpenShift. Así que, esa será la semana que viene. Y ya ahora creo que vamos a abrirlo para preguntas y respuestas. Pero muchísimas gracias por haber estado con nosotros. Muchísimas gracias, Juan. Me encantó conocer hablar contigo sobre este tema. Y, bueno, gracias por responder todas las preguntas. Muchas gracias a ti, y me gustó mucho estar en este programa. Qué bien. Espero que sea la primera, pero no la última. Bye. Bye.