Início / coding / Perguntas / 79597490
Accepted
Abdul Khadar
Asked: 2025-04-29 09:52:58 +0800 CST

Política do Azure Exigir uma tag na criação de recurso

  • 772

Eu habilitei a política do Azure [Exigir uma tag nos recursos]. Ela está validando tags na criação de recursos conforme o esperado, mas também está avaliando recursos existentes e mostrando Não compatível.

Definição

{
  "properties": {
    "displayName": "Require a tag on resources",
    "policyType": "BuiltIn",
    "mode": "Indexed",
    "description": "Enforces existence of a tag. Does not apply to resource groups.",
    "metadata": {
      "version": "1.0.1",
      "category": "Tags"
    },
    "version": "1.0.1",
    "parameters": {
      "tagName": {
        "type": "String",
        "metadata": {
          "displayName": "Tag Name",
          "description": "Name of the tag, such as 'environment'"
        }
      }
    },
    "policyRule": {
      "if": {
        "field": "[concat('tags[', parameters('tagName'), ']')]",
        "exists": "false"
      },
      "then": {
        "effect": "deny"
      }
    },
    "versions": [
      "1.0.1"
    ]
  },
  "id": "/providers/Microsoft.Authorization/policyDefinitions/871b6d14-10aa-478d-b590-94f262ecfa99",
  "type": "Microsoft.Authorization/policyDefinitions",
  "name": "871b6d14-10aa-478d-b590-94f262ecfa99"
}

Verifiquei se funciona tanto em recursos existentes quanto em novos. Existe alguma possibilidade de avaliar apenas em novos recursos?

1 respostas

  1. Best Answer

    Não, não especificamente novos recursos.

    A primeira pergunta é "como você definiria novo ?". A segunda pergunta é "por que você permitiria que recursos mais antigos/legados continuassem a violar sua política? " .

    • Se isso for para conformidade, você provavelmente precisará de uma definição estrita do que está incluído na política e do que não está.

    Ao implementar regras como essa, uma abordagem comum é primeiro resolver os recursos existentes para garantir que atendam às novas restrições de política. Você pode avaliar o impacto definindo o nível de execução como " Auditoria" . Você pode optar por usar um script para automatizar a atribuição das tags aos recursos existentes. Uma solução alternativa seria injetar uma tag [Legado] em todos os recursos existentes.

    Em seguida, habilite a imposição de negação somente quando os recursos legados forem marcados.

    A outra abordagem é aplicar a política em uma assinatura nova/separada ou em grupos de recursos específicos. Isso permite uma separação clara entre antes e depois e se alinha com muitas outras ferramentas e opções de relatórios no Azure. Se a sua política for por motivos de conformidade, isso é especialmente útil, principalmente se houver outras políticas que devam ser associadas à mesma coleção de recursos.

    Embora não seja recomendado, é possível criar uma política em torno de uma Tag de Data de Criação .
    No entanto, primeiro você precisa criar outra política que aplique uma tag "Data de Criação" aos recursos.

    Não insira a data de criação em uma Tag, mesmo que você encontre dicas neste e em outros artigos sobre como fazer isso. Tags não são adequadas para gerenciar valores únicos; elas são projetadas para categorizar e agrupar registros. No Azure, a interface foi projetada para incentivar a reutilização de tags. Se essa lista ficar inchada devido a muitas entradas de data únicas, o sistema de tags se tornará inutilizável para outros valores de tags genuínos.

    Este é um exemplo de como fazer isso, mas, por favor, não faça. ;)

    Isso resolveria o problema para todos os novos recursos, mas não ajudaria retrospectivamente. Você ainda precisaria criar um script com uma data para os recursos anteriores e só poderia recuperar a data real dos registros de atividades antes que eles expirassem após 90 dias.

    • 1

relate perguntas