Tutorial: Autenticación integrada para aplicaciones de Python con servicios de Azure

Microsoft Entra ID, cuando se usa con Azure Key Vault, proporciona un enfoque sólido y seguro para autenticar aplicaciones tanto en servicios de Azure como en plataformas de terceros que requieren claves de acceso o credenciales. Esta combinación elimina la necesidad de codificar los secretos de forma rígida en el código de la aplicación, y en su lugar, se basa en identidades administradas, control de acceso basado en roles (RBAC) y administración centralizada de secretos a través de Key Vault. Este enfoque simplifica la administración de identidades y mejora la posición de seguridad en entornos en la nube.

En este tutorial se exploran estos mecanismos de autenticación mediante un ejemplo práctico proporcionado en el repositorio de GitHub: github.com/Azure-Samples/python-integrated-authentication.

En el ejemplo se muestra cómo una aplicación de Python puede:

• Autenticación con Azure mediante DefaultAzureCredential

• Acceso a secretos de Azure Key Vault sin almacenar credenciales

• Comunicación segura con otros servicios de Azure, como Azure Storage, Cosmos DB y mucho más

Este artículo forma parte de una serie que proporciona un tutorial detallado sobre cómo autenticar una aplicación de Python con el identificador de Microsoft Entra, Azure Key Vault y Azure Queue Storage mediante la biblioteca del SDK azure-identity de Python de Azure.

Parte 1: Contexto

Aunque muchos servicios de Azure dependen exclusivamente del control de acceso basado en rol (RBAC), mientras que otros requieren acceso a través de secretos o claves. Estos servicios incluyen Azure Storage, bases de datos, Herramientas de Foundry, Key Vault y Event Hubs

Al compilar aplicaciones en la nube que interactúan con estos servicios, los desarrolladores pueden usar Azure Portal, la CLI o PowerShell para generar y configurar claves de acceso específicas del servicio. Estas claves están vinculadas a directivas de acceso concretas para evitar el acceso no autorizado. Sin embargo, este modelo requiere que la aplicación administre las claves explícitamente y autentíquese por separado con cada servicio, un proceso que sea tedioso y propenso a errores.

Insertar secretos directamente en el código o almacenarlos en máquinas de desarrollador corre el riesgo de exponerlos en:

• Control de código fuente
• Entornos locales no seguros
• Exportaciones accidentales de registros o configuraciones

Azure ofrece dos servicios clave para mejorar la seguridad y simplificar la autenticación:

• Azure Key Vault Azure Key Vault proporciona un almacén seguro basado en la nube para secretos, incluidas las claves de acceso, las cadenas de conexión y los certificados. Al recuperar secretos de Key Vault solo en tiempo de ejecución, las aplicaciones evitan exponer datos confidenciales en el código fuente o los archivos de configuración.

• Con las identidades administradas de Microsoft Entra, la aplicación puede autenticarse una vez con el identificador de Microsoft Entra. Desde allí, puede acceder a otros servicios de Azure( incluido Key Vault) sin administrar las credenciales directamente.

Este enfoque proporciona:

• Código sin credenciales (sin secretos en el control de código fuente)
• Integración sin problemas con los servicios de Azure
• Coherencia del entorno: el mismo código se ejecuta localmente y en la nube con una configuración mínima

En este tutorial se muestra cómo usar la identidad administrada de Microsoft Entra y Key Vault juntas en la misma aplicación. Con el identificador de Entra de Microsoft y Key Vault juntos, la aplicación nunca necesita autenticarse con servicios individuales de Azure y puede acceder de forma sencilla y segura a las claves necesarias para los servicios de terceros.

Importante

En este artículo se usa el término genérico común "clave" para hacer referencia a lo que se almacenan como "secretos" en Azure Key Vault, como una clave de acceso para una API REST. Este uso no debe confundirse con la administración de claves criptográficas de Key Vault, que es una característica independiente de los secretos de Key Vault.

Escenario de aplicación en la nube de ejemplo

Para comprender el proceso de autenticación de Azure más profundamente, tenga en cuenta el siguiente escenario: una aplicación web de Flask se implementa en Azure App Service. Expone un punto de conexión de API público y no autenticado que devuelve datos JSON en respuesta a solicitudes HTTP.

• Para generar su respuesta, la API invoca una API de terceros que requiere una clave de acceso. En lugar de almacenar esta clave en archivos de código o configuración, la aplicación la recupera de forma segura en tiempo de ejecución desde Azure Key Vault mediante la identidad administrada de Microsoft Entra.

• Antes de devolver su respuesta al cliente, la aplicación escribe un mensaje en una cola de Azure Storage para el procesamiento asincrónico. El mensaje podría representar una tarea, un registro o una señal, aunque el procesamiento de bajada no es el foco de este escenario.

Nota:

Aunque los puntos de conexión de API públicos normalmente están protegidos por sus propias claves de acceso o mecanismos de autenticación, en este tutorial se supone que el punto de conexión está abierto y no autenticado.

Esta simplificación ayuda a aislar los requisitos de autenticación internos de la aplicación(como el acceso a Azure Key Vault y Azure Storage) desde cualquier problema de autenticación relacionado con los clientes externos.

El escenario se centra únicamente en el comportamiento de la aplicación y no demuestra ni implica a un llamador externo autenticándose con el punto de conexión.

Parte 2: Requisitos de autenticación >>>