AvançadoDevSecOps personalização de pipeline

Saiba mais sobre os recursos avançados da adoção do DevSecOps depois de integrar seu primeiro aplicativo ou microsserviço.

Certifique-se de revisar o noções básicas deDevSecOps personalização de pipeline. Lá, você pode aprender sobre os diferentes modelos disponíveis, opções de suporte e outras informações importantes para começar.DevSecOps.

Opções de design.

Enquanto você integra mais aplicativos e microsserviços paraDevSecOps, você pode ter as seguintes perguntas de design:

Eu preciso de uma cadeia de ferramentas por microsserviço.
Eu preciso de um pipeline por microsserviço.
Preciso usar um compartilhadoDevSecOps repositório para inventário e problemas ou preciso de repositórios separados?

As informações e as melhores práticas a seguir devem ajudá-lo a fazer essas escolhas de design.

Considerações sobre cadeias de ferramentas e pipelines

A maioria dos aplicativos é feita de vários microsserviços com diferentes repositórios de origem. Geralmente, uma única cadeia de ferramentas é usada para hospedar microsserviços que são agrupados logicamente Em geral, use uma cadeia de ferramentas e um pipeline ou o mínimo de pipelines possível, mas diversos acionadores. Dentro de cada pipeline, é possível duplicar e configurar quantos acionadores forem necessários, até 1024 acionadores por pipeline Essa estratégia ajuda a aplicar processos, scripts e arquivos de configuração comuns. Para obter mais informações, consulte configurando diversos apps em uma cadeia de ferramentas de IC

Essa abordagem tem as seguintes vantagens:

O uso de menos pipelines evita duplicação e diminui erros. As atualizações também são mais fáceis de manter, por exemplo, quando uma propriedade de ambiente ou um segredo é incluído, editados ou excluído
Integrar um serviço é mais rápido com essa abordagem. Inclua uma integração do Git para seu microsserviço, duplique o Git e os acionadores manuais e modifique-os conforme necessário Em seguida, certifique-se de que seu arquivo .pipeline-config.yaml e scripts sejam implementados para seu microsserviço.

Esta abordagem tem as seguintes desvantagens:

Uma edição pode afetar cada equipe que está usando o mesmo pipeline.
O acesso de usuário é gerenciado usando Identity and Access Management(IAM) e é configurado no nível da cadeia de ferramentas, não no nível do pipeline. Portanto, se você estiver usando uma única cadeia de ferramentas para vários serviços, cada membro da equipe poderá visualizar os pipelines de outras equipes Dependendo do acesso do usuário no IAM, ele poderá editar, excluir ou acionar um pipeline.

Considerações sobre faturamento

O serviço Continuous Delivery determina o faturamento com base no número de usuários autorizados por instância de CD e em quantos grupos de recursos você usa para suas cadeias de ferramentas. Os usuários que têm acesso aos seus repositórios também são considerados usuários autorizados Para obter mais informações, consulte Usuários autorizados. Para reduzir os custos, você deve organizar todas as suas cadeias de ferramentas no mesmo grupo de recursos ou configurar o faturamento consolidado do Continuous Delivery em uma hierarquia de contas corporativas. Para obter mais informações, consulte Faturamento consolidado.

DevSecOps considerações sobre repositórios

Se você estiver criando um aplicativo composto de vários microsserviços, a maioriaDevSecOps repositórios - exceto o repositório de evidências - podem ser compartilhados entre os microsserviços.

Para mais informações, veja comoDevSecOps pipelines usam repositórios.

Considerações do repositório de configuração compartilhada

ODevSecOps aplicativos de amostra vêm com um arquivo .pipeline-config.yaml arquivo de configuração e scripts correspondentes. Ao integrar vários microsserviços, uma prática recomendada é separar os repositórios de código-fonte dosDevSecOps arquivos de configuração e scripts. Armazene-os em um repositório de configuração comum separado e dedicado que possa ser usado por seus pipelines de IC, CD ou CC

Isso consiste em:

Um repositório Git dedicado para hospedar uma biblioteca de scripts comum e arquivos.pipeline-config.yaml.
Um único arquivo.pipeline-config.yaml comum a todos os serviços. Se for muito complexo ou não possível, use arquivospipeline-config.yaml diferentes.
Customização por pasta. Implemente seus arquivos.pipeline-config.yaml para apontar para diferentes pastas de scripts em seu repositório de configuração. Organize seus scripts em pastas IC, CD e CC separadas ou com base na linguagem de serviço (Go, Python, NodeJS), serviço, nome do aplicativo ou o que melhor se ajuste às suas necessidades.

Altere seu(s) pipeline(s) para usar esse repositório de configuração compartilhada definindo o valor da propriedade do pipeline pipeline-config-repo (opcionalmente, o pipeline-config-branch ) para o repositório de configuração compartilhada URL.

Considerações do repositório de inventário

Um único repositório de inventário pode ser compartilhado entre muitos pipelines e cadeias de ferramentas Várias cadeias de ferramentas de IC, pipelines e acionadores podem contribuir para o mesmo repositório de inventário Os pipelines de IC enviam atualizações por push para o repositório de inventário, geralmente durante o estágio de liberação O repositório de inventário é então usado como a entrada de origem para o pipeline do CD. Em geral, é uma melhor prática agrupar repositórios de inventário na mesma cadeia de ferramentas para reduzir o número de solicitações de mudanças que são eventualmente criadas

O uso de um repositório de inventário compartilhado é uma decisão arquitetural que precisa ser tomada antes de iniciar a integração de microsserviços porque essa decisão afeta o número de solicitações de mudança que são criadas quando um pipeline é executado. Por exemplo, digamos que você queira integrar 10 microsserviços paraDevSecOps. É possível ter 10 cadeias de ferramentas de CD diferentes, com 10 repositórios de inventário diferentes, o que resulta em 10 solicitações de mudanças diferentes cada vez que um pipeline de CD é executado É mais fácil gerenciar esses 10 microsserviços diferentes se eles compartilharem um repositório de inventário comum e uma cadeia de ferramentas de CD comum Isso resulta em apenas uma solicitação de mudança, mesmo se você fizer atualizações em vários microsserviços, pois todos eles estão compartilhando o repositório de inventário e a cadeia de ferramentas

Considerações do repositório de problemas

Seu repositório de problemas é onde todos os problemas de vulnerabilidade para seus microsserviços são controlados. Se você decidir usar um repositório de inventário compartilhado, talvez você queira usar um repositório de problemas compartilhados também

Configurar incident-assigness e incident-labels no nível de pipeline ou acionador ajuda a designar automaticamente emissões para a equipe correta. Para obter mais informações, consulte Parâmetros de implementação contínua.

Considerações do IBM Cloud Object Storage

Se estiver usando um repositório de inventário compartilhado, você também poderá usar uma instância compartilhada do IBM Cloud® Object Storage. Conclua as etapas a seguir:

Crie um instância do IBM Cloud Object Storage para usar em cadeias de ferramentas e pipelines..
Configure pipelines e acionadores, se aplicável, para usar o depósito do IBM Cloud Object Storage configurando a propriedade do ambiente cos-bucket-name

Todos os microsserviços nos mesmos pipelines de CI, CD e CC compartilham um bucket Object Storage, independentemente do ambiente de implantação. O bucket Object Storage funciona de forma semelhante ao repositório de evidências, mas sem os problemas de desempenho que podem ocorrer com um repositório de evidências substancial. Como os problemas de desempenho não ocorrem com um bucket Object Storage substancial, você não precisa remover as evidências dos buckets Object Storage.

Object Storage granularidade do balde

DevSecOps não opinam sobre a granularidade dos buckets do Object Storage. Tecnicamente, você poderia usar um único bucket Object Storage em toda a sua organização. No entanto, a granularidade não deve ser menor que um inventário, pois o inventário é o menor agrupamento lógico de microsserviços que podem se mover juntos.

Na prática, a granularidade se resume ao modelo operacional que a sua equipe de conformidade deseja para gerenciar os dados de conformidade:

Se a equipe de conformidade se sentir à vontade para gerenciar vários compartimentos Object Storage com dados compartimentados, esse é um modelo viável.
Se eles preferirem gerenciar um único bucket maior do Object Storage com dados não compartimentados, isso também é possível.

Uma consideração importante: o Object Storage bucket (armário de evidências) deve ser legível pelo sistema, não por humanos. Ele não oferece, e em um futuro próximo não oferecerá, suporte a estruturas de pastas organizadas por repositório, microsserviço, produto ou organização. Ela continua sendo uma estrutura achatada de ativos e evidências.

Considerações sobre segurança e acesso

Baldes menos granulares Object Storage aumentam o raio de explosão no caso de uma violação de segurança (por exemplo, exposição de uma chave de API Object Storage ). Isso também pode gerar preocupações com a visibilidade cruzada, em que um produto vertical poderia ler os dados de conformidade de outro se eles compartilhassem o mesmo bucket.

Considerações sobre migração

Há maneiras de migrar entre Object Storage buckets, se necessário. Normalmente, isso envolve a configuração de determinadas propriedades do ambiente para um bucket de backup Object Storage e a reconstrução de componentes de CI. Consulte esta documentação para obter mais informações. No entanto, essas operações devem ser atividades de migração pontuais, e não algo projetado para fazer parte dos fluxos de trabalho operacionais diários.

Abordagem recomendada

Use um bucket Object Storage por grupo de produtos lógicos cujos dados de conformidade precisam ser movidos juntos. Por exemplo:

A Equipe de Serviço A (incluindo todos os esquadrões dentro dela) compartilha Object Storage Bucket A
A Equipe de Serviço B (incluindo todos os esquadrões dentro dela) compartilha Object Storage Bucket B

Essa abordagem equilibra a simplicidade operacional com os requisitos de segurança e controle de acesso.

Implementando em diversos ambientes

Implementar em vários ambientes de destino com o pipeline de CD pode ser alcançado de várias maneiras.

Cada targeted environment deve ter uma ramificação correspondente no repositório de inventário, em que as mudanças são promovidas de uma ramificação source para uma target..

Os designs opcionais a seguir podem se ajustar à sua arquitetura:

Use um acionador manual por ambiente de destino Duplique um acionador e, em seguida, edite as propriedades do ambiente para ajustar o novo ambiente.
Use um repositório de configuração Git com uma pasta por ambiente de destino, em que definições de configuração específicas são armazenadas em arquivos.

Trabalhando com scripts padrão e customizados

A maioria dos scripts de segurança e conformidade vem com scripts padrão que são executados se nenhum script customizado for fornecido para um estágio. Às vezes pode ser difícil determinar qual script é executado, onde localizar o script de origem correspondente e como substituir os scripts padrão.

Identificar qual script é executado

Para identificar qual script é executado para um estágio, abra a execução de pipeline (de preferência um pipeline de IC). Expanda uma tarefa e, em seguida, clique em run-stage para abrir os registros. O início dos logs do run-stage fornece informações sobre os scripts que foram usados no estágio, incluindo em qual repositório o script está localizado Nos logs, é possível rolar para localizar mais detalhes sobre os scripts que foram executados Por exemplo, a tarefa code-compliance-checks pode ter as informações a seguir no log run-stage, que inclui propriedades do ambiente para o estágio:

compliance-checks:
  image: icr.io/continuous-delivery/pipeline/pipeline-base-ubi:3.18
  dind: true
  abort_on_failure: false
  image_pull_policy: IfNotPresent
  script:
    #!/bin/sh

    "/opt/commons/compliance-checks/run.sh"

Nesse exemplo, o script que é executado é /opt/commons/compliance-checks/run.sh, que está localizado na biblioteca comum. Use esta biblioteca comum como uma origem para copiar o código que pode ser customizado para casos de borda específicos No exemplo, compliance-checks/run.sh está localizado na biblioteca compliance-commons..

Substituindo scripts padrão

Para substituir scripts padrão, conclua as etapas a seguir:

No log de estágio, copie o fragmento que identifica um script padrão:

compliance-checks:
  image: icr.io/continuous-delivery/pipeline/pipeline-base-ubi:3.18
  dind: true
  abort_on_failure: false
  image_pull_policy: IfNotPresent
  script:
    #!/bin/sh

    "/opt/commons/compliance-checks/run.sh"

Cole o fragmento no arquivo .pipeline-config.yaml.
Inclua seu código customizado antes ou depois que o script for chamado Este snippet invoca o script de verificação de conformidade padrão
Edite, exclua ou inclua propriedades conforme necessário.

O exemplo a seguir mostra o script atualizado em seu arquivo .pipeline-config.yaml:

compliance-checks:
  image: icr.io/continuous-delivery/pipeline/pipeline-base-ubi:3.18
  dind: true
  abort_on_failure: false
  image_pull_policy: IfNotPresent
  script: |
    #!/bin/sh
    # run some custom script here
    ./scripts/my-custom-script1.sh

    "/opt/commons/compliance-checks/run.sh"

    # then some additional work
    ./scripts/my-custom-script2.sh

Para obter mais informações, consulte scripts customizados..

Modelos Terraform para usarDevSecOps cadeias de ferramentas como código

As cadeias de ferramentas a seguir fornecem código para criarDevSecOps Cadeias de ferramentas CI, CD e CC usando Terraform:

O acesso antecipado a essas cadeias de ferramentas do Terraform está sendo fornecido no estado em que se encontra. Essas cadeias de ferramentas estão em desenvolvimento ativo, portanto, variáveis e nomes de variáveis podem ser alterados.