Visão geral do controle de acesso baseado em papéis (RBAC)

Nesta página, descrevemos a autorização detalhada com o controle de acesso baseado em função (RBAC), que está disponível no Cloud Data Fusion versão 6.5 e posteriores.

O RBAC restringe o acesso nos ambientes em que você desenvolve pipelines no Cloud Data Fusion. O RBAC ajuda a gerenciar quem tem acesso aos recursos do Cloud Data Fusion, o que pode fazer com recursos e as áreas que eles podem acessar, como instâncias ou namespaces. O RBAC do Cloud Data Fusion é um sistema de autorização que fornece com a tecnologia do Identity and Access Management (IAM).

Quando usar o RBAC

O controle de acesso baseado em função fornece isolamento em nível de namespace em uma única instância do Cloud Data Fusion. É recomendado para os seguintes casos de uso:

  • ajudar a minimizar o número de instâncias usadas pela organização;
  • Ter vários desenvolvedores, equipes ou unidades de negócios usa uma única instância do Cloud Data Fusion.

Com o RBAC do Cloud Data Fusion, as organizações podem:

  • Permitir que um usuário execute apenas um pipeline dentro de um namespace, mas não o modifique artefatos ou perfis de computação do ambiente de execução.
  • Permitir que um usuário apenas visualize o pipeline, mas não modifique nem execute um pipeline.
  • Permite que um usuário crie, implante e execute um pipeline.

Recomendado:mesmo com o RBAC, para manter o isolamento, segurança e estabilidade do desempenho, use projetos e instâncias para ambientes de desenvolvimento e produção.

Limitações

  • Um usuário pode receber um ou vários papéis no nível da instância ou do namespace.
  • O RBAC está disponível apenas na edição Enterprise do Cloud Data Fusion.
  • Número de namespaces: sem limite rígido para o número de namespaces por instância.
  • Para o número máximo de usuários simultâneos em uma instância com o controle de acesso baseado em função (RBAC) ativado, consulte Preços.
  • Papéis personalizados: não é possível criar papéis personalizados do RBAC.
  • O RBAC do Cloud Data Fusion não permite a autorização em Gerenciamento de conexão.
  • Ao usar tokens de acesso OAuth da conta de serviço para acessar a versão 6.5 instâncias com controle de acesso baseado em função (RBAC), os escopos a seguir precisam ser especificados, o escopo userinfo.email. Sem elas, você vai encontrar permissões negados.
    • https://www.googleapis.com/auth/userinfo.email
    • https://www.googleapis.com/auth/cloud-platform ou https://www.googleapis.com/auth/servicecontrol

Atribuições de funções

Uma atribuição de papel consiste em três elementos: principal, definição de papel e escopo.

Principal

Um principal (anteriormente conhecido como membro) pode ser uma Conta do Google (para usuários finais), um serviço conta de serviço (para apps e máquinas virtuais) ou um grupo do Google que está solicitando aos recursos do Cloud Data Fusion. É possível atribuir um papel a qualquer um desses principais.

Definição do papel

Um papel contém um conjunto de permissões que permitem realizar ações específicas nos recursos do Google Cloud.

O Cloud Data Fusion oferece várias papéis predefinidos que você pode usar.

Exemplos:

  • O papel de administrador de instância (datafusion.admin) permite que os principais criem e excluam namespaces e concedam permissões.
  • O papel de Desenvolvedor (datafusion.developer) permite que os principais criem e excluir, implantar e executar visualizações.

Escopo

O escopo é o conjunto de recursos a que o acesso se aplica. Ao fazer isso, você pode limitar ainda mais as ações permitidas pela definição de um escopo (por exemplo, uma instância ou namespace). Isso é útil se você deseja atribuir o papel de desenvolvedor, mas apenas para um namespace.

Recomendações de segurança

A adoção de um modelo de segurança e atendê-lo às necessidades e requisitos da sua organização pode ser um desafio. As recomendações a seguir têm como objetivo ajudar você a simplificar a jornada para adotar o modelo do RBAC do Cloud Data Fusion:

  • O papel de administrador da instância precisa ser concedido com cuidado. Esse papel permite acesso total a uma instância e a todos os recursos subjacentes do Cloud Data Fusion. Um principal com esse papel pode conceder permissões a outros usando a API REST.
  • O papel de Administrador de instâncias não deve ser concedido quando os principais forem necessários para ter acesso a namespaces individuais em um Cloud Data Fusion instância. Em vez disso, conceda o papel de acessador de instâncias com um dos papéis de visualizador/desenvolvedor/operador/editor concedidos em um subconjunto dos namespaces.
  • Acessador de instâncias pode ser atribuído primeiro com segurança, já que principais acesso à instância, mas não concede acesso a nenhum recurso na instância. Esse papel normalmente é usado com um visualizador/desenvolvedor/operador/editor para dar acesso a um ou um subconjunto de namespaces em uma instância.
  • É recomendado que o papel de leitor seja atribuído a usuários ou grupos do Google que se quiserem disponibilizar autoatendimento para entender o status de jobs em execução ou visualizar pipelines ou registros com instâncias do Cloud Data Fusion. de dados. Para por exemplo, os consumidores de relatórios diários que gostariam de saber o processamento foi concluído.
  • A função de desenvolvedor é recomendada para desenvolvedores de ETL responsáveis por criar, testar e gerenciar pipelines.
  • O papel de operador de um namespace é recomendado para usuários que estejam fornecendo administrador de operações ou serviços de DevOps. Eles são capazes de realizar ações que os desenvolvedores podem executar (exceto para visualizar pipelines) e implantar artefatos e gerenciar perfis de computação.
  • O papel de editor de um namespace é um papel privilegiado que concede ao usuário ou ao grupo do Google acesso total a todos os recursos no namespace. O Editor pode ser considerado a união dos papéis de desenvolvedor e operador.
  • Operadores e Administradores precisam ter cuidado para instalar plug-ins ou artefatos não confiáveis, porque isso pode gerar um risco de segurança.

Solução de problemas

Esta seção da página mostra como resolver problemas relacionados ao controle de acesso baseado em função (RBAC) em o Cloud Data Fusion.

Um principal com o papel de Leitor do Cloud Data Fusion para um namespace no RBAC pode editar pipelines

O acesso é baseado em uma combinação de IAM e RBAC papéis de segurança na nuvem. Os papéis do IAM têm precedência sobre os do RBAC. Verificar se o principal tem Editor do projeto ou Administrador do Cloud Data Fusion papéis do IAM.

Um principal com a função de administrador de instâncias no RBAC não pode acessar as instâncias do Cloud Data Fusion no console do Google Cloud

Há um problema conhecido no Cloud Data Fusion em que os principais com O papel de administrador da instância não pode acessar as instâncias no console do Google Cloud. Para corrigir o problema, conceda ao(a) Leitor do projeto ou um dos Papéis do IAM do Cloud Data Fusion para principal, além de torná-lo administrador de uma instância. Isso concede Acesso de leitor ao principal para todas as instâncias no projeto.

Impedir que um principal acesse namespaces em que não têm papel

Para impedir que um principal visualize namespaces em que não tem papel, ele não deve ter o Leitor do projeto ou qualquer um Papéis do IAM do Cloud Data Fusion. Em vez disso, conceda apenas papéis do RBAC ao principal no namespace onde precisam operar.

O principal com esse tipo de acesso não verá a lista do Cloud Data Fusion no console do Google Cloud. Em vez disso, forneça um link direto da seguinte forma: https://INSTANCE_NAME-PROJECT_ID.REGION_NAME.datafusion.googleusercontent.com/

Quando o principal abre a instância, o Cloud Data Fusion mostra uma lista de namespaces em que o principal recebe o papel de RBAC.

Conceder o papel de acessador do Cloud Data Fusion a um principal

O papel Acessador é atribuído implicitamente a um principal quando qualquer outro O papel do RBAC é atribuído a eles em instância. Para verificar se um principal tem esse papel em uma instância específica, consulte as Análise de políticas do IAM.

A seguir