> ## Documentation Index > Fetch the complete documentation index at: https://private-7c7dfe99-trino-dialect.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Segurança de rede do BYOC > Implante o ClickHouse em sua própria infraestrutura de nuvem export const Image = ({img, alt, size = "lg"}) => { const normalizedSize = ["sm", "md", "lg"].includes(size) ? size : "lg"; return
{alt}
; };
## Conexões entre o plano de controle do ClickHouse e sua VPC de BYOC
O plano de controle do ClickHouse Cloud mantém vários tipos de conexão para operar e dar suporte à sua implantação de BYOC: | Finalidade | Tipo de conexão | Observações | | -------------------------------------------------------- | ---------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Operações diárias — servidor da API do Kubernetes** | Pública com filtragem por IP (padrão), ou privada via Tailscale ou AWS VPC Lattice | Os serviços de gerenciamento se comunicam com o servidor da API do Kubernetes (EKS/GKE/AKS) pela rede pública, com acesso restrito por listas de permissão de IP. Após a implantação inicial, você pode opcionalmente alternar para acesso privado via Tailscale ou, na AWS, VPC Lattice. | | **Operações diárias — APIs do provedor de Cloud** | VPC do ClickHouse → provedor de Cloud | Os serviços de gerenciamento fazem chamadas às APIs do seu provedor de Cloud (por exemplo, EKS e EC2 na AWS, GKE no GCP, AKS no Azure) a partir do próprio ambiente do ClickHouse Cloud. Isso não envolve sua VPC/VNet nem o Tailscale. | | **Solução de problemas — serviço ClickHouse** | Tailscale | Engenheiros do ClickHouse acessam o serviço ClickHouse (por exemplo, tabelas de sistema) para diagnóstico via Tailscale. | | **Solução de problemas — servidor da API do Kubernetes** | Tailscale | Engenheiros do ClickHouse acessam o servidor da API do Kubernetes para diagnóstico do cluster via Tailscale. |
## APIs do provedor de Cloud vs. a API do Kubernetes
É fácil confundir dois caminhos de controle distintos. Eles diferem quanto à origem do tráfego, à forma de autenticação e à aplicabilidade do Tailscale: | | APIs do provedor de Cloud | Servidor da API do Kubernetes | | ------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **O que gerencia** | Recursos de Cloud: o próprio cluster do Kubernetes, grupos de nós, balanceadores de carga, buckets de armazenamento, DNS | Workloads no cluster: pods do ClickHouse, operadores e respectivas configurações | | **Destino do tráfego** | Os endpoints públicos de API do provedor de Cloud (por exemplo, `eks.amazonaws.com`, `ec2.amazonaws.com`) — esse tráfego nunca entra na sua VPC/VNet | O endpoint de API do seu cluster na sua conta | | **Autenticação** | AWS: `sts:AssumeRole` entre contas para assumir `ClickHouseManagementRole` e a função de gerenciamento específica da infraestrutura, protegido por um ID externo. GCP: impersonação de conta de serviço (sem chaves). Azure: identidade federada para o principal de serviço do ClickHouse (sem troca de credenciais) | Credenciais temporárias do Kubernetes emitidas pela API do provedor de Cloud (por exemplo, `eks:GetToken` usando a função assumida) | | **Aplicabilidade do Tailscale** | **Nenhuma.** Essas chamadas partem diretamente da rede do ClickHouse Cloud para o provedor de Cloud e não podem ser roteadas pelo Tailscale nem pela sua rede | Endpoint público restrito por padrão aos IPs de egress do ClickHouse; pode ser alterado para acesso privado via Tailscale ou, na AWS, VPC Lattice | | **Sua trilha de auditoria** | O AWS CloudTrail (ou os equivalentes no GCP/Azure) na sua conta registra todas as chamadas com a identidade assumida | Na AWS, os logs do plano de controle do EKS — incluindo o log de auditoria — são enviados para um grupo de logs do CloudWatch na sua conta (consulte [serviços AWS faturáveis](/pt-BR/products/bring-your-own-cloud/reference/billable-aws-services)); no GCP e no Azure, entre em contato com o suporte para confirmar ou habilitar o registro de auditoria do plano de controle do seu cluster | Em resumo: apenas o tráfego da API do Kubernetes e de solução de problemas pode usar o Tailscale. As chamadas à API do provedor de Cloud sempre partem da rede do ClickHouse Cloud e chegam aos endpoints do provedor — não é possível roteá-las pelo Tailscale, pois elas nunca entram na sua rede.
### Limites de permissões por origem de rede
Se a sua organização restringe a assunção de funções do IAM ou as chamadas à Cloud API com base na origem de rede (por exemplo, SCPs da AWS ou condições de confiança de funções que usam `aws:SourceIp` ou `aws:SourceVpc`), essas condições bloquearão a automação do ClickHouse: as chamadas se originam legitimamente da rede do ClickHouse Cloud, e não da sua. Isente as funções criadas pelo ClickHouse dessas condições ou entre em contato com o ClickHouse para obter os intervalos atuais de IPs de egress, caso seja necessário usar uma allowlist por origem. A seção a seguir descreve como a rede privada **Tailscale** é usada para solução de problemas e acesso opcional de gerenciamento.
## Rede privada Tailscale
O Tailscale fornece uma conexão de rede privada de confiança zero entre os serviços de gerenciamento do ClickHouse Cloud e sua implantação BYOC. Esse canal seguro permite que engenheiros do ClickHouse realizem solução de problemas e operações de gerenciamento sem exigir acesso de entrada à rede pública nem configurações complexas de VPN; os próprios agentes fazem conexões somente de saída e precisam de acesso à internet de saída para alcançar o serviço de coordenação do Tailscale.
### Visão geral
O Tailscale cria um túnel de rede privado e criptografado entre o plano de controle do ClickHouse (na VPC do ClickHouse) e o plano de dados do seu BYOC (na sua VPC). Essa conexão é usada exclusivamente para: * **Operações de gerenciamento**: serviços de gerenciamento do ClickHouse que coordenam com a sua infraestrutura de BYOC * **Acesso para solução de problemas**: engenheiros do ClickHouse acessando servidores da API do Kubernetes e tabelas de sistema do ClickHouse para diagnóstico * **Acesso a métricas**: os dashboards centralizados de monitoramento do ClickHouse acessam métricas da stack Prometheus implantada na sua VPC de BYOC, fornecendo aos engenheiros do ClickHouse observabilidade do ambiente. O Tailscale é usado **apenas para operações de gerenciamento e solução de problemas**. Ele **nunca é usado para tráfego de consultas** nem para acesso a dados de clientes. Todos os dados dos clientes permanecem na sua VPC e nunca são transmitidos por conexões do Tailscale.
### Como o Tailscale funciona no BYOC
BYOC Tailscale Para cada serviço ou endpoint que precisa ser acessado via Tailscale, o ClickHouse BYOC implanta: 1. **Registro de endereço tailnet**: cada endpoint registra um endereço tailnet exclusivo (por exemplo, `k8s.xxxx.us-east-1.aws.byoc.clickhouse-prd.com` para o servidor da API do Kubernetes) 2. **Contêiner do agente Tailscale**: um contêiner do agente Tailscale é executado no seu cluster do Kubernetes e é responsável por: * Conectar-se ao servidor de coordenação do Tailscale * Registrar serviços para torná-los detectáveis * Coordenar a configuração da rede com os pods do Kubernetes do Nginx 3. **Pod do Kubernetes do Nginx**: um pod do Kubernetes do Nginx que: * Faz a terminação do tráfego TLS do Tailscale * Encaminha o tráfego para os IPs apropriados dentro do seu cluster do Kubernetes
### Processo de conexão de rede
O estabelecimento da conexão no Tailscale segue estas etapas: 1. **Conexão inicial**: * Os agentes do Tailscale em ambas as pontas (o ambiente do engenheiro do ClickHouse e seu cluster do Kubernetes BYOC) se conectam ao servidor de coordenação do Tailscale * O agente do cluster registra o serviço do Kubernetes para que ele possa ser descoberto * Os engenheiros do ClickHouse precisam fazer um escalonamento interno para obter visibilidade do serviço 2. **Modo de conexão**: * **Modo direto**: os agentes tentam estabelecer uma conexão direta por meio de um túnel de travessia de NAT * **Modo de retransmissão**: se o modo direto falhar, a comunicação passa a usar o modo de retransmissão por meio de um servidor DERP (Distributed Encrypted Relay Protocol) do Tailscale 3. **Criptografia**: * Toda a comunicação é criptografada de ponta a ponta * Cada agente do Tailscale gera seu próprio par de chaves pública e privada (semelhante a uma PKI) * O tráfego permanece criptografado independentemente de usar o modo direto ou de retransmissão
### Recursos de segurança
**Conexões somente de saída**: * Os agentes do Tailscale no seu cluster do Kubernetes iniciam conexões de saída com os servidores de coordenação/relay do Tailscale * **Nenhuma conexão de entrada é necessária** — nenhuma regra do Security Group precisa permitir tráfego de entrada para os agentes do Tailscale * Isso reduz a superfície de ataque e simplifica a configuração de segurança da rede **Controle de acesso**: * Os engenheiros precisam solicitar acesso por meio de um fluxo interno de aprovação antes que o Tailscale possa encaminhá-los para um endpoint do cliente * O acesso é limitado no tempo e expira automaticamente * Todo acesso é auditado e registrado Para ver a política completa de acesso a dados — o que os engenheiros podem ver, autenticação por certificado e auditoria no lado do cliente — consulte [ClickHouse data access](/pt-BR/products/bring-your-own-cloud/reference/clickhouse-data-access).
### Acesso aos serviços de gerenciamento
Por padrão, os serviços de gerenciamento da ClickHouse acessam seu cluster do Kubernetes BYOC por meio do endereço IP público do servidor da API do Kubernetes, que é restrito apenas aos endereços IP do gateway NAT da ClickHouse. **Configuração opcional de endpoint privado**: * Você pode configurar o servidor da API do Kubernetes para usar apenas um endpoint privado * Nesse caso, os serviços de gerenciamento acessam o servidor de API via Tailscale (semelhante ao acesso humano para solução de problemas) ou, na AWS, via VPC Lattice (consulte [Conexão privada com a API do Kubernetes](/pt-BR/products/bring-your-own-cloud/configuration/configurations#k8s-api-private-connection)) * Por padrão, o endpoint público (restrito aos endereços IP NAT da ClickHouse) é mantido como mecanismo de contingência para necessidades emergenciais de investigação e suporte; após a verificação do acesso privado, ele pode ser totalmente desabilitado em coordenação com a ClickHouse
### Fluxo de tráfego de rede
**Fluxo de conexão do Tailscale**: 1. Agente do Tailscale no seu cluster do Kubernetes → servidor de coordenação do Tailscale (saída) 2. Agente do Tailscale na máquina do engenheiro → servidor de coordenação do Tailscale (saída) 3. Conexão direta ou retransmitida estabelecida entre os agentes 4. O tráfego criptografado flui pelo túnel estabelecido 5. O pod do Kubernetes do Nginx no EKS faz a terminação de TLS e roteia para os serviços internos **Nenhuma transmissão de dados do cliente**: * As conexões do Tailscale são usadas apenas para gerenciamento e solução de problemas * O tráfego de consulta e os dados do cliente nunca passam pelo Tailscale * Todos os dados do cliente permanecem dentro da sua VPC Para mais detalhes técnicos sobre como o Tailscale é implementado no BYOC, consulte o post do blog [Building ClickHouse BYOC on AWS](https://clickhouse.com/blog/building-clickhouse-byoc-on-aws#tailscale-connection). Para saber o que os engenheiros do ClickHouse podem ler depois de se conectarem e como o ClickHouse audita esse acesso, consulte [ClickHouse data access](/pt-BR/products/bring-your-own-cloud/reference/clickhouse-data-access).
## Limites de rede
Esta seção aborda os diferentes tipos de tráfego de rede de entrada e saída da VPC BYOC do cliente: * **Entrada**: Tráfego que entra na VPC BYOC do cliente. * **Saída**: Tráfego originado na VPC BYOC do cliente e enviado a um destino externo. * **público**: Um endpoint de rede acessível pela internet pública. * **privado**: Um endpoint de rede acessível apenas por conexões privadas, como VPC peering, VPC Private Link ou Tailscale. **A entrada do Istio é implantada atrás de um AWS NLB para aceitar tráfego de clientes ClickHouse.** *Entrada, público ou privado* O gateway de entrada do Istio faz a terminação de TLS. O certificado, provisionado pelo CertManager com Let's Encrypt, é armazenado como um Secret no cluster EKS. O tráfego entre o Istio e o ClickHouse é [criptografado pela AWS](https://docs.aws.amazon.com/whitepapers/latest/logical-separation/encrypting-data-at-rest-and--in-transit.html#:~:text=All%20network%20traffic%20between%20AWS,supported%20Amazon%20EC2%20instance%20types), já que ambos estão na mesma VPC. Por padrão, a entrada é acessível publicamente com filtragem por lista de permissões de IP. Os clientes podem configurar VPC peering para torná-la privada e desativar conexões públicas. Recomendamos fortemente configurar um [filtro de IP](/pt-BR/products/cloud/guides/security/connectivity/setting-ip-filters) para restringir o acesso.
### Acesso para solução de problemas
*Entrada, Privado* Os engenheiros do ClickHouse Cloud precisam de acesso para solução de problemas via Tailscale. Em implantações BYOC, esse acesso é provisionado com autenticação por certificado just-in-time. Consulte [ClickHouse data access](/pt-BR/products/bring-your-own-cloud/reference/clickhouse-data-access) para ver a política de acesso completa.
### Coletor de faturamento
*Saída, Privado* O coletor de faturamento coleta dados de faturamento do ClickHouse e os envia para um bucket do S3 pertencente ao ClickHouse Cloud. Ele é executado como um sidecar junto ao contêiner do servidor ClickHouse, coletando periodicamente métricas de CPU e memória. As solicitações na mesma região são roteadas por endpoints de serviço de gateway da VPC.
### Alertas
*Saída, Pública* O AlertManager está configurado para enviar alertas ao ClickHouse Cloud quando o cluster ClickHouse do cliente não estiver saudável. As métricas e os logs são armazenados na VPC BYOC do cliente. No momento, os logs são armazenados localmente no EBS. Em uma atualização futura, eles serão armazenados no LogHouse, um serviço ClickHouse dentro da VPC BYOC. As métricas usam uma pilha de Prometheus e Thanos, armazenada localmente na VPC BYOC.
### Estado do serviço
*Saída, Pública* O State Exporter envia informações sobre o estado do serviço ClickHouse e dos backups (eventos de status operacional, não conteúdos de backup) para uma fila SQS de propriedade do ClickHouse Cloud.