Usar o VPC Service Controls com endpoints de catálogo federado

No catálogo do ambiente de execução do Lakehouse, as regras de perímetro do VPC Service Controls para endpoints de catálogo federado permitem consultar tabelas externas do Apache Iceberg no BigQuery, além de ajudar a evitar a exfiltração de dados. Quando os projetos ou buckets do Cloud Storage doGoogle Cloud residem em um perímetro de serviço, é possível configurar regras de saída para o Amazon S3 e o Microsoft Azure Data Lake Storage (ADLS) Gen2 ou regras de entrada para o Cloud Storage. Essas regras autorizam a sincronização de metadados e consultas de tabelas registradas no AWS Glue Data Catalog, no Databricks Unity Catalog, no Snowflake Horizon Catalog e no Workday Data Lake.

Se os projetos não estiverem dentro de um perímetro de serviço, os endpoints do catálogo federado vão funcionar sem nenhuma configuração do VPC Service Controls. Para conexões entre nuvens com o SAP Business Data Cloud (SAP BDC), consulte Configuração do VPC Service Controls para o SAP BDC. Para proteger os buckets acessados pelo endpoint do catálogo REST do Apache Iceberg no modo de venda de credenciais, consulte Usar o VPC Service Controls com venda de credenciais.

Antes de começar

  1. Configure um endpoint de catálogo federado para o AWS Glue Data Catalog, o Databricks Unity Catalog, o Snowflake Horizon Catalog ou o Workday Data Lake.

  2. Crie um ou mais perímetros de serviço para seus projetos, dependendo de onde os arquivos de tabela estão armazenados:

  3. Se usuários ou contas de serviço fora do perímetro consultarem o endpoint do catálogo federado, adicione uma regra de entrada que os admita no perímetro do projeto do endpoint do catálogo.

Funções exigidas

Para receber as permissões necessárias para configurar perímetros de serviço, peça ao administrador que conceda a você os seguintes papéis do IAM na sua organização:

Para mais informações sobre a concessão de papéis, consulte Gerenciar o acesso a projetos, pastas e organizações.

Também é possível conseguir as permissões necessárias usando papéis personalizados ou outros papéis predefinidos.

Casos de uso e regras de perímetro necessárias

As regras de perímetro que você configura dependem de onde os arquivos de tabela residem e de onde os autores de chamada de consulta são executados:

Caso de uso Regra de perímetro obrigatória Etapas de configuração
Consultar tabelas entre nuvens no Amazon S3 ou no ADLS Gen2: consulte tabelas do Apache Iceberg em buckets do s3:// ou contêineres do abfss:// usando um endpoint de catálogo federado em um projeto protegido do BigQuery, bloqueando a saída externa não autorizada. Adicione uma regra de saída no perímetro do projeto do endpoint do catálogo que permita que a conta de serviço blirc-... do endpoint do catálogo e os principais de consulta leiam os buckets ou contêineres externos aprovados. Encontre a conta de serviço do endpoint do catálogo e adicione uma regra de saída para o armazenamento em nuvem externo.
Acessar tabelas de catálogo externo em buckets protegidos do Cloud Storage: consulte tabelas do Databricks Unity Catalog ou do Snowflake Horizon Catalog armazenadas em um bucket do gs:// dentro de um perímetro que restringe o storage.googleapis.com (mesmo no mesmo projeto e perímetro que o endpoint do catálogo federado). Adicione uma regra de entrada no perímetro do projeto do bucket do Cloud Storage que permita que a conta de serviço Google Cloud do catálogo remoto acesse storage.googleapis.com. Adicione uma regra de entrada para buckets do Cloud Storage em um perímetro de serviço.
Permitir consultas de autores de chamadas fora do perímetro do endpoint do catálogo: execute jobs do BigQuery no projeto do endpoint do catálogo usando contas de analista, ferramentas de BI ou contas de serviço de carga de trabalho localizadas fora do perímetro. Adicione uma regra de entrada no perímetro do projeto de endpoint do catálogo que permita que os autores de chamadas externos acessem bigquery.googleapis.com e biglake.googleapis.com, além da regra de armazenamento para o local da tabela. Configure a entrada do autor da chamada usando a referência de regras de entrada e siga o procedimento de armazenamento para o local da tabela.

Como o VPC Service Controls avalia o tráfego de endpoints de catálogo federado

Um endpoint de catálogo federado realiza duas operações distintas que leem do armazenamento subjacente: sincronização de metadados e consultas do BigQuery. A forma como o VPC Service Controls avalia essas operações depende de onde os arquivos da tabela estão armazenados:

  • Armazenamento em nuvem externo (Amazon S3 ou Azure Data Lake Storage Gen2): o VPC Service Controls avalia a saída do perímetro de serviço do projeto do endpoint do catálogo em relação à identidade do autor da chamada em Google Cloud e ao bucket ou contêiner externo de destino:

    Operação Identidade avaliada Recurso avaliado
    Sincronização de metadados A conta de serviço do Lakehouse provisionada automaticamente do endpoint do catálogo (blirc-PROJECT_NUMBER-ID@gcp-sa-biglakerestcatalog.iam.gserviceaccount.com) O bucket ou contêiner externo que contém os metadados do Apache Iceberg da tabela.
    Consulta A conta de usuário ou de serviço que executa o job do BigQuery Os buckets ou contêineres externos que armazenam os metadados e os arquivos de dados da tabela.

    Para tabelas armazenadas no Amazon S3 ou no ADLS Gen2, a regra de saída do perímetro precisa incluir todos os seguintes itens:

    • Identidades: a conta de serviço do endpoint do catálogo e os principais da consulta.
    • Recursos externos: cada bucket ou contêiner que suas tabelas usam para metadados e arquivos de dados.
    • Operações: bigquery.googleapis.com (com a permissão externalResource.read) e biglake.googleapis.com (com todos os métodos, '*').

  • Cloud Storage (locais externos do Databricks Unity Catalog ou do Snowflake Horizon Catalog no Google Cloud): durante a sincronização de metadados e as consultas do BigQuery, o BigQuery e o Lakehouse leem do Cloud Storage usando as credenciais de escopo reduzido vendidas pelo catálogo remoto, em vez da conta de serviço blirc-... do endpoint do catálogo. Quando o projeto do bucket do Cloud Storage está dentro de um perímetro de serviço que restringe o storage.googleapis.com, o storage.googleapis.com avalia a conta de serviço do Google Cloud do catálogo remoto como uma identidade externa que tenta entrar no perímetro. Essa avaliação se aplica mesmo quando o bucket está no mesmo projeto e perímetro de serviço que o endpoint do catálogo federado. Adicione uma regra de entrada ao perímetro de serviço do projeto do bucket que permita que a conta de serviçoGoogle Cloud do catálogo remoto acesse storage.googleapis.com.

O VPC Service Controls avalia apenas as leituras de armazenamento realizadas pelo BigQuery e pelo Lakehouse (biglake.googleapis.com). Ele não avalia as chamadas que o Lakehouse faz para o endpoint de API do catálogo remoto (como listar namespaces e tabelas) e não controla os mecanismos de consulta externos que leem o armazenamento diretamente.

Formatos de recursos externos

Especifique recursos externos em regras de saída como um URI exato de bucket ou contêiner. Caminhos de objeto e caracteres curinga não são aceitos. Os nomes de buckets, contêineres e contas de armazenamento precisam estar em letras minúsculas. As regras que contêm caracteres maiúsculos nesses nomes são rejeitadas quando você as salva. Os URIs do Azure Data Lake Storage Gen2 (abfss://) e do Armazenamento de Blobs do Azure (azure://) não são intercambiáveis nas regras de saída do VPC Service Controls. Para endpoints de catálogo federados, é necessário especificar o formato abfss://.

A tabela a seguir mostra os formatos de URI de recursos externos compatíveis com endpoints de catálogo federado:

Serviço de armazenamento Formatar Exemplo
Amazon S3 s3://BUCKET_NAME s3://my-iceberg-warehouse
Azure Data Lake Storage Gen2 abfss://CONTAINER@STORAGE_ACCOUNT.dfs.core.windows.net abfss://unity-catalog-storage@mystorageaccount.dfs.core.windows.net

Encontrar a conta de serviço do endpoint do catálogo

O Lakehouse provisiona uma conta de serviço dedicada para cada endpoint de catálogo federado quando você cria o endpoint de catálogo. Para tabelas no Cloud Storage, pule para Adicionar uma regra de entrada para buckets do Cloud Storage em um perímetro de serviço. Se as tabelas estiverem armazenadas no Amazon S3 ou no ADLS Gen2, recupere o endereço de e-mail da conta de serviço para a regra de saída:

gcloud biglake iceberg catalogs describe CATALOG_ID \
    --project=PROJECT_ID \
    --format='value(biglake-service-account)'

Substitua:

  • CATALOG_ID: o ID do endpoint do catálogo federado.
  • PROJECT_ID: o ID do projeto do Google Cloud que contém o endpoint do catálogo federado.

O comando retorna um endereço de e-mail no seguinte formato:

blirc-PROJECT_NUMBER-ID@gcp-sa-biglakerestcatalog.iam.gserviceaccount.com

Adicionar uma regra de saída para o armazenamento em nuvem externo

Se as tabelas acessadas pelo endpoint do catálogo federado estiverem armazenadas no Amazon S3 ou no ADLS Gen2, adicione uma regra de saída ao perímetro de serviço que protege o projeto do endpoint do catálogo.

Console

  1. No console do Google Cloud , acesse a página VPC Service Controls.

    Acessar o VPC Service Controls

  2. Selecione sua organização e política de acesso e clique no nome do perímetro de serviço que contém o projeto de endpoint do catálogo.

  3. Clique em Editar e, na seção Política de saída, clique em Adicionar uma regra de saída.

  4. Na seção De, em Identidades, selecione Selecionar identidades e grupos, clique em Adicionar identidades e adicione a conta de serviço do endpoint do catálogo e os usuários ou contas de serviço que executam consultas.

  5. Na seção Para:

    1. Selecione Recursos externos, clique em Adicionar recursos, insira cada bucket do s3:// ou contêiner do abfss:// que suas tabelas usam e clique em Adicionar recursos externos.
    2. Em Operações ou papéis do IAM, configure os seguintes serviços na tabela Operações da API:
      • API BigQuery (bigquery.googleapis.com): para restringir a entrada padrão de todos os métodos (*) ao acesso somente leitura, abra o menu de ações de bigquery.googleapis.com e clique em Editar, selecione Selecionar métodos, selecione a permissão externalResource.read e clique em Adicionar métodos selecionados.
      • API BigLake (biglake.googleapis.com): clique em Adicionar operações, selecione API BigLake (biglake.googleapis.com), selecione Todos os métodos e clique em Adicionar todos os métodos.

  6. Clique em Salvar.

CLI da gcloud

  1. Crie um arquivo chamado egress.yaml que especifique a conta de serviço do endpoint do catálogo, os principais de consulta e todos os buckets ou contêineres externos usados pelas tabelas. Para ver o esquema completo, consulte a referência de regras de saída.

    - egressFrom:
    identities:
    - serviceAccount:CATALOG_ENDPOINT_SERVICE_ACCOUNT
    - user:QUERY_USER_EMAIL
  egressTo:
    externalResources:
    - s3://S3_BUCKET_NAME
    - abfss://ADLS_CONTAINER@STORAGE_ACCOUNT.dfs.core.windows.net
    operations:
    - serviceName: bigquery.googleapis.com
      methodSelectors:
      - permission: externalResource.read
    - serviceName: biglake.googleapis.com
      methodSelectors:
      - method: '*'

    Substitua:

    • CATALOG_ENDPOINT_SERVICE_ACCOUNT: o endereço de e-mail da conta de serviço do endpoint do catálogo que você recuperou anteriormente.
    • QUERY_USER_EMAIL: o endereço de e-mail de um usuário ou conta de serviço que executa consultas pelo endpoint do catálogo federado. Para uma conta de serviço, use o prefixo serviceAccount: em vez de user:. Como alternativa, substitua identities por identityType: ANY_IDENTITY para permitir qualquer principal no perímetro.
    • S3_BUCKET_NAME, ADLS_CONTAINER e STORAGE_ACCOUNT: os locais de armazenamento externo que contêm os metadados e os arquivos de dados da tabela. Inclua apenas as entradas que se aplicam ao seu provedor de armazenamento.

  2. Encontre o ID numérico da política de acesso da sua organização:

    gcloud access-context-manager policies list \
    --organization=ORGANIZATION_ID \
    --format='value(name)'

    Substitua ORGANIZATION_ID pelo ID numérico da organização.

  3. Aplique a regra de saída ao perímetro de serviço:

    gcloud access-context-manager perimeters update PERIMETER_NAME \
    --policy=POLICY_ID \
    --set-egress-policies=egress.yaml

    Substitua:

    • PERIMETER_NAME: o nome do perímetro de serviço.
    • POLICY_ID: o ID numérico da sua política de acesso.

    Para testar a regra antes de aplicá-la, use gcloud access-context-manager perimeters dry-run update para aplicá-la a uma configuração de simulação e, após a validação, use gcloud access-context-manager perimeters dry-run enforce para aplicá-la.

  4. Verifique se a regra está ativa:

    gcloud access-context-manager perimeters describe PERIMETER_NAME \
    --policy=POLICY_ID \
    --format='yaml(status.egressPolicies)'

Adicionar uma regra de entrada para buckets do Cloud Storage em um perímetro de serviço

Se as tabelas em um catálogo remoto (como o Databricks Unity Catalog ou o Snowflake Horizon Catalog) forem armazenadas em um bucket do Cloud Storage protegido por um perímetro que restringe storage.googleapis.com, adicione uma regra de entrada ao perímetro de serviço do projeto do bucket. Como o BigQuery e o Lakehouse se autenticam no Cloud Storage usando a conta de serviço Google Cloud do catálogo remoto (não a conta de serviço blirc-...), essa regra é necessária mesmo quando o bucket está no mesmo projeto e perímetro que o endpoint do catálogo federado.

Console

  1. No console do Google Cloud , acesse a página VPC Service Controls.

    Acessar o VPC Service Controls

  2. Selecione sua organização e política de acesso e clique no nome do perímetro de serviço que protege o projeto que contém o bucket do Cloud Storage.

  3. Clique em Editar e, na seção Política de entrada, clique em Adicionar uma regra de entrada.

  4. Na seção De:

    1. Em Identidades, selecione Selecionar identidades e grupos, clique em Adicionar identidades e adicione a conta de serviço do Google Cloud provisionada pelo catálogo remoto para o bucket do Cloud Storage.
    2. Em Origens, selecione Todas as origens (ou selecione Selecionar origens para especificar um nível de acesso).

  5. Na seção Para:

    1. Em Recursos, escolha Selecionar recursos. Na guia Projetos, clique em Adicionar projetos, selecione o projeto que contém o bucket do Cloud Storage e clique em Adicionar projetos selecionados.
    2. Em Operações ou papéis do IAM, selecione Selecionar operações, clique em Adicionar operações, selecione API Storage do Cloud (storage.googleapis.com), selecione Todos os métodos e clique em Adicionar todos os métodos. Como alternativa, selecione Selecionar métodos para escolher métodos de serviço compatíveis específicos (como google.storage.objects.get, google.storage.objects.list e google.storage.buckets.get) e clique em Adicionar métodos selecionados.

  6. Clique em Salvar.

CLI da gcloud

  1. Crie um arquivo chamado ingress.yaml que permita que a conta de serviçoGoogle Cloud do catálogo remoto acesse storage.googleapis.com no projeto do bucket. Para ver o esquema completo, consulte a referência de regras de entrada.

    - ingressFrom:
    identities:
    - serviceAccount:REMOTE_CATALOG_GCS_SERVICE_ACCOUNT
    sources:
    - accessLevel: '*'
  ingressTo:
    operations:
    - serviceName: storage.googleapis.com
      methodSelectors:
      - method: '*'
    resources:
    - projects/BUCKET_PROJECT_NUMBER

    Substitua:

    • REMOTE_CATALOG_GCS_SERVICE_ACCOUNT: o endereço de e-mail da conta de serviço doGoogle Cloud provisionado pelo catálogo remoto para acessar o bucket do Cloud Storage (por exemplo, de DESCRIBE STORAGE CREDENTIAL no Databricks Unity Catalog ou DESC EXTERNAL VOLUME no Snowflake Horizon Catalog).
    • BUCKET_PROJECT_NUMBER: o número do projeto que contém o bucket do Cloud Storage.

  2. Encontre o ID numérico da política de acesso da sua organização:

    gcloud access-context-manager policies list \
    --organization=ORGANIZATION_ID \
    --format='value(name)'

    Substitua ORGANIZATION_ID pelo ID numérico da organização.

  3. Aplique a regra de entrada ao perímetro de serviço que protege o projeto do bucket:

    gcloud access-context-manager perimeters update BUCKET_PERIMETER_NAME \
    --policy=POLICY_ID \
    --set-ingress-policies=ingress.yaml

    Substitua:

    • BUCKET_PERIMETER_NAME: o nome do perímetro de serviço que protege o projeto do bucket.
    • POLICY_ID: o ID numérico da sua política de acesso.

    Para testar a regra antes de aplicá-la, use gcloud access-context-manager perimeters dry-run update para aplicá-la a uma configuração de simulação e, após a validação, use gcloud access-context-manager perimeters dry-run enforce para aplicá-la.

  4. Verifique se a regra está ativa:

    gcloud access-context-manager perimeters describe BUCKET_PERIMETER_NAME \
    --policy=POLICY_ID \
    --format='yaml(status.ingressPolicies)'

Verificar a configuração

As atualizações da política de perímetro de serviço podem levar até 30 minutos para serem propagadas. Depois que a regra entrar em vigor, verifique se a sincronização de metadados e as consultas do BigQuery são concluídas sem negações do VPC Service Controls:

  1. Aguarde a conclusão do próximo ciclo de sincronização de metadados programado e, em seguida, verifique os registros de auditoria de política negada nos registros de auditoria do Cloud para confirmar que não há violações do VPC Service Controls. A sincronização é executada automaticamente na programação de atualização e não pode ser acionada manualmente.

    No Análise de registros, selecione o projeto protegido: o projeto de endpoint do catálogo para armazenamento em nuvem externo ou o projeto de bucket do Cloud Storage para tabelas do Cloud Storage. Para mais informações, consulte Recuperar erros do VPC Service Controls nos registros de auditoria. Execute a seguinte consulta:

    log_id("cloudaudit.googleapis.com/policy")
protoPayload.metadata.@type:"type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"

    Se as entradas de violação aparecerem após a propagação da regra, inspecione os campos egressViolations.targetResource, ingressViolations.targetResource e authenticationInfo.principalEmail na entrada de registro para confirmar se eles correspondem aos recursos e às identidades na regra. Se as novas tabelas não forem sincronizadas e nenhuma entrada VpcServiceControlAuditMetadata aparecer, verifique as permissões e credenciais do catálogo remoto. Consulte Resolver problemas de acesso a dados entre nuvens.

  2. Execute uma consulta de teste em uma tabela no BigQuery usando a convenção de nomenclatura P.C.N.T (Project.Catalog.Namespace.Table) de quatro partes:

    SELECT COUNT(*)
FROM `PROJECT_ID.CATALOG_ID.NAMESPACE.TABLE_NAME`;

    Substitua:

    • PROJECT_ID: o ID do projeto do Google Cloud que contém o endpoint do catálogo federado.
    • CATALOG_ID: o ID do endpoint do catálogo federado.
    • NAMESPACE: o namespace no endpoint do catálogo federado.
    • TABLE_NAME: o nome de uma tabela no namespace.

    Se uma consulta for bloqueada pelo VPC Service Controls, a mensagem de erro vai incluir um valor vpcServiceControlsUniqueIdentifier. Filtre os registros de auditoria de política negada na Análise de registros correspondendo protoPayload.metadata.vpcServiceControlsUniqueId a esse identificador:

    log_id("cloudaudit.googleapis.com/policy")
protoPayload.metadata.@type:"type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"
protoPayload.metadata.vpcServiceControlsUniqueId="UNIQUE_IDENTIFIER"

    Substitua UNIQUE_IDENTIFIER pelo valor vpcServiceControlsUniqueIdentifier da mensagem de erro.

A seguir