Perguntas frequentes para DevSecOps

Veja as respostas às perguntas mais frequentes sobre como usar o site DevSecOps.

Qual é a diferença entre o pipeline CI e CC?

Você pode notar que os pipelines CI e CC têm etapas comuns. As varreduras e verificações que são executadas são semelhantes em natureza e detalhes. A tabela a seguir apresenta as diferenças entre o pipeline CI e CC.

Diferenças nos pipelines de CI e CC
Pipeline de CI Tubulação CC
Ele faz parte da cadeia de ferramentas de CI. Ele faz parte da cadeia de ferramentas do CC.
Ele é acionado depois que uma solicitação de mesclagem é mesclada com a ramificação master Ele pode ser acionado manualmente ou em intervalos predefinidos que são independentes de uma programação de implantação.
Um aplicativo URL e os detalhes do repositório de código do aplicativo são inseridos como parte do processo de configuração. Um aplicativo URL e os detalhes do repositório de código do aplicativo são fornecidos após a configuração da cadeia de ferramentas CC e antes do início da primeira execução do pipeline.
Os problemas de incidentes que são criados como parte de várias varreduras e verificações durante as verificações de conformidade não têm data de vencimento. Os problemas de incidentes que são criados como parte de várias varreduras e verificações durante as verificações de conformidade têm uma data de vencimento.
Os problemas de incidentes que são criados são encontrados durante a compilação. Os problemas de incidentes criados são encontrados durante varreduras periódicas do ambiente de preparação ou produção.
O arquivo summary.json não é gerado no final de cada execução do pipeline de CI. O arquivo summary.json não é gerado no final de cada execução do pipeline de CI.
Ele inclui etapas como a criação de artefatos de aplicativos, assinatura de artefatos e implementação no cluster de desenvolvimento. Isso, por sua vez, cria entradas para o pipeline de CD. Ele executa somente as varreduras e verificações necessárias para o teste de conformidade.

Como um usuário pode personalizar o pipeline?

Um pipeline é personalizado com o uso de scripts personalizados. Os scripts personalizados são pontos de extensão no pipeline em que adotantes, equipes e usuários podem fornecer scripts para executar tarefas personalizadas para suas estratégias de CI/CD.

Os estágios de um pipeline são controlados por scripts customizados. Você pode usar um arquivo de configuração (pipeline-config.yaml) para definir o comportamento das etapas, o conteúdo dos scripts e o artefato base que executa os scripts. Os scripts e a configuração dos estágios do pipeline são carregados de um repositório de aplicativos semelhante ao .travis.yml ou Jenkinsfile ou de um repositório personalizado.

Para obter mais informações, consulte Personalização de pipelines usando scripts personalizados.

Imagem de vários arcos para limitações das plataformas s390x e Power

O One-Pipeline oferece suporte nativo para as plataformas s390x e Power usando runtimeClassName (uma cadeia de caracteres para indicar o perfil de tempo de execução) no arquivo de configuração do One-Pipeline. No entanto, esse suporte nativo vem com algumas limitações e recomendações:

  • Limitações:
    • Este recurso está disponível somente na v11.
    • A hora de início do pod é maior do que a da classe de tempo de execução x86.
    • Você deve usar o podman com as cargas de trabalho s390x ou Power. Docker não está disponível.
      • Os scripts de usuário precisam ser atualizados para funcionar com o comando podman em vez do comando docker
      • A imagem do palco deve ter o podman instalado.
  • Recomendações: use as classes de tempo de execução do x86 para
    • digitalização, pois as várias imagens de ferramentas de digitalização podem não ter suporte a vários arcos.
    • assinatura de imagem, pois o suporte a vários arcos não está disponível (trabalho em andamento).

Como posso criar uma imagem base personalizada para várias arquiteturas?

O One Pipeline oferece uma imagem base oficial para várias arquiteturas, compatível com as seguintes plataformas:

  • linux/amd64
  • linux/ppc64le
  • linux/s390x

Para a maioria dos casos de uso, recomendamos utilizar diretamente a imagem base oficial:

icr.io/continuous-delivery/toolchains/devsecops/baseimage:<version>

Se o seu aplicativo precisar de pacotes adicionais do sistema operacional, ambientes de execução de linguagens de programação ou outras dependências personalizadas, você pode criar sua própria imagem base multiarquitetura personalizada como parte do seu pipeline de CI.

Use Docker Buildx com a opção --platform na etapa build-artifact :

docker buildx build \
  --platform linux/amd64,linux/ppc64le,linux/s390x \
  -t <registry>/<namespace>/<image>:<tag> \
  --push .

Isso cria imagens específicas para cada arquitetura e as publica como um único manifesto de imagens para várias arquiteturas. Os ambientes de execução de contêineres baixam automaticamente a imagem adequada para a plataforma de destino.

Abordagem recomendada

  1. Use a imagem base do One Pipeline como imagem de “ FROM ” no seu Dockerfile.
  2. Adicione apenas os pacotes ou dependências adicionais exigidos pelo seu aplicativo.
  3. Compile e publique a imagem usando o Buildx d Docker, em seu pipeline de CI.
  4. Verifique a imagem publicada usando docker buildx imagetools inspect ou skopeo inspect.

Para obter mais informações sobre o suporte a arquiteturas múltiplas e suas limitações, consulte “Limitações da imagem multi-arch para as plataformas s390x e Power ”.

Acionamento do pipeline usando a CLI

Um pipeline pode ser acionado usando a CLI do IBM Cloud ou uma API. Com a CLI, você pode iniciar um pipeline fornecendo a cadeia de ferramentas e as IDs do pipeline. Usando a API, você pode enviar uma solicitação POST com a autenticação e os cabeçalhos corretos para acionar o pipeline.

Para obter mais informações, consulte Uso de acionadores

Qual propriedade de ambiente é usada para clonar repositórios d Git?

Os pipelines do DevSecOps utilizam um sistema de tokens hierárquico para autenticar as operações do repositório Git, incluindo a clonagem. A propriedade de ambiente git-token funciona como token padrão, mas você pode substituí-la por tokens mais específicos para garantir maior segurança e melhor controle de acesso.

Ordem de prioridade dos tokens

O pipeline resolve os tokens de autenticação d Git, na seguinte ordem de prioridade (da mais alta à mais baixa):

  1. Token de acesso pessoal (PAT) especificado na integração da cadeia de ferramentas para um repositório específico
  2. Token específico do repositório: git-token-[repo_name]-[repo_org]
  3. Token específico da organização: git-token-[repo_org]
  4. Token padrão: git-token
  5. OAuth token da integração da cadeia de ferramentas (se estiver usando o OAuth em vez do PAT)

Exemplos de nomes de tokens

Para um repositório em https://github.com/my-org/my-app:

  • Específico do repositório: git-token-my-app-my-org
  • Específico da organização: git-token-my-org

Considerações importantes

  • Se o mesmo git-token for usado tanto para operações de leitura de repositórios (clonagem) quanto para operações de gravação (definição do status de PR/CI, atualização do inventário), o acesso somente leitura não é suficiente. O token deve ter permissões de gravação.
  • O uso de tokens específicos para cada repositório ou organização permite aplicar o princípio do privilégio mínimo, concedendo apenas as permissões necessárias para cada repositório.

Para obter mais informações sobre as funções dos tokens do repositório, consulte Recuperação de informações e tokens do repositório.

Como testar alterações na configuração d OnePipeline?

Testar alterações na configuração do OnePipeline requer uma abordagem sistemática para evitar interromper os pipelines de produção durante a validação das personalizações.

Entendendo os componentes d OnePipeline

OnePipeline consiste em dois componentes principais personalizáveis:

  • Definições de pipeline do Tekton: definições de pipeline gerenciadas centralmente para fluxos de trabalho de PR, CI, CD e CC, disponíveis no repositório compliance-pipelines. Novas versões são lançadas a cada duas semanas.

    • v10: Versão estável com capacidade limitada de processamento simultâneo
    • v11: Versão de última geração com máxima personalização e capacidade de processamento simultâneo

  • Configuração do pipeline (.pipeline-config.yaml): arquivo de configuração personalizado que substitui os comportamentos padrão do pipeline, incluindo imagens, scripts, arquiteturas e propriedades do pipeline. Este arquivo pode ser armazenado no repositório da sua aplicação ou em um repositório de configuração centralizado.

Abordagem de teste 1: Utilização de um arquivo de configuração de teste

Essa é a abordagem recomendada para testar alterações na configuração sem afetar os pipelines de produção.

  1. Criar um branch de teste

    • Crie um branch no repositório que contenha seu arquivo .pipeline-config.yaml
    • Faça suas alterações de configuração neste branch

  2. Configurar um gatilho de teste

    • Duplique o gatilho de pipeline existente na sua cadeia de ferramentas
    • Dê um nome claro (por exemplo, Manual-Test-Config)
    • Atualize as propriedades do gatilho para indicar sua configuração de teste:
      • pipeline-config: Nome do arquivo de configuração
      • pipeline-config-branch: Nome do seu branch de teste
      • pipeline-config-repo: Repositório URL contendo a configuração

  3. Teste no modo de desenvolvimento

    • Ativar o modo de desenvolvimento nas propriedades do gatilho
    • Execute o pipeline para validar seus scripts personalizados
    • O modo de desenvolvimento ignora a coleta de evidências, a criação de problemas de conformidade e as atualizações de inventário, tornando-o ideal para iterações rápidas
    • Importante: O modo de desenvolvimento não é adequado para cargas de trabalho de produção

  4. Teste com verificações de conformidade

    • Após validar os scripts no modo de desenvolvimento, desative dev-mode
    • Mantenha as atualizações de estoque desativadas durante os testes
    • Execute um fluxo de trabalho completo, incluindo a coleta de evidências e o gerenciamento de problemas
    • Verifique se todas as verificações de conformidade foram aprovadas conforme o esperado

  5. Promover para produção

    • Quando os testes forem satisfatórios, crie uma solicitação de pull para incorporar suas alterações ao ramo principal
    • As alterações serão aplicadas automaticamente aos gatilhos de produção
    • Se surgirem problemas, você pode reverter rapidamente as alterações

Abordagem de teste 2: Modificação do layout do pipeline

Bifurcação de definições de pipeline (avançado)

  • Crie uma ramificação do repositório compliance-pipelines
  • Desenvolva e teste as alterações no seu fork
  • Adicione o repositório bifurcado como uma integração do Git em sua cadeia de ferramentas
  • Atualize temporariamente a definição do pipeline para fazer referência ao seu fork
  • Configure um gatilho no modo de desenvolvimento para testar a nova definição do pipeline
  • Siga as etapas de teste da Abordagem 1

Melhores práticas

  • Sempre teste primeiro no modo de desenvolvimento para detectar erros de script rapidamente
  • Use nomes descritivos para os gatilhos de teste a fim de evitar confusão
  • Documente as alterações de configuração nas mensagens de commit
  • Mantenha os gatilhos de teste desativados ou exclua-os após os testes para evitar execuções acidentais
  • Considere criar uma cadeia de ferramentas de teste específica para grandes alterações no pipeline
  • Analise cuidadosamente os registros do pipeline para garantir que todas as etapas sejam executadas conforme o esperado

Para obter mais informações sobre como personalizar pipelines, consulte “Scripts personalizados” e