Consultando logs para recursos do Azure
No Azure Monitor Log Analytics, as consultas normalmente são executadas no contexto de um espaço de trabalho. Um espaço de trabalho pode conter dados para muitos recursos, dificultando o isolamento de dados para um recurso específico. Além disso, os recursos podem enviar dados para vários espaços de trabalho. Para simplificar essa experiência, a API REST permite consultar recursos do Azure diretamente para seus logs.
Formato da resposta
As consultas de recursos do Azure produzem a mesma forma de resposta que as consultas direcionadas a um espaço de trabalho do Log Analytics.
Formato do URL
Considere um recurso do Azure com um identificador totalmente qualificado:
/subscriptions/<sid>/resourceGroups/<rg>/providers/<providerName>/<resourceType>/<resourceName>
Uma consulta para os logs deste recurso em relação ao ponto de extremidade direto da API iria para a seguinte URL:
https://api.loganalytics.azure.com/v1/subscriptions/<sid>/resourceGroups/<rg>/providers/<providerName>/<resourceType>/<resourceName>/query
Uma consulta ao mesmo recurso via ARM usaria a seguinte URL:
https://management.azure.com/subscriptions/<sid>/resourceGroups/<rg>/providers/<providerName>/<resourceType>/<resourceName>/providers/microsoft.insights/logs?api-version=2018-03-01-preview
Essencialmente, essa URL é o recurso do Azure totalmente qualificado mais o provedor de extensão: /providers/microsoft.insights/logs
.
Acesso à tabela e RBAC
O microsoft.insights
provedor de recursos expõe um novo conjunto de operações para controlar o acesso aos logs no nível da tabela. Essas operações têm o seguinte formato para uma tabela chamada tableName
.
microsoft.insights/logs/<tableName>/read
Essa permissão pode ser adicionada a funções usando a actions
propriedade para permitir tabelas especificadas e a notActions
propriedade para não permitir tabelas especificadas.
Controlo de acesso a áreas de trabalho
As consultas de recursos do Azure examinam os espaços de trabalho do Log Analytics como possíveis fontes de dados. No entanto, os administradores podem bloquear o acesso ao espaço de trabalho por meio de funções RBAC. Por padrão, a API retorna apenas resultados de espaços de trabalho que o usuário tem permissões para acessar.
Os administradores de espaço de trabalho podem usar consultas de recursos do Azure sem quebrar o RBAC existente. Uma propriedade booleana no espaço de trabalho permite que os usuários com permissões de leitura exibam logs para um recurso específico do Azure, mas não consultem o espaço de trabalho que contém esses logs.
Esta é a ação para definir o escopo do acesso às Tabelas no nível do espaço de trabalho:
microsoft.operationalinsights/workspaces/query/<tableName>/read
Respostas de erro
Aqui está uma breve lista de cenários de falha comuns ao consultar recursos do Azure, juntamente com uma descrição do comportamento sintomático.
O recurso do Azure não existe
HTTP/1.1 404 Not Found
{
"error": {
"message": "The resource /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/test-rg/providers/microsoft.storage/storageaccounts/exampleResource was not found",
"code": "ResourceNotFoundError"
}
}
}
Sem acesso ao recurso
HTTP/1.1 403 Forbidden
{
"error": {
"message": "The provided credentials have insufficient access to perform the requested operation",
"code": "InsufficientAccessError",
"innererror": {
"code": "AuthorizationFailedError",
"message": "User '92eba38a-70da-42b0-ab83-ffe82cce658f' does not have access to read logs for this resource"
}
}
}
Nenhum log de recurso ou nenhuma permissão para espaço de trabalho contendo esses logs
Dependendo da combinação precisa de dados e permissões, a resposta contém um 200 sem dados resultantes ou gera um erro de sintaxe (erro 4xx).
Acesso parcial
Há alguns cenários em que um usuário pode ter permissões parciais para acessar os logs de um determinado recurso. Este é o caso se o usuário estiver faltando:
- Acesso ao espaço de trabalho que contém logs para o recurso do Azure.
- Acesso à referência de tabelas na consulta.
Eles veem uma resposta normal, com fontes de dados que o usuário não tem permissões para acessar filtradas silenciosamente. Para ver informações sobre o acesso de um usuário a um recurso do Azure, os espaços de trabalho subjacentes do Log Analytics e a tabelas específicas, inclua o cabeçalho Prefer: include-permissions=true
com solicitações. Isso faz com que o JSON de resposta inclua uma seção como o exemplo a seguir:
{
"permissions": {
"resources": [
{
"resourceId": "/subscriptions/<id>/resourceGroups<id>/providers/Microsoft.Compute/virtualMachines/VM1",
"dataSources": [
"/subscriptions/<id>/resourceGroups<id>/providers/Microsoft.OperationalInsights/workspaces/WS1"
]
},
{
"resourceId": "/subscriptions/<id>/resourceGroups<id>/providers/Microsoft.Compute/virtualMachines/VM2",
"denyTables": [
"SecurityEvent",
"SecurityBaseline"
],
"dataSources": [
"/subscriptions/<id>/resourceGroups<id>/providers/Microsoft.OperationalInsights/workspaces/WS2",
"/subscriptions/<id>/resourceGroups<id>/providers/Microsoft.OperationalInsights/workspaces/WS3"
]
}
],
"dataSources": [
{
"resourceId": "/subscriptions/<id>/resourceGroups<id>/providers/Microsoft.OperationalInsights/workspaces/WS1",
"denyTables": [
"Tables.Custom"
]
},
{
"resourceId": "/subscriptions/<id>/resourceGroups<id>/providers/Microsoft.OperationalInsights/workspaces/WS2"
}
]
}
}
A resources
carga útil descreve uma tentativa de consultar duas VMs. O VM1 envia dados para o espaço de trabalho WS1, enquanto o VM2 envia dados para dois espaços de trabalho: WS2 e WS3. Além disso, o usuário não tem permissão para consultar as SecurityEvent
tabelas ou SecurityBaseline
para o recurso.
A dataSources
carga filtra ainda mais os resultados, descrevendo quais espaços de trabalho o usuário pode consultar. Aqui, o usuário não tem permissões para consultar o WS3 e outra tabela filtrada do WS1.
Para indicar claramente quais dados essa consulta retornaria:
- Logs para VM1 no WS1, excluindo Tabelas. Personalizar a partir do espaço de trabalho.
- Logs para VM2, excluindo SecurityEvent e SecurityBaseline, no WS2.