Utilizando depósitos do IBM Cloud Object Storage como armazenamentos de evidências

É possível configurar buckets do IBM Cloud Object Storage (COS) para armazenar as evidências geradas pelas verificações de conformidade integradas aos pipelines do DevSecOps. As evidências de conformidades criam a trilha de auditoria utilizada pelos auditores durante uma auditoria de conformidade. Um dos objetivos do DevSecOps é a geração automatizada de evidências e o arquivamento em armazenamentos de evidências auditáveis. Para obter mais informações, consulte armário de evidências.

O pipeline de automação de conformidade armazena as seguintes informações no bucket do COS:

Artefatos da tarefa:
Resultados de testes, resultados de digitalizações ou qualquer saída salva pelas tarefas.
Logs de tarefa.
Após a execução do pipeline, os logs dessa execução são enviados para o repositório de evidências.
Evidência
Informações sobre as tarefas e seus resultados, que podem ser uma falha ou um sucesso. Para obter mais informações sobre o formato das evidências que são enviadas, consulte Resumo de evidências.

Configurando o depósito

Uma instância do Cloud Object Storage dedicada deve ser criada antes de configurar uma integração contínua ou uma cadeia de ferramentas de implementação contínua. Esse depósito COS é usado para armazenamento relacionado à conformidade, pois os armários de evidências devem ser criados no limite para seus aplicativos. Isso ajuda a melhorar a resiliência de seu pipeline Para obter mais informações, consulte Resiliência..

Para configurar seu bucket do Cloud Object Storage para atuar como um repositório de evidências de conformidade como parte de um pipeline de integração contínua ou implantação contínua, você pode usar as informações a seguir como orientação. Os scripts de modelo do pipeline ou da cadeia de ferramentas não configuram o locker no Cloud Object Storage.

Consulte esta página para obter mais informações sobre considerações (granularidade, segurança,...) para usar o Cloud Object Storage como evidência de conformidade.

Política de retenção

É possível configurar os buckets do Cloud Object Storage para aplicar uma política ou um período de retenção aos objetos enviados, também conhecidos como “imutáveis” Object Storage. O Immutable Object Storage preserva registros eletrônicos e mantém a integridade de dados. As políticas de retenção garantem que os dados sejam armazenados no formato “Write-One-Read-Many” (WORM), de forma não apagável e não regravável. Não é possível alterar ou excluir objetos em depósitos protegidos durante o período de retenção ou excluir depósitos protegidos que contenham objetos até o término do período de retenção. A política é aplicada até o término de um período de retenção e a remoção das possíveis restrições legais.

Recomenda-se que as equipes definam uma política de retenção para os depósitos que são usados como armazenamentos de evidências, para que cada objeto seja armazenado por um período mínimo de 365 dias.

Permissões de acesso ao depósito

Ao usar o Cloud Pipelines no ambiente DevSecOps, objetos como evidências, resumos de evidências e artefatos são canalizados para ou lidos de Buckets em IBM Cloud Object Storage (COS). As ferramentas não criam, atualizam, excluem ou alteram objetos ou compartimentos.

Para garantir o acesso seguro aos seus buckets na nuvem Object Storage e, ao mesmo tempo, facilitar as operações de pipeline necessárias, siga estas políticas de acesso:

  • Leitor.

    1. Essa permissão garante que os pipelines Continuous Delivery (CD) possam verificar as configurações de retenção do bucket sem modificar nenhum dado.
    2. Necessário para ler as evidências geradas pelo pipeline de CI

  • Escritor de Objetos.

    1. Essa permissão permite que os pipelines de Integração Contínua (CI), CD e Controle de Configuração (CC) façam upload ou gravem novos objetos nos buckets.

Etapas para criar credenciais de serviço

Para obter acesso ao seu bucket COS usando o Cloud Pipelines:

  1. Navegue até Credenciais de serviço:
  2. Criar uma nova credencial:
    • Clique em "Create" (Criar) e siga as instruções para criar uma nova credencial de serviço para seu bucket COS.

Etapas para atribuir acesso aos buckets COS

Para atribuir permissões de acesso apropriadas aos seus buckets COS:

  1. Navegue até IAM Bucket Permissions:
  2. Atribuir funções e políticas:
    • Atribua a função Reader aos pipelines de CD para verificar as políticas de retenção.
    • Atribua a função Object Writer aos pipelines de CI, CD e CC para escrever evidências em buckets.

Quando você usa o bucket do Object Storage Cloud como armazenamento de evidências, as permissões recomendadas são Leitor e Escritor de objetos. As permissões com privilégios mais altos (por exemplo, acesso em nível de administrador) devem ser evitadas para impedir a modificação acidental ou mal-intencionada de seus objetos.

Classes de armazenamento do

Os custos variam de acordo com as configurações e a frequência de implementação de cada equipe. Não é recomendável usar o plano gratuito como buckets do Cloud Object Storage, pois esse plano não pode ser configurado para ser imutável.

Estimativa de amostra

Se você estiver trabalhando com um pipeline de referência de integração contínua ou implantação contínua com seis etapas em cada um, uma única execução combinada de integração contínua e implantação contínua gera 37 solicitações da classe A e seis solicitações da classe B.

  • A integração contínua grava seis logs, seis artefatos e seis evidências, o que equivale a 18 solicitações PUT - Classe A.
  • A implantação contínua lê seis evidências (seis GET – Classe B), grava seis evidências, seis registros, seis artefatos e um resumo, o que equivale a 19 PUT – Classe A.

Com uma média de cinco microsserviços (cinco × integração contínua) e quatro regiões de implantação (quatro × implantação contínua), uma implantação completa equivale a 166 solicitações de Classe A e 24 de Classe B.

Considerando uma implementação completa por semana (quatro a cada mês), é possível calcular 664 solicitações de Classe A e 96 de Classe B por mês.

A quantia de dados que é coletada varia por caso de uso. Com tamanhos médios para evidência (1 kB), artefatos de teste (100 kB) e logs (15 kB), é possível calcular 0.01 GByte de dados que são criados e transferidos por mês..

Resiliência

Recomenda-se o uso da resiliência Cross-Region ou Regional, caso o limite não deva ser ultrapassado. Para obter mais informações sobre essas regiões, consulte Terminais e locais de armazenamento.

Nome do depósito

Os nomes dos buckets do Cloud Object Storage devem ser globalmente únicos e estar em conformidade com o DNS. Os nomes devem ter de 3 a 63 caracteres de comprimento e conter letras minúsculas, números e traços. Os depósitos devem receber nomes que comecem e terminem com uma letra minúscula ou com um número. Não é permitido usar nomes que se assemelhem a endereços IP. Os nomes de depósitos são exclusivos em todo o sistema IBM Cloud Object Storage e não podem conter informações pessoais, como parte de um nome ou endereço, dados de contas sociais ou bancárias, ou o SSN.

Os nomes dos depósitos devem ser exclusivos, pois todos os depósitos na nuvem pública compartilham um namespace global. Esse requisito permite o acesso a um bucket sem a necessidade de fornecer informações sobre nenhuma instância de serviço ou conta. Também não é possível criar um bucket cujo nome comece com “ cosv1- ” ou “account-”, pois esses prefixos são reservados pelo sistema.

Terminal

Use os terminais do private para a maioria das solicitações originadas de dentro do IBM Cloud® e use os terminais do public para a maioria das solicitações originadas de fora do IBM Cloud®. Para obter mais informações, consulte Tipos de Endpoint.

Para pipelines que estão em execução na região de Londres, use terminais do direct devido à infraestrutura do trabalhador gerenciada por pipeline lá.

Configuração de cadeias de ferramentas com o bucket COS

Para armazenar evidências, ativos e anexos, configure o bucket COS em seus pipelines. Como esse bucket é usado para reter as informações existentes, ele deve ter acesso a Reader e Object Writer. Para configurar esse bucket no pipeline.

Propriedades do ambiente para a configuração do bucket COS |Name |Type |Description |Required or Optional | Locked or Unlocked | |:----------|:------------------------------|:------------------|:----------|:----------| | cos-api-key | SECRET | A chave da API Cloud Object Storage. | Obrigatório | Bloqueado | | cos-access-key-id | SECRET | O ID da chave de acesso Cloud Object Storage das credenciais HMAC. (Fornecido junto com cos-secret-access-key em vez de cos-api-key)| Obrigatório | Desbloqueado | | cos-secret-access-key | SECRET | A chave de acesso secreta Cloud Object Storage das credenciais HMAC. (Fornecido junto com cos-access-key-id em vez de cos-api-key) | Obrigatório | Desbloqueado | | cos-bucket-name | texto | O nome do bucket na sua instância do Cloud Object Storage que é usado como repositório de evidências. |Obrigatório | Desbloqueado | | cos-endpoint | text | O ponto de extremidade que lê as evidências da instância Cloud Object Storage que é usada como um armário de evidências. Para obter mais informações, consulte Tipos de ponto de extremidade. | Obrigatório | Desbloqueado |

Configure o mesmo bucket em todos os seus pipelines CI/CD/CC.

Migração do Git Evidence Locker para o COS Evidence Locker

Para melhorar o desempenho, a confiabilidade e a escalabilidade da compilação, o suporte para Evidence Git Lockers baseados em foi descontinuado. A mudança para Evidence Cloud Object Storage Lockers baseados em COS ajuda a reduzir a dependência de Git operações e evita problemas de limitação de taxa dos Git hosting provedores.

Todos os usuários devem atualizar suas cadeias de ferramentas e pipelines para usar um COS Evidence Locker.

Quando sua cadeia de ferramentas usa apenas um Git Evidence Locker

Siga estas etapas para concluir a migração:

Quando sua cadeia de ferramentas usa tanto Git quanto COS Evidence Lockers

Se você já tiver ambos configurados:

  • Remova a propriedade evidence-repo environment de todos os pipelines.
  • Remova a GitHub/GitLab integração associada ao repositório de evidências em sua cadeia de ferramentas.

Preparando pipelines de CD para migração do Git para o COS Evidence Locker

Se seus pipelines de CI e CD dependem de um Git Evidence Locker, os pipelines de CD devem ser inicializados para usar o COS Evidence Locker. Você pode escolher uma das seguintes abordagens.

Abordagem 1: Bootstrap usando ambos os Evidence Lockers

Nesta abordagem, o COS Evidence Locker é ativado enquanto o Git Evidence Locker permanece configurado. A execução paralela permite que o COS Evidence Locker seja inicializado automaticamente usando o Git Evidence Locker.

  • Mantenha a configuração Git do Evidence Locker em vigor.
  • Ative o COS Evidence Locker.
  • Execute o pipeline do CD usando uma versão de definição de pipeline anterior a v10.46.1 (recomendado: v10.45.0 ).
  • Após a conclusão da execução, remova a configuração Git do Evidence Locker conforme descrito anteriormente.

Abordagem 2: Bootstrap sem Git Evidence Locker

Use essa abordagem se preferir uma migração limpa, sem depender de Git.

  • Remova a configuração Git do Evidence Locker.
  • Execute uma execução única do pipeline de CD com o force-redeploy parâmetro definido como true.
  • Após a conclusão da execução, redefina force-redeploy ou false remova completamente o parâmetro.

Essa execução única do pipeline de CD garante que o COS Evidence Locker seja preenchido com todos os ativos de inventário existentes. É necessária apenas uma única execução inicial e você pode. Se preferir não acionar uma implantação real, você pode pular as etapas de implantação e teste de aceitação para executar o pipeline de CD sem realizar nenhuma ação de implantação.

Você pode optar por arquivar o armário Git de evidências após a remoção, pois ele será necessário para fins de auditoria.

Migração de um bucket COS para outro bucket COS

Migração de um compartimento COS para outro compartimento COS Se você for um usuário existente do armário de evidências COS e precisar migrar de um bucket COS para outro, é importante garantir uma transição tranquila sem interromper seus fluxos de trabalho. Abaixo estão as etapas e considerações para migrar entre os buckets COS.

Motivos para a migração:

  • Reestruturação organizacional: Talvez você queira parar de usar um bucket COS e começar a usar outro.
  • Realocação do bucket: O bucket precisa ser movido de uma conta para outra, possivelmente devido a mudanças organizacionais ou requisitos de conformidade.

Etapas para migrar:

Configure o bucket de backup-COS: Se estiver migrando de um bucket COS antigo para um novo, certifique-se de que seu pipeline esteja configurado para usar os buckets antigo e novo. Isso permite uma migração suave sem interromper seus fluxos de trabalho existentes.

  • Crie o New COS Bucket conforme definido nas etapas acima.
  • Configurar políticas de IAM: Certifique-se de que o novo bucket COS tenha as políticas de IAM necessárias para o acesso do Reader e do Object Writer, conforme exigido por seus pipelines.
  • Atualizar variáveis de ambiente

Em IBM Toolchains, atualize as variáveis de ambiente para incluir os buckets COS antigos e novos. Para configurar o bucket antigo, use o prefixo backup- em todas as propriedades do ambiente COS e use as propriedades normais para configurar o novo bucket COS.

Nome Tipo Descrição Obrigatório ou opcional Bloqueado ou desbloqueado
backup-cos-api-key SECRET A chave da API do Backup Cloud Object Storage. Obrigatório Bloqueado
backup-cos-access-key-id SECRET O backup Cloud Object Storage ID da chave de acesso das credenciais HMAC. (Fornecido junto com backup-cos-secret-access-key em vez de backup-cos-api-key) Obrigatório Desbloqueado
backup-cos-secret-access-key SECRET O backup Cloud Object Storage Secret Access Key das credenciais HMAC. (Fornecido junto com backup-cos-access-key-id em vez de backup-cos-api-key) Obrigatório Desbloqueado
backup-cos-bucket-name Texto O nome do bucket de backup na sua instância do Cloud Object Storage que é usado como repositório de evidências. Obrigatório Desbloqueado
backup-cos-endpoint Texto O ponto de extremidade que lê as evidências da instância de backup Cloud Object Storage que é usada como um armário de evidências. Para obter mais informações, consulte Tipos de endpoint. Obrigatório Desbloqueado

Não exclua o bucket antigo por 365 dias, pois isso seria necessário para fins de auditoria.

Guia de solução de problemas para pipelines com execução lenta

  1. force-redeploy não deve ser definido como true, a menos que seja uma reimplantação de todas as entradas.
  2. O pipeline de promoção deve ser usado para promover o conjunto correto de delta, para que o cálculo do delta seja correto.
  3. Se você vir essas linhas, isso significa que o pipeline de CI não está gerando os resumos corretos. Retorne ao pipeline de CI e verifique se há algum erro ao criar os mini-resumos na etapa de conclusão.