Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
As chaves de acesso das Functions são tokens de autenticação que o runtime das Functions utiliza para proteger endpoints acionados via HTTP. Quando um chamador invoca uma função HTTP, inclui uma chave como um ?code= parâmetro de consulta ou como um x-functions-key cabeçalho. O runtime valida a chave e autoriza ou rejeita o pedido.
As chaves de acesso não são o mesmo que segredos ao nível de uma aplicação. As chaves de acesso protegem quem pode chamar as suas funções, enquanto os segredos ao nível da aplicação protegem aquilo a que as suas funções se ligam.
Quando usar chaves de acesso
| Scenario | Porque é que as chaves de acesso encaixam |
|---|---|
| Webhooks de terceiros | Fornecedores como o GitHub, o Stripe ou o Twilio chamam a sua função através de uma URL e um segredo. As teclas de acesso encaixam diretamente no ?code= padrão que esperam. |
| Chamadas entre serviços | O serviço backend A chama a Função B por HTTP. Uma chave partilhada é mais simples do que configurar registos de aplicações Microsoft Entra apenas para chamadas internas. |
| Assinaturas do Event Grid | O Event Grid valida e chama o endpoint da sua função usando uma chave do sistema que a plataforma gere automaticamente. |
| Autenticação de desenvolvimento/teste | Durante o desenvolvimento, é necessário autenticação básica sem configurar o OAuth/OIDC completo. As chaves de acesso fornecem uma porta de autenticação de baixa fricção sem configuração de identidade. |
| Compatibilidade de migração | As aplicações existentes do Funções do Azure já usam chaves de acesso. Ao migrar para Aplicações de Contentor, precisa da mesma autenticação baseada em chave para evitar interrupções nas chamadas. |
Note
Para APIs voltadas para utilizadores, cargas de trabalho zero-trust ou cenários de autorização por utilizador, use Microsoft Entra ID / OAuth 2.0 em vez de chaves de acesso. As chaves de acesso são segredos partilhados sem registo de auditoria a nível de identidade.
Pré-requisitos
- Uma conta do Azure com uma assinatura ativa. Cria uma conta gratuitamente.
- CLI do Azure versão 2.40.0 ou superior.
- Uma aplicação Funções do Azure existente nas Aplicações Container ou permissões para criar uma.
Tipos de chaves de acesso
O runtime das Funções gere quatro tipos de chaves:
| Tipo de chave | Scope | Purpose |
|---|---|---|
Chave mestra (_master) |
Aplicação de funções completas | Acesso ao nível de administrador a todas as funções e /admin/* endpoints de gestão. Não pode ser revogado, apenas rotacionado. |
Chaves de host (default + personalizadas) |
Aplicação de funções completas | Autorize chamadas para qualquer função ativada por HTTP na aplicação. |
Teclas de função (default + personalizadas) |
Função única | Autorizar chamadas para uma função específica. Proporciona um controlo mais granular do que as chaves host. |
| Chaves de sistema | Pontos de extremidade de extensão | Utilizado por extensões de plataforma como subscrições de webhook Event Grid e Durable Functions. Gerido automaticamente. |
Escolha um backend de armazenamento
Defina a variável de ambiente AzureWebJobsSecretStorageType para controlar onde o runtime persiste as chaves de acesso. Azure Container Apps suporta três backends de grau de produção.
| Back-end | Valor de configuração | Gera automaticamente chaves | Dependência externa | Melhor para |
|---|---|---|---|---|
| Armazenamento secreto de Aplicações de Contentores | containerapps |
Não - provisionas chaves como segredos das Aplicações Container | None | A maioria das cargas de trabalho (Recomendado) |
| Azure Key Vault | keyvault |
Não - criar disparador manualmente | Instância de Key Vault | Governação centralizada, auditoria de conformidade |
| Armazenamento de Blobs do Azure | blob |
Sim | Conta de armazenamento | Aplicações legadas ou conta existente AzureWebJobsStorage |
Tenha em mente estas considerações de backend:
- O tempo de execução não seleciona automaticamente o armazenamento secreto das Aplicações Container. Se não definir
AzureWebJobsSecretStorageTypeou definir para um valor não reconhecido, o anfitrião de Funções usa Armazenamento de Blobs quandoAzureWebJobsStorageestá disponível. - Mantenha
AzureWebJobsStoragea configuração para verificações de saúde do armazenamento e funcionalidades dependentes do armazenamento. - Não definas
AzureWebJobsSecretStorageTypeparafiles. O sistema de ficheiros Container Apps é efémero, por isso as chaves armazenadas neste backend são perdidas quando a aplicação escala para zero, reinicia ou implementa uma nova revisão.
Padrões secretos de nomes
A convenção de nomenclatura para chaves armazenadas depende do backend de armazenamento.
- Armazenamento secreto de Aplicações de Contentores
- Key Vault (serviço de armazenamento de chaves)
- Armazenamento de Blobs
A loja secreta Container Apps usa uma convenção diferente. O host das Functions lê as chaves a partir de ficheiros montados em volume em /run/secrets/functions-keys/. Cada ficheiro usa um nome pontilhado (por exemplo, host.master), mas os nomes secretos das Aplicações de Contentor só permitem caracteres alfanuméricos minúsculos e traços. Quando monta um volume secreto, deve definir explicitamente o path campo para o nome do ficheiro pontilhado que o anfitrião Functions espera (por exemplo, secretRef: host-master → path: host.master). A plataforma não realiza qualquer tradução automática de nomes.
| Tipo de chave | Nome secreto das Aplicações Container (traços) | Montagem path de volume (dots) |
|---|---|---|
| Chave mestra | host-master |
host.master |
| Chave padrão de host | host-function-default |
host.function.default |
| Chave de host personalizada | host-function-<name> |
host.function.<name> |
| Tecla de função padrão para uma função específica | functions-<functionname>-default |
functions.<functionName>.default |
| Tecla 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> |
Sugestão
Ao fazer a resolução de problemas, procure estes padrões na sua loja backend para verificar se as chaves estão configuradas corretamente.
Configurar a loja secreta Container Apps
A loja secreta Container Apps é o backend recomendado. As chaves permanecem dentro da plataforma Container Apps e não requerem armazenamento externo nem Key Vault. Os registos de atividade do Azure Resource Manager acompanham alterações a segredos e variáveis de ambiente.
Com este backend, o host Functions lê chaves de ficheiros montados em volumes em /run/secrets/functions-keys/. O anfitrião não gera automaticamente as chaves. Deve criar cada chave como um segredo de Aplicações de Contentores, e a plataforma monta-os como ficheiros para o host ler.
Importante
A loja secreta de Container Apps é só de leitura do ponto de vista do anfitrião. O host lê os ficheiros de chave montados, mas nunca escreve neles. Se falta uma chave necessária, o anfitrião não a gera automaticamente.
Passo 1: Definir o tipo de armazenamento
- Portal
- CLI do Azure
Acede à tua aplicação de contêiner de Funções no portal Azure.
Em Definições, selecione variáveis de Ambiente.
Selecione Adicionar e introduza os seguintes valores:
Property Value Nome AzureWebJobsSecretStorageTypeValue containerappsSelecione Guardar e depois selecione Aplicar para confirmar as alterações.
Passo 2: Gerar e armazenar segredos da chave de acesso
Gerar valores-chave e armazená-los como segredos das Apps Container. No mínimo, precisas da chave mestra e de uma chave host padrão.
- Portal
- CLI do Azure
Na tua aplicação contentor de Funções, em Definições, seleciona Segredos.
Selecione Adicionar e insira os seguintes valores:
Property Value Nome host-masterType Segredo de Container Apps Value Um valor-chave gerado aleatoriamente. Selecione Adicionar.
Repete para
host-function-defaultcom outro valor gerado aleatoriamente.Para adicionar uma tecla por função, adicione um segredo chamado
functions-<functionname>-default(tudo em minúsculas).
Note
Os nomes secretos das Aplicações Container só permitem caracteres alfanuméricos minúsculos e traços. Deve definir explicitamente o campo path na configuração do volume para o nome do ficheiro pontilhado que o host Functions espera (por exemplo, secretRef: host-master → path: host.master). Sem uma indicação explícita path, o ficheiro no disco mantém o nome tracejado e o anfitrião Functions não encontra a chave.
Passo 3: Configurar a montagem do volume
Monte os segredos como ficheiros em /run/secrets/functions-keys/.
- Portal
- CLI do Azure
Na tua aplicação contentor de Funções, em Aplicação, seleciona Revisões e réplicas.
Selecione Criar nova revisão.
No separador Escala e volumes , em Volumes, selecione Adicionar.
Insira os seguintes valores:
Property Value Tipo de volume Segredo Nome functions-keysPara cada segredo, defina o campo Path para o nome do ficheiro pontilhado que o anfitrião Functions espera (por exemplo, defina
host-masterpara pathhost.master, ehost-function-defaultpara pathhost.function.default).Selecione Adicionar.
No separador Contentor , selecione o seu contentor e depois selecione Editar.
Selecione a aba montagens de volume e selecione Adicionar.
Insira os seguintes valores:
Property Value Nome do volume functions-keysCaminho de montagem /run/secrets/functions-keysSelecione Guardar e depois selecione Criar para implementar a nova revisão.
Passo 4: Verificar
Depois de a aplicação reiniciar, confirme que as teclas estão a funcionar:
az containerapp function keys list \
--resource-group "<RESOURCE_GROUP>" \
--name "<FUNCTIONS_APP_NAME>" \
--key-type hostKey
Também pode verificar os registos da app para a mensagem Resolved secret storage provider ContainerAppsSecretsRepository, que confirma que o anfitrião está a usar a loja secreta Container Apps.
Rodar teclas
Para rodar uma chave criptográfica, atualize o segredo das Aplicações Container e reinicie a aplicação.
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 partilham os mesmos segredos montados. Após um reinício, cada réplica capta os valores-chave atualizados.
Configure o Key Vault ou Armazenamento de Blobs como a loja
O backend do Key Vault armazena as chaves de acesso como segredos do Key Vault, proporcionando auditoria e controlo de acesso de nível empresarial.
Crie um Key Vault (se não tiver um):
az keyvault create \ --name "<KEYVAULT_NAME>" \ --resource-group "<RESOURCE_GROUP>" \ --location "<LOCATION>"Ative a identidade gerida na sua aplicação de contentores (se ainda não estiver ativada):
az containerapp identity assign \ --resource-group "<RESOURCE_GROUP>" \ --name "<FUNCTIONS_APP_NAME>" \ --system-assignedConceda o papel de Oficial de Segredos do Cofre de Chaves à identidade gerida. O runtime necessita de acesso de leitura e escrita para criar e gerir 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 o URI do Key Vault:
Para a identidade atribuída ao 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 utilizador, defina também o 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>"Desencadear a criação de chaves ao listar chaves:
az containerapp function keys list \ --resource-group "<RESOURCE_GROUP>" \ --name "<FUNCTIONS_APP_NAME>" \ --key-type hostKey
Gerir chaves de acesso
Independentemente do backend, use os seguintes comandos para listar, criar e eliminar chaves de acesso:
Note
Mantenha pelo menos uma réplica a funcionar para realizar estas operações de gestão de chaves.
Liste todas as chaves do anfitrião:
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 masterKeyCriar ou sobrescrever 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 hostKeyMostrar uma tonalidade específica:
az containerapp function keys show \ --resource-group "<RESOURCE_GROUP>" \ --name "<FUNCTIONS_APP_NAME>" \ --key-name "<KEY_NAME>" \ --key-type hostKeyEliminar uma chave de anfitrião:
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
Passa a chave como parâmetro de consulta ou cabeçalho de pedido.
# 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>"