Segurança
Seu código e seus builds continuam seus
Cada job roda sozinho em uma máquina que não aceita conexões de entrada, e toda mudança que o Latchkey faz no seu código chega como um pull request que você revisa.
Última atualização
Leia a arquitetura de segurança completa- 1job por máquina, que depois é destruída
- 0conexões de entrada que um runner aceita
- 0pull requests em que o Latchkey faz merge
- AES-256na criptografia dos secrets que você guarda no Latchkey
01 · Isolamento
Uma máquina própria para cada job
Cada job roda na própria máquina virtual, com kernel próprio e um disco criptografado. Quando o job termina, a máquina é encerrada e o disco é apagado, e nenhuma máquina jamais roda um segundo job.
- 01InícioUma máquina virtual que nenhum job usou
- 02ExecuçãoSeu job, sozinho na máquina
- 03EncerramentoDesligada de vez, nunca reutilizada
- 04ExclusãoO disco criptografado vai junto
Seu código é baixado em uma máquina que roda só o seu job e é destruída quando ele termina. O que o Latchkey guarda depois de um job está listado na Política de Privacidade e na documentação.
02 · Rede
Os runners saem. Nada entra.
Cada runner acessa a internet pelo próprio endereço IPv4 público, usado apenas para as conexões que o próprio runner abre, e o firewall dele não tem regras de entrada. Seu build ainda pode baixar pacotes e chamar seus serviços. No Latchkey CI, um pull request de um fork só alcança o GitHub e um conjunto fixo de registries públicos de pacotes.
03 · Credenciais
Credenciais emitidas para cada job
Toda credencial que o Latchkey emite para um job é emitida só para esse job e não alcança dados de nenhum outro workspace. Cada uma termina com o job ou em cerca de uma hora, exceto o token que o Docker usa para o registry de contêineres do Latchkey, que dura 12 horas. Nenhum token do GitHub de longa duração é colocado em um runner.
- Token de clonecerca de 1 hora
- Token do jobtermina com o job
- Acesso ao cacheaté 12 horas
04 · Secrets
Seus secrets do Latchkey ficam lacrados
Os secrets que você guarda no Latchkey são criptografados com AES-256-GCM, e o Latchkey só descriptografa um secret para um job em execução com uma etapa que o nomeia. O valor dele é mascarado onde quer que apareça inteiro no log do job, e nenhuma requisição do painel, da CLI ou de uma API key o retorna.
O Latchkey nunca chama a API do GitHub para buscar os seus secrets do Actions.
05 · Mudanças
Toda mudança no seu código espera a sua revisão
O Latchkey só faz commit em novas branches latchkey/ que ele mesmo cria e depois abre um pull request. Ele nunca faz push nas suas branches e nunca faz merge, então o merge é sempre decisão sua.
06 · Autorreparo
O autorreparo age dentro de limites seguros
Quando uma etapa falha, o autorreparo só pode executar ações de uma lista fixa e verificada, e a IA não recebe shell. Se o autorreparo der erro ou estourar o tempo, a etapa que falhou continua falhando.
- Permitido
apt-get install -y libssl-devpacote da lista fixa - Permitido
repetir a etapa que falhoumesma etapa, mesma máquina - Recusado
sudo rm -rf /var/lib/dockersó um comando sudo é permitido - Recusado
LD_PRELOAD=/tmp/hook.sovariável de ambiente insegura - Recusado
read ~/.ssh/id_rsacaminho sensível
07 · O básico
E o resto, coberto
Criptografia em repouso
Discos dos runners, cache de build e artefatos são criptografados em repouso.
Criptografia em trânsito
Todo endpoint público usa HTTPS, e nossa API exige TLS 1.2 ou superior.
Caches isolados
O cache de build de um workspace só é acessível com credenciais restritas a esse workspace.
Períodos de retenção
Caches de dependências expiram após 14 dias, artefatos e logs de jobs após 7, registros de autorreparo após 90 e correções propostas após 365.
API keys com escopo
As API keys são somente leitura, a menos que você escolha mais, guardadas como hashes SHA-256 e exibidas uma única vez.
Papéis no workspace
Os papéis Owner, Admin e Member definem quem pode gerenciar a cobrança, os membros e as integrações.
Forks em sandbox
No Latchkey CI, pull requests de forks só alcançam o GitHub e um conjunto fixo de registries públicos de pacotes.
Limite de tempo do runner
Uma proteção de último recurso encerra qualquer runner que ainda esteja rodando 8 horas após iniciar.
08 · GitHub App
O GitHub App, permissão por permissão
Você escolhe quais repositórios o app pode ver, e ele não tem permissão para ler os seus secrets do Actions. Aqui está cada permissão que ele pede, e por quê.
| Por quê | Permissão | Acesso |
|---|---|---|
| Rodar seus jobs nos runners do Latchkey | Organization self-hosted runners | Leitura e escrita |
| Ler execuções e logs, iniciar uma execução que você pedir, cancelar uma execução | Actions | Leitura e escrita |
| Ler arquivos, branches e pull requests, incluindo a lista de arquivos que um pull request altera, e propor mudanças como pull requests | Contents, Workflows, Pull requests | Leitura e escrita |
| Reportar os resultados do Latchkey CI nos seus commits e ler as verificações neles enquanto você migra do GitHub Actions | Checks | Leitura e escrita |
| Ver cada grupo que sua fila de merge cria, para que o Latchkey CI construa aqueles em que um arquivo de workflow roda | Merge queues | Leitura |
| Ler o plano, o uso do Actions, os runners hospedados no GitHub e os membros da sua organização | Organization plan, Organization administration, Members | Leitura |
| Ler dados básicos do repositório | Metadata | Leitura |
| Remover webhooks que o Latchkey criou em um repositório | Repository hooks | Leitura e escrita |
| Hoje não é usado por nenhum recurso do Latchkey | Administration, Organization hooks | Leitura e escrita, sem uso |
| Hoje não é usado por nenhum recurso do Latchkey | Artifact metadata | Leitura, sem uso |
Sem permissão de secrets do Actions.
Relatar e revisar
Encontrou uma vulnerabilidade?
Escreva para security@latchkey.dev e, por favor, relate de forma privada, não em uma issue pública.
security.txtFazendo uma revisão de segurança?
A documentação traz todos os detalhes.