Autenticación sin contraseña para servidores: práctica con ASA

Rate this content
Bookmark

Hoy en día, no necesitas una contraseña separada para cada sitio web en el que inicias sesión. Sin embargo, gracias a la deuda tecnológica y la tradición, muchos profesionales de DevOps todavía tienen que lidiar con una gran cantidad de claves SSH para acceder a los servidores en los que a veces necesitamos estar. Con OAuth moderno, un solo inicio de sesión y un segundo factor para demostrar tu identidad son suficientes para acceder de forma segura a todos los servicios a los que tienes autorización. ¿Y si SSHing en servidores fuera tan fácil? En este masterclass, utilizaremos la herramienta de Acceso Avanzado a Servidores de Okta (anteriormente ScaleFT) para experimentar una forma en que el sueño de enviar claves SSH como la contraseña se ha hecho realidad.


- discutiremos cómo funciona ASA y cuándo es la herramienta adecuada para el trabajo

- guiaremos el proceso de configuración de una cuenta de prueba gratuita de Okta para usar ASA, y la configuración de la puerta de enlace ASA y el servidor en servidores Linux

- luego nos conectaremos por SSH a nuestros hosts con los clientes ASA sin necesidad de proporcionar una clave SSH desde nuestras laptops

- revisaremos los registros de auditoría de nuestras sesiones SSH para examinar qué comandos se ejecutaron

32 min
29 Mar, 2022

Comments

Sign in or register to post your comment.

Video Summary and Transcription

Este masterclass presenta la herramienta ASA de Okta para gestionar el acceso a servidores y explora los conceptos de autenticación y autorización. Se discuten los desafíos de gestionar claves SSH y los beneficios de utilizar claves de un solo uso. El masterclass también explica cómo ASA de Okta simplifica el acceso a servidores al reutilizar un proveedor de identidad. Proporciona una guía paso a paso para configurar y gestionar la autorización y autenticación utilizando ASA de Okta. Por último, se cubre el proceso de configuración de servidores y clientes, así como la limpieza después de las pruebas.

Available in English

1. Introducción a ASA de Okta

Short description:

Hola a todos. Soy Emily para los humanos o eDunham para las computadoras. Soy una nerd de código abierto y asistente desde los primeros días en que nos llamábamos DevOps. Trabajo como defensora del desarrollo en Okta. Hoy les mostraré una herramienta de Okta, pero mis opiniones y cualquier error que pueda cometer son completamente míos. Muchos avances en DevOps se centran en alejarnos de ejecutar y gestionar servidores. Pero muchos de nosotros todavía tenemos que ejecutar servidores. Tal vez sea porque estamos trabajando en la migración de una arquitectura antigua que era de última generación cuando se diseñó por primera vez. O tal vez estamos lidiando con cargas de trabajo que realmente requieren que gestionemos directamente nuestros recursos informáticos. De cualquier manera, cuando gestionamos nuestros propios recursos en la nube o hardware, aún podemos separar tareas individuales que sería mejor hacer con software o servicios diseñados específicamente. Hoy me gustaría presentarles un truco para separar una de las partes difíciles de gestionar quién puede acceder a qué y cuándo, y mostrarles cómo replicar ese truco. La herramienta que hace este truco genial, ASA de Okta, no será perfecta para todos los casos de acceso. Sin embargo, incluso si nunca terminas trabajando directamente con ASA, espero que comprender su contexto te ayude a pensar críticamente sobre las fortalezas y debilidades de tus herramientas existentes como SSH convencional. Conocer más sobre tus herramientas y sus alternativas puede ayudarte a tomar las mejores decisiones de seguridad para cada desafío operativo al que te enfrentes.

Soy Emily para los humanos o eDunham para las computadoras. Soy una nerd de código abierto y asistente desde los primeros días en que nos llamábamos DevOps. Trabajo como defensora del desarrollo en Okta. Hoy les mostraré una herramienta de Okta, pero mis opiniones y cualquier error que pueda cometer son completamente míos.

Tenemos aproximadamente dos horas y una audiencia dividida. Algunas personas están aquí en la sala de Zoom y otras están viendo esta grabación en el futuro. Grabaremos la primera mitad con todas estas explicaciones para que las personas del futuro puedan unirse a nosotros. Pero para la segunda mitad práctica, al final, detendré la grabación para que podamos simplemente charlar. Y puedes hacer las preguntas que tal vez no quieras que queden registradas para la posteridad. No tienes que mirar la pantalla mientras escuchas esto. Pero te ayudará ver las capturas de pantalla una vez que llegue al resumen de la configuración.

Ahora, muchos avances en DevOps y gestionar servidores. se centran en alejarnos de ejecutar Eso a menudo es genial. Puedes delegar tareas individuales a personas o entidades especializadas en ellas. Tu base de datos bases de datos, tu herramienta de red es gestionada por expertos en redes. es administrada por expertos en Y eso es genial cuando es algo que puedes hacer. Cuando tienes los recursos para delegar el trabajo específico del dominio a especialistas en esos dominios, generalmente lo harán mejor que tu equipo. Al igual que cuando estás programando, si puedes usar una biblioteca bien probada de primitivas criptográficas en lugar de intentar crear la tuya propia, casi siempre terminarás con un código más seguro como resultado.

Pero muchos de nosotros todavía tenemos que ejecutar servidores. Tal vez sea porque estamos trabajando en la migración de una arquitectura antigua que era de última generación cuando se diseñó por primera vez. O tal vez estamos lidiando con cargas de trabajo que realmente requieren que gestionemos directamente nuestros recursos informáticos. De cualquier manera, cuando gestionamos nuestros propios recursos en la nube o hardware, aún podemos separar tareas individuales que sería mejor hacer con software o servicios diseñados específicamente. Hoy me gustaría presentarles un truco para separar una de las partes difíciles de gestionar quién puede acceder a qué y cuándo, y mostrarles cómo replicar ese truco.

Ahora, como persona que escucha charlas y también usa herramientas, comenzaré con el descargo de responsabilidad que siempre estoy atenta. La herramienta que hace este truco genial, ASA de Okta, no será perfecta para todos los casos de acceso. El mayor obstáculo que podrías encontrar es que el precio es por servidor y se prueba principalmente con la suposición de que estás utilizando Okta como proveedor de identidad. La parte del proveedor de identidad es relativamente negociable, pero lamentablemente el precio no lo es. Sin embargo, incluso si nunca terminas trabajando directamente con ASA, espero que comprender su contexto te ayude a pensar críticamente sobre las fortalezas y debilidades de tus herramientas existentes como SSH convencional. Conocer más sobre tus herramientas y sus alternativas puede ayudarte a tomar las mejores decisiones de seguridad para cada desafío operativo al que te enfrentes.

2. Comprendiendo la Autenticación y Autorización

Short description:

Dado que estamos hablando de seguridad, aclaremos qué significa autenticación. Se expande en dos formas: autenticación y autorización. La autenticación verifica si alguien es la misma persona que antes, mientras que la autorización determina si la persona autenticada tiene permiso para realizar una acción específica. Ningún método de autenticación es perfecto, pero agregar múltiples factores dificulta que los atacantes se hagan pasar por nosotros. La autenticación por sí sola no es suficiente para la autorización. Al igual que tener una identificación no garantiza la entrada a un bar, estar autenticado no garantiza la autorización. La autorización puede cambiar con el tiempo. Comprender la autenticación y autorización es crucial al gestionar el acceso a los recursos.

Dado que estamos hablando de security, me gustaría asegurarme de que todos entendamos qué significa exactamente la autenticación. Esto puede ser algo conocido para algunos de ustedes, pero todos lo escuchan por primera vez en algún momento y las personas ingresan a DevOps desde diferentes ámbitos. El truco de la autenticación es que se expande en dos formas diferentes. Primero, puede referirse a la autenticación. La autenticación responde a la pregunta: ¿es esta la misma persona que antes? Por ejemplo, una licencia de conducir o un pasaporte se utilizan a menudo para la autenticación y poder ingresar a lugares como bares o aviones. El documento con mi foto muestra que probablemente soy la misma persona a la que el gobierno emitió esa identificación. Mi nombre de usuario, contraseña y acceso a mi teléfono son una forma de autenticación para muchas cuentas en línea. Si los tengo, probablemente soy la misma persona que creó la cuenta. El microchip de mi gato también es una forma de autenticación. Si se escapara y alguien escaneara su chip para averiguar cómo llevarla de vuelta a casa, les diría que es el mismo gato que se registró en esa base de datos cuando la llevé por primera vez al veterinario. El descargo de responsabilidad aquí es que ninguna forma de autenticación es perfecta. En cualquier lugar donde el software interactúa con el resto del mundo, hay margen para que ocurran cosas inesperadas. Si alguien conociera todos mis secretos y tuviera acceso a todos mis dispositivos y pudiera usar mis biometrías, podría hacerse pasar por mí. Si alguien pudiera hacer que su rostro se parezca convincentemente al mío, podría pretender ser yo usando mi identificación con foto. Parafraseando a un gran autor, a medida que avanza la tecnología, la tecnología para engañar a esa tecnología crece junto con ella. Esto mantiene las cosas interesantes. Pero lo que podemos hacer es dificultar enormemente que alguien más se haga pasar por nosotros. Cada vez que agregamos otro factor de autenticación, hacemos que sea más difícil para un atacante pretender con éxito ser nosotros. Para acceder a mis cuentas de trabajo, necesitarías conocer mi contraseña, tener mi teléfono y tener mis biometrías juntas. Es relativamente fácil que una contraseña se vea comprometida, especialmente si alguien la reutiliza. Es relativamente fácil que un teléfono sea robado o que se secuestre una tarjeta SIM. Pero cuanto más factores se sumen, más cosas tendrían que salir bien para que un atacante pueda derrotar tus mecanismos de autenticación. Entonces, eso es la autenticación. Responde a la pregunta: ¿eres la misma persona que el tonto? Ahora, la autenticación es necesaria pero no suficiente para la autorización. Al igual que ser la misma persona en mi identificación no es suficiente para garantizar que pueda ingresar a un bar, también necesito estar autorizado por ser mayor de edad. Tener un pasaporte no es suficiente para permitirte subir a un avión, también necesitas estar autorizado para ese vuelo al tener un boleto. La autorización puede cambiar de un día para otro o incluso de un minuto a otro. Si tenía un boleto para este vuelo ayer, eso no significa que pueda subir al mismo vuelo mañana sin un nuevo boleto. Si estoy conectado a mi cuenta de Google y alguien comparte un documento conmigo, no estaba autorizado para verlo hace un momento y ahora sí lo estoy. Entonces, la autorización responde a la pregunta: ¿se le permite a esta persona autenticada hacer lo que está intentando? ¿Qué tiene que ver esto con el acceso a los servidores? Bueno, si alguna vez has gestionado el acceso a los recursos como persona de Operaciones, has razonado sobre la autenticación de los usuarios y la autorización.

3. Mecanismo de Autenticación y Autorización

Short description:

Si creas una clave con una frase de contraseña, entonces quien conozca la frase de contraseña probablemente sea la misma persona que creó la clave o al menos alguien a quien le hayan delegado eso. Pero solo tener la clave no te da acceso al host. Alguien tiene que colocar la clave en el host. Cuando colocan tu clave pública en el host, autorizan a cualquier persona con tu clave a iniciar sesión en él siempre que esa clave pública permanezca allí. Gestionar todo esto a gran escala tiende a convertirse en una verdadera aventura. Con claves compartidas, la incorporación es trivial. Simplemente les das una copia de la clave. Pero hacer la desvinculación correctamente es muy costoso. ¿Qué sucede cuando alguien se retira a una isla tropical y necesitas sacarlo del sistema? ¿Vas a rotar la clave para todos los que la tienen? ¿O simplemente te rendirás y los expulsarás de la red, eliminando su acceso en otro nivel para que incluso si pudieran pasar, aún tendrían la clave y podrían iniciar sesión? Con una clave por usuario, la desvinculación es solo cuestión de eliminar la única clave de cada host al que la agregaste. Pero parte de la carga se traslada a la incorporación. Debes configurar y mantener la automatización para enviar las nuevas claves a todos los hosts a los que les estás otorgando acceso y ninguno de los que no lo estás haciendo. Esto debe ejecutarse correctamente y de manera oportuna cada vez que agregues un usuario y cada vez que un usuario necesite cambiar su clave por cualquier motivo, y hacer que alguien del equipo de operaciones siga una lista de verificación o su memoria para realizar el trabajo de un trabajo de CI manualmente sigue siendo una forma de automatización. Los scripts son scripts, incluso si ejecutas cada paso manualmente, hacerlo manualmente es más lento y más propenso a errores y crea sufrimiento humano adicional.

Hay un mecanismo familiar de autenticación y autorización. Si creas una clave con una frase de contraseña, entonces quien conozca la frase de contraseña probablemente sea la misma persona que creó la clave o al menos alguien a quien le hayan delegado eso. Pero solo tener la clave no te da acceso al host. Alguien tiene que colocar la clave en el host. Cuando colocan tu clave pública en el host, autorizan a cualquier persona con tu clave a iniciar sesión en él siempre que esa clave pública permanezca allí. Entonces, en el cliente, tienes tu clave privada. En el servidor, tienes tu clave pública. Y cuando intentas iniciar sesión, hacen algunos cálculos juntos para asegurarse de que las dos mitades probablemente provengan de la misma clave. Bueno, hacen cálculos que demostrarían que sería prohibitivamente difícil falsificar la clave por ahora. Algún día en el futuro, las claves que estamos usando actualmente se volverán cada vez más fáciles de romper a medida que avance la tecnología. O a veces tendrás un grupo de personas que comparten una clave y todas inician sesión en la misma cuenta en un servidor. El servidor cree que solo hay un cliente, lo cual a veces está bien. Pero a menudo conduce a consecuencias no deseadas. Gestionar todo esto a gran escala tiende a convertirse en una verdadera aventura. Aunque hay algunas soluciones diferentes para diferentes partes del problema. Con claves compartidas, la incorporación es trivial. Simplemente les das una copia de la clave. Pero hacer la desvinculación correctamente es muy costoso. ¿Qué sucede cuando alguien se retira a una isla tropical y necesitas sacarlo del sistema? ¿Vas a rotar la clave para todos los que la tienen? ¿O simplemente te rendirás y los expulsarás de la red, eliminando su acceso en otro nivel para que incluso si pudieran pasar, aún tendrían la clave y podrían iniciar sesión? A veces esto se resuelve simplemente tratando de no pensar en cuántas copias de esa clave privada están vagando por ahí en los archivos de antiguos colegas. Con una clave por usuario, la desvinculación es solo cuestión de eliminar la única clave de cada host al que la agregaste. Pero parte de la carga se traslada a la incorporación. Debes configurar y mantener la automatización para enviar las nuevas claves a todos los hosts a los que les estás otorgando acceso y ninguno de los que no lo estás haciendo. Esto debe ejecutarse correctamente y de manera oportuna cada vez que agregues un usuario y cada vez que un usuario necesite cambiar su clave por cualquier motivo, y hacer que alguien del equipo de operaciones siga una lista de verificación o su memoria para realizar el trabajo de un trabajo de CI manualmente sigue siendo una forma de automatización. Los scripts son scripts, incluso si ejecutas cada paso manualmente, hacerlo manualmente es más lento y más propenso a errores y crea sufrimiento humano adicional.

4. Gestión de Acceso al Servidor con Claves de Uso Único

Short description:

A lo largo de los años, las personas han ideado soluciones mejores y peores para gestionar los dolores de cabeza de seguridad que rodean la autenticación y autorización. En lugar de tener una única clave valiosa y de larga duración, resulta que puedes crear claves de uso único para el acceso SSH y RDP a los servidores, las cuales tú, como usuario, nunca tienes que tocar ni pensar en ellas. En lugar de preguntar a cada host de la red quién tiene permiso para acceder, puedes utilizar la misma fuente de verdad sobre la identidad que ya están utilizando todas tus otras aplicaciones, como el chat y el correo electrónico.

A lo largo de los años, las personas han ideado soluciones mejores y peores para gestionar los dolores de cabeza de seguridad que rodean la autenticación y autorización. Por ejemplo, a menudo es apropiado dirigir el tráfico a los hosts internos a través de un bastión, que está mejor protegido de lo que sería práctico hacer con todos los servidores en tu implementación. Y en ese bastión, puedes implementar exactamente la supervisión y el registro que necesitas. La mayoría de las implementaciones permiten aplicar reglas de red para evitar el acceso entre hosts, donde ninguna persona autorizada querría conectarse, pero un atacante sí. Por ejemplo, las personas autorizadas probablemente nunca se conectarán directamente desde el servidor de la aplicación A al servidor de la aplicación B. Como, ¿por qué harías eso? Pero porque siempre estarán yendo por una ruta diferente, como a través del bastión. Pero un atacante que haya comprometido el servidor de la aplicación A, realmente querrá ir directamente al servidor de la aplicación B. Así que simplemente puedes prohibir ese acceso. Estas capas adicionales de security generalmente son excelentes de tener, pero no necesariamente obvian todo el problema subyacente. Por ejemplo, si mis permisos necesitan cambiar en un host en el que tengo mi clave, alguien tiene que iniciar sesión y cambiarlos. Si dejo de formar parte de un equipo autorizado para acceder al host, alguien o algún script tiene que eliminar mi clave pública de él. Esta es la antigua y familiar forma de gestionar el acceso, y funciona bastante bien para muchos casos de uso. Tiene una cierta simplicidad, ubicuidad y familiaridad a su favor. Pero la gran desventaja es que hace que tus claves SSH y frases de contraseña sean extremadamente valiosas, peligrosas de perder e incómodas de reemplazar. Son literalmente las llaves de tu castillo. Y nadie quiere tener que volver a cambiar cada cerradura, ya sea física o digital. Sin embargo, cuando me incorporé a Okta, me presentaron un paradigma totalmente diferente pero sorprendentemente compatible hacia atrás para gestionar el acceso al servidor. En lugar de tener una única clave valiosa y de larga duración, resulta que puedes crear claves de uso único para el acceso SSH y RDP a los servidores, las cuales tú, como usuario, nunca tienes que tocar ni pensar en ellas. En lugar de preguntar a cada host de la red quién tiene permiso para acceder, puedes utilizar la misma fuente de verdad sobre la identidad que ya están utilizando todas tus otras aplicaciones, como el chat y el correo electrónico. Así que, en lugar de pedir a los equipos de operaciones que manejen otro conjunto de secretos cruciales, puedes aprovechar la authentication que ya están utilizando en su navegador para acceder a todas sus otras herramientas vitales. Los protocolos SSH y RDP todavía se utilizan porque son realmente buenos. Son ubicuos y están bien probados y soportados. Solo estamos cambiando los detalles de cómo gestionamos las claves involucradas para reducir el valor de esas claves para los atacantes. Así que te mostraré cómo se ve. Es súper aburrido porque divertido e interesante no son palabras que quiero escuchar cuando hablamos de un flujo de trabajo que nos permite acceder donde lo necesitamos para resolver incidentes y cortes más rápido. Entonces, esto resulta ser una laptop bastante nueva. En realidad no tengo nada en mi directorio SSH. No necesito ninguna clave aquí. Tengo un archivo de configuración. He configurado un proxy en la configuración para poder usar mi binario SSH local.

5. Understanding SSH and Zero Trust

Short description:

Solo un comando proxy allí. Tengo acceso al host DevOps JS, creado como un juguete para esta masterclass. Sin claves SSH. Ahora hablemos de lo que está sucediendo bajo el capó. En 2015, los ingenieros crearon un producto llamado Scale Ft para el acceso al servidor de confianza cero. Fue adquirido por Okta en 2018 y renombrado como ASA. Confianza cero significa que la autenticación y autorización se verifican en cada intento. La gestión tradicional de claves SSH tiene vulnerabilidades, pero con la autenticación de confianza cero, los hosts no llevan un registro de los permisos de acceso.

en lugar de un envoltorio. Solo un comando proxy allí. Y luego tengo un host conocido para no tener que preguntarme si confío en este servidor. Entonces, le preguntaré a esta herramienta a qué tengo acceso. Y tengo acceso al host DevOps JS. Lo creé como un juguete con el que podemos jugar durante esta masterclass. Sin claves SSH. Simplemente voy a acceder por SSH. Y lo digo en serio. Correcto. No tengo un directorio .ssh. No tengo ninguna clave en este host. Y por lo tanto, nadie puede tomar mi clave y hacerse pasar por mí. Súper simple. Súper aburrido. A veces, aburrido es bueno. Ahora que he hecho que SSH sea mucho más aburrido en la superficie de lo que solía ser, hablemos de lo que está sucediendo bajo el capó. Entonces, cuando tocas el software que nos permite hacer todo esto, lo primero que notarás es que tiene su historia incorporada en sus convenciones de nomenclatura. En 2015, algunos ingenieros crearon un producto para el acceso al servidor de confianza cero llamado Scale Ft. Fueron comprados por Okta en 2018 y han estado perfeccionando su tecnología y su integración con Okta como proveedor de identidad desde entonces. En esta adquisición, el producto Scale Ft fue renombrado como ASA para el acceso al servidor avanzado. Entonces, ASA y SFT son, desde la perspectiva del usuario, diferentes nombres para lo mismo. Puede que notes que introduje una palabra de moda en esa explicación. Confianza cero. Esto simplemente significa que la autenticación y autorización de un usuario se verifican más o menos en cada intento de hacer algo. Cuando te autenticaste recientemente, tenemos un nivel bastante alto de confianza en que eres la persona que está utilizando tus credenciales. Pero cuanto más tiempo ha pasado desde la última autenticación, menos confianza tenemos en que la persona que utiliza tus credenciales sea realmente su propietario. Tal vez alguien haya robado tu computadora portátil o interceptado algún tráfico de red o te hayas alejado para tomar un café y el gato haya caminado sobre tu teclado. Con la gestión tradicional de claves SSH, generalmente ha pasado mucho tiempo desde que tu clave se agregó a un host. Eso es muchas oportunidades para que otra persona la intercepte y es lo que hace que las claves tradicionales tengan un alto valor. Sin embargo, con la autenticación de confianza cero,

6. Using Okta's ASA for Server Access

Short description:

El proveedor de identidad se encarga de saber quiénes son los usuarios y los servidores, así como quién tiene derechos de acceso. Al reutilizar un proveedor de identidad, acceder a los servidores se vuelve tan simple como iniciar sesión en cualquier otra aplicación. Pasaremos rápidamente por la configuración, pero no es necesario seguirlo ahora mismo. Explicaremos tres niveles de dificultad para poner en práctica ASA y proporcionaremos una organización y un servidor de demostración para opciones sencillas. Para comenzar, regístrese en una cuenta de prueba gratuita de Okta y configure un segundo factor para el acceso de administrador. Luego, agregue la aplicación Advanced Server Access a su cuenta de prueba.

no pedimos a los hosts que lleven un registro de quién tiene permiso para acceder a ellos. En cambio, el proveedor de identidad se encarga de saber quiénes son los usuarios, quiénes son los servidores y quién tiene permisos para hacer qué, dónde y cuándo. La convención de nomenclatura aquí es que nos referimos a los usuarios como clientes, a los servidores como agentes y a la fuente central de verdad sobre lo que está permitido y quién es quién como el proveedor de identidad. Los clientes no siempre son humanos. Pueden ser otras automation en su infraestructura. Los agentes no siempre son servidores. Pueden ser casi cualquier cosa a la que se pueda acceder mediante SSH.

Ahora, la parte súper conveniente de todo este proceso es que, como usuario, tengo menos cosas en qué pensar que si estuviera administrando mis propias claves. Al reutilizar un proveedor de identidad donde la organización ya centralizaba el acceso a otras aplicaciones como chat y correo electrónico, acceder a los servidores se vuelve como iniciar sesión en cualquier otra cosa. Por lo tanto, la parte práctica de este laboratorio se sentirá un poco artificial porque estamos empezando desde cero. No asumimos que tienes los permisos adecuados para jugar así en una cuenta existente de Okta. Al igual que escribir una aplicación de demostración con un marco web completo requerirá más código y dependencias que una aplicación de demostración similar con un marco que no escala tan bien, esta configuración es excesiva para las tareas que realizaremos en la demostración. Explicaré rápidamente cómo funciona la configuración ahora porque las personas que vean la grabación más tarde podrán pausarla si desean seguirla paso a paso. Amigos en la sala, no recomiendo intentar seguir cada paso en este momento. Después de detener la grabación, explicaré tres niveles de dificultad para poner en práctica ASA y te guiaré en cada uno mientras respondo preguntas y ayudo a debug cualquier problema que puedas encontrar. Para las opciones sencillas, te permitiré usar mi organización de demostración y el servidor de juguete que te mostré hace un minuto. Pero los desactivaré después de la conferencia, por lo que no serán útiles para las personas en el futuro. Para jugar con ASA a través de Okta, primero necesitaremos una cuenta de Okta para hacerlo. Simplemente crearemos una cuenta de prueba gratuita. Para evitar sorpresas, ten en cuenta que el soporte está muy entusiasmado por ponerse en contacto y ayudar a resolver cualquier problema que puedas tener. Si eso afecta tu elección de cómo proporcionas tu dirección de correo electrónico o incluso si decides registrarte, simplemente infórmate. Ve a okta.com. Crea una cuenta, recibe tu correo electrónico de activación y luego inicia sesión y cambia tu contraseña. Configura un segundo factor cuando te lo solicite, porque lo necesitarás cuando inicies sesión en esa cuenta como administrador, cuando accedas al panel de administración. Entonces, en esa cuenta de Okta, vamos a ingresar al panel de administración para convertirnos en administradores. Aquí te obligará a tener un segundo factor porque no podemos tener administradores que solo usen una contraseña. Y podemos ver que somos administradores porque se puede ver `admin` en la URL y la consola se ve diferente. Luego iremos a aplicaciones en la barra lateral y aplicaciones debajo de eso y navegaremos por el catálogo de aplicaciones. Haremos una búsqueda rápida de advanced server access y agregaremos esa aplicación a nuestra cuenta de prueba. No es necesario cambiar ninguna configuración aquí, simplemente hace lo correcto de inmediato. Y luego Okta necesita saber quién tiene permiso para usar ASA antes de permitir que alguien lo use.

7. Managing Authorization and Authentication

Short description:

Para autorizar el acceso, asigna al usuario y elige un nombre de usuario en ASA. Si usas grupos de Okta, agrega el grupo que representa al equipo de Okta. Mantén abierta la pestaña de ASA y prepárate para editar la configuración. Abre app.scaleft.com para crear un nuevo equipo. El único paso complicado es el intercambio de información entre Okta y ScaleFT. En Okta, edita la configuración, mientras que en ScaleFT ASA, ingresa y copia la configuración. Elige un nombre de equipo único a nivel mundial. Transfiere la información entre las aplicaciones utilizando las URL proporcionadas. Guarda en Okta y autentica en ScaleFT. Asegúrate de tener los permisos de usuario y las URL correctas para evitar errores. Este proceso solo ocurre una vez por organización.

Este es el paso de autorización. Para hacer la demostración mínima viable, asignaré mi usuario y elegiré el nombre de usuario que ASA me dará. Aunque, si estuviera en una instancia de Okta con grupos establecidos, agregaría personas por grupos. Agregaría el grupo que representa al equipo de Okta. Siempre puedes volver más tarde y cambiarlo para dar permisos a través de grupos en lugar de usuarios individuales. Así que mantén abierta la pestaña de ASA en la pestaña de inicio de sesión. Tendrás la configuración, vas a prepararte para editar esa configuración. Y también abrirás app.scaleft.com y comenzarás a crear un nuevo equipo. Ahora, aquí está la única parte realmente complicada de todo el proceso. Necesitamos que las dos aplicaciones básicamente se den la mano. Okta necesita saber algunas cosas sobre ScaleFT, y ScaleFT necesita saber algunas cosas sobre la aplicación ASA en Okta. Por lo tanto, este intercambio de información es básicamente la única parte difícil. Entonces, en tu pestaña de Okta, verás algo que se ve así. Editando tu configuración. En tu pestaña de ScaleFT ASA, verás algo como lo que está a la derecha, donde ingresas algunas configuraciones, copias algunas configuraciones. Aquí elegirás un nombre de equipo. Recomiendo encarecidamente elegir, por ejemplo, tu nombre DevOps JS, tu nombre testing. Algo así. Porque los nombres de equipo son únicos a nivel mundial. Como la nomenclatura de los buckets de S3. Para transferir información entre las dos aplicaciones, esa URL llamada metadatos del proveedor de identidad, esa URL se coloca en el cuadro de URL de metadatos del proveedor de identidad. Y luego la URL base y las restricciones de audiencia se transfieren en sentido contrario. Primero, guardas en Okta. Y luego, una vez que hayas hecho todo hasta este punto, presionas el botón de autenticación en ScaleFT. Si encuentras un error al intentar autenticarte, es posible que hayas olvidado agregar tu usuario y darle permisos. Es posible que no hayas ingresado la URL base y la restricción de audiencia en Okta o tal vez tengas un valor incorrecto o no válido en la URL de metadatos del proveedor de identidad. Es una de esas cosas en las que seguir los pasos con precisión importa mucho. Esa fue la parte más difícil. Felicidades. Eso ocurre exactamente una vez por organización.

8. Configuración de Proyectos y Autorizaciones

Short description:

Tus entornos como desarrollo, producción y puesta en escena se representarán como proyectos separados dentro del mismo equipo. Ahora, si queremos que los cambios en la membresía del grupo de Okta y los permisos de usuario se envíen automáticamente a ASA, tenemos un enlace más que hacer. En la pestaña de aprovisionamiento de Okta, configuraremos la integración de la API. Ese es el sistema para la gestión de identidad entre dominios. Finalmente, necesitamos autorizar a las personas para que realicen acciones. Con fines de demostración, agregaré el grupo Todos al proyecto. Ahora, obtengamos un servidor. Podríamos hacer la configuración una vez en la imagen que planeamos implementar, y luego simplemente clonarla varias veces. O si tuviéramos una cuenta de AWS o GCP, podríamos configurarla para inscribir automáticamente todos los servidores nuevos en ASA. Sin embargo, la demostración mínima viable es jugar con la inscripción de tokens.

Tus entornos como desarrollo, producción y puesta en escena se representarán como proyectos separados dentro del mismo equipo. Así que nunca tendrás que hacer esa configuración nuevamente a medida que crezcas.

Ahora, si queremos que los cambios en la membresía del grupo de Okta y los permisos de usuario y demás se envíen automáticamente a ASA, tenemos un enlace más que hacer. Si solo estás jugando con esto por tu cuenta, puedes omitir esta parte, pero es realmente útil si quieres jugar con la sincronización de equipos de ida y vuelta. En la pestaña de aprovisionamiento de Okta, configuraremos la integración de la API haciendo clic en ese botón. Se abrirá ASA aquí. Aprobaremos la concesión de permisos y daremos al usuario de servicio un nombre de usuario de servicio que reconoceremos. Lo aprobaremos y luego lo guardaremos en Okta. Ese es el sistema para la gestión de identidad entre dominios, y luego podrás sincronizar cosas de ida y vuelta.

Entonces, los últimos pasos de configuración para prepararnos para inscribir servidores son que necesitaremos crear un proyecto en el lado de ASA. Es posible que desees usar proyectos para dividir como Desarrollo, Puesta en Escena y Producción. Más adelante, ofreceré crear proyectos individuales para aquellos que deseen inscribir un servidor de juguete no compartido, y acabo de crear el proyecto DevOpsJS para jugar hoy. Así que hay muchas opciones en el cuadro de diálogo Crear Proyecto. Son útiles en implementaciones reales. No te preocupes por las opciones. Lo único que te importa para jugar con esto, para comenzar, es tener el nombre. Finalmente, necesitamos autorizar a las personas para que realicen acciones. Con fines de demostración, agregaré el grupo Todos al proyecto. Más adelante, puedes crear más grupos y sincronizarlos para gestionar permisos más detallados, y más adelante, a medida que juegues con esto, puedes jugar con lo que llamamos pseudo permisos que permitirán que ciertos usuarios o grupos solo usen sudo para comandos específicos. Hemos resuelto el proveedor de identidad y esa fue la parte difícil. También es la parte que solo se hace una vez, independientemente del tamaño de la implementación. Ahora, obtengamos un servidor. Si estuviéramos haciendo esto para un montón de servidores, podríamos hacer la configuración una vez en la imagen que planeamos implementar, y luego simplemente clonarla varias veces. Y esos clones se registrarán en ASA, y será como, oh, fuiste implementado desde esa imagen. Genial. Y crear el host en sí mismo. O si tuviéramos una cuenta de AWS o GCP, podríamos configurarla para inscribir automáticamente todos los servidores nuevos en ASA incluso sin el token. Sin embargo, la demostración mínima viable es jugar con la inscripción de tokens porque es lo más simple para una sola vez. Entonces, aquí mismo, en mi proyecto de ASA, en la inscripción, crearé un token de inscripción.

9. Configuración del Servidor y Cliente

Short description:

Para configurar el servidor, coloca el token e instala el agente ASA. El token se coloca en un archivo específico y, cuando se instala el agente, se registra en el proveedor de identidad. Al iniciar el servicio, aparecerá en el proveedor de identidad. En el mundo real, la automatización se encargaría de este proceso. Para la configuración del servidor, asegúrate de leer las notas de configuración para tu distribución. En las versiones recientes de Ubuntu, se requiere un paso adicional en la configuración de SSH. Una vez que SFTD esté en ejecución y registrado, el servidor estará listo. La configuración del cliente es aún más fácil.

Y copiaré ese token de inscripción. Ahora, la única parte complicada de la configuración del servidor es que primero colocas el token y luego instalas SFT. Pegaré el token en Linux en var lib sftd enrollment.token. Y en un host Linux limpio, también necesitaré crear el directorio var lib sftd primero, porque aún no he instalado las herramientas. En Windows, estaría en c, Windows system 32, config system profile, app data, local scaleft enrollment.token. Así que tu token va en ese archivo, nada más en ese archivo, solo pega lo que copiaste de la interfaz web. Y luego, cuando instales el agente ASA correspondiente a lo que estás utilizando, verá el token al iniciar, se registrará en el proveedor de identidad, y funcionará sin problemas. Así que inicias el servicio y aparece en tu proveedor de identidad. Se comunican entre sí en segundo plano, verifican el token y el host aparece. En el mundo real, tendríamos nuestra automatización para hacer todo eso. Pero esto es, por supuesto, el sandbox, has escuchado sobre C1, hacer uno, enseñar uno como una forma de solidificar el conocimiento. Y automatizar una tarea cae sólidamente en la categoría de enseñar uno. Así que ahora puedes ver uno, puedes hacer uno mientras juegas con esto. Y luego puedes enseñar uno a tu automatización si terminas usando esta herramienta en el mundo real. La única complicación con la configuración del servidor, asegúrate de leer todas las notas en la página de configuración para tu distribución. Hay un paso adicional en las versiones recientes de Ubuntu, donde agregas una línea a tu configuración de SSH, diciendo, sí, en realidad usamos el algoritmo RSA, como RSA está permitido. Y cuando SFTD esté en ejecución y se haya registrado en el proveedor de identidad, tendrás un servidor. Te dije que se volvería más fácil, y aún será más fácil para el

10. Configuración del Cliente y Limpieza

Short description:

Para configurar un cliente, instala el cliente en tu sistema operativo y regístralo. Puedes instalarlo en tu laptop o en un contenedor. Utiliza un navegador web para la autenticación. Si se ejecuta sin interfaz gráfica, se proporcionará una URL para la autenticación. Una vez instalado, ejecuta 'SFT enroll' y elige un equipo. La configuración centraliza la gestión de acceso, simplifica la escalabilidad y permite reutilizar un proveedor de identidad existente. Explora características como generar comandos de salto de proxy, utilizar un bastión para el registro de sesiones y revocar permisos de usuario. Limpia después de realizar pruebas desinstalando clientes, eliminando contenedores y apagando servidores. Las cuentas de prueba caducarán después de 30 días, pero se pueden desactivar bajo solicitud. Gracias por participar y no dudes en comunicarte si tienes alguna pregunta.

cliente. Entonces, finalmente, dos pasos para configurar un cliente. Instalar el cliente en cualquier sistema operativo desde el que estés siendo un cliente, y registrarlo. Así que, para la instalación, puedes instalarlo solo en tu laptop, o puedes instalarlo en un contenedor. Querrá utilizar un navegador web para hacer su autenticación y demostrar que eres tú en este proyecto con el proveedor de identidad. Pero si se ejecuta headless, como en un contenedor Docker, te proporcionará una URL que simplemente copiarás y abrirás en tu navegador. Así que cualquier flujo de trabajo que prefieras para eso estará bien. Lo tendrás instalado y luego ejecutarás 'SFT enroll'. Eso te pedirá que elijas en qué equipo quieres estar en tu navegador, y luego te autenticarás. Ahora, si ya estás en tu navegador, puedes reutilizar eso dependiendo de la configuración que el administrador de tu proveedor de identidad haya establecido para cuánta frecuencia quiere obligar a las personas a volver a autenticarse. La configuración en la organización de demostración con la que jugaremos más tarde es extremadamente permisiva, con tiempos de espera de 24 horas, que es el máximo y así sucesivamente, porque nada de seguridad importante debería estar sucediendo en esta organización. Así que ahí lo tienes. En lugar de pedirle a cada host que sepa quién tiene permiso para acceder a él, y acceder, o pedirle a cada usuario que guarde celosamente un par único de secretos que permitirían a cualquier atacante hacerse pasar por ellos, hemos centralizado todo ese trabajo en un proveedor de identidad que la empresa probablemente ya estaba utilizando en alguna versión si tienes cosas como correo electrónico. Es excesivo hacerlo para un solo host, pero una vez que tienes tu primer host y tu primer cliente registrado, puedes ver lo sencillo que es escalar a más hosts y más clientes. Si ya estás utilizando el proveedor de identidad para cualquier otra cosa, puedes reutilizar lo que sabe sobre la identidad de las personas en lugar de reinventar la rueda. Así que una vez que tengas la configuración, te recomendaría explorar las características que te resulten interesantes. Puedes ejecutar 'SFT SSH config' para generar un comando de salto de proxy para que puedas utilizar tu binario SSH local en lugar del envoltorio SFT como hice cuando lo demostré en la demostración deliciosamente aburrida. También puedes usar un bastión para registrar todas las sesiones de SSH y RDP. Esto crea registros en lugar de grabaciones de sesiones, lo cual es bueno porque el texto es buscable. Los registros son excelentes no solo para lidiar con atacantes, sino también para hacer análisis forense de tu propio trabajo. Pueden responder a la pregunta de cómo solucioné este problema la última vez que ocurrió, o qué pasos de solución de problemas habría tomado nuestro arquitecto cuando estaba de vacaciones. Puedes ver cuándo fue la última vez que realizaron esta tarea, ¿qué hicieron? Así que podrías agregar a un nuevo usuario a un grupo con permisos e iniciar sesión como ese nuevo usuario sin esperar a que se ejecute ninguna otra automatización, porque el host dirá, proveedor de identidad. Y el proveedor de identidad dirá, host, deja entrar a esta persona con esta clave que solo estamos usando esta vez. Y es bastante sencillo. O puedes revocar los permisos de un usuario en tu proveedor de identidad y luego intentar iniciar sesión como ellos y ver que no funciona. Ahora, a medida que juegas con esto, a medida que descubres las cosas que puede hacer, juega con ello, eventualmente terminarás de probar. Y siempre recomiendo limpiar cuando termines de jugar con una herramienta como esta. Así que para limpiar después de este ejercicio, es posible que desees desinstalar cualquier cliente que hayas instalado en tu laptop o eliminar o archivar cualquier contenedor en el que hayas instalado muchas cosas. Probablemente querrás apagar cualquier servidor que hayas creado para el ejercicio. Puedes ignorar la cuenta de prueba y desaparecerá. Caducará después de 30 días y ya no será una cuenta accesible. Pero si deseas desactivarla por completo, puedes enviar un correo electrónico al soporte para hacerlo. Y si estás recibiendo más correos electrónicos de los que te gustaría, es posible que desees utilizar el botón de cancelar suscripción. Eso terminaría el ejercicio hasta el final. Así que a aquellos que están viendo la grabación más tarde, gracias por escuchar y espero que hayan aprendido algo útil. Ten en cuenta que cuanto más lejos estés de marzo de 2022, es menos probable que estos pasos funcionen para ti de la misma manera que funcionaron para mí, porque el software siempre está cambiando. No dudes en comunicarte conmigo si tienes alguna pregunta. Y si no conozco las respuestas, te pondré en contacto con alguien que las conozca.

Watch more workshops on topic

React Summit 2023React Summit 2023
56 min
0 to Auth in an hour with ReactJS
WorkshopFree
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool. There are multiple alternatives that are much better than passwords to identify and authenticate your users - including SSO, SAML, OAuth, Magic Links, One-Time Passwords, and Authenticator Apps.
While addressing security aspects and avoiding common pitfalls, we will enhance a full-stack JS application (Node.js backend + React frontend) to authenticate users with OAuth (social login) and One Time Passwords (email), including:- User authentication - Managing user interactions, returning session / refresh JWTs- Session management and validation - Storing the session securely for subsequent client requests, validating / refreshing sessions- Basic Authorization - extracting and validating claims from the session token JWT and handling authorization in backend flows
At the end of the workshop, we will also touch other approaches of authentication implementation with Descope - using frontend or backend SDKs.
DevOps.js Conf 2022DevOps.js Conf 2022
152 min
MERN Stack Application Deployment in Kubernetes
Workshop
Deploying and managing JavaScript applications in Kubernetes can get tricky. Especially when a database also has to be part of the deployment. MongoDB Atlas has made developers' lives much easier, however, how do you take a SaaS product and integrate it with your existing Kubernetes cluster? This is where the MongoDB Atlas Operator comes into play. In this workshop, the attendees will learn about how to create a MERN (MongoDB, Express, React, Node.js) application locally, and how to deploy everything into a Kubernetes cluster with the Atlas Operator.
React Summit 2023React Summit 2023
88 min
Deploying React Native Apps in the Cloud
WorkshopFree
Deploying React Native apps manually on a local machine can be complex. The differences between Android and iOS require developers to use specific tools and processes for each platform, including hardware requirements for iOS. Manual deployments also make it difficult to manage signing credentials, environment configurations, track releases, and to collaborate as a team.
Appflow is the cloud mobile DevOps platform built by Ionic. Using a service like Appflow to build React Native apps not only provides access to powerful computing resources, it can simplify the deployment process by providing a centralized environment for managing and distributing your app to multiple platforms. This can save time and resources, enable collaboration, as well as improve the overall reliability and scalability of an app.
In this workshop, you’ll deploy a React Native application for delivery to Android and iOS test devices using Appflow. You’ll also learn the steps for publishing to Google Play and Apple App Stores. No previous experience with deploying native applications is required, and you’ll come away with a deeper understanding of the mobile deployment process and best practices for how to use a cloud mobile DevOps platform to ship quickly at scale.
DevOps.js Conf 2022DevOps.js Conf 2022
13 min
Azure Static Web Apps (SWA) with Azure DevOps
WorkshopFree
Azure Static Web Apps were launched earlier in 2021, and out of the box, they could integrate your existing repository and deploy your Static Web App from Azure DevOps. This workshop demonstrates how to publish an Azure Static Web App with Azure DevOps.
DevOps.js Conf 2022DevOps.js Conf 2022
163 min
How to develop, build, and deploy Node.js microservices with Pulumi and Azure DevOps
Workshop
The workshop gives a practical perspective of key principles needed to develop, build, and maintain a set of microservices in the Node.js stack. It covers specifics of creating isolated TypeScript services using the monorepo approach with lerna and yarn workspaces. The workshop includes an overview and a live exercise to create cloud environment with Pulumi framework and Azure services. The sessions fits the best developers who want to learn and practice build and deploy techniques using Azure stack and Pulumi for Node.js.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Node Congress 2022Node Congress 2022
26 min
It's a Jungle Out There: What's Really Going on Inside Your Node_Modules Folder
Top Content
Do you know what’s really going on in your node_modules folder? Software supply chain attacks have exploded over the past 12 months and they’re only accelerating in 2022 and beyond. We’ll dive into examples of recent supply chain attacks and what concrete steps you can take to protect your team from this emerging threat.
You can check the slides for Feross' talk here.
React Advanced Conference 2021React Advanced Conference 2021
19 min
Automating All the Code & Testing Things with GitHub Actions
Top Content
Code tasks like linting and testing are critical pieces of a developer’s workflow that help keep us sane like preventing syntax or style issues and hardening our core business logic. We’ll talk about how we can use GitHub Actions to automate these tasks and help keep our projects running smoothly.
DevOps.js Conf 2022DevOps.js Conf 2022
33 min
Fine-tuning DevOps for People over Perfection
Demand for DevOps has increased in recent years as more organizations adopt cloud native technologies. Complexity has also increased and a "zero to hero" mentality leaves many people chasing perfection and FOMO. This session focusses instead on why maybe we shouldn't adopt a technology practice and how sometimes teams can achieve the same results prioritizing people over ops automation & controls. Let's look at amounts of and fine-tuning everything as code, pull requests, DevSecOps, Monitoring and more to prioritize developer well-being over optimization perfection. It can be a valid decision to deploy less and sleep better. And finally we'll examine how manual practice and discipline can be the key to superb products and experiences.
DevOps.js Conf 2022DevOps.js Conf 2022
27 min
Why is CI so Damn Slow?
We've all asked ourselves this while waiting an eternity for our CI job to finish. Slow CI not only wrecks developer productivity breaking our focus, it costs money in cloud computing fees, and wastes enormous amounts of electricity. Let’s take a dive into why this is the case and how we can solve it with better, faster tools.
DevOps.js Conf 2022DevOps.js Conf 2022
31 min
The Zen of Yarn
In the past years Yarn took a spot as one of the most common tools used to develop JavaScript projects, in no small part thanks to an opinionated set of guiding principles. But what are they? How do they apply to Yarn in practice? And just as important: how do they benefit you and your projects?
In this talk we won't dive into benchmarks or feature sets: instead, you'll learn how we approach Yarn’s development, how we explore new paths, how we keep our codebase healthy, and generally why we think Yarn will remain firmly set in our ecosystem for the years to come.