Listar todos os projetos e pastas na sua hierarquia

A API Cloud Resource Manager permite descobrir e catalogar todas as pastas e projetos na sua Cloud de Confiance by S3NS hierarquia de recursos. Essa visibilidade ajuda você a realizar verificações de auditoria e criar ferramentas de gerenciamento personalizadas. As operações de lista padrão podem omitir recursos quando os usuários têm papéis personalizados restritos. É possível filtrar as consultas por referências pai para receber resultados da pesquisa consistentes e identificar nós que as permissões de privilégio mínimo podem ocultar.

Listar todos os nós de recursos

Ao verificar a hierarquia para listar todos os recursos, você precisa de resultados fortemente consistentes. Se a verificação não exibir todos os recursos ou fornecer resultados desatualizados, pode ser difícil saber se algo deu errado. Para garantir que você sempre tenha resultados mais precisos e completos, use uma conta de serviço e faça uma verificação da seguinte forma:

1. Conceda a uma conta de serviço as permissões list e get para Organizações, Pastas e Projetos no recurso Organização.
2. Se você for listar os recursos Projeto e Pasta, especifique o recurso pai na string de filtro.
3. Execute o método projects.list() com essa conta de serviço para cada tipo de recurso que você quer encontrar e para quaisquer recursos intermediários, como Pastas.

Exemplo para listar todos os nós de recursos

O pseudocódigo a seguir demonstra como listar todos os nós de recursos nas organizações:

organizations = organizations.search()
projects = emptyList()

parentsToList = queueOf(organizations)
while (parent = parentsToList.pop()) {
  // TODO: Iterate over paginated results as needed.
  // TODO: Handle PERMISSION_DENIED appropriately.
  projects.addAll(projects.list(parent.type, parent.id))
  parentsToList.addAll(folders.list(parent))
}

Ao criar uma experiência do usuário personalizada, convém também misturar os resultados da pesquisa e carregar os recursos pai conforme necessário (enquanto também captura a exceção PERMISSION_DENIED).

Reduzir a latência na lista de projetos do gcloud

Se a consulta gcloud projects list falhar ou demorar muito, o número de projetos doCloud de Confiance by S3NS a serem retornados pode ser muito grande. Para corrigir isso, aplique as flags filter e page-size ao comando gcloud projects list.

Para saber mais sobre as sinalizações que podem ser adicionadas ao comando gcloud projects list, consulte gcloud projects list.

Excluir exemplo de projetos do Apps Script

A causa mais comum de falhas de consulta ou latência é um grande número de projetos do Apps Script em uma organização. O comando a seguir mostra como excluir projetos do Apps Script da lista de projetos e limitar o número de recursos retornados por página.

gcloud projects list --filter="NOT parent.id: 'APPS_SCRIPT_FOLDER_ID' "--page-size='30'

Acessar o código da pasta do Apps Script

Para encontrar o ID da pasta do Apps Script, siga as etapas abaixo.

1. Na barra de ferramentas do console do Cloud de Confiance , clique em Pesquisar recursos, documentos, produtos e muito mais e digite apps-script.

   Acessar o console do Cloud de Confiance

2. Em Recursos, selecione a pasta apps-script.

3. Em ID da pasta, copie o ID da pasta.

Pesquisar recursos

Se sua pesquisa tiver a finalidade de procurar um recurso que foi criado há algum tempo, você pode fazer uma verificação mais rápida que tenha consistência posterior em vez de consistência forte. Esse método de pesquisa pode omitir alguns recursos do resultado da pesquisa, especialmente os recursos que foram alterados recentemente. Para pesquisar recursos:

1. Use uma conta de serviço que tenha a permissão get para o recurso que você está procurando.
2. Execute o método projects.search() com essa conta de serviço.

Como solucionar problemas de recursos omitidos

Se você estiver desenvolvendo uma ferramenta de verificação, recomendamos usar as permissões list e get concedidas no nível Organização. Isso evita problemas causados pelas permissões parciais do usuário, o que resulta na omissão de alguns recursos na lista.

Se você estiver projetando uma experiência do usuário personalizada que verifica as permissões do usuário, não há uma solução simples. Se o usuário não tiver permissões do nível Organização, ele precisará de determinadas permissões em todos os recursos para que eles sejam exibidos. Se o usuário não tiver permissões em um recurso da hierarquia, talvez alguns recursos não sejam exibidos.

Se um usuário tiver a permissão list, mas não a permissão get para um recurso específico, ele não vai ficar visível no console doCloud de Confiance . No entanto, o recurso será retornado em uma pesquisa usando a API ou a Google Cloud CLI que especifica o pai do recurso. Essa disparidade entre o console do Cloud de Confiance e outros métodos é uma fonte comum de confusão ao tentar verificar a hierarquia de recursos.

Os diagramas a seguir demonstram algumas configurações comuns de permissões e como elas alteram os recursos que ficam visíveis para o usuário que está fazendo uma pesquisa.

Neste exemplo, todas as permissões necessárias foram concedidas no recurso Organização. Portanto, toda a hierarquia fica visível ao fazer uma lista ou pesquisa.

Neste exemplo, o usuário tem todas as permissões necessárias, exceto resourcemanager.organizations.get, mas recebe essas permissões no nível Pasta. Essa lacuna de permissões fornece a ele total visibilidade na lista ou na pesquisa dessa parte da hierarquia, mas não da outra metade.

Este exemplo mostra a experiência de um usuário somente com a permissão resourcemanager.projects.get concedida no nível do recurso Pasta. Ele pode ver os projetos sob essa pasta na hierarquia, mas somente por meio de pesquisa. O uso da funcionalidade de lista não vai retornar resultados.

Este exemplo ilustra um cenário semelhante em que as permissões concedidas só permitem encontrar os recursos de pasta por pesquisa. A operação de lista não retorna resultados.

O usuário neste exemplo tem uma combinação de permissões em toda a organização. Ele pode listar pastas no nível Organização, o que permite encontrá-las com pesquisas que especificam o recurso pai em toda a hierarquia. Ele pode listar recursos do projeto para uma pasta, mas não para a outra, e tem a permissão resourcemanager.projects.get em um projeto na parte inferior da hierarquia.

O resultado é que ele não pode retornar os projetos no lado esquerdo dessa hierarquia de recursos. Eles podem listar os projetos no lado direito apenas usando uma pesquisa que especifique o recurso pai, e apenas um projeto fica visível quando visualizado no console do Cloud de Confiance .

Neste exemplo, é possível receber o recurso Organization e listar os recursos Project especificando o pai em toda a hierarquia. No entanto, você não tem permissão para listar ou pesquisar pastas intermediárias. Seus projetos são pesquisáveis se você souber o ID da pasta pai. As pastas não estão visíveis para você, então não é possível descobrir o ID se você ainda não o tiver. O único recurso que aparece no console do Cloud de Confiance é a organização.

Ao projetar sua experiência do usuário personalizada, é importante estar ciente de situações semelhantes a essas. Você pode usar uma combinação de listagem e pesquisa para renderizar a hierarquia de recursos. Você também deve considerar como comunicar aos usuários que eles não têm as permissões necessárias para ver toda a hierarquia de recursos.