Data lake do Kerber no Dataproc

Last reviewed 2024-04-16 UTC

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 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:

A arquitetura de alto nível de um data lake do Kerberos no Google Cloud usando o Dataproc.

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:

  1. 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.

  2. 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:

Uma arquitetura de rede que usa um padrão de malha híbrido.

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 (porta tcp:88) e LDAPLDAP (porta 636) 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çã