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. |
Padrões secretos de nomes
A convenção de nomenclatura para chaves armazenadas depende do backend de armazenamento.
Cofre de Chaves
O backend Key Vault armazena cada chave como um segredo individual de Key Vault usando uma convenção de duplo hífen (--):
| Tipo de chave | Padrão secreto de nomes | Example |
|---|---|---|
| Chave mestra | host--masterKey--master |
host--masterKey--master |
| Tecla de função (por defeito) | host--functionKey--default |
host--functionKey--default |
| Tecla de função (personalizada) | host--functionKey--<name> |
host--functionKey--MyApiClient |
| Chave do sistema | host--systemKey--<extension> |
host--systemKey--eventgrid_extension |
| Chave por função | function--<functionName>--<keyName> |
function--myhttpfunc--default |
Armazenamento de Blobs
O backend Armazenamento de Blobs armazena chaves como ficheiros JSON no contentor de blob azure-webjobs-secrets. Todas as chaves ao nível do host (mestre, chaves de função e chaves do sistema) são armazenadas juntas numa única host.json bolha. As chaves por função são armazenadas em blobs separados nomeados em referência a cada função.
| Caminho do blob | Índice |
|---|---|
<siteSlotName>/host.json |
ficheiro JSON contendo masterKey, functionKeys, e systemKeys |
<siteSlotName>/<functionName>.json |
ficheiro JSON contendo chaves para uma função específica |
Armazenamento secreto de Aplicações de Contentores
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.
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.
Importante
Para cargas de produção, prefira backends nesta ordem: Container Apps secret store (containerapp) > Azure Key Vault (keyvault) > Armazenamento de Blobs do Azure (blob). A loja secreta Container Apps não tem dependências externas e é a mais simples de operar.
| Back-end | Valor de configuração | Gera automaticamente chaves | Dependência externa | Melhor para |
|---|---|---|---|---|
| Armazenamento secreto de Aplicações de Contentores | containerapp |
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 |
Advertência
Não definas AzureWebJobsSecretStorageType para files. No Azure Container Apps, o sistema de ficheiros é efémero, por isso as chaves de host armazenadas no backend files são perdidas sempre que a aplicação escala para zero, reinicia ou lança uma nova revisão. Use sempre um dos três backends de produção listados acima.
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
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 containerappSelecione 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.
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/.
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.
Configurar Armazenamento de Blob (Armazenamento de Blobs)
O backend do Armazenamento de Blobs permite ao runtime gerar e gerir automaticamente chaves de acesso. Use esta opção quando já tiver uma conta AzureWebJobsStorage de armazenamento e não precisar de governação centralizada.
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 a função Contribuidor de Dados do Blob de Armazenamento na conta de armazenamento à identidade gerida:
PRINCIPAL_ID=$(az containerapp show \ --resource-group "<RESOURCE_GROUP>" \ --name "<FUNCTIONS_APP_NAME>" \ --query identity.principalId \ --output tsv) STORAGE_ID=$(az storage account show \ --name "<STORAGE_ACCOUNT_NAME>" \ --resource-group "<RESOURCE_GROUP>" \ --query id \ --output tsv) az role assignment create \ --role "Storage Blob Data Contributor" \ --assignee "$PRINCIPAL_ID" \ --scope "$STORAGE_ID"Defina o tipo de armazenamento:
az containerapp update \ --resource-group "<RESOURCE_GROUP>" \ --name "<FUNCTIONS_APP_NAME>" \ --set-env-vars "AzureWebJobsSecretStorageType=blob"O runtime gera as chaves automaticamente no próximo arranque a frio. Verificar:
az containerapp function keys list \ --resource-group "<RESOURCE_GROUP>" \ --name "<FUNCTIONS_APP_NAME>" \ --key-type hostKey
Configurar Cofre de Chaves
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:
# List all host keys
az containerapp function keys list \
--resource-group "<RESOURCE_GROUP>" \
--name "<FUNCTIONS_APP_NAME>" \
--key-type hostKey
# List the master key
az containerapp function keys list \
--resource-group "<RESOURCE_GROUP>" \
--name "<FUNCTIONS_APP_NAME>" \
--key-type masterKey
# Create or overwrite a custom host key
az containerapp function keys set \
--resource-group "<RESOURCE_GROUP>" \
--name "<FUNCTIONS_APP_NAME>" \
--key-name "MyCustomKey" \
--key-value "<YOUR_KEY_VALUE>" \
--key-type hostKey
# Show a specific key
az containerapp function keys show \
--resource-group "<RESOURCE_GROUP>" \
--name "<FUNCTIONS_APP_NAME>" \
--key-name "<KEY_NAME>" \
--key-type hostKey
# Delete a host key
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>"