Autenticación de aplicaciones de Go en servicios de Azure mediante el SDK de Azure para Go
Cuando una aplicación necesita acceder a un recurso de Azure, como Azure Storage, Azure Key Vault o servicios de Azure AI, la aplicación debe autenticarse en Azure. Este requisito es cierto para todas las aplicaciones, independientemente de si se implementan en Azure, se implementan de forma local o en desarrollo en una estación de trabajo de desarrollador local. En este artículo se describen los enfoques recomendados para autenticar una aplicación en Azure cuando se usa el SDK de Azure para Go.
Enfoque recomendado de autenticación de aplicaciones
Use la autenticación basada en tokens en lugar de cadenas de conexión para las aplicaciones cuando se autentiquen en recursos de Azure. El SDK de Azure para Go proporciona mecanismos que admiten la autenticación basada en tokens. Las aplicaciones se pueden autenticar sin problemas en los recursos de Azure, tanto si la aplicación está en desarrollo local, implementada en Azure como si se implementa en un servidor local.
El tipo específico de autenticación basada en tokens que usa una aplicación para autenticarse en los recursos de Azure depende de dónde se ejecuta la aplicación. Los tipos de autenticación basada en tokens se muestran en el diagrama siguiente.
- Cuando un desarrollador ejecuta una aplicación durante el desarrollo local: La aplicación se autentica en Azure mediante una entidad de servicio de aplicación para el desarrollo local o las credenciales de Azure del desarrollador. Estas opciones se describen en la sección Autenticación durante el desarrollo local.
- Cuando una aplicación se hospeda en Azure: La aplicación se autentica en los recursos de Azure mediante una identidad administrada. Esta opción se describe en la sección Autenticación en entornos de servidor.
- Cuando una aplicación se hospeda e implementa de forma local: La aplicación se autentica en los recursos de Azure mediante un principal de servicio de aplicación. Esta opción se describe en la sección Autenticación en entornos de servidor.
DefaultAzureCredential
El tipo DefaultAzureCredential proporcionado por el SDK de Azure permite a las aplicaciones usar diferentes métodos de autenticación en función del entorno en el que se ejecuten. De este modo, las aplicaciones se pueden promover desde entornos de desarrollo local a entornos de prueba y a entornos de producción sin cambios en el código.
Configure el método de autenticación adecuado para cada entorno y DefaultAzureCredential detecte y use automáticamente ese método de autenticación. El uso de DefaultAzureCredential se prefiere sobre la codificación manual de la lógica condicional o las marcas de características para usar diferentes métodos de autenticación en distintos entornos.
Los detalles sobre el uso del tipo DefaultAzureCredential se describen en la sección Uso de DefaultAzureCredential en una aplicación.
Ventajas de la autenticación basada en tokens
Use la autenticación basada en tokens en lugar de usar cadenas de conexión al compilar aplicaciones para Azure. La autenticación basada en tokens ofrece las siguientes ventajas sobre la autenticación con cadenas de conexión:
- Los métodos de autenticación basados en tokens descritos en este artículo le permiten establecer los permisos específicos necesarios para la aplicación en el recurso de Azure. Esta práctica sigue el principio de privilegios mínimos. Por el contrario, una cadena de conexión concede derechos completos al recurso de Azure.
- Cualquiera o cualquier aplicación con una cadena de conexión puede conectarse a un recurso de Azure, pero los métodos de autenticación basados en tokens limitan el acceso al recurso solo a las aplicaciones diseñadas para acceder al recurso.
- Con una identidad administrada, no hay ningún secreto de aplicación que almacenar. La aplicación es más segura porque no hay ninguna cadena de conexión ni secreto de aplicación que se pueda poner en peligro.
- El paquete azidentity del SDK de Azure administra los tokens en segundo plano. Los tokens administrados hacen que el uso de la autenticación basada en tokens sea tan fácil de usar como una cadena de conexión.
Limite el uso de cadenas de conexión para aplicaciones de prueba de concepto iniciales o prototipos de desarrollo que no tengan acceso a la producción ni a los datos confidenciales. De lo contrario, siempre se prefiere la autenticación basada en tokens disponible en el SDK de Azure al autenticarse en los recursos de Azure.
Autenticación en entornos de servidor
Cuando se hospeda en un entorno de servidor, a cada aplicación se le asigna una identidad de aplicación de única por entorno donde se ejecuta la aplicación. En Azure, una identidad de aplicación se representa mediante una entidad de servicio. Este tipo especial de entidad de seguridad identifica y autentica las aplicaciones en Azure. El tipo de entidad de servicio que se va a usar para la aplicación depende de dónde se esté ejecutando la aplicación:
| Método de autenticación | Descripción |
|---|---|
| Aplicaciones hospedadas en Azure | Las aplicaciones hospedadas en Azure deben usar una entidad de servicio de identidad administrada. Las identidades administradas están diseñadas para representar la identidad de una aplicación hospedada en Azure y solo se pueden usar con aplicaciones hospedadas en Azure. Por ejemplo, a una aplicación web de Gin hospedada en Azure Container Apps se le asignaría una identidad administrada. La identidad administrada asignada a la aplicación se usaría para autenticar la aplicación en otros servicios de Azure. Las aplicaciones que se ejecutan en Azure Kubernetes Service (AKS) pueden usar una credencial de identidad de carga de trabajo. Esta credencial se basa en una identidad administrada que tiene una relación de confianza con una cuenta de servicio de AKS. |
| Aplicaciones hospedadas fuera de Azure (por ejemplo, aplicaciones locales) |
Las aplicaciones hospedadas fuera de Azure (por ejemplo, aplicaciones locales) que necesitan conectarse a los servicios de Azure deben usar una entidad de servicio de aplicación. Una entidad de servicio de aplicación representa la identidad de la aplicación en Azure y se crea a través del proceso de registro de la aplicación. Por ejemplo, considere una Gin aplicación web hospedada localmente que use Azure Blob Storage. Crearía una entidad de servicio de aplicación para la aplicación mediante el proceso de registro de la aplicación. AZURE_CLIENT_ID, AZURE_TENANT_ID y AZURE_CLIENT_SECRET se almacenarían como variables de entorno para que la aplicación las lea en tiempo de ejecución y permitan que la aplicación se autentique en Azure mediante la entidad de servicio de la aplicación. |
Autenticación durante el desarrollo local
Cuando una aplicación se ejecuta en la estación de trabajo de un desarrollador durante el desarrollo local, todavía debe autenticarse en los servicios de Azure usados por la aplicación. Hay dos estrategias principales para autenticar aplicaciones en Azure durante el desarrollo local:
| Método de autenticación | Descripción |
|---|---|
| Crear objetos de entidad de servicio de aplicación dedicados que se usarán durante el desarrollo local. | En este método, los objetos de entidad de servicio de aplicación dedicados se configuran mediante el proceso de registro de la aplicación para su uso durante el desarrollo local. A continuación, la identidad de la entidad de servicio se almacena como variables de entorno a las que debe acceder la aplicación cuando se ejecuta en el desarrollo local. Este método permite asignar los permisos de recursos específicos necesarios para la aplicación a los objetos de entidad de servicio que usan los desarrolladores durante el desarrollo local. Esta práctica garantiza que la aplicación solo tiene acceso a los recursos específicos que necesita y replica los permisos que tendrá la aplicación en producción. La desventaja de este enfoque es la necesidad de crear objetos de entidad de servicio independientes para cada desarrollador que trabaja en una aplicación. |
| Autentíque la aplicación en Azure mediante las credenciales del desarrollador durante el desarrollo local. | En este método, un desarrollador debe iniciar sesión en Azure desde la CLI de Azure o la CLI para desarrolladores de Azure en su estación de trabajo local. A continuación, la aplicación puede acceder a las credenciales del desarrollador desde el almacén de credenciales y usar esas credenciales para acceder a los recursos de Azure desde la aplicación. Este método tiene la ventaja de una configuración más sencilla porque un desarrollador solo necesita iniciar sesión en su cuenta de Azure a través de una de las herramientas de desarrollo mencionadas anteriormente. La desventaja de este enfoque es que la cuenta del desarrollador probablemente tenga más permisos de los que requiere la aplicación. Como resultado, la aplicación no replica con precisión los permisos con los que se ejecutará en producción. |
Uso de DefaultAzureCredential en una aplicación
DefaultAzureCredential es una secuencia ordenada de mecanismos para autenticarse en Microsoft Entra ID. Cada mecanismo de autenticación es una clase que implementa la interfaz TokenCredential y se conoce como credencial. En tiempo de ejecución, DefaultAzureCredential intenta autenticarse con la primera credencial. Si esa credencial no puede adquirir un token de acceso, se intenta realizar la siguiente credencial de la secuencia, etc., hasta que se obtenga correctamente un token de acceso. De este modo, la aplicación puede usar credenciales diferentes en distintos entornos sin escribir código específico del entorno.
Para usar DefaultAzureCredential en una aplicación de Go, agregue el paquete azidentity a su aplicación.
go get github.com/Azure/azure-sdk-for-go/sdk/azidentity
En el ejemplo de código siguiente se muestra cómo crear una instancia de cliente del SDK de Azure con DefaultAzureCredential. En este caso, es el cliente azblob que se usa para acceder a Azure Blob Storage (almacenamiento de blobs de Azure).
import (
"context"
"github.com/Azure/azure-sdk-for-go/sdk/azidentity"
"github.com/Azure/azure-sdk-for-go/sdk/storage/azblob"
)
const (
account = "https://<replace_with_your_storage_account_name>.blob.core.windows.net/"
containerName = "sample-container"
blobName = "sample-blob"
sampleFile = "path/to/sample/file"
)
func main() {
// create a credential
cred, err := azidentity.NewDefaultAzureCredential(nil)
if err != nil {
// TODO: handle error
}
// create a client for the specified storage account
client, err := azblob.NewClient(account, cred, nil)
if err != nil {
// TODO: handle error
}
// TODO: perform some action with the azblob Client
// _, err = client.DownloadFile(context.TODO(), <containerName>, <blobName>, <target_file>, <DownloadFileOptions>)
}
Cuando el código anterior se ejecuta en la estación de trabajo de desarrollo local, busca en las variables de entorno de una entidad de servicio de aplicación o en las herramientas de desarrollo instaladas localmente, como la CLI de Azure, para un conjunto de credenciales de desarrollador. Cualquier enfoque se puede usar para autenticar la aplicación en los recursos de Azure durante el desarrollo local.
Cuando se implementa en Azure, este mismo código también puede autenticar la aplicación en los recursos de Azure. DefaultAzureCredential puede recuperar la configuración del entorno y las configuraciones de identidad administrada para autenticarse automáticamente en los servicios de Azure.