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.
As chaves de acesso do Functions são tokens de autenticação que o runtime Functions usa para proteger endpoints acionados por HTTP. Quando um chamador invoca uma função HTTP, ela inclui uma chave como um ?code= parâmetro de consulta ou um x-functions-key cabeçalho. O runtime valida a chave e autoriza ou rejeita a solicitação.
As chaves de acesso não são iguais aos segredos no nível do aplicativo. As chaves de acesso protegem quem pode chamar as suas funções, enquanto os segredos no nível do aplicativo protegem ao que suas funções se conectam.
Quando usar chaves de acesso
| Scenario | Por que as chaves de acesso se encaixam |
|---|---|
| Webhooks de terceiros | Provedores como GitHub, Stripe ou Twilio chamam sua função por meio de uma URL e um segredo. As chaves de acesso são inseridas diretamente no padrão ?code= que eles esperam. |
| Chamadas de serviço a serviço | O serviço de back-end A chama a Função B por HTTP. Uma chave compartilhada é mais simples do que configurar registros de aplicativo Microsoft Entra para chamadas exclusivamente internas. |
| Assinaturas do Event Grid | Event Grid valida e chama seu endpoint de função usando uma chave de sistema que a plataforma gerencia automaticamente. |
| Autenticação de desenvolvimento/teste | Durante o desenvolvimento, você precisa de autenticação básica sem configurar o OAuth/OIDC completo. As chaves de acesso fornecem uma porta de autenticação de baixo atrito sem configuração de identidade. |
| Compatibilidade de migração | Os aplicativos Azure Functions existentes já usam chaves de acesso. Ao migrar para os Aplicativos de Contêiner, você precisa da mesma autenticação baseada em chave para evitar a interrupção dos chamadores. |
Note
Para APIs voltadas para o usuário, cargas de trabalho de confiança zero ou cenários de autorização por usuário, use Microsoft Entra ID/OAuth 2.0 em vez de chaves de acesso. As chaves de acesso são segredos compartilhados sem trilha de auditoria no nível da identidade.
Pré-requisitos
- Uma conta do Azure com uma assinatura ativa. Crie uma conta gratuitamente.
- CLI do Azure versão 2.40.0 ou superior.
- Um aplicativo do Azure Functions existente no Aplicativos de Contêiner ou permissões para criar um.
Tipos de chave de acesso
O runtime do Functions gerencia quatro tipos de chaves:
| Tipo de chave | Scope | Purpose |
|---|---|---|
Chave mestra (_master) |
Aplicativo de função completo | Acesso no nível do administrador a todas as funções e /admin/* pontos de extremidade de gerenciamento. Não pode ser revogado, apenas rotacionado. |
Chaves de host (default + personalizadas) |
Aplicativo de função completo | Autorize chamadas para qualquer função disparada por HTTP no aplicativo. |
Teclas de função (default + personalizadas) |
Função única | Autorizar chamadas para uma função específica. Fornece um controle mais granular do que as chaves de host. |
| Chaves do sistema | Pontos de extremidade de extensão | Usado por extensões de plataforma, como as assinaturas de webhook do Event Grid e Durable Functions. Gerenciado automaticamente. |
Escolher um back-end de armazenamento
Defina a variável de ambiente AzureWebJobsSecretStorageType para controlar onde o runtime persiste as chaves de acesso. Aplicativos de Contêiner do Azure dá suporte a três back-ends de nível de produção.
| Back-end | Valor de configuração | Gera chaves automaticamente | Dependência externa | Mais indicado para |
|---|---|---|---|---|
| Repositório secreto de Aplicativos de Contêiner | containerapps |
Não, você faz a provisão das chaves como os segredos de Aplicativos de Contêiner | None | A maioria das workloads (recomendado) |
| Azure Key Vault | keyvault |
Não – acionar a criação manualmente | Instância do Key Vault | Governança centralizada, auditoria de conformidade |
| Armazenamento de Blobs do Azure | blob |
Yes | Conta de armazenamento | Aplicativos herdados ou conta existente AzureWebJobsStorage |
Tenha em mente essas considerações do backend:
- O runtime não seleciona automaticamente o armazenamento secreto dos Apps de Contêineres. Se você não definir
AzureWebJobsSecretStorageTypeou definir como um valor não reconhecido, o host de Funções usa Armazenamento de Blobs quandoAzureWebJobsStorageestá disponível. - Mantenha
AzureWebJobsStoragea configuração para verificações de saúde do armazenamento e recursos dependentes do armazenamento. - Não defina
AzureWebJobsSecretStorageTypecomofiles. O sistema de arquivos Container Apps é efêmero, então as chaves armazenadas nesse backend são perdidas quando o app escala para zero, reinicia ou implanta uma nova revisão.
Padrões de nome secreto
A convenção de nomenclatura para chaves armazenadas depende do back-end de armazenamento.
O repositório secreto de Aplicativos de Contêiner usa uma convenção diferente. O host do Functions lê chaves de arquivos montados em volume em /run/secrets/functions-keys/. Cada arquivo usa um nome pontilhado (por exemplo), host.mastermas os nomes secretos dos Aplicativos de Contêiner permitem apenas caracteres alfanuméricos minúsculos e traços. Ao montar um volume secreto, você deve definir explicitamente o path campo como o nome do arquivo pontilhado que o host do Functions espera (por exemplo, secretRef: host-master → path: host.master). A plataforma não executa nenhuma tradução automática de nome.
| Tipo de chave | Nome do segredo dos Aplicativos de Contêiner (traços) | Montagem de volumes path (pontuações) |
|---|---|---|
| Chave mestra | host-master |
host.master |
| Chave de host padrão | host-function-default |
host.function.default |
| Chave de host personalizada | host-function-<name> |
host.function.<name> |
| Chave de função padrão para uma função específica | functions-<functionname>-default |
functions.<functionName>.default |
| Chave de função personalizada para uma função específica | functions-<functionname>-<keyname> |
functions.<functionName>.<keyName> |
| Chave do sistema | host-systemkey-<extension> |
host.systemKey.<extension> |
Dica
Ao solucionar problemas, pesquise esses padrões no repositório de back-end para verificar se as chaves estão configuradas corretamente.
Configurar o repositório secreto de Aplicativos de Contêiner
O repositório secreto de Aplicativos de Contêiner é o back-end recomendado. As chaves permanecem dentro da plataforma de Aplicativos de Contêiner e não exigem armazenamento externo ou Key Vault. Os logs de atividade do Azure Resource Manager acompanham as alterações em segredos e as variáveis de ambiente.
Com esse back-end, o host do Functions lê chaves de arquivos montados em volume em /run/secrets/functions-keys/. O host não gera chaves automaticamente. Você deve criar cada chave como um segredo dos Aplicativos de Contêiner e a plataforma as monta como arquivos para o host ler.
Importante
O repositório secreto de Aplicativos de Contêiner é somente leitura da perspectiva do host. O host lê os arquivos de chave montados, mas nunca grava neles. Se uma chave necessária estiver ausente, o host não a gerará automaticamente.
Etapa 1: Definir o tipo de armazenamento
Acesse seu aplicativo de contêiner do Functions no Azure portal.
Em Configurações, selecione Variáveis de ambiente.
Selecione Adicionar e insira os seguintes valores:
Property Valor Nome AzureWebJobsSecretStorageTypeValor containerappsSelecione Salvar e, em seguida, selecione Aplicar para confirmar as alterações.
Etapa 2: Gerar e armazenar segredos de chave de acesso
Gere valores de chave e armazene-os como segredos dos Aplicativos de Contêiner. No mínimo, você precisa da chave mestra e de uma chave de host padrão.
Em seu aplicativo de contêiner do Functions, em Configurações, selecione Segredos.
Selecione Adicionar e insira os seguintes valores:
Property Valor Nome host-masterType Segredo dos Aplicativos de Contêiner Valor Um valor de chave gerado aleatoriamente. Selecione Adicionar.
Repita para
host-function-defaultcom outro valor gerado aleatoriamente.Para adicionar uma chave por função, adicione um segredo chamado
functions-<functionname>-default(todas minúsculas).
Note
Os nomes de segredo dos Aplicativos de Contêiner permitem apenas caracteres alfanuméricos minúsculos e traços. Você deve definir explicitamente o campo path na configuração do volume para o nome de arquivo com pontos que o host do Functions espera (por exemplo, secretRef: host-master → path: host.master). Sem um explícito path, o arquivo no disco retém o nome tracejado e o host do Functions não encontrará a chave.
Etapa 3: configurar o ponto de montagem do volume
Monte os segredos como arquivos em /run/secrets/functions-keys/.
Em seu aplicativo de contêiner do Functions, em Aplicativo, selecione Revisões e réplicas.
Selecione Criar nova revisão.
Na guia Escala e volumes , em Volumes, selecione Adicionar.
Insira os valores a seguir:
Property Valor Tipo de volume Segredo Nome functions-keysPara cada segredo, defina o campo Caminho como o nome do arquivo pontilhado que o host do Functions espera (por exemplo, definido
host-mastercomo caminhohost.masterehost-function-defaultcaminhohost.function.default).Selecione Adicionar.
Na guia Contêiner , selecione seu contêiner e, em seguida, selecione Editar.
Selecione a guia Montagens de volume e selecione Adicionar.
Insira os valores a seguir:
Property Valor Nome do volume functions-keysCaminho de montagem /run/secrets/functions-keysSelecione Salvar e, em seguida, selecione Criar para implantar a nova revisão.
Etapa 4: Verificar
Depois que o aplicativo for reiniciado, confirme se as chaves estão funcionando:
az containerapp function keys list \
--resource-group "<RESOURCE_GROUP>" \
--name "<FUNCTIONS_APP_NAME>" \
--key-type hostKey
Você também pode verificar os logs do aplicativo para a mensagem Resolved secret storage provider ContainerAppsSecretsRepository, o que confirma que o host está usando o repositório secreto de Aplicativos de Contêiner.
Girar chaves
Para girar uma chave, atualize o segredo dos Aplicativos de Contêiner e reinicie o aplicativo:
NEW_KEY=$(openssl rand -hex 32)
az containerapp secret set \
--resource-group "<RESOURCE_GROUP>" \
--name "<FUNCTIONS_APP_NAME>" \
--secrets "host-function-default=$NEW_KEY"
az containerapp revision restart \
--resource-group "<RESOURCE_GROUP>" \
--name "<FUNCTIONS_APP_NAME>" \
--revision "<REVISION_NAME>"
Note
Todas as réplicas compartilham os mesmos segredos montados. Após uma reinicialização, cada réplica obtém os valores das chaves atualizados.
Configure o Key Vault ou Armazenamento de Blobs como o store
O back-end do Key Vault armazena as chaves de acesso como os segredos do Key Vault, fornecendo auditoria de padrão corporativo e controle de acesso.
Crie um Key Vault (se você não tiver um):
az keyvault create \ --name "<KEYVAULT_NAME>" \ --resource-group "<RESOURCE_GROUP>" \ --location "<LOCATION>"Habilitar a identidade gerenciada em seu aplicativo de contêiner (se ainda não estiver habilitado):
az containerapp identity assign \ --resource-group "<RESOURCE_GROUP>" \ --name "<FUNCTIONS_APP_NAME>" \ --system-assignedConceda a função Key Vault Secrets Officer à identidade gerenciada. O runtime precisa de acesso de leitura e gravação para criar e gerenciar chaves:
PRINCIPAL_ID=$(az containerapp show \ --resource-group "<RESOURCE_GROUP>" \ --name "<FUNCTIONS_APP_NAME>" \ --query identity.principalId \ --output tsv) KEYVAULT_ID=$(az keyvault show \ --name "<KEYVAULT_NAME>" \ --query id \ --output tsv) az role assignment create \ --role "Key Vault Secrets Officer" \ --assignee "$PRINCIPAL_ID" \ --scope "$KEYVAULT_ID"Defina o tipo de armazenamento e Key Vault URI:
Para identidade atribuída pelo sistema:
az containerapp update \ --resource-group "<RESOURCE_GROUP>" \ --name "<FUNCTIONS_APP_NAME>" \ --set-env-vars \ "AzureWebJobsSecretStorageType=keyvault" \ "AzureWebJobsSecretStorageKeyVaultUri=https://<KEYVAULT_NAME>.vault.azure.net"Para a identidade atribuída pelo usuário, defina também a ID do cliente:
az containerapp update \ --resource-group "<RESOURCE_GROUP>" \ --name "<FUNCTIONS_APP_NAME>" \ --set-env-vars \ "AzureWebJobsSecretStorageType=keyvault" \ "AzureWebJobsSecretStorageKeyVaultUri=https://<KEYVAULT_NAME>.vault.azure.net" \ "AzureWebJobsSecretStorageKeyVaultClientId=<USER_ASSIGNED_IDENTITY_CLIENT_ID>"Iniciar a criação de chaves listando-as:
az containerapp function keys list \ --resource-group "<RESOURCE_GROUP>" \ --name "<FUNCTIONS_APP_NAME>" \ --key-type hostKey
Gerenciar chaves de acesso
Independentemente do back-end, use os seguintes comandos para listar, criar e excluir chaves de acesso:
Note
Mantenha pelo menos uma réplica ativa para realizar essas operações de gerenciamento de chaves.
Liste todas as chaves de host:
az containerapp function keys list \ --resource-group "<RESOURCE_GROUP>" \ --name "<FUNCTIONS_APP_NAME>" \ --key-type hostKeyListe a chave mestra:
az containerapp function keys list \ --resource-group "<RESOURCE_GROUP>" \ --name "<FUNCTIONS_APP_NAME>" \ --key-type masterKeyCrie ou substitua uma chave de host personalizada:
az containerapp function keys set \ --resource-group "<RESOURCE_GROUP>" \ --name "<FUNCTIONS_APP_NAME>" \ --key-name "MyCustomKey" \ --key-value "<YOUR_KEY_VALUE>" \ --key-type hostKeyMostre uma tonalidade específica:
az containerapp function keys show \ --resource-group "<RESOURCE_GROUP>" \ --name "<FUNCTIONS_APP_NAME>" \ --key-name "<KEY_NAME>" \ --key-type hostKeyExclua uma chave de host:
az containerapp function keys delete \ --resource-group "<RESOURCE_GROUP>" \ --name "<FUNCTIONS_APP_NAME>" \ --key-name "MyCustomKey" \ --key-type hostKey
Chamar uma função com uma chave de acesso
Passe a chave como um parâmetro de consulta ou cabeçalho de solicitação.
# Query parameter
curl "https://<FUNCTIONS_APP_URL>/api/<FUNCTION_NAME>?code=<HOST_KEY>"
# Header
curl "https://<FUNCTIONS_APP_URL>/api/<FUNCTION_NAME>" \
-H "x-functions-key: <HOST_KEY>"