Os recursos do Google Cloud são organizados em uma hierarquia, com cada nó (Organizações, Pastas, Projetos e assim por diante) tendo uma referência ao elemento pai. Você pode usar essa referência como um termo-chave de filtro para que as verificações melhorem a consistência das pesquisas de recursos.
Você pode conceder permissões a usuários usando papéis personalizados. Esses papéis funcionam com base no princípio do menor privilégio e geralmente fornecem apenas o mínimo de permissões necessárias para executar uma tarefa específica.
Esse esquema pode ser útil para isolar diferentes grupos de usuários. Exemplo:
- Uma grande empresa com departamentos que não deveriam poder inspecionar os recursos de seus colegas.
- Prestadores de serviços com permissões para um projeto específico, mas sem outros recursos.
No entanto, devido às permissões restritas, os papéis personalizados podem fazer com que muitos recursos em sua hierarquia sejam omitidos ao executar uma operação de lista. Ao fazer pesquisas como um usuário que recebeu um papel personalizado, pode ser difícil saber por que certos recursos não estão aparecendo.
Para evitar esse cenário, esta página discute as práticas recomendadas para listar todos dos recursos gerenciados pela API Cloud Resource Manager na hierarquia de recursos. Você pode usar essa orientação para configurar verificações de auditoria personalizadas ou para criar sua própria experiência do usuário na API Cloud Resource Manager.
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:
- Conceda a uma conta de serviço as permissões
list
eget
para Organizações, Pastas e Projetos no recurso Organização. - Se você for listar os recursos Projeto e Pasta, especifique o recurso pai na string de filtro.
- 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 do Google Cloud a serem retornados pode ser muito grande. Para corrigir isso, aplique as sinalizações filter
e page-size
ao seu 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 estas etapas.
Na barra de ferramentas do console do Google Cloud, clique em Pesquisar recursos, documentos, produtos e muito mais e digite
apps-script
.Em Recursos, selecione a pasta apps-script.
Em ID da pasta, copie o ID.
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:
- Use uma conta de serviço que tenha a permissão
get
para o recurso que você está procurando. - Execute o método
projects.search()
com esta 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 elaborando uma experiência do usuário personalizada que verifica as permissões do usuário, não há uma solução fácil. 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, esse recurso não vai ficar visível no console do Google Cloud. No entanto, o recurso será retornado em uma pesquisa usando o
API ou Google Cloud CLI que especifica o pai do recurso. Essa disparidade
entre o console do Google Cloud 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. Usar a funcionalidade de lista não retornará resultados.
Este exemplo mostra o mesmo problema que o anterior, em que as permissões concedidas permitem somente que o usuário encontre seus recursos de Pasta por meio de pesquisa. Usar a funcionalidade de lista não retornará 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. Ele pode listar os projetos no lado direito apenas usando uma pesquisa que especifica o recurso pai, e apenas um projeto visíveis no console do Google Cloud.
Neste exemplo, o usuário pode acessar o recurso Organização e listar recursos de Projeto especificando o elemento pai em toda a hierarquia. No entanto, ele não tem permissão para listar ou pesquisar qualquer uma das pastas intermediárias. Os projetos dele poderão ser pesquisados se o usuário souber o código da pasta pai. As pastas não ficam visíveis para esse usuário e, portanto, ele não poderá descobrir o código caso ele ainda não o tenha. O único recurso que no console do Google Cloud é a organização.
Na elaboração da experiência do usuário personalizada, é importante estar ciente de situações semelhantes às descritas anteriormente. 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.