Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Nesta página, descrevemos como usar tags com o Identity and Access Management (IAM) para ajudar você
a controlar o acesso aos seus recursos do Google Cloud.
Os recursos herdam valores de tag da organização pai, das
pastas e do projeto. Como resultado, é possível usar tags para gerenciar o acesso a qualquer
recurso do Google Cloud.
Veja alguns casos de uso comuns para gerenciar o acesso com tags:
Ambientes de desenvolvimento, preparação e produção. Por exemplo, é possível adicionar as tags environment: dev ao ambiente de desenvolvimento e environment: prod ao ambiente de produção.
Tipos de componentes Por exemplo, é possível adicionar as tags component: frontend aos recursos de front-end e component: batch aos recursos para processamento em lote.
Nomes de projetos. Por exemplo, se sua equipe está trabalhando em um projeto com o codinome Atlas, é possível adicionar a tag project: atlas aos recursos de desenvolvimento dela.
Definições e identificadores de tags
Antes de anexar tags aos recursos, você precisa definir a chave para a tag, bem como os valores que a tag permite. É possível criar essas definições no nível da organização ou para envolvidos no projeto. Você usa o Resource Manager para gerenciar definições de tags. Para saber mais, consulte Como criar e definir uma nova tag.
Cada chave e valor de tag tem alguns identificadores diferentes:
Um código permanente, que é globalmente exclusivo e não pode ser reutilizado. Por exemplo, uma chave de tag pode ter o ID permanente tagKeys/123456789012 e um valor de tag pode ter o ID permanente tagValues/567890123456.
Um nome curto. O nome curto de cada chave precisa ser exclusivo no projeto ou
na organização em que a chave é definida, e o nome curto de cada valor precisa ser exclusivo
para a chave associada. Por exemplo, uma chave de tag pode ter o nome abreviado env, e um
valor de tag pode ter o nome abreviado prod.
Um nome de namespace, que adiciona o ID numérico da sua organização ou do projeto ao
nome curto de uma chave de tag. Por exemplo, uma chave de tag criada para uma organização pode ter o nome
de namespace 123456789012/env. Para saber como conseguir o ID da organização, consulte
Como conseguir o ID do recurso da sua organização. Uma chave de tag criada para um projeto pode ter o nome
de namespace myproject/env. Para saber como conseguir o ID do projeto, consulte
Como identificar
projetos.
Conforme explicado nesta página, depois de anexar tags a um recurso, você pode gravar condições para conceder acesso com base em tags. Para gravar uma condição, você precisa escolher qual tipo de identificador usar na condição.
Siga estas diretrizes para escolher entre elas:
Para testar tags, use o nome com namespace (para chaves) e o nome curto (para valores). Esses identificadores são mais fáceis de entender e lembrar, especialmente ao começar.
Se você gerenciar a configuração de maneira declarativa,usando uma ferramenta como o Terraform, use o nome de namespace (para chaves) e o nome curto (para valores). É possível reutilizar esses identificadores ao longo do tempo, o que significa que uma ferramenta declarativa pode excluí-los e recriá-los, e suas condições continuarão a funcionar.
Essa abordagem tem uma desvantagem: digamos que você exclua uma chave ou um valor de tag e crie uma nova chave ou valor com o mesmo nome, mas com um significado diferente.
Se sua condição se referir ao nome de namespace ou nome curto, a condição continua sendo aplicada à nova chave ou ao valor.
Em alguns casos, esse comportamento pode fazer com que os principais tenham acesso que você não pretendia.
Para ajudar a minimizar riscos, considere usar códigos permanentes, que nunca podem ser reutilizados.
Veja por que os códigos permanentes ajudam a minimizar riscos: Suponha que você exclua uma chave ou um valor de tag e, em seguida, crie uma nova chave ou valor com o mesmo nome, mas um significado diferente. Se sua condição se referir ao código permanente, ela não se aplicará à nova chave ou valor. Consequentemente, é menos provável que os principais tenham acesso que não foi pretendido para eles.
Uma desvantagem é que, se você excluir e recriar chaves e valores e quiser preservar o acesso dos principais, também será necessário atualizar suas políticas de IAM para fazer referência aos novos IDs permanentes.
Acesso a recursos com tag
Use tags com condições do IAM para conceder um papel condicionalmente, dependendo das tags anexadas ou herdadas por um recurso. Se uma condição for avaliada como true, o acesso será concedido. caso contrário, o acesso não será concedido. Para saber mais, consulte a visão geral das condições do IAM.
As seções a seguir mostram exemplos de expressões de condição que verificam as tags em um recurso. A condição chama funções diferentes dependendo da verificação do ID permanente ou do nome curto. Para saber mais sobre essas funções, consulte Tags de recurso.
Condições que usam IDs permanentes
Essa condição concede um papel em recursos com a tag tagKeys/123456789012: tagValues/567890123456:
Essa condição concede um papel nos recursos que têm qualquer tag com a chave tagKeys/123456789012, independentemente do valor:
resource.hasTagKeyId('tagKeys/123456789012')
Essa condição concede um papel em recursos que têm a tag
tagKeys/123456789012: tagValues/567890123456 e qualquer tag que use a
chave tagKeys/987654321098:
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-08-28 UTC."],[[["\u003cp\u003eTags, which are key-value pairs, can be attached to Google Cloud resources to control access through conditional granting or denying of IAM roles and permissions.\u003c/p\u003e\n"],["\u003cp\u003eResources inherit tag values from parent levels (organization, folders, project), allowing for centralized access management across various Google Cloud resources.\u003c/p\u003e\n"],["\u003cp\u003eTag identifiers include permanent IDs (unique and non-reusable), short names (unique within the project/organization), and namespaced names (short name plus organization/project ID), each offering different trade-offs in terms of manageability and risk.\u003c/p\u003e\n"],["\u003cp\u003eTags are commonly used for environment separation (e.g., development, production), categorizing component types (e.g., frontend, batch), and project identification to help organize access.\u003c/p\u003e\n"],["\u003cp\u003eIAM conditions can be configured to check resource tags using either permanent IDs or namespaced/short names, with permanent IDs preferred for minimizing risk of unintended access due to tag name reuse.\u003c/p\u003e\n"]]],[],null,["# Tags and conditional access\n\nThis page describes how to use tags with Identity and Access Management (IAM) to help you\ncontrol access to your Google Cloud resources.\n\nTo learn more about tags, see [Tags overview](/resource-manager/docs/tags/tags-overview).\n\nOverview of tags\n----------------\n\nA tag is a key-value pair that is attached to a\n[Google Cloud resource](/resource-manager/docs/tags/tags-supported-services#supported_service_resources). You can\n[conditionally grant IAM roles](/iam/docs/conditions-overview) or\n[conditionally deny IAM permissions](/iam/docs/deny-overview) based on\nwhether a resource has a specific tag.\n\nResources [inherit tag values](/resource-manager/docs/tags/tags-overview#inheritance) from their parent organization,\nfolders, and project. As a result, you can use tags to manage access to any\nGoogle Cloud resource.\n\nThese are some common use cases for managing access with tags:\n\n- **Development, staging, and production environments.** For example, you could add the tags `environment: dev` to your development environment and `environment: prod` to your production environment.\n- **Component types.** For example, you could add the tags `component: frontend` to front-end resources and `component: batch` to resources for batch processing.\n- **Project names.** For example, if your team is working on a project with the codename Atlas, you could add the tag `project: atlas` to the team's development resources.\n\n\n| **Important:** Do not include sensitive information in tags. Sensitive information includes personally identifiable information (PII), such as an individual's name or job title. Tags are not intended to contain sensitive information.\n\n\u003cbr /\u003e\n\nTag definitions and identifiers\n-------------------------------\n\nBefore you attach tags to resources, you must define the key for the tag, as\nwell as the values that the tag allows. You can create these definitions at\nthe organization or project level. You use [Resource Manager](/resource-manager/docs) to\nmanage tag definitions. To learn more, see\n[Creating and defining a new tag](/resource-manager/docs/tags/tags-creating-and-managing#creating).\n\nEach tag key and value has a few different identifiers:\n\n\n- A *permanent ID* , which is globally unique and can never be reused. For example, a tag key could have the permanent ID `tagKeys/123456789012`, and a tag value could have the permanent ID `tagValues/567890123456`.\n- A *short name* . The short name for each key must be unique within the project or organization under which the key is defined, and the short name for each value must be unique for its associated key. For example, a tag key could have the short name `env`, and a tag value could have the short name `prod`.\n- A *namespaced name* , which adds your organization's numeric ID or project's ID to the short name of a tag key. For example, a tag key created for an organization could have the namespaced name `123456789012/env`. To learn how to get your organization ID, see [Getting\n your organization resource ID](/resource-manager/docs/creating-managing-organization#retrieving_your_organization_id). A tag key created for a project could have the namespaced name `myproject/env`. To learn how to get your project ID, see [Identifying\n projects](/resource-manager/docs/creating-managing-projects#identifying_projects).\n\n\u003cbr /\u003e\n\nAs explained on this page, after you attach tags to a resource, you can\n[write conditions to grant access based on tags](#control-access). To write a\ncondition, you must choose which type of identifier to use in the condition.\nFollow these guidelines to choose between them:\n\n- **To experiment with tags,** consider using the namespaced name (for keys) and the short name (for values). These identifiers are easier to understand and remember, especially as you get started.\n- **If you manage your configuration declaratively,** using a tool such as\n Terraform, consider using the namespaced name (for keys) and the short name\n (for values). You can reuse these identifiers over time, which means that a\n declarative tool can delete and recreate them, and your conditions will\n continue to work.\n\n This approach comes with a tradeoff: Suppose you delete a tag key or value,\n then create a new key or value with the same name but a different meaning.\n If your condition refers to the namespaced name or short name, then the\n condition continues to apply to the new key or value.\n\n In some cases, this behavior might cause principals to get access that you\n did not intend for them to have.\n- **To help minimize risk,** consider using permanent IDs, which can never be\n reused.\n\n Here's why permanent IDs help minimize risk: Suppose you delete a tag key or\n value, then create a new key or value with the same name but a different\n meaning. If your condition refers to the permanent ID, then the condition\n does not apply to the new key or value. As a result, principals are less\n likely to get access that you did not intend for them to have.\n\n One drawback is that if you delete and recreate keys and values, and you\n want to preserve principals' access, you must also update your allow\n policies to refer to the new permanent IDs.\n\nAccess to tagged resources\n--------------------------\n\nYou can use tags with IAM Conditions to grant a role\nconditionally, depending on the tags that are attached to or inherited by a\nresource. If a condition evaluates to `true`, then access is granted; otherwise,\naccess is not granted. To learn more, see the\n[overview of IAM Conditions](/iam/docs/conditions-overview).\n\n\nCertain\nareas of the Google Cloud console don't recognize allow policy role bindings\nwith tag-based conditions. As a result, if you have a role with a tag-based\ncondition, then the Google Cloud console might incorrectly prevent you from\nperforming certain actions. If you encounter this issue, then use an alternate\nmethod, such as the gcloud CLI, to perform the action.\n\n\n| **Note:** Conditions that check the tags for a resource *and* other\n| attributes, such as the resource name or the timestamp of the request, are in preview.\n| Such conditions are subject to the \"Pre-GA Offerings Terms\" in the General Service Terms section\n| of the [Service Specific Terms](/terms/service-terms#1). For more information, see\n| the [launch stage descriptions](/products#product-launch-stages).\n|\n|\n| Conditions that check the tags for a resource and *don't* check any other attributes are\n| generally available.\n\n\u003cbr /\u003e\n\nThe following sections show examples of condition expressions that check the\ntags on a resource. The condition calls different functions depending on whether\nit checks the permanent ID or the short name. To learn more about these\nfunctions, see [Resource tags](/iam/docs/conditions-attribute-reference#resource-tags).\n\n### Conditions that use permanent IDs\n\nThis condition grants a role on resources with the tag\n`tagKeys/123456789012: tagValues/567890123456`: \n\n resource.matchTagId('tagKeys/123456789012', 'tagValues/567890123456')\n\nThis condition grants a role on resources that have any tag with the key\n`tagKeys/123456789012`, regardless of its value: \n\n resource.hasTagKeyId('tagKeys/123456789012')\n\nThis condition grants a role on resources that have both the tag\n`tagKeys/123456789012: tagValues/567890123456`, and any tag that uses the\nkey `tagKeys/987654321098`: \n\n resource.matchTagId('tagKeys/123456789012', 'tagValues/567890123456') &&\n resource.hasTagKeyId('tagKeys/987654321098')\n\n### Conditions that use namespaced names and short names\n\nThis condition grants a role on resources with the tag `env: prod`, indicating\nthat the resource is in a production environment: \n\n resource.matchTag('123456789012/env', 'prod')\n\nThis condition grants a role on resources that have any tag with the key `env`,\nregardless of its value: \n\n resource.hasTagKey('123456789012/env')\n\nThis condition grants a role on resources that have both the tag `env: prod` and\nany tag that uses the key `project`: \n\n resource.matchTag('123456789012/env', 'prod') &&\n resource.hasTagKey('123456789012/project')\n\nWhat's next\n-----------\n\n- Learn how to [manage tags and attach tags to resources](/resource-manager/docs/tags/tags-creating-and-managing).\n- Get details about [checking tags in a condition](/iam/docs/conditions-attribute-reference#resource-tags)."]]
