Veja neste artigo como garantir que sua cadeia de suprimentos de software siga um caminho conhecido e seguro antes da implantação do seu código em um cluster do Google Kubernetes Engine (GKE). No artigo, analisamos como a autorização binária funciona e explicamos como implementá-la e usá-la melhor com o Google Cloud para garantir que o pipeline de implantação possa fornecer o máximo de informações possível para você aplicar aprovações em cada um dos estágios necessários.
Os relatórios State of DevOps identificaram recursos que impulsionam o desempenho da entrega de software. Este artigo ajudará você com os seguintes recursos:
Elementos básicos para proteger sua cadeia de suprimentos de software
Quando você cria e implanta aplicativos em contêineres, é recomendável usar artefatos imutáveis como unidades de implantação. Artefatos imutáveis garantem a capacidade de implantar e escalonar seu software em muitos hosts e ambientes com a certeza de que ele se comportará conforme o esperado.
Depois de criar os artefatos imutáveis, coloque-os em um armazenamento de artefatos com catalogação e controle de versão e para uso posterior.
Em várias fases do processo de lançamento, pessoas ou sistemas automatizados podem adicionar metadados que descrevam o resultado de uma atividade, semelhante à sinalização de um ponto de verificação. Por exemplo, você pode adicionar metadados à sua imagem indicando que ela passou por um conjunto de testes de integração.
Depois que seus artefatos tiverem metadados, crie uma política de implantação que defina quais validações eles precisam passar para serem implantados na sua infraestrutura. Crie um mecanismo na sua infraestrutura para validar que uma carga de trabalho passe por todos os seus pontos de verificação obrigatórios antes de ser admitida. Esse tipo de validação, feito pouco antes de o código ser configurado para execução, garante que nenhuma implantação possa ignorar os estágios necessários do seu fluxo.
O diagrama a seguir mostra um processo geral para o gerenciamento da cadeia de suprimentos de software.
Como proteger cadeias de suprimentos no GKE
Na tabela a seguir, mapeamos os elementos básicos da cadeia de suprimentos para os recursos do Google Cloud.
| Elemento básico | Implementação do Google Cloud |
|---|---|
| Artefato imutável | Imagem do contêiner |
| Artifact Store | Artifact Registry |
| Metadados do artefato | Observação |
| Auditores do artefato | Atestadores |
| Validações do artefato | Atestados |
| Política de implantação | Política de autorização binária |
O artefato imutável do GKE que você implanta é uma imagem do Docker. Essa imagem é criada uma vez e, em seguida, enviada para o Artifact Registry, o armazenamento de artefatos, para que você possa implementá-la em qualquer número de clusters do GKE.
No Artifact Registry, você adiciona informações sobre imagens com tags,
que representam um único elemento de metadados. O uso mais comum para tags do Docker em imagens é denotar a versão do software ou um treinamento de lançamento, como v2.0.0 ou beta. Ainda que essa informação seja útil, não é possível usar tags para adicionar detalhes sobre o artefato, como onde ele foi construído, de qual código-fonte foi criado ou se está aprovado para implantação em ambientes de produção.
Para esses detalhes, use atestados.
Os atestadores podem declarar se uma imagem atende a um critério específico ao adicionar observações sobre imagens no Artifact Analysis.
Essas informações podem ser acessadas durante todo o ciclo de vida da imagem. Alguns tipos de observações são categorizados para que seja possível filtrar melhor as informações sobre suas imagens. Um tipo de observação é um attestation, que é adicionado por atestadores no seu projeto. Por exemplo, você pode ter um atestador que valide que as imagens foram criadas sem vulnerabilidades de segurança críticas ou que uma imagem foi criada por um sistema de versão específico.
Para adicionar um atestador ao seu projeto, faça upload de uma chave pública do Pretty Good Privacy (PGP) associada para criar e identificar seu atestador. Os atestadores podem criar atestados ao assinar mensagens que identificam quais resumos específicos de imagens de conteúdo endereçável eles estão atestando.
Veja no diagrama a seguir um exemplo de como adicionar um atestado a uma imagem para um resumo específico.
Com a autorização binária, configure uma política que defina quais atestados precisam estar presentes na sua imagem para que ela seja implantada nos seus clusters. Essa política cria um elemento básico para garantir que suas imagens sigam o caminho correto no canal de implantação sem ignorar etapas importantes. Em cada um dos estágios críticos do seu canal de implantação, crie um atestado informando que a imagem passou por essa etapa. Os atestados podem ser adicionados por sistemas automatizados ou por pessoas.
Por exemplo, pode ser que você queira garantir que sua imagem tenha passado por validações da sua equipe de controle de qualidade. Depois de concluir o teste, um dos membros da equipe de controle de qualidade usa uma chave específica para assinar um atestado do atestador qa-validated. Esse atestado é necessário para que seus clusters de produção implantem a imagem.
Da mesma forma, talvez você queira garantir que sua imagem tenha sido verificada quanto a vulnerabilidades e que nenhuma anomalia tenha sido detectada. Um sistema automatizado pode monitorar novas imagens no seu repositório e adicionar um atestado de que elas atendem a um determinado padrão de vulnerabilidade. Depois que o sistema valida a verificação de vulnerabilidades, ele pode assinar e adicionar um atestado do atestador not-vulnerable usando sua chave de criptografia. É possível criptografar essa chave com o Cloud Key Management Service,
armazená-la com segurança no Cloud Storage, controlar o acesso a ela
por meio do Identity and Access Management e fazer auditoria do uso por meio do Cloud Logging.
Veja no diagrama a seguir imagens no Artifact Registry com atestados adicionados por pessoas e atestadores automatizados.
Com a autorização binária, você cria políticas que definem quais chaves de criptografia podem ser usadas para validar cada um dos seus atestados. Também é possível adicionar determinadas imagens à lista de imagens isentas para ignorar a validação do atestado ou desativar a autorização binária para determinados clusters.
Ainda que o Google Cloud forneça serviços gerenciados para criar e gerenciar sua cadeia de suprimentos de software, também é possível usar implementações de código aberto para implementar processos semelhantes em outros ambientes.
Na tabela a seguir, mapeamos os serviços do Google Cloud para ferramentas de código aberto que fornecem funcionalidades semelhantes.
| Google Cloud | Código aberto |
|---|---|
| Artifact Registry | Distribuição Docker |
| API de metadados | Grafeas |
| Autorização binária | Kritis |
| Verificação de vulnerabilidades | Clair, Anchore Engine |
Práticas recomendadas para canais de entrega contínua
A validação da sua cadeia de suprimentos de software é mais eficaz quando há um canal de entrega contínua que usa automação para implantar o código-fonte de um repositório na sua infraestrutura de produção. Os estágios desses canais variam entre as organizações, mas você pode implementar algumas práticas recomendadas de alto nível para garantir a implantação segura do seu software pelo canal.
Orientação geral para canais de CI/CD
Muitas organizações permitem que equipes individuais escolham o próprio processo de entrega contínua e as próprias ferramentas. Embora essa flexibilidade seja capaz de aumentar a autonomia e permitir que as equipes usem ferramentas conhecidas, pode ser mais complicado garantir que todas as versões sigam as práticas recomendadas. Talvez você queira centralizar os pipelines de lançamento para as equipes com um aplicativo como o Cloud Deploy ou o Spinnaker, que ajuda a garantir a padronização, o compartilhamento e auditoria em um único lugar.
Criação da imagem
Como acontece com qualquer cadeia de suprimentos, seu software é tão seguro quanto os materiais que você usa para construir seus artefatos executáveis. Ao usar o GKE, é necessário garantir que as imagens que você criou são provenientes de imagens base seguras.
A primeira etapa para maximizar a segurança das suas imagens base é usar uma distribuição mínima que inclua apenas o software e as bibliotecas necessárias para executar seu aplicativo. Para distribuições conhecidas como Ubuntu, Debian e CentOS, o Google Cloud fornece imagens de base que são verificadas para vulnerabilidades, criadas de modo reproduzível e armazenadas no Google Cloud. É possível extraí-los diretamente do seu ambiente sem passar por redes Imagens distroless são um conjunto de imagens de base que inclui apenas as bibliotecas e ferramentas necessárias para executar aplicativos escritos em várias linguagens de programação. Após escolher uma base, tente minimizar o que é adicionado. Aproveite as versões em vários estágios do Docker para separar dependências de tempo de compilação e de ambiente de execução, o que reduz a superfície de ataque.
Após a criação da imagem, verifique se ela está de acordo com as políticas da organização. Crie testes de estrutura de contêiner (em inglês) que validam o conteúdo e os metadados da imagem. Também é possível usar container-diff (em inglês) para comparar seus contêineres atuais e recém-criados.
Quando você restringiu o conteúdo da imagem do app, tente auditar e reduzir o escopo de imagens de terceiros permitidas nos seus clusters. Você pode usar a autorização binária para adicionar as imagens que podem ignorar seus requisitos de atestado à lista de imagens isentas. Verifique se a entrada é a mais específica possível para cada uma das imagens necessárias, mas não é possível criar por meio do pipeline de criação de artefatos.
Para mais informações sobre como criar contêineres, consulte a documentação de práticas recomendadas para o desenvolvimento de contêineres.
Ativar análise de vulnerabilidade da imagem
Ative a verificação de vulnerabilidades do Artifact Registry nos seus projetos para ter mais informações sobre possíveis problemas de segurança nas imagens do Docker. As verificações automatizadas, executadas assim que as imagens são enviadas, podem ajudar você a entender a gravidade das vulnerabilidades nas suas imagens. É necessário verificar as vulnerabilidades antes e depois da implantação, porque podem ser encontradas novas vulnerabilidades. A verificação de vulnerabilidades analisa continuamente todas as imagens retiradas do registro nos últimos 30 dias. Use o Pub/Sub para receber notificações sempre que forem encontradas vulnerabilidades nas suas imagens.
Validar sua política durante a implantação
Para proteger sua cadeia de suprimentos de software, ative a validação de imagem durante a implantação. Por ser a última etapa em um canal de entrega contínua, a implantação é um bom momento para garantir que o processo inclua todos os estágios e passe por todos os pontos de verificação. Se você adotar essa abordagem, não será possível implantar imagens mal-intencionadas, mesmo com acesso às credenciais do seu cluster.
Com a autorização binária, é possível configurar uma regra padrão para todos os clusters no
projeto e, em seguida, substituir essas regras por configurações específicas do cluster.
Por exemplo, talvez você queira que todos os clusters exijam atestados de verificação de vulnerabilidades e validação de controle de qualidade, mas também quer garantir que os desenvolvedores possam testar novas tecnologias e imagens no cluster development sem validação de controle de qualidade. Para mais informações sobre políticas de autorização binária,
consulte a
documentação de
referência do YAML de políticas.
Exemplo de canal
Aqui está um exemplo de pipeline que é dividido em duas fases principais: criação e implantação.
A tabela a seguir oferece mais detalhes sobre as etapas do pipeline e o ponto em que os atestados são adicionados.
| Número da etapa | Resumo | Descrição | Ícone de atestado |
|---|---|---|---|
| 1 | Encontrar o código-fonte | Selecione o código-fonte na revisão desejada para uso pelo sistema de versão. | Nenhum |
| 2 | Executar testes unitários | Verifique se o código passa por todos os testes de unidade antes de criar um artefato. |
|
| 3 | Criar uma imagem do Docker | Use o Dockerfile no código-fonte local para criar uma imagem que possa ser enviada para o Artifact Registry. | Nenhum |
| 4 | Garantir que a imagem do Docker esteja em conformidade com a política | Com os testes de estrutura de contêiner, você confirma que sua imagem tem o conteúdo correto e que os comandos dentro da imagem retornam a saída correta. |
|
| 5 | Enviar imagem para o Artifact Registry | Após a conclusão do teste de unidade do seu código e a validação do conteúdo da sua imagem, envie a imagem para o Artifact Registry. O push aciona uma verificação de vulnerabilidades automaticamente. | Nenhum |
| 6 | Garantir que a imagem não tenha vulnerabilidades críticas | A verificação de vulnerabilidades leva alguns minutos para ser concluída e, em seguida, adiciona notas aos metadados da imagem sobre as Vulnerabilidades e Exposições Comuns (CVEs, na sigla em inglês) que surgirem. Aguarde a exibição desses dados e adicione um atestado se nenhuma vulnerabilidade crítica for encontrada. |
|
| 7 | Implantar a imagem para a etapa de preparo | Inicie uma implantação em um ambiente de pré-produção em que sua alteração pode ser validada e observada em cenários os mais próximos da produção possível. |
|
| 8 | Aprovar código para implantação em produção | Se todos os sinais mostrarem que a alteração atende aos seus requisitos, aprove a implantação no ambiente de produção. | Nenhum |
| 9 | Implantar o código nos clusters de produção | Agora, defina a imagem para ser atualizar em todo o seu grupo de clusters. Cada cluster verifica se todos os atestados estão completos antes de executar seu app. | Nenhum |
Exemplo de atestados
Veja abaixo alguns atestados que podem ser incluídos no seu canal de lançamento:
- Os resultados da análise de vulnerabilidade não incluíram vulnerabilidades críticas.
- A validação manual do controle de qualidade foi aprovada.
- Todos os programas de software incluídos na imagem tem a licença adequada.
- O artefato foi criado em um sistema de versão confiável.
A seguir
- Leia o tutorial de autorização binária.
- Aprenda sobre a integração entre autorização binária e verificação de vulnerabilidades.
- Saiba mais sobre como adicionar automaticamente um atestado para imagens de contêiner com procedência de build criadas pelo Cloud Build.
- Assista à palestra do Google Cloud Next 2021: Como proteger a cadeia de suprimentos de software
- Saiba como adicionar metadados às suas imagens do Artifact Registry.
- Confira arquiteturas de referência, diagramas e práticas recomendadas do Google Cloud. Confira o Centro de arquitetura do Cloud.
- Leia nossos recursos sobre DevOps.
- Saiba mais sobre os recursos de DevOps relacionados a este artigo:
- Faça a verificação rápida de DevOps para entender sua posição em relação ao restante do setor.