Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Este artigo é a principal referência de como o Azure Functions se conecta a serviços remotos. Ele fornece orientações específicas baseadas no tipo de conexão e no método de autenticação.
Importante
Use identidades gerenciadas com o Microsoft Entra ID sempre que possível. Esse método de autenticação elimina segredos e oferece a mais alta segurança.
Categorias de conexão
As conexões do Azure Functions se enquadram nestas categorias básicas:
- Host obrigatório: Conexões de que o host do Functions precisa para operar, como armazenamento e monitoramento.
- Bindings: conexões que o host gerencia para seus gatilhos e associações.
- SDK do cliente: conexões que você cria e gerencia no seu próprio código de função.
Dica
O Functions também suporta conectores gerenciados (em prévia), que permitem conectar a serviços como Office 365, Teams e SharePoint com OAuth e gerenciamento de webhooks integrados por meio de um Espaço Nominal de Conectores. Para mais informações, consulte Usar conectores no Azure Functions.
O host do Functions exige que seu aplicativo tenha estas conexões específicas nomeadas, que dão suporte tanto às execuções de função quanto aos logs:
AzureWebJobsStorage: O Functions usa essa conta de armazenamento padrão para habilitar comportamentos principais, como coordenar a execução singleton dos gatilhos do temporizador e o armazenamento padrão para chaves de acesso à função. O host requer essa conexão com uma conta de armazenamento suportada. Seu aplicativo de funções não pode ser iniciado sem essa configuração de conexão. Para obter mais informações, confira Considerações de armazenamento do Azure Functions.APPLICATIONINSIGHTS_CONNECTION_STRING: Você também deve configurar o host para gravar logs em uma instância do Application Insights.WEBSITE_AZUREFILESCONNECTIONSTRING: Usado apenas por aplicativos que rodam em um plano Consumption ou Elastic Premium. Define a conta de armazenamento que contém o compartilhamento Arquivos do Azure que mantém o pacote de implantação para seu app.
Métodos de autenticação
Importante
Quando possível, use identidades gerenciadas para suas conexões. Essa abordagem elimina completamente os segredos. Quando o serviço de destino não suporta autenticação Microsoft Entra ID, use o Azure Key Vault para gerenciar segredos centralmente. Use segredos compartilhados diretamente nas configurações do app como último recurso.
O Functions suporta estes métodos de autenticação ao se conectar a serviços remotos:
| Método de autenticação | Segurança | Quando usar |
|---|---|---|
| identidades gerenciadas | Máximo | O serviço Target suporta o Microsoft Entra ID. Nenhum segredo a ser gerenciado. |
| Azure Key Vault | Alto | O serviço não suporta identidades gerenciadas, ou você precisa de gerenciamento centralizado de segredos com rotação. |
| Segredo compartilhado | Baixo | Padrão legado. Migre para identidades gerenciadas ou Key Vault o quanto antes. |
Escolha seu método de autenticação preferido no topo do artigo para ver orientações detalhadas de configuração.
Defina conexões
Em tempo de execução, seu aplicativo de funções acessa informações de conexão como variáveis de ambiente a partir destas localizações:
| Ambiente | Onde as configurações são armazenadas |
|---|---|
| Azure | Configurações de aplicação (criptografadas em repouso) |
| Desenvolvimento local | local.settings.json (opcionalmente criptografado) |
Em ambos os ambientes, as configurações são expostas ao seu código como variáveis de ambiente. As configurações específicas que você precisa dependem tanto do tipo de conexão quanto do método de autenticação que você escolher.
Quando você usa autenticação Microsoft Entra para se conectar a um serviço Azure, as configurações específicas do aplicativo que você usa dependem do serviço conectado e se você está usando uma identidade atribuída pelo sistema ou pelo usuário para autenticar a conexão.
As identidades que você usa para suas conexões devem ter permissões para realizar as ações pretendidas. Para a maioria dos serviços do Azure, esse requisito significa que você precisa atribuir uma função no Azure RBAC, usando papéis internos ou personalizados que forneçam essas permissões. Para saber mais, veja Conceder permissões a uma identidade.
Tenha essas considerações em mente ao usar conexões baseadas em identidade:
Em um aplicativo hospedado em Functions, conexões baseadas em identidade usam uma identidade gerenciada. A identidade atribuída ao sistema, que é específica para o seu app, é usada por padrão. No entanto, as identidades atribuídas pelo usuário, que também exigem as propriedades
*__credentiale*__clientID, são mais flexíveis e recomendadas.Quando seu aplicativo roda em outros contextos, como desenvolvimento local, sua identidade de desenvolvedor é usada em seu lugar. Para mais informações, consulte o artigo sobre desenvolvimento local .
Conexões baseadas em identidade são suportadas apenas na versão 4.x e posteriores do runtime de Funções. Se você está rodando um aplicativo C# antigo na versão 1.x do runtime Functions, primeiro precisa migrar para a versão 4.x.
Você pode configurar seu aplicativo de funções para usar uma identidade em vez de uma cadeia de conexão ao se conectar à conta de armazenamento padrão (AzureWebJobsStorage) e outras conexões exigidas pelo host.
O suporte AzureWebJobsStorage à identidade gerenciada varia conforme o plano de hospedagem:
| Plano de hospedagem | MI para armazenamento do host | Requisito do Arquivos do Azure | Recommendation |
|---|---|---|---|
| Consumo flexível | Suporte completo | Nenhum (sem Arquivos do Azure) | Recomendado para MI |
| Dedicado (Serviço de Aplicativo) | Suporte completo | Nenhum (sem escalonamento dinâmico) | MI completo, sem necessidade de solução alternativa |
| Consumo | Blobs, filas, tabelas | Key Vault ou remover Arquivos do Azure | Armazenar WEBSITE_AZUREFILESCONNECTIONSTRING no Key Vault |
| Elástico Premium | Blobs, filas, tabelas | Key Vault ou remover Arquivos do Azure | Armazenar WEBSITE_AZUREFILESCONNECTIONSTRING no Key Vault |
Antes de usar identidades gerenciadas para conexões que exigem o host, considere estas limitações:
Para planos Consumption e Premium, implemente uma dessas soluções alternativas para o Arquivos do Azure:
- Armazene apenas a
WEBSITE_AZUREFILESCONNECTIONSTRINGcadeia de conexão no Key Vault, que é a próxima opção mais segura. - Crie um aplicativo de plano Consumption ou Premium que rode sem o Arquivos do Azure. Há impactos de desempenho ao rodar sem o Arquivos do Azure. Para obter mais informações, consulte Criar um aplicativo sem Arquivos do Azure.
- Armazene apenas a
Esses gatilhos dependem de
AzureWebJobsStoragefuncionar corretamente:- Armazenamento de Blobs do Azure
- Hubs de Eventos do Azure
- Durable Functions (por padrão)
- Temporizador
Se seu app usar alguma dessas extensões, certifique-se de que a versão dele também suporta identidades gerenciadas.
AzureWebJobsStoragemantém artefatos de implantação em compilações do lado do servidor (remotas) em um plano Consumo em Linux. Nesse cenário, você deve implantar e executar seu aplicativo a partir de um pacote externo.Outros componentes do seu aplicativo de funções podem reutilizar a conexão
AzureWebJobsStorage, o que pode incluir extensões de associação de armazenamento ou clientes de armazenamento criados com o SDK do Azure. Ao usar identidades gerenciadas, crie novas configurações de aplicação para esses componentes não host, mesmo quando suportam identidades gerenciadas.
Essas configurações específicas do aplicativo definem conexões baseadas em identidade tanto com AzureWebJobsStorage quanto com APPLICATIONINSIGHTS_CONNECTION_STRING:
| Setting | Description |
|---|---|
AzureWebJobsStorage__blobServiceUri |
O URI do Armazenamento de Blobs na conta de armazenamento padrão. Exigido para nuvens soberanas ou um DNS de armazenamento personalizado, como: https://mystorageaccount.blob.contoso.com.
HTTPS é obrigatório. |
AzureWebJobsStorage__queueServiceUri |
O URI do Armazenamento de Filas na conta de armazenamento padrão. Exigido para nuvens soberanas ou um DNS de armazenamento personalizado, como: https://mystorageaccount.queue.contoso.com.
HTTPS é obrigatório. |
AzureWebJobsStorage__tableServiceUri |
O URI para o armazenamento de tabelas na conta de armazenamento padrão. Exigido para nuvens soberanas ou um DNS de armazenamento personalizado, como: https://mystorageaccount.table.contoso.com.
HTTPS é obrigatório. |
AzureWebJobsStorage__credential |
Defina como managedidentity para usar autenticação de identidade gerenciada. Uma identidade gerenciada deve estar disponível no ambiente host. |
AzureWebJobsStorage__clientId ouAzureWebJobsStorage__managedIdentityResourceId |
Retorna uma identidade específica atribuída pelo usuário usada para obter um token de acesso para autenticação de identidade gerenciada. Quando nenhum dos dois está definido, a identidade atribuída pelo sistema da aplicação é usada. |
APPLICATIONINSIGHTS_AUTHENTICATION_STRING |
Permite conexões com o Application Insights usando autenticação Microsoft Entra. Definido para ( Authorization=AAD designado pelo sistema) ou ClientId=<YOUR_CLIENT_ID>;Authorization=AAD (atribuído pelo usuário). |
Como o valor com sublinhado duplo (__) é interpretado em runtime como dois pontos (:), a série de configurações é interpretada como propriedades do objeto AzureWebJobsStorage. Por exemplo, considere estas AzureWebJobsStorage configurações de conexão:
AzureWebJobsStorage__blobServiceUri=https://<STORAGE_ACCOUNT_NAME>.blob.core.windows.netAzureWebJobsStorage__queueServiceUri=https://<STORAGE_ACCOUNT_NAME>.queue.core.windows.netAzureWebJobsStorage__tableServiceUri=https://<STORAGE_ACCOUNT_NAME>.table.core.windows.netAzureWebJobsStorage__credential=managedidentityAzureWebJobsStorage__clientId=<MY_USER_ASSIGNED_IDENTITY_ID>
Em tempo de execução, o host interpreta essas configurações como uma configuração complexa AzureWebJobsStorage .
"AzureWebJobsStorage":
{
"blobServiceUri": "https://<STORAGE_ACCOUNT_NAME>.blob.core.windows.net",
"queueServiceUri": "https://<STORAGE_ACCOUNT_NAME>.queue.core.windows.net",
"tableServiceUri": "https://<STORAGE_ACCOUNT_NAME>.table.core.windows.net",
"credential": "managedidentity",
"clientId": "<MY_USER_ASSIGNED_IDENTITY_ID>"
}
Você também deve conceder permissões para a identidade na conta de armazenamento padrão, para que o host possa se conectar com permissões suficientes para realizar as tarefas necessárias. Para saber como, veja Conceder permissões para uma identidade.
Conceder permissões a uma identidade
Quando você usa identidades gerenciadas com autenticação Microsoft Entra ID, deve atribuir permissões específicas à identidade que seu aplicativo usa ao fazer conexões com o serviço remoto. A maneira mais fácil de conceder permissões de privilégio mínimo ao seu app é atribuindo funções embutidas.
Tenha em mente estas recomendações ao conceder permissões RBAC para as identidades do seu app:
- Sempre que possível, siga o princípio do menor privilégio concedendo à identidade apenas os privilégios mínimos exigidos. Por exemplo, se o app só precisa ler uma fonte de dados, use uma função que tenha permissão apenas para ler, e não para escrever dados.
- Não use funções amplas e embutidas como Proprietário, nem mesmo para fazer o app funcionar.
- Após criar ou modificar uma atribuição de função, pode levar até 10 minutos para a mudança se propagar. Durante esse período, sua função pode receber erros de autorização (403) mesmo que a função esteja corretamente atribuída. Se você encontrar erros imediatamente após criar uma atribuição de função, espere alguns minutos e tente novamente.
- Quando múltiplas conexões exigem permissões para o mesmo serviço, use a função que é o subconjunto mínimo de permissões para todas as conexões a esse serviço.
- Várias associações exigem permissões mais amplas na sua conta de armazenamento do que as exigidas pela conexão
AzureWebJobsStorage. - Para acessar chaves no Key Vault usando identidades gerenciadas, atribua seu aplicativo ao papel de Usuário do Key Vault Secrets. Você também pode usar uma política de acesso do Key Vault para atribuir a permissão de segredos Get à identidade gerenciada. Para mais informações, consulte como conceder a uma identidade no seu aplicativo acesso ao seu cofre de chaves.
- Este artigo refere-se apenas a funções embutidas que fornecem permissões mínimas. Dependendo dos requisitos do seu aplicativo, talvez você precise criar suas próprias funções personalizadas.
As permissões que você precisa dependem do tipo de conexão:
AzureWebJobsStorage: A função Storage Blob Data Owner fornece as permissões mínimas na conta de armazenamento para a conexãoAzureWebJobsStorageexigida pelo host. Esse papel fornece o nível de acesso ao armazenamento que o host das Funções precisa, seguindo o princípio do privilégio mínimo.Para alguns tipos de problemas, o Functions pode gerar eventos de diagnóstico para ajudar a solucionar o problema, mesmo quando seu app não consegue iniciar. Você também deve adicionar a função Colaborador de Dados da Tabela de Armazenamento, que dá acesso ao Armazenamento de Tabela onde esses eventos de diagnóstico persistem. Sem essas permissões extras, você pode ver avisos nos seus logs sobre a impossibilidade de gravar esses eventos.
Várias outras vinculações podem exigir que você use uma função um pouco mais ampla. A coluna Armazenamento exigido pelo host da tabela na guia Associações lista esses requisitos da função.
APPLICATIONINSIGHTS_AUTHENTICATION_STRING: A função Monitoring Metrics Publisher concede as permissões mínimas que o host precisa para se conectar ao Application Insights para registro.
Observação
Ao usar APPLICATIONINSIGHTS_AUTHENTICATION_STRING para se conectar ao Application Insights usando a autenticação do Microsoft Entra, você também deve Desativar a autenticação local para o Application Insights. Essa configuração requer autenticação do Microsoft Entra para que a telemetria seja processada em sua área de trabalho.
Observação
Use o Key Vault apenas para conexões que atualmente não suportam Microsoft Entra ID com identidades gerenciadas pelo Azure.
Como alguns serviços ainda não suportam autenticação Microsoft Entra, seu app pode ainda exigir segredos em certos casos. Para esses casos, o Azure Key Vault pode ajudar a agilizar o ciclo de vida de gerenciamento para autenticação baseada em segredos. Seu app pode usar o Key Vault para armazenar e acessar segredos compartilhados de forma mais segura, incluindo a cadeia de conexão padrão da conta de armazenamento. Embora as conexões ainda utilizem segredos compartilhados, o Key Vault oferece um nível maior de segurança para seus segredos, incluindo manutenção e rotação de chaves. Seu aplicativo pode se conectar ao Key Vault usando identidades gerenciadas, mesmo quando o serviço ainda não suporta conexões baseadas em identidade gerenciada.
Quando você usa o Key Vault, crie a configuração do aplicativo para a conexão usando uma referência do Key Vault em vez do segredo real. Para mais informações, veja as configurações do aplicativo Source no Key Vault.
Tenha essas considerações em mente ao manter conexões no Key Vault:
Para acessar as chaves no cofre, você deve conceder uma identidade no seu app para acessar seu cofre de chaves.
Você pode usar o Key Vault para armazenar configurações para suas conexões baseadas em identidade gerenciada. Quando seu aplicativo usa o Key Vault, as referências devem usar um separador de chave de
:ou/, comoStorage1:blobServiceUri. Quando você usa o delimitador de configuração do aplicativo regular de__, os nomes de referência não são resolvidos corretamente.
Você pode configurar a configuração AzureWebJobsStorage para retornar uma referência do Key Vault contendo a cadeia de conexão, em vez de retornar a própria cadeia de conexão. Para saber como, veja Usar referências do Key Vault como configurações do app.
O Arquivos do Azure atualmente não suporta conexões de identidade gerenciada. Por causa dessa limitação, use o Key Vault para proteger a WEBSITE_AZUREFILESCONNECTIONSTRING configuração, que é necessária para escalonamento dinâmico tanto pelos planos Consumption quanto Premium. O plano Flex Consumption também é um plano dinâmico que não usa Arquivos do Azure e suporta totalmente conexões de identidade gerenciada.
Cuidado
Evite trabalhar diretamente com segredos compartilhados. Sempre que possível, use um método de autenticação mais seguro para suas conexões.
Mitigue os riscos potenciais de perda ou comprometimento de segredos usando identidades gerenciadas com autenticação Microsoft Entra ID. Quando o serviço remoto não suporta identidades gerenciadas, pelo menos use o Azure Key Vault, que mantém segredos compartilhados de forma mais segura.
Se por algum motivo você não puder usar um método de autenticação mais seguro, a plataforma criptografa os dados nas configurações da sua aplicação enquanto está em repouso. Migre seus aplicativos do uso de segredos compartilhados para um método de autenticação mais seguro o quanto antes.
Defina a cadeia de conexão para a conta de armazenamento padrão na configuração AzureWebJobsStorage. Essa configuração é o comportamento padrão de conexão quando você cria seu aplicativo de função.
Gerenciar conexões de clientes SDK
Quando você cria suas próprias conexões de SDK cliente em código de função, sempre reutilize instâncias cliente entre invocações em vez de criar novas. Essa melhor prática em todos os planos de hospedagem reduz a latência, evita o esgotamento dos sockets e melhora a eficiência dos recursos.
Reutilizar instâncias de cliente
Siga estas diretrizes ao usar um cliente específico de serviço em uma aplicação Azure Functions:
- Não crie um novo cliente a cada invocação de função.
- Crie um cliente único e compartilhado que toda invocação de função possa reutilizar.
- Considere criar um único cliente compartilhado em uma classe auxiliar se diferentes funções usarem o mesmo serviço.
A abordagem recomendada depende da sua linguagem:
Use injeção de dependência para registrar clientes singleton ou de escopo.
Veja exemplos de código cliente para padrões completos em cada linguagem.
Limites de conexão em um plano de consumo
Observação
Os limites de conexão rígida descritos nesta seção se aplicam apenas ao plano de Consumo legado. O Flex Consumption plan não é executado no mesmo ambiente de sandbox e não impõe esses limites. No entanto, a reutilização de clientes ainda é recomendada em todos os planos para obter o melhor desempenho.
No plano de Consumo legado, aplicativos funcionais são executados em um ambiente de área restrita que limita o número de conexões de saída a 600 ativas (1.200 no total) por instância. Quando você atinge esse limite, o host de Funções escreve a seguinte mensagem nos logs: Host thresholds exceeded: Connections. Para saber mais, confira Limites do serviço do Functions.
Esse limite é por instância. Quando o controlador de escala adiciona instâncias do aplicativo de funções para lidar com mais solicitações, cada instância tem um limite de conexão independente. Isso significa que não há limite global de conexão, e você pode ter mais de 600 conexões ativas em todas as instâncias ativas.
Ao resolver problemas de conexão, certifique-se de que o Application Insights esteja ativado para o seu aplicativo funcional. Application Insights permite exibir métricas para seus aplicativos de funções, como execuções. Para obter mais informações, consulte Exibir telemetria no Application Insights.
Exemplos de código do cliente
Esta seção demonstra as melhores práticas para criar e usar clientes de seu código de função.
Solicitações HTTP
Registre um HttpClient compartilhado usando injeção de dependência para que todas as invocações de funções reutilizem a mesma instância. Nesse caso, você não precisa descartar o cliente porque o tempo de execução gerencia sua vida útil.
using Microsoft.Azure.Functions.Extensions.DependencyInjection;
using Microsoft.Extensions.DependencyInjection;
[assembly: FunctionsStartup(typeof(MyNamespace.Startup))]
namespace MyNamespace;
public class Startup : FunctionsStartup
{
public override void Configure(IFunctionsHostBuilder builder)
{
builder.Services.AddHttpClient();
}
}
Então injete IHttpClientFactory ou HttpClient na sua classe de função:
using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.Logging;
namespace MyNamespace;
public class MyFunction(HttpClient httpClient, ILogger<MyFunction> logger)
{
[Function("MyFunction")]
public async Task Run([TimerTrigger("0 */5 * * * *")] TimerInfo timer)
{
var response = await httpClient.GetAsync("https://example.com");
logger.LogInformation("Response status: {Status}", response.StatusCode);
}
}
Azure Cosmos DB clients
Registre um CosmosClient único na sua startup para que todas as funções compartilhem uma única conexão. A documentação do Azure Cosmos DB recomenda que você use um cliente singleton durante toda a vida útil da sua aplicação.
using Microsoft.Azure.Cosmos;
using Microsoft.Azure.Functions.Extensions.DependencyInjection;
using Microsoft.Extensions.DependencyInjection;
[assembly: FunctionsStartup(typeof(MyNamespace.Startup))]
namespace MyNamespace;
public class Startup : FunctionsStartup
{
public override void Configure(IFunctionsHostBuilder builder)
{
builder.Services.AddSingleton(_ =>
{
var connectionString = Environment.GetEnvironmentVariable("CosmosDBConnection");
return new CosmosClient(connectionString);
});
}
}
Depois, injete CosmosClient na sua classe de função:
using Microsoft.Azure.Cosmos;
using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.Logging;
namespace MyNamespace;
public class MyCosmosFunction(CosmosClient cosmosClient, ILogger<MyCosmosFunction> logger)
{
private readonly Container _container = cosmosClient.GetContainer("mydb", "mycontainer");
[Function("MyCosmosFunction")]
public async Task Run([TimerTrigger("0 */5 * * * *")] TimerInfo timer)
{
var item = new { id = "myId", partitionKey = "myPartitionKey", data = "example" };
await _container.UpsertItemAsync(item, new PartitionKey("myPartitionKey"));
logger.LogInformation("Item upserted");
}
}
Conexões SqlClient
O código de função pode usar o Provedor de Dados .NET Framework para SQL Server (SqlClient) para fazer conexões com um Banco de Dados SQL relacional. Esse provedor também é o fornecedor subjacente para frameworks de dados que dependem do ADO.NET, como o Entity Framework. Ao contrário das conexões HttpClient e DocumentClient, o ADO.NET implementa o pool de conexões por padrão. No entanto, como você ainda pode ficar sem conexões, é necessário otimizar as conexões com o banco de dados. Para obter mais informações, consulte Pool de Conexões do SQL Server (ADO.NET).
Dica
Algumas estruturas de dados, como Entity Framework, normalmente obtêm cadeias de conexão da seção ConnectionStrings de um arquivo de configuração. Nesse caso, é necessário adicionar explicitamente as cadeias de conexão de banco de dados SQL à coleção Cadeias de conexão das configurações de aplicativo de funções e no local.settings.json file no projeto local. Se você está criando uma instância de SqlConnection no seu código de função, armazene o valor da cadeia de conexão nas configurações do aplicativo junto com suas outras conexões.
Configuração de Aplicativos do Azure
Configuração de Aplicativos do Azure é um serviço do Azure que você pode usar para gerenciar centralmente as configurações de aplicação. O App Configuration suporta pares hierárquicos chave-valor e versionamento, e integra-se ao Azure Key Vault para um gerenciamento de segredos mais seguro. Para obter mais informações, consulte o que é a Configuração de Aplicativos do Azure?
Para melhorar a segurança, seu aplicativo de funções utiliza identidades gerenciadas com autenticação Microsoft Entra para acessar as configurações em uma App Store. Para obter mais informações, consulte Usar referências de Configuração de Aplicativos do Azure Functions.
Observação
Ao usar o Configuração de Aplicativos do Azure para armazenar configurações de conexões baseadas em identidade gerenciada, as referências devem usar um separador de chave de : ou / no formato <CONNECTION_NAME_PREFIX>:fullyQualifiedNamespace. Quando você usa o delimitador de configuração do aplicativo regular de __, os nomes de referência não são resolvidos corretamente.
Conteúdo relacionado
Usar conectores no Azure Functions – Conecte-se a serviços como Office 365, Teams e SharePoint usando conectores gerenciados com OAuth integrado e manuseio de webhooks.
Para obter mais informações sobre por que se deve usar clientes estáticos, consulte Antipadrão de instanciação inadequada.
Para obter mais dicas de desempenho do Azure Functions, consulte Melhore o desempenho e a confiabilidade do Azure Functions.