Conectividade privada
O Cherri Code oferece suporte à conectividade de rede privada para equipes corporativas que precisam usar o Cherri Code com sistemas inacessíveis pela internet pública. Isso inclui GitHub Enterprise Server, GitLab Enterprise, Bitbucket Data Center, Artifactory, Nexus, APIs privadas de controle de código-fonte e tráfego de webhook desses sistemas para o Cherri Code.
A mesma configuração de conectividade privada é usada em todos os serviços do Cherri Code que precisam acessar seu sistema de controle de código-fonte, incluindo agentes na nuvem, Bugbot e serviços de backend do Cherri Code.
Para configurar a conectividade privada, entre em contato com [email protected] ou seu representante de vendas do Cherri Code.
Opções compatíveis
| Opção | Ideal para | Provedor de nuvem | Status |
|---|---|---|---|
| AWS PrivateLink | Conectividade privada entre o Cherri Code e seu provedor de Git ou repositório de pacotes, incluindo o tráfego de webhooks de volta ao Cherri Code | AWS | Compatível |
| Cloudflare Tunnel | Acesso do Cherri Code a uma origem privada quando o AWS PrivateLink não for viável | Qualquer ambiente capaz de executar cloudflared | Compatível |
Como escolher
Use o AWS PrivateLink quando seu provedor de Git privado ou repositório de pacotes estiver na AWS ou puder ser colocado atrás de um AWS Network Load Balancer. Essa é a opção preferencial para GitHub Enterprise Server e GitLab Enterprise auto-hospedados.
O AWS PrivateLink pode atender a duas direções de tráfego:
- O Cherri Code acessa seu provedor de Git privado para clonar repositórios e chamar APIs do Git.
- Seu provedor de Git envia webhooks ou callbacks ao Cherri Code via
api2.cursor.sh, sem saída para a internet pública.
Use o Cloudflare Tunnel quando não for possível publicar um serviço de endpoint da AWS ou quando precisar de um modelo de implantação que exija apenas um túnel de saída da sua rede.
Se sua equipe precisar do Google Private Service Connect (PSC), entre em contato com o Cherri Code. Atualmente, o Cherri Code não oferece um serviço de PSC voltado para clientes.
Pré-requisitos
Antes de começar, verifique se você tem:
- Um espaço de trabalho do Cherri Code Enterprise
- Um GitHub Enterprise Server, GitLab Enterprise, Bitbucket Data Center ou repositório privado de pacotes auto-hospedado (como Artifactory ou Nexus), acessível via HTTPS na porta 443
- Um certificado TLS publicamente confiável para o hostname do Git ou do repositório
- Controle do DNS desse hostname
- Permissões da AWS para criar serviços de endpoint ou endpoints de interface da VPC, se usar o AWS PrivateLink
- Permissão para executar
cloudflared, se usar o Cloudflare Tunnel
O Cherri Code não oferece suporte a certificados autoassinados, conexões não criptografadas, SSH, portas personalizadas ou serviços de endpoint exclusivos para IPv6 nesses caminhos de conectividade privada.
Se você usar um proxy na frente do GitHub Enterprise Server, verifique se ele permite que a integração de app do GitHub do Cherri Code use as APIs REST e GraphQL autenticadas do GitHub.
AWS PrivateLink
O AWS PrivateLink oferece suporte a tráfego privado nos dois sentidos entre o Cherri Code e seu provedor de Git ou repositório de pacotes. Talvez você precise de um dos sentidos ou de ambos, dependendo da sua política de rede.
Direção 1: do Cherri Code para seu provedor de Git ou repositório de pacotes
Use esta opção quando o Cherri Code precisar clonar repositórios, chamar APIs do Git ou acessar um repositório privado de pacotes, como Artifactory ou Nexus.
1. Crie um serviço de endpoint da AWS
Crie um Network Load Balancer na frente do endpoint HTTPS do seu provedor de Git ou repositório de pacotes. Publique esse balanceador de carga como um serviço de endpoint de VPC da AWS.
Envie ao Cherri Code:
- Nome do serviço de endpoint, por exemplo,
com.amazonaws.vpce.us-east-1.vpce-svc-0123456789abcdef0 - Região da AWS
- hostname do Git ou do repositório, por exemplo,
github.example.comouartifactory.example.com - Se o DNS privado gerenciado pela AWS está habilitado no seu serviço de endpoint
- Se o Network Load Balancer preserva os IPs dos clientes ou se o backend filtra os IPs de origem
Se o serviço de endpoint estiver fora de us-east-1, habilite o acesso entre regiões nele.
2. Autorize a entidade principal da AWS do Cherri Code
O Cherri Code fornecerá a entidade principal da AWS a ser adicionada à lista de entidades principais permitidas do seu serviço de endpoint. Adicione exatamente a entidade principal fornecida pelo Cherri Code:
arn:aws:iam::<cursor-aws-account-id>:rootO Cherri Code não pode criar o endpoint de interface até que essa entidade principal seja autorizada. Se a entidade principal estiver ausente ou não corresponder exatamente, a AWS retornará InvalidServiceName.
Se o balanceador de carga preservar os IPs dos clientes ou se o backend filtrar IPs de origem, permita estes CIDRs de sub-rede do Cherri Code PrivateLink:
10.2.8.0/2110.2.24.0/2110.2.40.0/213. Aceite a conexão do endpoint
Depois que o Cherri Code criar o endpoint de interface, aceite a conexão do endpoint na sua conta da AWS se o serviço de endpoint exigir aceitação manual.
4. Configurar o DNS
Se o serviço de endpoint expuser DNS privado gerenciado pela AWS para o hostname do Git ou do repositório, o Cherri Code habilitará o DNS privado no endpoint de interface.
Se o serviço de endpoint não expuser DNS privado, o Cherri Code criará o DNS privado do seu lado e mapeará esse hostname para o nome DNS do endpoint.
Use no Cherri Code o mesmo hostname presente no certificado TLS e no DNS.
Direção 2: Do seu provedor de Git para api2.cursor.sh
Use esta opção quando o host do GitHub Enterprise Server ou GitLab Enterprise não puder acessar a internet pública, mas ainda precisar enviar webhooks ou callbacks ao Cherri Code.
O Cherri Code disponibiliza um serviço de endpoint AWS PrivateLink para api2.cursor.sh. Crie um endpoint de interface da VPC na sua conta da AWS e habilite o DNS privado para que api2.cursor.sh seja resolvido para IPs privados do endpoint pela rede do seu provedor de Git.
Detalhes do serviço de endpoint
O Cherri Code confirmará se a sua entidade principal da AWS está na lista de permissão antes de você criar o endpoint.
| Campo | Valor |
|---|---|
| Nome do serviço | com.amazonaws.vpce.us-east-1.vpce-svc-054b15427d4bea2b7 |
| ID do serviço | vpce-svc-054b15427d4bea2b7 |
| Região de origem | us-east-1 |
| Regiões de consumidores compatíveis | us-east-1, us-east-2, us-west-2, eu-central-1, eu-west-1, ap-southeast-2 |
| Tipos de endereço IP | Somente IPv4 |
| Nome de DNS privado | api2.cursor.sh |
Modo 1: DNS privado gerenciado pela AWS
Este é o modo recomendado. Defina private_dns_enabled = true.
resource "aws_vpc_endpoint" "cursor_api2" { vpc_id = aws_vpc.app.id service_name = "com.amazonaws.vpce.us-east-1.vpce-svc-054b15427d4bea2b7" service_region = "us-east-1" vpc_endpoint_type = "Interface" subnet_ids = [for subnet in aws_subnet.app_private : subnet.id] private_dns_enabled = true security_group_ids = [aws_security_group.cursor_api2_endpoint.id]}A AWS associa sua VPC à zona privada hospedada e gerenciada de api2.cursor.sh. Dentro da VPC, api2.cursor.sh é resolvido para os IPs das ENIs de endpoint. Não é necessário nenhum registro no Route 53.
Modo 2: Zona hospedada privada gerenciada pelo cliente
Use este modo se quiser gerenciar o registro DNS. Defina private_dns_enabled = false e crie uma zona hospedada privada para api2.cursor.sh associada à VPC consumidora.
resource "aws_vpc_endpoint" "cursor_api2" { vpc_id = aws_vpc.app.id service_name = "com.amazonaws.vpce.us-east-1.vpce-svc-054b15427d4bea2b7" service_region = "us-east-1" vpc_endpoint_type = "Interface" subnet_ids = [for subnet in aws_subnet.app_private : subnet.id] private_dns_enabled = false security_group_ids = [aws_security_group.cursor_api2_endpoint.id]}resource "aws_route53_zone" "cursor_api2" { name = "api2.cursor.sh" comment = "Customer-managed PHZ for api2.cursor.sh scoped to the app VPC." vpc { vpc_id = aws_vpc.app.id }}resource "aws_route53_record" "cursor_api2_a" { zone_id = aws_route53_zone.cursor_api2.zone_id name = "api2.cursor.sh" type = "A" alias { name = aws_vpc_endpoint.cursor_api2.dns_entry[0].dns_name zone_id = aws_vpc_endpoint.cursor_api2.dns_entry[0].hosted_zone_id evaluate_target_health = false }}Se o GitHub Enterprise Server ou o GitLab Enterprise usar DNS fora da VPC do endpoint, encaminhe as consultas a api2.cursor.sh ao resolvedor da VPC ou crie uma substituição de DNS privado equivalente. Não crie uma substituição de DNS público.
Cloudflare Tunnel
Use o Cloudflare Tunnel quando o AWS PrivateLink não for adequado.
O Cherri Code cria o túnel e compartilha:
- Um hostname público em um DNS controlado pelo Cherri Code
- Um token de túnel por meio de um compartilhamento seguro no 1Password
- Uma configuração de exemplo do
cloudflared
Sua rede executa o cloudflared e estabelece conexões de saída com a Cloudflare. Não é necessária nenhuma regra de firewall de entrada.
Configuração de exemplo do cloudflared:
ingress: - hostname: <cursor-provided-hostname> service: https://<your-internal-service>:443 - service: http_status:404Exemplo de comando para executar:
docker run -d --restart=always --name cloudflared \ -v /path/to/config.yml:/etc/cloudflared/config.yml \ cloudflare/cloudflared:latest \ tunnel --config /etc/cloudflared/config.yml \ run --token <TUNNEL_TOKEN>Mantenha o token de túnel em segredo. Não o envie por e-mail ou chat.
Conclua a conexão com o controle de código-fonte
Após configurar a rede privada, conclua a configuração do controle de código-fonte no Cherri Code:
- Para GitHub Enterprise Server, siga a configuração da integração com o GitHub.
- Para GitLab Enterprise, siga a configuração da integração com o GitLab.
- Para Bitbucket Data Center, siga a configuração da integração com o Bitbucket.
- Use o mesmo hostname abrangido pelo certificado TLS e pela configuração de DNS privado.
- Se houver um proxy na frente do seu provedor de Git, verifique se ele permite o tráfego autenticado da API descrito em Pré-requisitos.
O Cherri Code usa a integração de controle de código-fonte conectada para agentes na nuvem, Bugbot e outros serviços do Cherri Code que precisam de acesso ao repositório.
Verifique o caminho do webhook privado
Se o seu provedor de Git envia webhooks ao Cherri Code pelo caminho do PrivateLink api2.cursor.sh, execute estas verificações pelo mesmo caminho de rede usado pelo GitHub Enterprise Server ou GitLab Enterprise:
getent hosts api2.cursor.sh# ou, se o dig estiver disponíveldig +short api2.cursor.shcurl -sS #Cada IP resolvido deve estar dentro do CIDR da sua VPC de consumidor. Se você vir IPs públicos, como 3.x.x.x ou 44.x.x.x, o DNS privado não está sendo aplicado.
A solicitação curl deve retornar HTTP 200 com um corpo que começa com Welcome to Cherri Code. Essa resposta indica que a solicitação chegou a um backend api2 ativo do Cherri Code.
Solução de problemas
| Sintoma | Causa provável | Solução |
|---|---|---|
| O Cherri Code não consegue concluir a conexão privada com seu provedor de Git | O Cherri Code não consegue alcançar ou se conectar ao serviço de endpoint | Confirme se o nome do serviço de endpoint, a região e a entidade principal autorizada correspondem aos valores fornecidos pelo Cherri Code e entre em contato com o Cherri Code, informando o timestamp |
| O Cherri Code informa que a conexão de endpoint está aguardando uma ação do cliente | O serviço de endpoint exige aprovação na sua conta da AWS | Revise as solicitações pendentes de conexão de endpoint para o serviço e aprove a solicitação do Cherri Code |
| O Bugbot ou os agentes na nuvem se conectam ao GHES, mas falham durante a configuração do app, a sincronização do repositório ou o processamento de webhooks | Um proxy na frente do GHES está bloqueando ou reescrevendo solicitações autenticadas às APIs REST ou GraphQL do GitHub | Permita que a integração de app do GitHub do Cherri Code use as APIs REST e GraphQL autenticadas do GitHub |
api2.cursor.sh é resolvido para IPs públicos | O DNS privado não está no caminho de resolução usado pelo GitHub Enterprise Server ou GitLab Enterprise | Habilite o DNS privado gerenciado pela AWS ou encaminhe o DNS para o resolvedor da VPC do endpoint |
A conexão TCP com api2.cursor.sh:443 expira | O grupo de segurança, a NACL, a tabela de rotas ou o firewall bloqueia o tráfego para as ENIs do endpoint | Permita TCP 443 da rede do seu provedor de Git para as ENIs do endpoint |
O TLS falha para api2.cursor.sh | O DNS aponta para o destino incorreto ou o cliente não está usando SNI | Verifique o DNS do endpoint e tente novamente com o SNI habilitado |
curl # não retorna Welcome to Cherri Code. | O tráfego não está chegando a um backend íntegro do Cherri Code | Envie ao Cherri Code o timestamp, a VPC de origem e os IPs de endpoint resolvidos |
| O Cloudflare Tunnel não se conecta | O cloudflared não consegue alcançar a Cloudflare ou o token/a configuração está incorreto | Verifique as regras de firewall de saída, o token e os logs do cloudflared |
Google Private Service Connect
No momento, o Cherri Code não oferece Google Private Service Connect para clientes.
Se você precisar de conectividade privada entre uma VPC do GCP e os serviços do Cherri Code ou entre o Cherri Code e um serviço privado no seu projeto do GCP, entre em contato com o Cherri Code para que possamos avaliar a necessidade. Por enquanto, use AWS PrivateLink ou Cloudflare Tunnel quando esses modelos de implantação forem adequados.
O que enviar ao Cherri Code
Para configurar o AWS PrivateLink com seu provedor de Git ou repositório de pacotes:
- Nome do serviço de endpoint
- Região da AWS
- hostname do Git ou do repositório
- Se o DNS privado está habilitado
- Se o balanceador de carga preserva os IPs dos clientes ou filtra os IPs de origem
Para api2.cursor.sh via AWS PrivateLink:
- Entidade principal da AWS que o Cherri Code deve incluir na lista de permissão
- VPC e região em que você criará o endpoint de interface
- Se você planeja usar DNS privado gerenciado pela AWS ou pelo cliente
Para Cloudflare Tunnel:
- URL da origem interna
- Contatos do cliente para o compartilhamento seguro no 1Password
- Restrições de hostname ou nomenclatura