Nesta página, apresentamos as práticas recomendadas para criar uma arquitetura multitenant e hospedar código não confiável com o Cloud Run. Como um cliente do Cloud de Confiance by S3NS , um "inquilino" é definido como um dos seus próprios clientes, e "código não confiável" é o código fornecido por esses inquilinos para ser executado na sua plataforma.
Casos de uso
Os casos de uso dessas arquiteturas incluem:
- Plataformas de hospedagem de apps: você oferece uma plataforma em que seus clientes implantam o código. Por exemplo, uma plataforma de hospedagem na Web (os clientes fornecem um servidor da Web).
- Plataformas de hospedagem de agentes: seus clientes usam SDKs para criar agentes de IA, e sua plataforma os executa em segundo plano.
- Plataformas de modelos ajustados: você oferece a capacidade de personalizar modelos de IA para cada cliente.
- Funções definidas pelo usuário: seu software permite que os clientes definam uma lógica personalizada usando código. Por exemplo, você fornece um mecanismo de análise e quer permitir que os clientes escrevam funções personalizadas, ou você fornece um gateway de API e quer permitir que os clientes filtrem ou modifiquem solicitações com base na própria lógica personalizada.
- Extensibilidade de software como serviço (SaaS): talvez você esteja oferecendo um SaaS e queira permitir que os clientes ampliem os recursos dele usando extensões. Essas extensões podem ser escritas por clientes ou parceiros.
Cloud de Confiance clientes estão usando o Cloud Run em produção para esses casos de uso.
Desafios das plataformas multilocatárias
Os desafios típicos da criação dessa arquitetura incluem:
- Segurança: não é possível verificar ou higienizar o código fornecido. Código não confiável pode incluir ações maliciosas ou dependências vulneráveis. Se não for isolado corretamente, o código não confiável poderá acessar dados sensíveis de outros locatários. Simplesmente empacotar o código em um contêiner não é um limite de segurança forte o suficiente. O código também precisa ser restrito no que ele pode fazer aplicando o princípio de privilégio mínimo de permissões.
- Eficiência de custos: essa arquitetura pode ficar cara se cada locatário gerar custos fixos para sua plataforma.
- Gerenciamento de locatários: gerenciar centenas de milhares de locatários pode ser difícil, principalmente quando se trata de exclusão de dados.
Benefícios do Cloud Run
Uma arquitetura baseada no Cloud Run oferece uma solução para desafios comuns com muitos benefícios, como segurança, eficiência de custos e gerenciamento de locatários.
Segurança
O Cloud Run oferece os recursos de segurança prontos para uso relevantes para essa arquitetura:
- Isolamento de computação: o Cloud Run garante um isolamento estrito entre instâncias de contêiner, seja do mesmo serviço ou de serviços diferentes de projetos diferentes. Para mais informações sobre segurança de contêineres e ambientes de execução, consulte Visão geral do design de segurança.
- Isolamento de rede: o Cloud Run não apenas coloca os contêineres em sandbox, mas também fornece uma pilha de rede multitenant.
- Identidade do serviço: as cargas de trabalho do Cloud Run podem ser configuradas para ter identidades dedicadas com permissões restritas.
Economia
- Redução da escala a zero e pagamento por uso: as instâncias do Cloud Run são reduzidas automaticamente a zero quando não estão em uso, garantindo que as cargas de trabalho hospedadas só sejam cobradas quando precisam ser executadas. Resultando em uma utilização de recursos muito eficiente em comparação com arquiteturas que usam máquinas virtuais "sempre ativas".
- Faturamento por solicitação: além do escalonamento até zero, você pode aproveitar um modelo de faturamento ainda mais granular que cobra apenas quando as solicitações são processadas, oferecendo uma eficiência de custo ainda maior.
- Sob demanda e com inicialização rápida: quando reduzidos, os serviços do Cloud Run podem ser escalonados verticalmente de novo rapidamente, resultando em pouca latência percebida pelo usuário final do aplicativo implantado.
- Rotulagem automática de custos: todos os custos informados pelo Cloud Run são rotulados, permitindo automatizar a atribuição e o rastreamento de custos dos seus locatários.
- Compromissos para reduzir os custos agregados: no nível da conta de faturamento, é possível usar descontos por uso contínuo flexíveis para otimizar os gastos com qualquer uso básico do Cloud Run.
Gestão de locatários
Devido à natureza sob demanda, os custos do Cloud Run não são maiores ao usar vários projetos Cloud de Confiance , permitindo o gerenciamento de locatários conforme descrito em Organizar seus projetos Cloud de Confiance .
Arquitetura de destino para plataformas multilocatárias
Em um nível alto, esta é a arquitetura recomendada:
Como organizar seus projetos do Cloud de Confiance
Você precisa configurar uma organização Cloud de Confiance , o faturamento off-line e entrar em contato com sua equipe de conta para informar que você está agindo como uma conta de revendedor. ACloud de Confiance pode trabalhar com você para garantir que os canais de comunicação adequados sejam implementados para a mitigação de abusos.
Use pastas para organizar seus projetos Cloud de Confiance . É essencial colocar em pastas diferentes os projetos que executam seu código de terceiros e os projetos que executam código não confiável dos locatários. Você precisa automatizar a integração de locatários para que a criação dos projetos e recursos de um locatário não exija intervenção humana.
O Google recomenda usar um Cloud de Confiance projeto por locatário. Também é possível hospedar vários locatários no mesmo projeto, mas isso tem outras limitações:
Locatário único por projeto Cloud de Confiance (recomendado)
Nessa arquitetura, cada locatário da plataforma é hospedado em umCloud de Confiance projeto dedicado, o que traz muitos benefícios:
- Segurança mais simples: o projeto Cloud de Confiance é um limite estrito para todos os recursos que ele contém. Isso significa que, se um locatário precisar de acesso a vários recursos doCloud de Confiance , como vários serviços do Cloud Run e um bucket do Cloud Storage, você poderá usar o projeto como um perímetro seguro.
- Menos limitado:
- O número de recursos em um determinado projeto é limitado. Por exemplo, o Cloud Run permite criar apenas 1.000 serviços por região em um projeto. Há limites semelhantes no número de contas de serviço e outros recursos relacionados.
- O número de projetos é uma cota e pode ser aumentado. Não há limites para esse número em uma organização do Cloud de Confiance . Há um limite flexível de 100.000 projetos por conta de faturamento, que pode ser multiplicado ao conversar com o Google. Sua organização também pode criar várias contas de faturamento e agrupá-las em um "grupo de contas" (atualmente em prévia privada).
- Monitoramento e gerenciamento mais simples:
- Usar um projeto por locatário facilita os processos de exclusão de dados, em que excluir dados de um locatário se resume a excluir o projeto respectivo.
- OCloud de Confiance Monitoring e o Logging funcionam em todos os projetos e permitem monitorar toda a frota.
- Com as cotas no nível do projeto, é possível limitar a utilização de recursos do Cloud Run para um determinado locatário, alinhando os limites aos seus próprios níveis de preços.
- Com as políticas personalizadas da organização, é possível aplicar a todos os projetos de uma pasta restrições específicas, como regiões disponíveis ou alocação máxima de CPU/memória.
A criação de um projeto Cloud de Confiance e a inicialização de APIs e recursos podem ter latência. O Google recomenda usar um pool de projetos pré-criados que você atribui aos seus locatários quando necessário.
Vários locatários por projeto Cloud de Confiance (não recomendado)
É possível hospedar vários locatários no mesmo projeto Cloud de Confiance, mas o Google não recomenda essa arquitetura.
Muitos serviços do Cloud de Confiance têm limites de recursos por projeto. Por exemplo, o Cloud Run tem um limite não ajustável de 1.000 serviços do Cloud Run por região em um projeto. Consequentemente, hospedar vários locatários por projeto ainda exige que você gerencie uma frota de projetos Cloud de Confiance , o que aumenta a complexidade do gerenciamento de locatários. Do ponto de vista da segurança, os projetos do Cloud de Confiance são projetados como um limite de segurança. Hospedar dois locatários distintos nos mesmos projetos exige mais cuidado quando se trata de segurança. Por exemplo, usando contas de serviço dedicadas e permissões refinadas.
Como implantar em várias regiões
Para confiabilidade e escalonabilidade, o Google recomenda distribuir as implantações de locatários em várias Cloud de Confiance regiões. Cada aplicativo de locatário é implantado em uma única região, mas você pode usar regiões diferentes para locatários diferentes. A seleção da região pode ser aleatória ou levar em consideração a localização do locatário para otimizar a latência.
Roteamento de solicitações e domínios personalizados
Se você quiser expor os serviços do Cloud Run do seu locatário aos usuários finais, adicione seu próprio domínio e use sua própria lógica de roteamento. Por exemplo, para mapear um subdomínio para o projeto Cloud de Confiance que hospeda o serviço do locatário.
É possível implementar seu serviço de roteamento personalizado, mas o Google recomenda usar um balanceador de carga de aplicativo externo global com Service Extensions para lógica de roteamento. As Service Extensions podem ser implementadas como plug-ins (em que a lógica é executada inline com o processamento de solicitações) ou chamadas (a lógica de roteamento é delegada a um serviço separado do Cloud Run, que pode chamar um dos bancos de dados multirregionais escalonáveis doCloud de Confiance, como o Spanner).
Usar um balanceador de carga de aplicativo também permite adicionar uma camada de armazenamento em cache aproveitando o Cloud CDN e proteção adicional contra ataques distribuídos de negação de serviço (DDoS) à sua plataforma usando o Cloud Armor.
Reputação e abuso
Qualquer plataforma de hospedagem que possa executar código não confiável está sujeita a abuso.
Recomendamos usar uma conta do Cloud Billing diferente para cada um dos níveis de reputação que você oferece. Por exemplo, os locatários do nível sem custo financeiro não podem estar vinculados à mesma conta de faturamento dos clientes que pagam valores altos. O Google pode considerar essas contas de faturamento em diferentes níveis de reputação.
Conforme descrito em Organizar seus projetos do Cloud de Confiance , além de separar por contas de faturamento, use pastas para organizar os projetos. O Google pode ajudar você a definir cotas no nível da pasta para garantir que todos os recursos em uma pasta nunca consumam mais do que um máximo definido, permitindo que você gerencie melhor o custo da sua plataforma.
Por padrão, o Google remove automaticamente as cargas de trabalho abusivas de acordo com os Cloud de Confiance Termos de Serviço. O Google também pode registrar eventos de detecção de abuso no Cloud Logging, para que você possa tomar medidas.