Neste documento, descrevemos os conceitos, as práticas recomendadas e a arquitetura de referência para rede, autenticação e autorização de um data lake Kerberos no Google Cloud usando o Dataproc em -cluster Centro de distribuição de chaves (KDC, na sigla em inglês) e Apache Ranger (em inglês). O Dataproc é o serviço Hadoop e Spark gerenciado do Google Cloud. Este documento é destinado a administradores do Apache Hadoop, arquitetos de nuvem e equipes de Big Data que estão migrando os clusters tradicionais do Hadoop e do Spark para um data lake moderno com tecnologia do Dataproc.
Um data lake do Kerberized no Google Cloud ajuda organizações com implantações híbridas e em várias nuvens a estender e usar os investimentos em TI existentes no gerenciamento de identidade e controle de acesso.
No Google Cloud, as organizações podem fornecer às equipes quantos clusters efêmeros com escopo de job forem necessários. Isso elimina grande parte da complexidade da manutenção de um cluster com dependências crescentes e interações de configuração de software. As organizações também podem criar clusters de execução mais longa para acesso de vários usuários e serviços. Neste documento, mostramos como usar ferramentas padrão do setor, como o Kerberos e o Apache Ranger, para ajudar a garantir a segurança refinada do usuário (autenticação, autorização e auditoria) para os dois casos de cluster no Dataproc.
Caso de uso de cliente
As empresas estão migrando os data lakes locais baseados em Hadoop para plataformas em nuvem pública. Isso resolve os desafios que estão enfrentando no gerenciamento dos clusters tradicionais.
Uma dessas organizações, uma grande líder em tecnologia empresarial em software e hardware, decidiu migrar o sistema Hadoop local para o Google Cloud. O ambiente local do Hadoop atendeu às necessidades de análise de centenas de equipes e unidades de negócios, incluindo a equipe de segurança cibernética com 200 membros. Quando um membro da equipe executou uma grande consulta no data lake legado, houve problemas devido à natureza rígida dos recursos. A organização teve dificuldade para acompanhar as necessidades de análise da equipe usando o ambiente local. Por isso, ela mudou para o Google Cloud. Ao migrar para o Google Cloud, a organização conseguiu reduzir em 25% por mês o número de problemas relatados no data lake local.
A base do plano de migração da organização para o Google Cloud foi a decisão de remodelar e otimizar os grandes clusters monolíticos de acordo com as cargas de trabalho das equipes e mudar o foco do gerenciamento de clusters para o desbloqueio do valor comercial. Os poucos clusters grandes foram divididos em clusters menores e econômicos do Dataproc, enquanto as cargas de trabalho e as equipes foram migradas para os seguintes tipos de modelos:
- Clusters com escopo de job temporário: com apenas alguns minutos de tempo de ativação, o modelo temporário permite que um job ou fluxo de trabalho tenha um cluster dedicado que é encerrado após a conclusão do job. . Esse padrão separa o armazenamento dos nós de computação substituindo o Hadoop Distributed File System (HDFS) pelo Cloud Storage, usando o Conector do Cloud Storage integrado" do Dataproc para Hadoop.
- Clusters de longa duração: quando os clusters com escopo de job temporário não podem atender ao caso de uso, os clusters do Dataproc podem ser de longa duração. Quando os dados com estado do cluster são transferidos para o Cloud Storage, ele pode ser encerrado facilmente e é considerado como em execução semi. O escalonamento automático de clusters inteligentes também permite que esses clusters comecem pequenos e otimizem os recursos de computação para aplicativos específicos. Esse escalonamento automático substitui o gerenciamento de filas do YARN.
O desafio da segurança híbrida
No cenário anterior, o cliente migrou o sistema de gerenciamento de dados substancial para a nuvem. No entanto, outras partes da TI da organização precisavam permanecer no local (por exemplo, alguns dos sistemas operacionais legados que alimentam o data lake).
A arquitetura de segurança necessária para garantir que o provedor de identidade local central baseado em LDAP (IdP, na sigla em inglês) permaneça a fonte autoritativa para as identidades corporativas usando o data lake. A segurança local do Hadoop é baseada no Kerberos e no LDAP para autenticação, geralmente como parte do Microsoft Active Directory (AD) da organização, e em vários outros softwares de código aberto. produtos OSS, como o Apache Ranger. Essa abordagem de segurança permite autorização e auditoria minuciosas das atividades dos usuários e das equipes nos clusters de data lake. No Google Cloud, o gerenciamento de identidade e acesso (IAM) é usado para gerenciar o acesso a recursos específicos do Google Cloud, como o Dataproc e o Cloud Storage.
Neste documento, discutimos uma abordagem de segurança que usa o melhor da segurança do Hadoop local e do OSS (com foco no Kerberos, no LDAP corporativo e no Apache Ranger) junto comIAM para ajudar a proteger cargas de trabalho e dados dentro e fora dos clusters do Hadoop.
Arquitetura
O diagrama a seguir mostra a arquitetura geral:
No diagrama anterior, os clientes executam jobs em clusters de várias equipes ou de equipe única. Os clusters usam um metastore Hive central e a autenticação Kerberos com um provedor de identidade corporativa.
Componentes
Na arquitetura, é proposta uma combinação de ferramentas de código aberto padrão do setor e do IAM para autenticar e autorizar as diferentes maneiras de enviar jobs, descritas posteriormente neste documento. A seguir, veja os principais componentes que trabalham juntos para fornecer segurança refinada das cargas de trabalho das equipes e dos usuários nos clusters do Hadoop:
Kerberos: o Kerberos é um protocolo de autenticação de rede que usa criptografia de chave secreta para fornecer autenticação forte para aplicativos cliente/servidor. O servidor Kerberos é conhecido como Centro de distribuição de chaves (KDC, na sigla em inglês).
O Kerberos é amplamente usado em sistemas locais, como o AD, para autenticar usuários, serviços e máquinas humanos (as entidades de clientes são indicadas como usuários principais). A ativação do Kerberos no Dataproc usa a distribuição gratuita do MIT do Kerberos para criar um KDC no cluster. O KDC no cluster do Dataproc atende às solicitações dos principais usuários para acessar recursos no cluster, como o Apache Hadoop YARN, o HDFS (links em inglês) e o Apache Spark (recursos do servidor são indicados como principais do serviço). A confiança entre domínios do Kerberos permite que você conecte os principais de usuários de um realm a outro.
Apache Ranger: o Apache Ranger oferece autorização detalhada para que os usuários executem ações específicas nos serviços do Hadoop. Ele também faz auditorias do acesso do usuário e implementa ações administrativas. O Ranger pode sincronizar com um servidor LDAP corporativo local ou com o AD para receber identidades de usuários e serviços.
Metastore do Hive compartilhado: o metastore do Hive é um serviço que armazena metadados para o Apache Hive e outras ferramentas do Hadoop. Como muitas dessas ferramentas são criadas com base nele, o metastore do Hive se tornou um componente crítico de muitos data lakes. Na arquitetura proposta, um metastore Hive centralizado e em Kerberos permite que vários clusters compartilhem metadados de maneira segura.
O Kerberos, o Ranger e um metastore Hive compartilhado funcionam juntos para permitir a segurança refinada do usuário nos clusters do Hadoop, mas o IAM controla o acesso aos recursos do Google Cloud. Por exemplo, o Dataproc usa a conta de serviço do Dataproc para executar leituras e gravações em buckets do Cloud Storage.
Dimensões do cluster
As seguintes dimensões caracterizam um cluster do Dataproc:
- Locação: um cluster será multilocatário se atender às solicitações de mais de um usuário ou serviço humano ou locatário único se ele disponibiliza as solicitações de um único usuário ou serviço.
- Kerberos: um cluster poderá ser Kerberized se você ativar o Kerberos no Dataproc ou não kerberized se você não ativar o Kerberos no Dataproc.
- Ciclo de vida: um cluster será temporário se for criado apenas para a duração de um job ou fluxo de trabalho específico, conterá apenas os recursos necessários para executar o job; e é desligado na conclusão do job. Caso contrário, o cluster será considerado como semi-long running.
Diferentes combinações dessas dimensões determinam os casos de uso mais adequados a um cluster específico. Neste documento, discutimos os seguintes exemplos representativos:
Os clusters de várias equipes de exemplo mostrados na arquitetura são clusters do kerberized, multilocatários e de longa duração. Esses clusters são mais adequados para cargas de trabalho de consulta interativas, por exemplo, eles servem para análise de dados de longo prazo e exploração de Business Intelligence (BI). Na arquitetura, os clusters estão localizados em um projeto do Google Cloud compartilhado por várias equipes e atende às solicitações dessas equipes, portanto, o nome delas.
Neste documento, o termo equipe ou equipe de aplicativo descreve um grupo de pessoas em uma organização que estão trabalhando no mesmo componente de software ou atuando como um só. funcional. Por exemplo, uma equipe pode se referir a desenvolvedores de back-end de um microsserviço, analistas de BI de um aplicativo comercial ou até mesmo a equipes multifuncionais, como equipes de infraestrutura de Big Data.
Os clusters de equipe única de amostra mostrados na arquitetura são clusters que podem ser multilocatários (para membros da mesma equipe) ou de um único locatário.
- Como clusters efêmeros, os clusters de equipe única podem ser usados para jobs, como os engenheiros de dados, para executar jobs de processamento em lote do Spark ou por cientistas de dados para um job de treinamento de modelo.
Como clusters de longa duração, clusters de equipe única podem exibir análises de dados e cargas de trabalho de BI com escopo para uma única equipe ou pessoa.
Os clusters de equipe única estão localizados em projetos do Google Cloud que pertencem a uma equipe, o que simplifica a auditoria de uso, o faturamento e o isolamento de recursos. Por exemplo, somente membros da equipe única podem acessar os intervalos do Cloud Storage que são usados para manter os dados do cluster. Nessa abordagem, as equipes de aplicativo têm projetos dedicados. Portanto, os clusters de equipe única não são criados no Kerberos.
Recomendamos que você analise seus requisitos específicos e escolha as melhores combinações de dimensões para sua situação.
Como enviar jobs
Os usuários podem enviar jobs para ambos os tipos de clusters usando várias ferramentas, incluindo:
- A API REST, usando chamadas REST ou bibliotecas de cliente.
- A ferramenta de linha de comando gcloud da Google Cloud CLI em uma janela de terminal local ou no Console do Google Cloud no Cloud Shell, aberto em um navegador local.
- Um modelo de fluxo de trabalho do Dataproc, que é uma configuração de fluxo de trabalho reutilizável que define um gráfico de jobs com informações sobre onde executar esses jobs. Se o fluxo de trabalho usar a opção cluster gerenciado, ele usará um cluster temporário.
- Cloud Composer usando o operador do Dataproc. Os gráficos acíclicos dirigidos (DAGs, na sigla em inglês) do Composer também podem ser usados para orquestrar modelos de fluxo de trabalho do Dataproc.
- Abrir uma sessão SSH no nó mestre no cluster e enviar um job diretamente ou usando ferramentas como Apache Beeline Essa ferramenta geralmente é reservada apenas para administradores e usuários avançados. Um exemplo de usuário avançado é um desenvolvedor que quer solucionar problemas dos parâmetros de configuração de um serviço e verificá-los executando jobs de teste diretamente no nó mestre.
Rede
O diagrama a seguir destaca os conceitos de rede da arquitetura:
No diagrama anterior, a arquitetura de rede usa um padrão híbrido de malha, em que alguns recursos estão localizados no Google Cloud e outros estão no local. O padrão híbrido em malha usa uma VPC compartilhada, com um projeto host comum e projetos separados para cada tipo de cluster e equipe do Dataproc. A arquitetura é descrita em detalhes nas seções No Google Cloud e No local.
No Google Cloud
No Google Cloud, a arquitetura é estruturada usando uma VPC compartilhada. Com uma VPC compartilhada, os recursos de vários projetos se conectam a uma rede VPC comum. O uso de uma rede VPC comum permite que os recursos se comuniquem entre si com segurança e eficiência usando endereços IP internos dessa rede. Para configurar uma VPC compartilhada, crie os seguintes projetos:
- Projeto host: contém uma ou mais redes VPC compartilhadas usadas por todos os projetos de serviço.
Projetos de serviço: contém o Google Cloud. Um administrador de VPC compartilhada anexa os projetos de serviço ao projeto host para permitir que eles usem sub-redes e recursos na rede VPC compartilhada. Esse anexo é essencial para que os clusters de equipe única possam acessar o metastore centralizado do Hive.
Conforme mostrado no diagrama de Rede, recomendamos criar projetos de serviço separados para o cluster de metastore do Hive, os clusters de várias equipes e os clusters para cada equipe individual , Os membros de cada equipe da sua organização podem criar clusters de equipe única nos respectivos projetos.
Para permitir que os componentes dentro da rede híbrida se comuniquem, você precisa configurar regras de firewall para permitir o seguinte tráfego:
- Tráfego interno de cluster para serviços do Hadoop, incluindo HDFS NameNode, para se comunicar com o HDFS DataNodes e para o YARN ResourceManager para se comunicar com o YARN NodeManagers. Recomendamos o uso da filtragem com a conta de serviço do cluster para essas regras.
- Tráfego de cluster externo em portas específicas para se comunicar com o Hivemetastore (porta
tcp:9083,8020), KDC local (portatcp:88) e LDAPLDAP (porta636) e outros serviços externos centralizados que você usa no seu cenário específico, por exemplo, Kafka no Google Kubernetes Engine (GKE).
Todos os clusters do Dataproc nessa arquitetura são criados apenas com endereços IP internos. Para permitir que os nós de cluster acessem as APIs e os serviços do Google, ative o Acesso privado do Google para as sub-redes de cluster. Para permitir que administradores e usuários avançados acessem as instâncias de VM do endereço IP particular, use o encaminhamento de TCP do IAP para encaminhar SSH, RDP e outros tráfegos em um túnel criptografado.
As interfaces da Web do cluster dos aplicativos de cluster e componentes opcionais (por exemplo, Spark, Hadoop, Jupyter e Zeppelin) são acessadas com segurança por meio do Gateway de componentes do Dataproc. O Gateway de componentes do Dataproc é um HTTP -invertendo proxy baseado no Apache Knox.
No local
Este documento pressupõe que os recursos localizados no local são o serviço de diretório corporativo LDAP e o centro de distribuição de chaves (KDC, na sigla em inglês) corporativo do Kerberos, em que os principais de serviços do usuário e da equipe são definidos. Se você não precisa usar um provedor de identidade local, é possível simplificar a configuração usando o Cloud Identity e um KDC em um cluster do Dataproc ou em um máquina virtual.
Para se comunicar com o LDAP e o KDC locais, use o Cloud Interconnect ou o Cloud VPN. Essa configuração ajuda a garantir que a comunicação entre ambientes use endereços IP particulares se as sub-redes no endereço IP RFC 1918 não se sobrepuserem. Para mais informações sobre as diferentes opções de conexão, consulte Como escolher um produto de conectividade de rede.
Em um cenário híbrido, as solicitações de autenticação precisam ser tratadas com latência mínima. Para atingir essa meta, é possível usar as seguintes técnicas:
- Exiba todas as solicitações de autenticação para identidades de serviço do KDC no cluster e use apenas um provedor de identidade externo ao cluster para identidades do usuário. Espera-se que a maior parte do tráfego de autenticação seja solicitações de identidades de serviço.
- Se você estiver usando o AD como seu provedor de identidade, os Nomes principais do usuário (UPNs, na sigla em inglês) representam os usuários humanos e as contas de serviço do AD. Recomendamos replicar os UPNs do seu AD local para uma região do Google Cloud próxima aos clusters de data lake. Essa réplica do AD manipula solicitações de autenticação para UPNs, para que as solicitações nunca sejam transmitidas para o AD local. Cada KDC no cluster processa os nomes principais do serviço (SPNs, na sigla em inglês) usando a primeira técnica.
O diagrama a seguir mostra uma arquitetura que usa as duas técnicas:
No diagrama anterior, um AD local sincroniza UPNs com uma réplica do AD em uma região do Google Cloud. A réplica do AD autentica UPNs, e um KDC no cluster autentica SPNs.
Para informações sobre como implantar o AD no Google Cloud, consulte Como implantar um ambiente do Microsoft Active Directory tolerante a falhas. Para informações sobre como dimensionar o número de instâncias para controladores de domínio, consulte Como integrar o MIT Kerberos e o Active Directory.
Autenticação
O diagrama a seguir mostra os componentes usados para autenticar usuários em diferentes clusters do Hadoop. Com a autenticação, os usuários podem usar serviços como o Apache Hive ou o Apache Spark.
No diagrama anterior, os clusters nos domínios do Kerberos podem configurar a confiança entre realms para usar serviços em outros clusters, como o metastore do Hive. Os clusters não derivados podem usar um cliente Kerberos e uma tabela de chaves da conta para usar serviços em outros clusters.
Metastore do Hive compartilhado e protegido
O metastore Hive centralizado permite que vários clusters que executam diferentes mecanismos de consulta de código aberto, como Apache Spark, Apache Hive/Beeline e Presto, compartilhem metadados.
Você implanta o servidor metastore do Hive em um cluster do Dataproc do Kerberos e o banco de dados do metastore do Hive em um RDBMS remoto, como uma instância do MySQL no Cloud SQL. Como um serviço compartilhado, um cluster de metastore do Hive exibe apenas solicitações autenticadas. Para mais informações sobre como configurar o metastore do Hive, consulte Como usar o Apache Hive no Dataproc.
Em vez do metastore do Hive, é possível usar o metastore do Dataproc, que é um metastore do Apache Hive sem servidor, totalmente gerenciado e altamente disponível (dentro de uma região). Também é possível ativar o Kerberos para o serviço Metastore do Dataproc, conforme explicado em Como configurar o Kerberos para um serviço.
Kerberos
Nesta arquitetura, os clusters de várias equipes são usados para fins de análise e são gerados conforme o guia de configuração de segurança do Dataproc. O modo seguro do Dataproc cria um KDC no cluster e gerencia os principais de serviço e as guias de chave do cluster, conforme exigido pela especificação do modo seguro do Hadoop.
Uma keytab é um arquivo que contém um ou mais pares de principais do Kerberos e uma cópia criptografada da chave desse principal. Um keytab permite a autenticação programática do Kerberos
quando o login interativo com o
comando kinit
é inviável.
O acesso a uma keytab significa a capacidade de personificar os principais contidos nela. Portanto, um keytab é um arquivo altamente confidencial que precisa ser transferido e armazenado com segurança. Recomendamos o uso do Gerenciador de secrets para armazenar o conteúdo das tabelas de chaves antes que elas sejam transferidas para os respectivos clusters. Para ver um exemplo de como armazenar o conteúdo de um keytab, consulte Como configurar o Kerberos para um serviço. Depois que é feito o download de um keytab para o nó mestre do cluster, o arquivo precisa ter permissões de acesso a arquivos restritas.
O KDC no cluster processa as solicitações de autenticação para todos os serviços dentro desse cluster. Espera-se que a maioria das solicitações de autenticação seja esse tipo de solicitação. Para minimizar a latência, é importante que o KDC resolva essas solicitações sem que elas saiam do cluster.
As solicitações restantes são de usuários humanos e contas de serviço do AD. A réplica do AD no Google Cloud ou no provedor de ID central no local processa essas solicitações, conforme explicado na seção Local anterior.
Nesta arquitetura, os clusters de equipe única não são fragmentados, portanto, não há KDC presente. Para permitir que esses clusters acessem o metastore compartilhado do Hive, você só precisa instalar um cliente Kerberos. Para automatizar o acesso, use a tecla keytab da equipe. Para mais informações, consulte a seção Mapeamento de identidade mais adiante neste documento.
Confiança entre domínios do Kerberos em clusters de várias equipes
A confiança entre domínios é altamente relevante quando suas cargas de trabalho são híbridas ou em várias nuvens. A confiança entre domínios permite integrar identidades corporativas centrais aos serviços compartilhados disponíveis no data lake do Google Cloud.
No Kerberos, um realm define um grupo de sistemas em um KDC comum. Com a autenticação entre domínios, um usuário principal de um realm pode se autenticar em outro realm e usar os serviços dele. Essa configuração exige que você estabeleça a confiança entre domínios.
Na arquitetura, há três realms:
- EXAMPLE.COM: é o realm corporativo, em que todos os principais de usuários do Kerberos para usuários, equipes e serviços são definidos (UPNs, na sigla em inglês).
- MULTI.EXAMPLE.COM: é o realm que contém os clusters de várias equipes. O cluster é pré-configurado com os principais de serviços (SPNs, na sigla em inglês) para os serviços do Hadoop, como o Apache Spark e o Apache Hive.
- METASTORE.EXAMPLE.COM: é um realm para o metastore do Hive.
Os clusters de equipe única não são criados no Kerberos. Por isso, não pertencem a um realm.
Para poder usar os principais de usuários corporativos em todos os clusters, estabeleça as seguintes relações unidirecionais de confiança entre domínios:
Configure o realm de várias equipes e o realstore do metastore para confiar no realm corporativo. Com essa configuração, os principais definidos no domínio corporativo podem acessar os clusters e o metastore de várias equipes.
Ainda que a confiança possa ser transitiva, recomendamos que você configure o realm do metastore para ter uma confiança direta no realm corporativo. Essa configuração evita, dependendo da disponibilidade do realm multiequipe.
Configure o realm do metastore para confiar no realm de várias equipes, para que os clusters de várias equipes possam acessar o metastore. Essa configuração é necessária para permitir o acesso principal do HiveServer2 ao metastore.
Para mais informações, consulte Primeiros passos com clusters dataproc do Kerberos com confiança entre domínios e os arquivos de configuração do Terraform correspondentes no repositório do GitHub.
Se você preferir uma abordagem de IAM integrada ou nativa da nuvem para clusters com várias equipes e não precisar de gerenciamento de identidade híbrido, use Multilocação segura e baseada em conta de serviço do Dataproc Nesses clusters, várias identidades do IAM podem acessar o Cloud Storage e outros recursos do Google como contas de serviço diferentes.
Mapeamento de identidade em clusters de equipe única
Nas seções anteriores, descrevemos a configuração da estrutura do Kerberos da arquitetura. No entanto, os clusters de equipe única não são Kerberized, portanto, exigem uma técnica especial para permitir que eles participem desse ecossistema. Essa técnica usa a propriedade de separação do projeto do Cloud e as contas de serviço do IAM para isolar e ajudar a proteger as cargas de trabalho do Hadoop das equipes de aplicativo.
Conforme descrito na seção anterior Rede, cada equipe tem um projeto do Cloud correspondente em que pode criar clusters de equipe única. Dentro dos clusters de equipe única, um ou mais membros da equipe são os locatários do cluster. Esse método de segregação por projetos também restringe o acesso aos buckets do Cloud Storage (usados por esses clusters) às respectivas equipes.
Um administrador cria o projeto de serviço e provisiona a conta de serviço da equipe nesse projeto. Ao criar um cluster, essa conta de serviço é especificada como a conta de serviço do cluster.
O administrador também cria um principal do Kerberos para a equipe no domínio corporativo e cria a guia key correspondente. A guia key é armazenada com segurança no Gerenciador de secret e o administrador copia a keytab para o nó mestre do cluster. O principal do Kerberos permite acesso do cluster de equipe única ao metastore do Hive.
Para facilitar o provisionamento automatizado e reconhecer facilmente esses pares de identidades relacionadas, as identidades devem seguir uma convenção de nomenclatura comum, por exemplo:
- Conta de serviço da equipe:
revenue-reporting-app@proj-A.iam.gserviceaccount.com - Principal da equipe do Kerberos:
revenue_reporting/app@EXAMPLE.COM
Essa técnica de mapeamento de identidade oferece uma abordagem exclusiva para mapear uma identidade do Kerberos para uma conta de serviço, ambas pertencentes à mesma equipe.
Essas identidades são usadas de maneiras diferentes:
- A identidade do Kerberos dá ao cluster acesso a recursos compartilhados do Hadoop, como o metastore do Hive.
- A conta de serviço concede ao cluster acesso a recursos compartilhados do Google Cloud, como o Cloud Storage.
Essa técnica evita a necessidade de criar um mapeamento semelhante para cada membro da equipe. No entanto, como essa técnica usa uma conta de serviço ou um principal do Kerberos para toda a equipe, as ações no cluster do Hadoop não podem ser rastreadas para membros individuais da equipe.
Para gerenciar o acesso aos recursos de nuvem no projeto da equipe que estão fora do escopo dos clusters do Hadoop (como buckets do Cloud Storage, serviços gerenciados e VMs), um administrador adiciona os membros da equipe a um Grupo do Google. O administrador pode usar o grupo do Google para gerenciar permissões de IAM para toda a equipe acessar recursos de nuvem.
Ao conceder permissões do IAM a um grupo e não a membros individuais da equipe, você simplifica o gerenciamento do acesso do usuário quando os membros entram ou saem da equipe de aplicativos. Ao conceder permissões diretas do IAM ao grupo do Google da equipe, é possível desativar a falsificação de identidade para a conta de serviço, o que ajuda a simplificar a rastreabilidade de ações nos registros de auditoria do Cloud. Ao definir os membros da sua equipe, recomendamos que você equilibre o nível de granularidade necessário para gerenciar o acesso, usar recursos e auditar os esforços administrativos derivados dessas tarefas.
Se um cluster atender exatamente um usuário humano (um cluster de locatário único), em vez de uma equipe, use o recurso Autenticação pessoal de cluster do Dataproc. Os clusters com a Autenticação de cluster pessoal ativada são destinados apenas a cargas de trabalho interativas de curto prazo para serem executados com segurança como uma identidade de usuário final. Esses clusters usam as credenciais de usuário final do IAM para interagir com outros recursos do Google Cloud, como o Cloud Storage. Em vez de autenticar como a conta de serviço do cluster, o cluster é autenticado como usuário final. Nesse tipo de cluster, o Kerberos é ativado e configurado automaticamente para a comunicação segura dentro do cluster pessoal.
Fluxo de autenticação
Para executar um job em um cluster do Dataproc, os usuários têm muitas opções, conforme descrito na seção anterior Como enviar jobs. Em todos os casos, a conta de usuário ou de serviço precisa ter acesso ao cluster.
Quando um usuário executa um job em um cluster de várias equipes, há duas opções para um principal do Kerberos, conforme mostrado no diagrama a seguir:
O diagrama anterior mostra as seguintes opções:
- Se o usuário usar uma ferramenta do Google Cloud, como a API Dataproc, o Cloud Composer ou a ferramenta de linha de comando gcloud, para enviar a solicitação de job, o cluster usará o Principal do Kerberos do Dataproc para autenticar com o KDC e acessar o metastore do Hive.
- Se o usuário executar um job de uma sessão SSH, ele poderá enviar jobs diretamente nessa sessão usando o próprio principal do Kerberos do usuário.
Quando um usuário executa um job em um cluster de equipe única, há apenas um principal do Kerberos possível, o principal do Kerberos da equipe, como mostrado no diagrama a seguir:
No diagrama anterior, um job usa o principal do Kerberos da equipe quando o job precisa acessar o metastore do Hive compartilhado. Caso contrário, como os clusters de equipe única não são Kerberized, os usuários podem iniciar jobs usando a própria conta de usuário.
Para clusters de equipe única, é recomendável executar kinit para o principal de equipe como parte de uma ação de inicialização no momento da criação do cluster. Após a criação do cluster, use uma programação cron
de acordo com o ciclo de vida do tíquete definido, usando a
opção de comando timetime (-l).
Para executar kinit, a ação de inicialização primeiro faz o download da tecla key para o nó mestre do cluster.
Por motivos de segurança, é necessário restringir o acesso ao keytab.
Conceda permissões de leitura POSIX apenas à conta que executa kinit. Se possível, exclua a keytab e renove o token usando kinit -R para estender a vida útil usando um job cron até atingir a vida útil máxima do tíquete. Nesse momento,
o job cron pode fazer o download da chave novamente, executar novamente kinit e reiniciar o
ciclo de renovação.
Os tipos de cluster de uma ou várias equipes usam contas de serviço para acessar outros recursos do Google Cloud, como o Cloud Storage. Os clusters de equipe única usam a conta de serviço da equipe como a conta de serviço do cluster personalizado.
Autorização
Esta seção descreve os mecanismos de autorização detalhados e detalhados para cada cluster, conforme mostrado no diagrama a seguir:
A arquitetura no diagrama anterior usa o IAM para autorização detalhada e o Apache Ranger para autorização refinada. Esses métodos de autorização são descritos nas seções a seguir: Autorização detalhada e Autorização refinada.
Autorização aproximada
O IAM permite controlar o acesso de usuários e grupos aos recursos do projeto. O IAM define as permissões e os papéis que as concedem.
Há quatro papéis do Dataproc predefinidos: administrador, editor, visualizador e worker. Esses papéis concedem permissões do Dataproc que permitem aos usuários e contas de serviço realizar ações específicas em clusters, jobs, operações e modelos de fluxo de trabalho. Os papéis concedem acesso aos recursos do Google Cloud necessários para realizar as tarefas. Um desses recursos é o Cloud Storage, que recomendamos usar como camada de armazenamento do cluster, em vez do HDFS.
A granularidade das permissões do IAM do Dataproc não se estende ao nível dos serviços em execução em cada cluster, como o Apache Hive ou o Apache Spark. Por exemplo, é possível autorizar uma determinada conta a acessar dados de um bucket do Cloud Storage ou executar jobs. No entanto, não é possível especificar quais colunas do Hive a conta pode acessar com esse job. Na próxima seção, você verá como implementar esse tipo de autorização detalhada nos clusters.
Autorização detalhada
Para autorizar o acesso detalhado, use o componente opcional Ranger do Dataproc na arquitetura descrita em Práticas recomendadas para usar o Apache Ranger no Dataproc. Nessa arquitetura, o Apache Ranger está instalado em cada um dos clusters, tanto de equipe única quanto de várias equipes. O Apache Ranger fornece controle de acesso detalhado para seus aplicativos do Hadoop (autorização e auditoria) no nível de serviço, tabela ou coluna.
O Apache Ranger usa identidades fornecidas pelo repositório LDAP corporativo e definidas como principais do Kerberos. Em clusters de várias equipes, o daemon UserRanger atualiza periodicamente as identidades do Kerberos do servidor LDAP corporativo. Em clusters de equipe única, apenas a identidade da equipe é obrigatória.
Os clusters temporários apresentam um desafio porque são encerrados após a conclusão dos jobs, mas não podem perder as políticas do Ranger e os registros de administrador. Para enfrentar esse desafio, você externaliza políticas para um banco de dados central do Cloud SQL e externaliza registros de auditoria para pastas do Cloud Storage. Para mais informações, consulte Práticas recomendadas para usar o Apache Ranger no Dataproc.
Fluxo de autorização
Quando um usuário quer acessar um ou mais serviços do cluster para processar dados, a solicitação passa pelo seguinte fluxo:
- O usuário se autentica por meio de uma das opções descritas na seção Fluxo de autenticação.
- O serviço de destino recebe a solicitação do usuário e chama o plug-in correspondente do Apache Ranger.
- O plug-in recupera periodicamente as políticas do Ranger Policy Server. Essas políticas determinam se a identidade do usuário tem permissão para executar a ação solicitada no serviço específico. Se a identidade do usuário tiver permissão para executar a ação, o plug-in permitirá que o serviço processe a solicitação e o usuário receba os resultados.
- Toda interação do usuário com um serviço do Hadoop, permitida ou negada, é gravada nos registros do Ranger pelo servidor de auditoria do Ranger. Cada cluster tem a própria pasta de registros no Cloud Storage. O Dataproc também grava registros de jobs e clusters que podem ser visualizados, pesquisados, filtrados e arquivados no Cloud Logging.
Neste documento, as arquiteturas de referência usavam dois tipos de clusters do Dataproc: clusters de várias equipes e clusters de equipe única. Ao usar vários clusters do Dataproc que podem ser facilmente provisionados e protegidos, uma organização pode usar uma abordagem de job, produto ou focada em domínio em vez de clusters tradicionais e centralizados. Essa abordagem funciona bem com uma arquitetura geral Data Mesh, que permite que as equipes sejam totalmente proprietárias e seguras do data lake e das cargas de trabalho, além de oferecer dados como serviço.
A seguir
- Leia sobre os primeiros passos com clusters do Dataproc no Kerberos com confiança entre domínios e os arquivos de configuração do Terraform correspondentes no repositório do GitHub.
- Leia sobre as práticas recomendadas para usar o Apache Ranger no Dataproc
- Leia sobre como configurar o acesso seguro a dados no Dataproc para analistas de dados usando ferramentas de Business Intelligence (BI), como Tableau e Looker.
- Leia sobre como mover seu sistema Apache Hadoop local para o Google Cloud.
- Leia sobre as Práticas recomendadas para federar o Google Cloud com um provedor de identidade externo.
- Para mais arquiteturas de referência, diagramas e práticas recomendadas, confira a Central de arquitetura do Cloud.