Prácticas recomendadas para autenticar aplicaciones de forma segura en Google Cloud

Los documentos de Google Cloud pueden ayudarte con distintas partes de tu trabajo. En ocasiones, es posible que quieras obtener información sobre un servicio nuevo o ver una función en acción. En otra visita a los documentos, es posible que debas desarrollar una aplicación para usar en producción.

Nuestros documentos suelen estar escritos para ayudarte a tener en marcha un servicio o una función. En un entorno de producción o desarrollo, puede haber algunas prácticas recomendadas de seguridad para tu organización que podrías considerar. Es posible que debas autenticar tus aplicaciones de manera diferente a la que se muestra en los documentos.

A fin de ayudarte a elegir el método de autenticación correcto para tus aplicaciones, usa el siguiente árbol de decisión. En el resto de este artículo, se explica cada una de las formas seguras de autenticar tus aplicaciones.

Diagrama de árbol de decisión para ayudarte a elegir una forma de autenticar tus aplicaciones. Cada opción se detalla en las secciones de este artículo.

Descripción general de las credenciales predeterminadas de la aplicación

La mayoría de las veces, deseas que tu código realice solicitudes a la API. Puedes usar una estrategia llamada credenciales predeterminadas de la aplicación (ADC) para encontrar las credenciales necesarias y autenticar tu aplicación de forma automática. Todas las bibliotecas cliente de Google Cloud son compatibles con ADC.

Con ADC, puedes desarrollar de manera local con un método de autenticación y, luego, autenticar con un método diferente cuando se implemente para probar o producción. No se requieren cambios en el código mientras pasas de los diferentes entornos de implementación a los métodos de autenticación compatibles.

Las bibliotecas cliente determinan qué métodos de autenticación están disponibles para su uso. ADC selecciona el método de autenticación correcto para que la aplicación realice solicitudes a la API, sin importar si desarrollas contenido de forma local o ejecutas en producción. Cuando sea posible, procura usar ADC para tus aplicaciones.

Para obtener más información, consulta la descripción general de las credenciales predeterminadas de la aplicación (ADC) y cómo ADC encuentra las credenciales de forma automática.

Desarrollo y pruebas locales con la herramienta de línea de comandos de gcloud

En esta situación, debes usar la herramienta de línea de comandos de gcloud para realizar cambios de configuración en tu proyecto con las API de Cloud o escribir código para probar integraciones nuevas con esas API. Este tipo de uso interactivo es principalmente para el desarrollo y las pruebas en tu máquina local. Proporciona tus propias credenciales para acceder a la herramienta de línea de comandos de gcloud. Este enfoque te permite hacer un seguimiento de la identidad que realizó la solicitud a la API y administrar las cuotas o proporcionar un registro de auditoría con fines de seguridad.

Para autenticar de forma interactiva con la herramienta de línea de comandos de gcloud a fin de emitir tus propios comandos y realizar cambios en la configuración, usa el comando gcloud auth login y especifica un proyecto de facturación que sea de algún usuario usando la marca --billing-project. Las llamadas a algunas API de Cloud, como la API de Cloud Translation o la API de Cloud Vision, fallan con el conjunto de proyectos de facturación propiedad del usuario.

Para que tu código realice llamadas a la API de Cloud desde tu entorno de desarrollo local, usa las bibliotecas cliente de Google y ADC. Para hacerlo, usa el comando gcloud auth application-default login y especifica un proyecto de facturación propiedad del usuario con la marca --billing-project. Otra vez, las llamadas a algunas API de Cloud, como la API de Cloud Translation o la de Cloud Vision, fallan sin el conjunto de proyectos de facturación propiedad del usuario.

No asignes una función a tu cuenta que otorgue más permisos de los necesarios para realizar las solicitudes a la API de Cloud. El recomendador de Identity and Access Management (IAM) puede revisar qué permisos no se necesitaron en los últimos 90 días para que puedas quitarlos.

Dentro de los entornos de Google Cloud

En esta situación, el código de tu aplicación se ejecuta en Google Cloud y usa la familia de productos de Compute o sin servidores, como las VM de Compute Engine, Cloud Run, App Engine, Google Kubernetes Engine (GKE) o Cloud Functions. Debido a que las aplicaciones se ejecutan en el entorno de Google Cloud usa las credenciales predeterminadas.

Con las credenciales predeterminadas, tu aplicación recupera el token de identidad asociado con la instancia virtual que ejecuta tu código. El token de identidad se recupera de un servidor de metadatos que se ejecuta en la instancia virtual. Este token se puede usar para autenticar y realizar solicitudes a la API de Cloud mediante las ADC.

No necesitas hacer nada diferente para usar las credenciales predeterminadas, ya que forman parte de las ADC. No es necesario cambiar el código ni crear y administrar las cuentas de servicio y la rotación de claves.

Centro de datos local o de otro proveedor de servicios en la nube

En esta situación, el código de tu aplicación se ejecuta en tu propia infraestructura de centro de datos o en otro proveedor de servicios en la nube, como AWS o Azure. Si hay compatibilidad con OpenID Connect (OIDC), usa la federación de identidad para cargas de trabajo externas y crea un grupo de identidad de carga de trabajo para cada entorno con el fin de proporcionar autenticación a tus aplicaciones.

Con la federación de identidades, puedes usar Identity and Access Management (IAM) para otorgar funciones de IAM de identidades externas, incluida la capacidad de suplantar cuentas de servicio. Este enfoque te permite acceder a los recursos directamente mediante un token de acceso de corta duración.

Estos son algunos ejemplos de proveedores de identidad:

  • AWS
  • Azure Active Directory
  • Active Directory local
  • Okta
  • Clústeres de Kubernetes

Si quieres obtener más información, consulta cómo usar la federación de identidad para las cargas de trabajo externas y cómo crear un grupo de Workload Identity.

Si no tienes asistencia para OIDC o no deseas usar la federación de identidades, puedes crear cuentas de servicio administradas por el usuario. Estas cuentas de servicio se analizan en la siguiente sección. Asegúrate de almacenar estas credenciales de forma segura en una bóveda digital que pueda ofrecer tu proveedor, como AWS Secret Manager o Azure Key Vault. No escribas estas credenciales en el disco, excepto en un formato encriptado.

Cuentas de servicio administradas por el usuario

En este caso, tu código no se ejecuta dentro de Google Cloud ni en un entorno que admita OpenID Connect y la federación de identidades. Siempre que el entorno se considere de confianza y no haya restricciones de servicio de políticas de la organización para evitar su uso, puedes usar cuentas de servicio para autenticar tus aplicaciones. ADC funciona con cuentas de servicio, por lo que tus aplicaciones pueden usar de forma automática diferentes métodos de autenticación en distintos entornos de implementación.

Una cuenta de servicio es un tipo especial de cuenta que usa una aplicación, no una persona. Cada cuenta de servicio está asociada con pares de claves RSA públicas/privadas que se usan para la autenticación. Asegúrate de que haya poco riesgo de que el entorno sea vulnerable y de que se expongan las claves de la cuenta de servicio. A fin de proteger las claves que exportas y minimizar los posibles riesgos de seguridad, revisa las prácticas recomendadas para las claves de la cuenta de servicio.

También puedes usar un JWT autofirmado (token web JSON) o un token de OIDC con tu cuenta de servicio a fin de evitar un recorrido de ida y vuelta innecesario para adquirir los tokens. Para obtener más información, consulta cómo realizar una solicitud autenticada con JWT a una API de Cloud Endpoints.

Las cuentas de servicio realizan acciones en tu nombre, pero pueden tener permisos excesivos asignados y, con frecuencia, no se borran cuando ya no se necesitan. El recomendador de Identity and Access Management puede revisar qué permisos no se necesitaron en los últimos 90 días y puedes identificar las cuentas de servicio no utilizadas que deben quitarse.

Entornos de semiconfianza o restringidos

En esta situación, el código de la aplicación se ejecuta en un entorno de semiconfianza o tiene restricciones de política que limitan la cantidad de acciones que se pueden realizar. No uses cuentas de servicio en estos entornos para autenticar y realizar solicitudes a la API de Cloud.

El servicio de políticas de la organización se puede usar para aplicar restricciones en tu proyecto que te impidan interactuar con recursos que se ejecutan en otros proyectos, especialmente aquellos en producción.

Dado que cada entorno es único y es posible que se apliquen requisitos de seguridad diferentes, revisa las instrucciones específicas del servicio que podrían afectarte. Trabaja con tus equipos de operaciones y seguridad a fin de diseñar la mejor solución para tus necesidades.

En un nivel alto, debes diseñar un sistema que te permita obtener un token de acceso de corta duración de forma segura. Se aplican las siguientes consideraciones de diseño:

  • El token debería durar el tiempo suficiente para que tu app se ejecute o se pueda actualizar.
  • Limitar el token a las funciones requeridas
  • No escribas el token en el disco.

Algunas soluciones de ejemplo pueden incluir el acceso a una administración de claves digital local, como Hashicorp Vault , o limitar el acceso a Cloud Run y, luego, recuperar automáticamente credenciales de Secret Manager o credenciales encriptadas desde Cloud Key Management Service.

También puedes comunicarte con Google Cloud Consulting para obtener ayuda sobre cómo diseñar y compilar una solución segura.

Consideraciones de seguridad

Si usas tokens OIDC o JWT como parte del proceso de autenticación de tu aplicación, los tokens son válidos durante toda su vida útil. A fin de reducir el riesgo de exposición, configura la vida útil del token para que sea un poco más larga de lo que esperas que se ejecute tu trabajo. Por ejemplo, si se necesita un token durante 15 minutos mientras se ejecuta tu trabajo, configura la vida útil del token a 20 minutos.

No puedes revocar estos tokens sin borrar la cuenta de servicio superior. Nuevamente, asegúrate de asignar políticas de vida útil del token para reducir el tiempo que un token potencialmente vulnerado permanecerá utilizable.

Las claves de las cuentas de servicio pueden robarse y usarse para generar credenciales de la forma menos rastreable posible o hasta la siguiente rotación de la clave. A fin de proteger las claves que exportas y minimizar los posibles riesgos de seguridad, revisa las prácticas recomendadas para las claves de la cuenta de servicio , como la rotación de claves y la auditoría.

Si es necesario, puedes borrar las claves de la cuenta de servicio para que no se puedan usar más.

¿Qué sigue?

Si quieres obtener más información sobre el uso de credenciales en aplicaciones, consulta Prácticas recomendadas para administrar las credenciales.