Tag google

El registro en muchas cuentas distintas, con una clave para cada una, puede parecer tedioso, sobre todo cuando puedes hacerlo con tus credenciales de Facebook o Google. Te contamos cuáles son los pro y contras de usar este tipo de inicio de sesión conocido como SSO y a qué debes prestar atención.

“Continuar con Google” es una forma muy sencilla de registrarse e iniciar sesión en un sitio web o una aplicación. Todo lo que tienes que hacer es pulsar o hacer clic en el botón y permitir que algunos de los datos personales de tu cuenta se compartan con el servicio online de terceros.

Muchos sitios te permiten iniciar sesión con tu cuenta de Facebook, Google, Microsoft, LinkedIn, Apple u otra cuenta de una gran empresa tecnológica; hoy se busca la comodidad y no suelen faltar opciones para elegir y satisfacer todos los gustos.

Cuando vinculas tu acceso a Google con otro servicio, estás autorizando a Google a compartir tu información personal a cambio de facilidad de acceso y comodidad. ¿Hasta qué punto puede ser seguro?

Para ayudarte a encontrar un equilibrio entre seguridad y comodidad, te contamos los pros y los contras de utilizar este método de autenticación denominado inicio de sesión único (SSO), también conocido como inicio de sesión social, para tus cuentas personales online.

Figura 1. Ejemplo de opciones SSO para iniciar sesión o crear una cuenta

Figura 2. Más opciones de SSO

Un único inicio de sesión para todos

Primero lo primero: ¿qué es exactamente el SSO? Es un esquema de autenticación que permite a una organización obtener acceso consentido a tu información personal al tiempo que te permite registrarte e iniciar sesión en sus servicios en lugar de exigirte que te registres a través de un formulario independiente.

No es de extrañar que esta práctica sea tan común en todo Internet:

• Facilidad de registro y acceso. En lugar de tener que rellenar otro formulario con su nombre, apellidos, número de teléfono o dirección de correo electrónico, solo tiene que hacer clic en su opción SSO preferida y compartir esos datos (y posiblemente también otros) con la nueva aplicación o sitio web. [Es importante destacar que su contraseña nunca se comparte con el sitio web, sino que su identidad se verifica mediante un token de autenticación]
• Atracción y captación de usuarios. Los servicios en línea saben muy bien que cuanto más fácil te resulte registrarte e iniciar sesión, más probable es que lo hagas y vuelvas a hacerlo.
• Se acabó el cansancio de las contraseñas. Diferentes sitios web tienen diferentes requisitos de contraseña; además, debemos utilizar una combinación única de nombre de usuario y contraseña cada vez. Pero gracias a esta implementación de SSO, establecer una contraseña segura con una sola de las grandes plataformas de Internet puede darte acceso a cientos de otros sitios web, reduciendo enormemente el número de contraseñas que necesitas crear y memorizar.
• Mejor prevención de los compromisos de cuentas autoinfligidos (en algunos casos). A medida que nuestras listas de contraseñas se vuelven demasiado extensas para recordarlas, muchas personas pueden llevar un registro de sus credenciales en papel o en una hoja de cálculo Excel. Pero, ¿qué ocurre si alguien se hace con esa lista de contraseñas? Tener que recordar únicamente la contraseña de tu cuenta de Google y proteger la cuenta adecuadamente puede reducir la necesidad de generar, y luego depender, de una lista de contraseñas mal protegida (por ejemplo, si los gestores de contraseñas no son lo tuyo).

Entonces, ¿deberías utilizar siempre SSO?

La respuesta es clara: no.

Aunque el SSO ofrece algunas ventajas importantes al usuario, le expone a riesgos que pueden no revelarse hasta que sea demasiado tarde. ¿Cuáles son algunas de las implicaciones?

• Todos los huevos están en la misma cesta. Si tus credenciales de Facebook o Google caen en las manos equivocadas, los ciberdelincuentes no solo tendrán acceso a esa cuenta, sino también a todos los sitios web a los que la hayas vinculado. Lo que nos lleva al siguiente punto…
• Protege tu cuenta principal “como si tu vida dependiera de ello”. Una contraseña segura —quizá en forma de frase de contraseña que consista en una frase que mezcle mayúsculas, minúsculas y números— puede ser clave para proteger tus cuentas y datos personales. Si por alguna razón no usas un gestor de contraseñas, quizá puedas plantearte elegir una frase de contraseña en un formato que te permita añadirle el nombre del sitio web, pero sin que toda la cadena sea demasiado predecible.
• Cuestiones de privacidad. Cuando vinculas cuentas, estás permitiendo que tu información personal se transmita al sitio web y, debido a lo fácil que es configurarlo, podrías estar consintiendo la transferencia de más información de la que te imaginas. Y aunque Facebook, Google, Microsoft o Apple te permiten comprobar todas tus conexiones con terceros, revocar el acceso no significa que también estés revocando el consentimiento de un sitio web para utilizar tus datos. Además, si después de “eliminar conexiones” vuelves a entrar en el mismo sitio web y utilizas tu login social preferido, te dejarán entrar igual que antes, como si nunca hubieras revocado el acceso.

Figura 3. Revocación del consentimiento para que Google vincule tus datos

• Atracción y captación de usuarios (y las implicaciones para tu huella digital). Es cierto que hemos mencionado la captación eficaz de usuarios como una de las ventajas del SSO para aplicaciones y sitios web, pero puede ser un arma de doble filo. Si acabas registrándote en aplicaciones o sitios web que nunca has necesitado tanto, ¿cuánto tardarás en olvidarte de ellos? Para evitarlo, asegúrate de llevar un registro de todos los sitios web en los que te registraste y de la información personal que guardan sobre ti; por ejemplo, la información de tu tarjeta de crédito puede estar almacenada en un sitio web que hayas utilizado una vez y del que te hayas olvidado. Aunque esto puede ocurrir independientemente de cómo inicies sesión, la naturaleza sin fricciones del método “exprés” puede hacerte más propenso a olvidarte de todas esas aplicaciones o sitios web en los que una vez iniciaste sesión con tu cuenta de Google o Facebook.

Entonces, ¿con SSO o sin SSO?

Cuando se combinan con otras medidas de seguridad y privacidad, los inicios de sesión sociales pueden ahorrar mucho tiempo. Pero en el caso de los sitios web que guardan tu información personal, como tu nombre completo, dirección, datos bancarios o números de tarjeta de crédito, es más seguro optar por una cuenta independiente protegida por una frase de contraseña compleja y única, junto con la autenticación de dos factores (2FA).

En resumen, considera el uso de SSO solo si:

• habilitas la autenticación de doble factor (2FA) en la cuenta principal, ya que así será más difícil que alguien se haga pasar por ti en Internet,
• confía en la plataforma que utilizas para acceder al otro sitio web; no obstante, la confianza es algo voluble y debes tomar otras precauciones,
• utiliza servicios de pago como PayPal o una tarjeta de crédito virtual como opciones de pago para cualquier sitio web al que hayas accedido utilizando SSO; esto te ayudará a evitar que se filtren tus datos bancarios,
• utiliza la configuración de tu cuenta principal para realizar un seguimiento de todos los sitios web a los que la has vinculado.

Figura 4. Gestión de aplicaciones de terceros y autorizaciones SSO en Google

¿Hay alguna otra forma?

Equilibrar el fácil acceso a todas tus cuentas online y mantenerlas seguras puede ser todo un reto. Existen otras formas de conseguirlo además de los inicios de sesión sociales:

Una alternativa obvia consiste en crear una cuenta independiente para cada servicio y utilizar un gestor de contraseñas que te evite el dolor de cabeza que supone crear, gestionar y rellenar automáticamente tus credenciales de inicio de sesión. Otra opción es usar una dirección de correo electrónico desechable, sobre todo para sitios web que no te interesan demasiado o que no piensas volver a utilizar. Además, algunos gobiernos han creado una identificación única de ciudadano que da a la gente acceso en línea a servicios ofrecidos por algunas organizaciones públicas y privadas.

Sea cual sea el método que elijas, podrás disfrutar de tu presencia en Internet sin demasiados problemas (o prisas) siempre que sigas las prácticas generales de ciberhigiene, como evitar revelar tus credenciales, activar el 2FA y ser consciente de toda tu huella digital.

Fuente: www.welivesecurity.com

El ascenso de Microsoft como uno de los principales contribuidores del código abierto ha sido casi meteórico desde la llegada de Satya Nadella al cargo de CEO. La transformación de la corporación ha sido tal que llegó a autorpoclamarse como la número uno del código abierto después de que Linux se convirtiera en el sistema operativo más usado en Azure, su plataforma de computación en la nube.

Sin embargo, parece que Microsoft está perdiendo su corona, ya que la empresa de asesoría Aiven, radicada en Helsinki (Finlandia), ha publicado que Google ha incrementado lo suficiente su número de contribuidores como para superar a la corporación de Redmond. Este cambio en el primer puesto viene en parte debido a que el gigante del buscador incrementó la cantidad de commits mensuales en GitHub en un 20% en comparación con los datos del mismo periodo del año pasado.

Heikki Nousiainen, director de tecnología (CTO) y cofundador de Aiven, ha mostrado su sorpresa ante el dato de que Google haya superado a Microsoft. Si antes dijimos que el incremento de la contribución de Google es solo una parte de las razones, es porque Nousiainen ha expuesto que “un factor en esto ha sido una disminución de los commits año tras año de Microsoft en proyectos de código abierto. Sin embargo, el compromiso de Microsoft con la libertad y la innovación de los desarrolladores es consistente, ya que la empresa es un jugador importante en código abierto e incluso compró GitHub en 2018”.

Aiven también ha destacado que Amazon ha empezado a centrarse más en el Open Source a través de proyectos como OpenSearch, que nació como un bifurcación de Elasticsearch. Sin embargo, posiblemente el dato más interesantes es que Google, Microsoft y Amazon muestran un compromiso cada vez mayor con el código abierto al haber aumentado entre todos en un 300% la cantidad de contribuidores en GitHub en los últimos seis años, lo que delata una competencia entre las grandes corporaciones en este sentido.

Mayores contribuidores al codigo abierto en GitHub según el Open Source Contributor Index (OCSI).

Si uno mira directamente las tablas publicadas por Open Source Contributor Index (OCSI), Google ha tenido a 5.421 contribuidores activos el pasado mes de julio frente a los 5.268 de Microsoft. El gigante de Mountain View ha dominado todos los meses del año 2022, mientras que la corporación de Redmond hizo lo propio en 2021 con la salvedad de febrero, cuando Google logró hacerse con el primer puesto.

El pique entre Google y Microsoft por liderar las contribuciones en GitHub está servido, más viendo que dichas compañías están tomando distancia de otras como Red Hat, Intel, IBM, Amazon, Facebook y la propia GitHub, que son las únicas que superaron los mil contribuidores en julio de 2022.

Como vemos, las grandes corporaciones se han tomado muy serio la contribución al código abierto, pero también se detecta una tendencia a preferir guardarse cartas en lugar de realizar una auténtica contribución de cara a la comunidad, lo que se traduce en la preponderancia de licencias permisivas como MIT y Apache 2 frente a las GPL.

Fuente: www.muylinux.com

Aunque Linux es considerado como un sistema seguro porque lo es, debido a su diseño y a las características que se han ido incorporando a lo largo del tiempo, siempre se puede hacer más, especialmente en el desarrollo directo del kernel Linux, en el que los esfuerzos suelen derivarse a otras áreas.

Así, The Linux Foundation ha anunciado que Google financiará el trabajo a tiempo completo de dos desarrolladores que se centrarán en la seguridad del núcleo; dos mantenedores del kernel Linux con años de experiencia a sus espaldas y que ahora enfocarán toso sus esfuerzos en detectar y corregir las fallas de seguridad que se encuentren.

Teniendo a Google por un lado y a dos desarrolladores por el otro, puede parecer una iniciativa irrisoria, pero la compañía espera que otras organizaciones se animen a hacer lo mismo en con el objetivo de corregir de una vez por todas una larga lista de problemas que ya se sabe que están ahí. La opinión de Google es que apuntar al kernel tendrá un impacto más amplio en la seguridad subyacente de ecosistema de software que se basa en este.

La tarea de uno de estos desarrolladores consistirá en «corregir todos los errores encontrados con los compiladores de Clang / LLVM mientras se trabaja en el establecimiento de sistemas de integración continua para respaldar el trabajo en curso. Una vez que estos objetivos estén bien establecidos, el plan es comenzar a agregar funciones y pulir el kernel utilizando estas tecnologías de compilación».

El segundo mantenedor se dedica ya a «eliminar varias clases de desbordamientos de búfer mediante la transformación de todas las instancias de matrices de un elemento y de longitud cero en miembros de matriz flexible, que es el mecanismo preferido y menos propenso a errores para declarar tales tipos de longitud variable», así como «se está enfocando activamente en corregir errores antes de que lleguen a la línea principal, mientras que también desarrolla de manera proactiva mecanismos de defensa que eliminan clases enteras de vulnerabilidades».

¿Y todo lo demás? Por el modelo colaborativo de desarrollo que emplea Linux, son muchos los ojos que detectan problemas y alertan de ellos, y los encargados de solucionarlos suelen ser los responsables del área en cuestión, pero hay ciertas partes del kernel que son más susceptivas a acumular más errores y menos atención, como las descritas, por lo que es ahí donde se están centrando los esfuerzos ahora.

De momento parece que todo marcha bien, pero porque haya poco que arreglar, sino por todo lo contrario. En The Register han entrevistado a este par de desarrolladores y el titular lo dice todo: «Estamos encontrando errores mucho más rápido de lo que podemos solucionarlos», lo cual no es negativo per se, pero sí indica que la labor que han comenzado no es de las que se terminan pronto.

Hace tiempo además que en The Linux Foundation se están preocupando por mejorar la seguridad no solo del kernel, sino de los componentes de código abierto más populares. En este caso, lo harán en colaboración con Google, que al menos por ahora sigue teniendo en Linux el motor de todos sus grandes proyectos.

¿Y qué dice Linus Torvalds de todo esto? Nada. El jefe se está controlando todo lo que puede, desde que la presión de los nuevos inquisidores de Internet se le echase al cuello por su «comportamiento tóxico» y nos ha dejado sin las declaraciones sin filtro de antaño, como aquella en la que hablaba del circo de la seguridad y de «la gente de OpenBSD masturbándose como monos porque no hay nada más importante que la seguridad».

Con todo, Torvalds se refería a que todos los errores importan, sean relativos a la seguridad o a cualquier otro aspecto. Y algo de razón no le faltaba, como señalaba tiempo después su compañero de batalla Greg Kroah-Hartman en relación a los procedimientos de seguridad aplicados a Linux. No obstante, nunca está de más fijarse en todo lo que se pueda.

Fuente: www.muylinux.com

Esta función está disponible actualmente en Estados Unidos, México, Brasil, España e India, pero la intención es ampliar su cobertura a otros países.

La semana pasada Google anunció una nueva funcionalidad en Android: las llamadas verificadas. Una función que busca evitar el spam y los engaños telefónicos y a la vez ayudar a empresas legítimas a transmitir mayor confianza y seguridad de cara a los clientes. Muchas veces no atendemos una llamada entrante si desconocemos el número que llama. A partir de esta nueva función los usuarios que tengan la app Teléfono de Google configurada como predeterminada para gestionar las llamadas en su dispositivo, además de corroborar que la misma proviene de una fuente verificada -mediante una marca azul-, verán en la pantalla el nombre de la empresa y una breve descripción del motivo de la llamada.

Esta opción funciona con aquellas empresas que se anotaron para formar parte de este programa y que sus llamadas aparezcan como verificadas en los dispositivos de los clientes. Las empresas que quieran formar parte de esta iniciativa y que estén en los países con cobertura (Estados Unidos, México, Brasil, España o India) pueden comenzar comunicándose con alguno de los socios de Google para implementar las llamadas verificadas.

La app de Teléfono de Google viene predeterminada en algunos teléfonos además de Pixel, como es el caso de los dispositivos con Android One, pero puede ser descargada desde la play store.

Según Google, las pruebas que realizaron durante la etapa piloto demostraron que con esta función las personas están más dispuestas a contestar una llamada que antes. Por ejemplo, el ratio de personas que atienden una llamada de un banco será más alta gracias a la función que añade el motivo de la llamada. Lo mismo en el caso de una llamada de un servicio de paquetería o envío de comida que quiere saber si el cliente está en el domicilio para recibir la entrega, explica Google.

Esta iniciativa se suma a los mensajes SMS verificados, funcionalidad que lanzó Google el año pasado y que al igual que con las llamadas telefónicas, confirma la identidad de la empresa en los mensajes de texto. Esta función actualmente está disponible en nueve países, entre ellos Brasil, México y España, y según Google el plan es ampliar la cobertura durante este 2020.

Vale la pena mencionar que los ataques de vishing han aumentado durante la pandemia. El uso de esta técnica de ingeniería social para estafar a los usuarios mediante llamadas telefónicas suplantando la identidad de una empresa o institución ha estado muy activa. En Estados Unidos organismos alertaron en agosto sobre el incremento de este tipo de ataques aprovechando que muchas personas están teletrabajando. En España, la Oficina de Seguridad Internauta alertó sobre este mismo comportamiento también el mes pasado, mientras que en América Latina también se están aprovechando de esta situación aparejada a la pandemia en países como Argentina, donde desde hace varios meses se registran casos de estafas telefónicas en las que se hacen pasar por organismos como la Administración Nacional de la Seguridad Social (ANSES) o instituciones bancarias para robar datos personales y dinero.

Créditos de la imagen: Hassan OUAJBIR en Pexels

Fuente: www.welivesecurity.com

Google ha publicado como Open Source un proyecto con la intención de ayudar a los vendedores de hardware a crear sus propias “llaves de seguridad” y contribuir al impulso de la mencionada tecnología.

El proyecto, que es una iniciativa llamada OpenSK, se compone de un firmware construido con Rust que permite convertir chips de Nordic en dispositivos que cumplen con los estándares de claves de seguridad FIDO U2F y FIDO2 (Fast Identity Online). Pero no solo el chip y el firmware cubre OpenSK, sino que también se ha publicado una carcasa protectora que se puede imprimir en 3D, por lo que los dispositivos resultantes se ven y pueden ser usados como llaves estándares.

Google ha explicado en su blog corporativo que espera en el futuro expandir la iniciativa a más fabricantes de chips, aunque ha empezado por los de Nordic debido a que son asequibles desde el punto de vista económico y soportan los criterios estipulados para los estándares de FIDO2, NFC y Bluetooth Low Energy. Poniendo esos recursos a disposición de todos, Google espera ayudar a impulsar y expandir este tipo de tecnologías haciéndolas más accesibles para los fabricantes, ya que hasta el momento solo Google y Yubikey han creado llaves compatibles con FIDO a través de hardware y software privativo.

Profundizando en los detalles técnicos, OpenSK está escrito en Rust y se ejecuta en TockOS para ofrecer un mejor aislamiento y abstracciones del sistema operativo más limpias con el fin de reforzar la seguridad. La fuerte seguridad ofrecida por Rust a nivel de memoria y las abstracciones de coste cero hacen que el código sea menos vulnerable a los ataques lógicos. Por su parte, TockOS, con su arquitectura aislada (sandbox), ofrece un aislamiento entre el applet de la llave de seguridad, los drivers y el kernel para construir una defensa en profundidad.

Sin embargo, y a pesar de las buenas intenciones de la iniciativa, de momento sería prudente cogerla con con pinzas, ya que Google ha anunciado el lanzamiento inicial de OpenSK como “un proyecto experimental de investigación para ser usado para propósitos de pruebas e investigación”, así que igualmente puede terminar naufragando antes de cumplir con su propósito.

Fuente: www.muylinux.com

“El software de código abierto nunca fue pensado para que las empresas de servicios en la nube lo tomasen y lo vendieran“. Es la opinión que mejor resume los desafíos que plantea la nube para el código abierto, al menos para quienes dicen sentirse desafiados. Son palabras de Salil Deshpande, director gerente de Bain Capital Ventures, inversora de la desarrolladora de bases de datos de código abierto Redis Labs.

Lo que plantean compañías como Redis Labs es que ellas son las que desarrollan el software sin apenas colaboración externa, pero los beneficios van a parar a los grandes proveedores de las plataformas de servicios en la nube, como Amazon Web Services (AWS), Microsoft Azure o Google Cloud. Al fin y al cabo, la mayoría de clientes acuden donde se lo dan todo hecho y ahí es donde invierten su capital.

Los “renegados” del código abierto

Por este motivo, asistimos desde hace unos meses a una pequeña guerra en la que están involucrados proyectos como Redis Labs, MongoDB, Cloud Foundry o Puppet, entre otros. Todos tienen un enemigo y estrategia común: los grandes proveedores, y cerrar parte de su código, respectivamente; pero no todos se han atrevido a llevarla a cabo y a los que lo han hecho, no les está yendo del todo bien la cosa.

MongoDB fue una de las primera en mover ficha, recibiendo el rechazo no solo de los temidos proveedores de servicios, sino de los proveedores de Linux, léase distribuciones como Debian o Red Hat, dispuestas a eliminar todo rastro de la base de datos de sus repositorios. Y es que nadie acepta su nueva licencia. Pero no ha sido la única en encontrar una respuesta inesperada.

En un movimiento directo en contra de AWS, que a la postre ha servido al gigante de la nube para dar su opinión sobre esta polémica, Elastic hizo recientemente un giro similar al de MongoDB. Elastic desarrolla el motor de búsqueda Elasticsearch, derivado de Apache Lucene y un producto clave para AWS con el que, además, la compañía dice haber contribuido adecuadamente.

La respuesta de los gigantes

Ante la adversidad, Amazon ha reaccionado como cabía esperar, para disgusto de Elastic: se han juntado con otros afectados de gran tamaño como Netflix o Expedia y han lanzado Open Distro for Elasticsearch, una bifurcación del original basada en el último código disponible, con el compromiso de mantenerlo como proyecto de código abierto.

Adrian Cockcroft, vicepresidente de Estrategia de Arquitectura Cloud de AWS, fue el encargado de anunciar Open Distro for Elasticsearch en un artículo más reivindicativo que de presentación, en el que no dudó en recordar las numerosas contribuciones que ha hecho la compañía con todo el software que utilizan, y en el que insistía en una idea que no parece tener clara todo el mundo: el código abierto debe permanecer abierto, porque de lo contrario pierde toda confianza.

En ese mismo artículo Cockcroft menciona otro caso que da fe de la rotundidad de la compañía al tratar asuntos que puedan siquiera alentar confusión al respecto, como por ejemplo los cambios en Java que tanta alarma generaron, por injustificada que fuera. ¿Qué hizo AWS? Empaquetar su propia implementación, basada en OpenJDK, y ofrecerla de manera totalmente gratuita a sus clientes.

La reacción más sorprendente a todo este asunto, sin embargo, es la protagonizada por Google. Uno de sus activos más prometedores es Google Cloud, plataforma fundada a fuerza de código abierto con el que la compañía contribuye como la que más desde siempre, y en torno a la cual se acaba de celebrar en San Francisco su evento anual, Google Cloud Next.

Un evento que ha dado para mucho, y del que entre otras tantas noticias destaca el acuerdo de colaboración de Google con siete firmas de código abierto incluyendo Elastic, Redis Labs o MongoDB, cuyo software integrará en sus servicios, derivando el soporte y repartiendo las ganancias, se entiende.

“Siempre hemos visto a nuestros amigos en la comunidad del código abierto como colaboradores iguales, y no simplemente como un recurso para explotar“, comenta Chris DiBona, director de Código Abierto de Google. “Con eso en mente, ofreceremos servicios administrados operados por estos socios que están estrechamente integrados en Google Cloud, brindando una experiencia de usuario perfecta en la administración, facturación y soporte. Esto hace que sea más fácil para nuestros clientes empresariales desarrollar tecnologías de código abierto, y cumple con nuestro compromiso de apoyar y hacer crecer continuamente estas comunidades de código abierto“.

Fuente: www.muylinux.com

Java es una tecnología muy importante para Google. Lo lógico es pensar en Android y en ART si miramos el mercado de consumo, aunque no hay que descartar su utilización, posiblemente con un papel protagonista, en las “bambalinas” de la compañía.

Según informan en eWeek, con el fin de facilitar la vida a los desarrolladores de Java, Google ha anunciado la publicación como Open Source de Jib, una herramienta para ayudar en la construcción de aplicaciones de Java que van dentro de contenedores. Entrando en detalles técnicos, fue descrito por el ingeniero Qingyang Chen como un constructor de imágenes de contenedor diseñado para manejar todos los pasos de la creación de una aplicación Java empaquetada que es introducida en un contenedor.

Docker ha ayudado mucho en la facilitación de la creación de contenedores, una tecnología que lleva existiendo desde años, pero que hasta no hace tanto se mostraba como algo complejo para la mayoría. Sin embargo, la contenedorización de una aplicación Java tampoco es que resulte demasiado sencilla a pesar de las ayudas actuales, ya que para ello hay que escribir un Dockerfile, ejecutar el demonio de Docker como root y esperar que los procesos de construcción se completen antes de colocar la imagen en un registro remoto.

Jib, que está implementado en Java y está integrado con Maven y Gradle, se dedica principalmente a eliminar los requerimientos mencionados en el párrafo anterior. Esto permite acortar el tiempo necesario para servir aplicaciones Java en contenedores sin tener que estar pendientes de elementos como las instrucciones de construcción del contenedor presentes en el Dockerfile o la creación de un fichero JAR para todo lo asociado con la aplicación.

Para reducir todavía más los tiempos de creación, Jib se apoya en una caché de registro y las capas de imágenes, pudiendo organizar así una aplicación en imágenes distintas y reconstruyendo solo aquellas que hayan cambiado. Esto quiere decir que solo se reconstruyen las partes cuyo código haya sido modificado. También soporta el uso de lenguaje declarativo para construir imágenes de contenedor a partir de metadatos de Maven y Gradle.

En resumidas cuentas, el propósito de Jib es la de facilitar y mejorar la productividad a la hora de crear aplicaciones de Java que son introducidas en contenedores Docker, por lo que estamos ante una herramienta orientada a desarrolladores. Su código ha sido publicado en GitHub bajo Apache License 2.0, la licencia que habitualmente emplea Google.

Fuente:www.muylinux.com