VPC Service Controls com a Gemini Enterprise Agent Platform

O VPC Service Controls pode ajudar a reduzir o risco de exfiltração de dados da Gemini Enterprise Agent Platform. Use o VPC Service Controls para criar um perímetro de serviço que proteja os recursos e dados especificados por você. Por exemplo, quando você usa o VPC Service Controls para proteger o Agent Platform, os artefatos a seguir não podem deixar o perímetro de serviço:

  • Dados de treinamento de um modelo personalizado ou AutoML
  • Modelos que você criou
  • Modelos pesquisados usando a pesquisa de arquitetura neural da Agent Platform
  • Solicitações de inferências on-line
  • Resultados de uma solicitação de inferência em lote
  • Modelos do Gemini

Como controlar o acesso às APIs do Google

As APIs do Agent Platform, conforme descrito em Como acessar o Gemini Enterprise Agent Platform no local e na multinuvem, abrangem uma variedade de opções de acessibilidade, incluindo a Internet pública, o Private Service Connect para APIs do Google e o Acesso privado do Google.

Acesso público

Por padrão, essas APIs públicas podem ser acessadas pela Internet. No entanto, as permissões do IAM são necessárias para uso. Embora recursos como o Private Service Connect para APIs do Google e o Acesso privado do Google facilitem a comunicação particular em arquiteturas de rede híbrida, eles não eliminam a acessibilidade da Internet pública para APIs da Agent Platform.

Para estabelecer um controle granular sobre o acesso à API e restringir explicitamente a exposição da Internet pública, a implementação do VPC Service Controls se torna essencial. Quando você estabelece um perímetro do VPC Service Controls (VPC-SC) e inclui o Gemini Enterprise nos serviços protegidos, todo o acesso público à Internet à instância do Agent Platform é bloqueado automaticamente. Como resultado, os usuários que tentam acessar os serviços da Agent Platform de maneira programática ou usando o console do Google Google Cloud têm o acesso negado, a menos que estejam incluídos em uma lista de permissões.

Para restaurar o acesso de fontes autorizadas fora do perímetro (por exemplo, usuários nos escritórios corporativos), consulte Permitir acesso público a recursos protegidos de fora de um perímetro do VPC Service Controls para instruções de implantação.

Acesso particular

As organizações que precisam restringir as APIs públicas do Google ao acesso particular podem usar o VPC Service Controls em combinação com o Private Service Connect para APIs do Google (pacote do VPC Service Controls) ou o Acesso privado do Google. Quando implantadas em redes híbridas e dentro delas Google Cloud, as duas opções permitem o acesso particular às APIs do Google no local. No entanto, o Private Service Connect para APIs do Google também oferece flexibilidade na definição de um endereço IP personalizado e um nome de endpoint DNS.

Como prática recomendada, use o IP virtual restrito (VIP) com o Private Service Connect para APIs do Google ou o Acesso privado do Google para fornecer uma rota de rede particular para solicitações aos Google Cloud serviços sem expor as solicitações à Internet. O VIP restrito é compatível com todas as APIs que o VPC Service Controls pode proteger e que exigem considerações para redes locais e VPC. Veja alguns exemplos:

Como controlar o acesso à API por meio do acesso a serviços particulares

As APIs da Agent Platform a seguir implantadas com acesso a serviços particulares exigem configuração de rede adicional quando implementadas em um ambiente protegido com o VPC Service Controls:

  • Pesquisa de vetor (consulta de índice)
  • Treinamento personalizado (plano de dados)
  • Pipelines da Agent Platform
  • Endpoints particulares de previsão on-line

Por exemplo, o Agent Platform Pipelines é um serviço gerenciado pelo Google (produtor), implantado em um projeto de locatário único e rede VPC com a capacidade de escalonar serviços com suporte com base nos requisitos do consumidor. A comunicação entre as redes do produtor e do consumidor é estabelecida com o peering de rede VPC, exceto para a saída da Internet, que é roteada pela rede do produtor.

Na rede do produtor, existe uma rota padrão que permite a saída da Internet, além de acesso irrestrito às APIs do Google. A atualização da rede do produtor para oferecer suporte ao VIP restrito exige a ativação do VPC Service Controls para peerings, que executa as seguintes ações em todos os serviços com suporte implantados na rede VPC do produtor de serviços:

  • Remove a rota padrão IPv4 (destino 0.0.0.0/0, próximo salto no gateway de Internet padrão).
  • Cria zonas particulares gerenciadas pelo Cloud DNS e autoriza essas zonas para a rede VPC do produtor de serviços. As zonas incluem googleapis.com, pkg.dev, gcr.io e outros domínios ou nomes de host necessários para APIs e serviços do Google compatíveis com o VPC Service Controls.
  • Os dados de registro nas zonas resolvem todos os nomes de host para 199.36.153.4, 199.36.153.5, 199.36.153.6 e 199.36.153.7.

Um método alternativo para remover a rota padrão da rede do produtor sem afetar os serviços gerenciados pelo Google é usar a VPN de alta disponibilidade pelo Cloud Interconnect que consiste nas seguintes etapas:

  1. Implante uma rede VPC de serviços, além da VPN de alta disponibilidade, na rede VPC do consumidor.
  2. Implante serviços gerenciados pelo Google na rede VPC de serviços.
  3. Ative o VPC Service Controls para peerings.
  4. Anuncie a sub-rede de acesso a serviços particulares como um anúncio de rota personalizada do Cloud Router se os serviços gerenciados exigirem acessibilidade no local.
  5. Atualize o peering de rede VPC de serviços com a opção de exportar rotas personalizadas.

Suporte do VPC Service Controls para pipelines de ajuste de IA generativa

O suporte do VPC Service Controls é fornecido no pipeline de ajuste dos seguintes modelos:

  • text-bison for PaLM 2
  • BERT
  • T5
  • A família de modelos textembedding-gecko.

Como usar o VPC Service Controls com pipelines da plataforma de agentes do Gemini Enterprise

O perímetro de serviço bloqueia o acesso da Agent Platform a APIs e serviços de terceiros na Internet. Se você estiver usando Google Cloud componentes de pipeline ou criando seus próprios componentes de pipeline personalizados para uso com pipelines da Agent Platform, não será possível instalar dependências do PyPI no registro público do Índice de pacotes do Python (PyPI, na sigla em inglês). Em vez disso, faça uma destas ações:

Usar contêineres personalizados

Como prática recomendada de software de produção, os autores de componentes precisam usar componentes Python em contêineres e criar as dependências na imagem do contêiner. Assim, nenhuma instalação ativa é necessária durante a execução de um pipeline. Uma maneira de fazer isso é a seguinte:

  1. Crie sua própria imagem de contêiner com o SDK do Kubeflow Pipelines e outros pacotes pré-instalados. Por exemplo, você pode usar us-docker.pkg.dev/vertex-ai/training/tf-cpu.2-17:latest como a camada de base da imagem e adicionar uma camada extra para instalar os pacotes no tempo de build do contêiner.
  2. Atualize o código de definição do componente para definir o caminho base_image e a flag install_kfp_package como False. Essa flag instrui o compilador do KFP a não injetar um comando pip install kfp na linha de comando do contêiner, porque o pacote do SDK do Kubeflow Pipelines já está instalado na imagem. Exemplo:

    @component(
        base_image='gcr.io/deeplearning-platform-release/tf-cpu.2-17',
        install_kfp_package=False,
    )
    def my_component(...):
        ...
    

Instalar pacotes de um repositório do Artifact Registry

Como alternativa, você pode criar um repositório do Artifact Registry no seu projeto, armazenar pacotes Python nele e configurar o ambiente da Agent Platform para instalar a partir dele, conforme descrito nesta seção. Para mais informações, consulte Gerenciar pacotes Python.

Configurar papéis e permissões

  1. A conta de serviço do ambiente do Agent Platform precisa ter o papel iam.serviceAccountUser.
  2. Se você instalar pacotes PyPI personalizados de um repositório na rede do projeto e esse repositório não tiver um endereço IP público:
    1. Atribua permissões para acessar esse repositório à conta de serviço do ambiente.
    2. Verifique se a conectividade com esse repositório está configurada no seu projeto.

Crie o repositório

  1. Crie um repositório do Artifact Registry no modo VPC no seu projeto.
  2. Armazene os pacotes Python necessários no repositório.

Configure o ambiente da Agent Platform para instalar a partir do repositório

Para instalar pacotes PyPI personalizados de um ou mais repositórios do Artifact Registry, faça uma chamada semelhante à seguinte para @dsl.component:

@dsl.component(packages_to_install=["tensorflow"],
pip_index_urls=['https://us-central1-python.pkg.dev/mygcpproject1/pypi-repo1/simple', 'https://us-central1-python.pkg.dev/mygcpproject2/pypi-repo2/simple'],)
def hello_world(text: str) -> str:
    import my_package
    import tensorflow

    return my_package.hello_world(text)

Como usar o VPC Service Controls com a interface do PSC

As APIs da Agent Platform a seguir implantadas com a interface do Private Service Connect exigem configuração de rede adicional quando implementadas em um ambiente protegido com o VPC Service Controls:

  • Treinamento personalizado (plano de dados)
  • Pipelines da Agent Platform
  • Endpoints particulares de inferência on-line
  • Agent Runtime

A capacidade de serviço dos produtores do Agent Platform de acessar a internet pública depende da configuração de segurança do seu projeto, especificamente se você está usando ou não o VPC Service Controls:

  • Sem o VPC Service Controls: o locatário gerenciado pelo Google que hospeda a Agent Platform mantém o acesso padrão à Internet. Esse tráfego de saída sai diretamente do ambiente seguro e gerenciado pelo Google em que o serviço do produtor é executado. A exceção a esse comportamento é o Agent Runtime, que não fornece saída da Internet. Em vez disso, é necessário implantar uma VM de proxy com um endereço RFC 1918 para saída da Internet.

  • Com o VPC Service Controls: quando o projeto está incluído em um perímetro do VPC Service Controls (VPC-SC), o ambiente gerenciado pelo Google que hospeda a Agent Platform tem o acesso padrão à Internet bloqueado. Essa restrição é uma medida de segurança projetada para evitar a exfiltração de dados. Para permitir que a Agent Platform acesse a Internet pública nesse cenário, é necessário configurar explicitamente um caminho de saída seguro que roteie o tráfego pela rede VPC.

O método recomendado envolve:

  1. Implantar um servidor proxy dentro do perímetro da VPC em uma sub-rede RFC 1918.
  2. Criar um gateway do Cloud NAT para permitir que a VM de proxy acesse a Internet.
  3. Definir o servidor proxy (endereço IP ou FQDN) no ambiente de execução.

Não há proxy de rede prescrito ou preferencial para essa tarefa. Você pode usar qualquer solução adequada. Exemplos incluem: Squid Proxy, HAProxy, Envoy, e TinyProxy.

Criação do perímetro de serviço

Para uma visão geral da criação de um perímetro de serviço, consulte Criar um perímetro de serviço na documentação do VPC Service Controls.

Como adicionar serviços restritos ao perímetro

Ao estabelecer um perímetro de serviço, recomendamos que você inclua todos os serviços restritos como uma prática recomendada de segurança. Essa abordagem abrangente ajuda a minimizar possíveis vulnerabilidades e acesso não autorizado. No entanto, pode haver cenários em que sua organização tenha requisitos específicos focados na proteção do Gemini Enterprise Agent Platform e das APIs interconectadas. Nesses casos, você tem a flexibilidade de selecionar e incluir apenas as APIs específicas do Agent Platform que são essenciais para suas operações.

As APIs da Agent Platform que podem ser incorporadas ao perímetro de serviço incluem o seguinte:

  • O Gemini Enterprise oferece suporte aos seguintes serviços e recursos:
    • Inferência em lote
    • Conjuntos de dados
    • Feature Store da Agent Platform (veiculação on-line do Bigtable)
    • Agent Platform Feature Store (veiculação on-line otimizada) (descontinuado)
    • IA generativa na plataforma de agentes do Gemini Enterprise (Gemini)
    • Model Registry
    • Inferência on-line
    • Ajuste de modelos abertos
    • Pesquisa de vetor (criação de índice)
    • Pesquisa de vetor (consulta de índice)
    • Treinamento personalizado (plano de controle)
    • Treinamento personalizado (plano de dados)
    • Pipelines da Agent Platform
    • Endpoints particulares de inferência on-line
    • Colab Enterprise
    • Agent Runtime
    • Clusters de treinamento gerenciados
  • A API Notebooks oferece suporte ao seguinte serviço:
    • Vertex AI Workbench

Limitações

As limitações a seguir se aplicam ao usar o VPC Service Controls:

  • Para rotular dados, é preciso adicionar os endereços IP dos rotuladores a um nível de acesso.
  • Para os componentes do pipeline, os componentes iniciam os contêineres que verificam a imagem de base para todos os requisitos. Google Cloud O pacote do KFP, bem como todos os pacotes listados no argumento packages_to_install, são os requisitos de um contêiner. Se algum requisito especificado não estiver presente na imagem de base (fornecida ou personalizada), o componente vai tentar fazer o download deles no Índice de pacotes do Python (PyPI). Como o perímetro de serviço bloqueia o acesso da Gemini Enterprise Agent Platform a APIs e serviços de terceiros na Internet, o download falha com Connection to pypi.org timed out. Para saber como evitar esse erro, consulte Como usar o VPC Service Controls com pipelines do Agent Platform.
  • Ao usar o VPC Service Controls com kernels personalizados no Vertex AI Workbench, é preciso configurar o peering de DNS para enviar solicitações de *.notebooks.googleusercontent.com para a sub-rede 199.36.153.8/30 (private.googleapis.com) em vez de 199.36.153.4/30 (restricted.googleapis.com).
  • Ao usar o VPC Service Controls com a Vertex AI Inference, os endpoints precisam ser criados depois que o projeto for adicionado ao perímetro de serviço. Se um endpoint for criado em um projeto que não faz parte de um perímetro de serviço e, posteriormente, esse projeto for adicionado a um perímetro de serviço, a tentativa de implantar um modelo nesse endpoint vai falhar. Se o endpoint for um endpoint público compartilhado, então o envio de uma solicitação ao endpoint também vai falhar. Da mesma forma, a tentativa de implantar um modelo em um endpoint vai falhar se o endpoint foi criado em um projeto que fazia parte de um perímetro de serviço e, posteriormente, o projeto foi removido.
  • Ao usar o VPC Service Controls com o Agent Runtime, o projeto precisa fazer parte de um perímetro de serviço antes de implantar o agente. Se um agente for implantado antes que o projeto seja adicionado a um perímetro, ele não será protegido pelo VPC Service Controls e continuará tendo acesso à Internet pública.
  • As implantações públicas com um clique do Model Garden (endpoint dedicado) não são compatíveis em um ambiente VPC-SC. Em vez disso, use um endpoint particular que ofereça suporte ao VPC Service Controls. Para mais informações, consulte Implantar um modelo em um endpoint particular.
  • A geração de registros de solicitações e respostas não está disponível com o VPC Service Controls.

A seguir