Gerenciando segredos em suas cadeias de ferramentas

As integrações de ferramentas em seus conjuntos de ferramentas de CI e CD exigem segredos, por exemplo, senhas, chaves de API, certificados ou outros tokens. Por exemplo, uma chave de API IBM Cloud® executa tarefas básicas de pipeline, como efetuar login no IBM Cloud. Da mesma forma, a chave de API do ID de serviço grava a evidência no depósito na instância do Cloud Object Store.

Por motivos de segurança, esses segredos não devem revelar a identidade ou a conta de uma pessoa, pois as pessoas geralmente têm permissões de acesso maiores do que o requisito de automação da cadeia de ferramentas real A afiliação com a identidade ou conta de uma pessoa também violaria o princípio de segurança de "privilégio mínimo". Além disso, as pessoas frequentemente mudam de função ou até mesmo de empresa e suas credenciais precisam ser removidas, o que pode interromper a automação da cadeia de ferramentas. O uso de uma identidade afiliada especificamente para fins de automação proporciona uma separação de tarefas entre a automação e as pessoas que a utilizam.

Em vez disso, os segredos usados para recursos que não sejam IBM Cloud (como GitHub Enterprise ) devem ser afiliados a uma ID funcional em sua empresa, com apenas o acesso apropriado necessário para as cadeias de ferramentas. Da mesma forma, os segredos dos recursos do IBM Cloud devem estar associados a uma chave de API de ID de serviço do IAM que esteja associada a um ID de serviço do IAM. As permissões de acesso ao ID de serviço do IAM precisam ter o escopo do privilégio mínimo exigido pelas cadeias de ferramentas.

O gerenciamento de credenciais como essas deve ser feito com segurança e em conformidade com as melhores práticas de gerenciamento secreto. Em particular, isso significa colocar em cofre os segredos necessários usando um provedor de cofre aprovado dentro dos limites, como IBM Cloud® Secrets Manager, IBM® Key Protect ou HashiCorp Vault e, em seguida, vincular os segredos da cadeia de ferramentas a esses recursos.

Os recursos de gerenciamento de segredos fornecidos na configuração da cadeia de ferramentas e nas interfaces de usuário do pipeline permitem a seleção de segredos armazenados em cofre usando as integrações de segredos para IBM Cloud® Secrets Manager, IBM® Key Protect ou HashiCorp Vault. Usando o diálogo Selecionador de segredos, um editor de cadeia de ferramentas ou de pipeline pode selecionar segredos nomeados de uma integração de segredos de limite que é configurada por CRN (Cloud Resource Name) ou por nome, que é, então, resolvida por referência no tempo de execução dentro da cadeia de ferramentas e do pipeline. Após um segredo ser escolhido, uma referência de CRN ou de segredo canônico é injetada na propriedade segura da cadeia de ferramentas ou do pipeline correspondente em que o formato é crn:v1:...secret:<secret-guid> se for uma integração do Secrets Manager configurada pelo CRN ou, como alternativa, {vault::integration-name.secret-name} se for uma integração de área segura que usa qualquer um dos provedores suportados e configurado por nome.

O formato de referência por nome canônico atualmente não resolve um segredo que inclua o caractere de ponto no nome do segredo, porque esse caractere é usado para delimitar cada seção do caminho canônico

Independentemente de qual tipo de referência secreta é usado, por CRN ou por nome, os componentes da interface com o usuário de front-end e o diálogo Selecionador de Segredos usam apenas uma referência secreta O valor resolvido de uma referência de segredo por CRN ou por nome nunca é exposto ao front-end e é sempre resolvido dinamicamente no tempo de execução dentro de uma cadeia de ferramentas e pipeline com base em uma autorização permitida disponível (configurada usando as políticas de Autorizações e Acesso do IAM).

No IBM Cloud®, o processo dinâmico de resolução por CRN e por nome referências de segredos em cadeias de ferramentas e pipelines é executado usando terminais privados virtuais (VPE) internos para todas as instâncias do provedor IBM Cloud® Secrets Manager e IBM® Key Protect em todas as regiões. Isso assegura que todos os dados de solicitação e resposta entre cadeias de ferramentas, pipelines e instâncias do provedor IBM Cloud® Secrets Manager e IBM® Key Protect sejam mantidos dentro da rede privada do IBM Cloud no limite e não viajem por nenhum canal de rede pública.

Além de selecionar manualmente segredos escolhidos em uma base única a partir de quaisquer integrações de segredos vinculados em uma cadeia de ferramentas, a opção de usar um Secret Hint também está disponível. Esta opção possibilita que um modelo de cadeia de ferramentas seja predefinido com nomes de segredos sugeridos (também conhecidos como Hints) que são uma referência secreta de formato curto. O formato de uma sugestão secreta é {vault::secret-name} pelo qual nenhum nome de integração secreta é incluído. Isso fornece flexibilidade para o autor da cadeia de ferramentas na que todos os nomes secretos necessários podem ser pré-preenchidos em um toolchain.yml e então esses nomes são automaticamente resolvidos contra quaisquer que sejam as integrações de segredos configurados para a cadeia de ferramentas.

Conforme descrito anteriormente, é possível configurar Secrets Manager para referenciar segredos por CRN. Para obter mais informações, consulte Nomes de recursos de nuvem(CRN). Esse formato permite maior flexibilidade porque é possível referenciar segredos de uma instância do Secrets Manager em uma conta diferente se a autorização correta estiver em vigor. Para obter mais informações, consulte Configurando Secrets Manager.

Os segredos usados na CI e na CD são descritos a seguir:

Um Hint é um nome padrão sugerido que é automaticamente resolvido em relação ao primeiro segredo correspondente com o mesmo nome em qualquer uma das integrações de segredos por nome disponíveis que estão vinculadas à cadeia de ferramentas.

Segredos de pipeline do DevSecOps

SegredosDevSecOps
Segredo	Sugestão	Informações
Chave de API do IBM Cloud	`ibmcloud-api-key`	Necessário: CI & CD Usado para autenticar com a nuvem pública IBM e realizar uma ampla gama de operações
Chave Privada GPG	`signing_key`	Obrigatório: Somente CI Este é o certificado usado para assinar imagens criadas pelo pipeline de CI
Chave de API do serviço de trabalhador privado do IBM	`private-worker-service-api-key`	Necessário: Apenas CI Uma chave API de ID de serviço Usada para executar cargas de trabalho de pipeline de entrega em um Tekton Private Worker Service
Token de acesso do GitHub	`git-token`	Opcional: CI & CD Usado para autenticar com GitHub e fornecer acesso aos repositórios
Token API Artifactory	`artifactory-token`	Necessário: IC & CD Utilizado para acessar imagens usadas por tarefas de pipeline
Webhook do Slack	`slack-webhook`	Opcional: CI & CD Este webhook é necessário se você optar por usar a integração da ferramenta Slack para publicar notificações de status da cadeia de ferramentas
Token da API do ServiceNow	`servicenow-api-token`	Necessário: somente CD Usado para acessar o Service Now para operações de gerenciamento de mudanças..
ID de função do HashiCorp Vault	`role-id`	Necessário: CI & CD Usado para autenticar com o servidor HashiCorp Vault
ID de segredo do HashiCorp Vault	`secret-id`	Necessário: CI & CD Usado para autenticar com o servidor HashiCorp Vault
Chave de API do gravador do IBM Cloud Object Storage	`cos-api-key`	Necessário: IC & CD Utilizado para autenticar com o serviço Object Storage-Essa chave deve ter `writer` permissão
IBM Cloud Object Storage Chave da API do leitor	`backup-cos-api-key`	Necessário: IC & CD Utilizado para autenticar com o serviço Object Storage-Essa chave deve ter `Reader` permissão
Token de autenticação ou de senha do SonarQube	`sonarqube-password`	Opcional: CI Usado para autenticar com o analisador de código-fonte SonarQube

Se você estiver usando um servidor HashiCorp Vault, assegure-se de que a integração da ferramenta HashiCorp Vault use o método AppRole Auth Method. Ao usar o método de autenticação AppRole, você precisa de role-id e secret-id para integrar com êxito o servidor do Vault HashiCorp à cadeia de ferramentas. Como role-id e secret-id são segredos em si, recomenda-se armazená-los usando uma integração de ferramenta IBM Key Protect para que possam ser recuperados e aplicados com segurança no fluxo de trabalho da cadeia de ferramentas. Todos os outros segredos da cadeia de ferramentas devem ser armazenados e recuperados usando a integração da ferramenta HashiCorp Vault.

Se a propriedade de ambiente do pipeline git-token não estiver definida, ibmcloud-api-key será usado para recuperar o token de acesso Git Repos and Issue Tracking por padrão. No entanto, caso ibmcloud-api-key não tenha acesso a git, deve-se configurar git-token.

Configurando os armazenamentos de segredos

Com o IBM Cloud, você pode escolher entre várias ofertas de gerenciamento de segredos e proteção de dados que o ajudam a proteger seus dados confidenciais e a centralizar seus segredos. Você pode escolher entre as integrações do cofre dependendo de seus requisitos conforme explicado em Gerenciando IBM Cloud segredos. Esta documentação fornece informações sobre pré-requisitos e como usar uma lista de nomes secretos prescritos, também conhecidos como dicas. Ao usar sugestões em um modelo, uma cadeia de ferramentas pode ser preenchida automaticamente com segredos pré-configurados sem a necessidade de selecioná-los manualmente nas várias integrações de área segura anexadas à cadeia de ferramentas.

Use IBM Cloud® Secrets Manager para armazenar e aplicar com segurança segredos como chaves de API, assinatura de imagem ou credenciais do HashiCorp Vault que fazem parte de sua cadeia de ferramentas.

Secrets Manager formulário de integração de ferramentas — Integração de ferramentasIBM Secrets Manager

Os modelos também vêm com uma integração de ferramenta do HashiCorp Vault como o exemplo a seguir:

Formulário de integração da ferramenta Vault daHashiCorp com campos obrigatórios e valores de exemplo — Integração da ferramenta Vault daHashiCorp

Para usar o HashiCorp Vault, você deve fornecer as seguintes informações:

Nome: um nome para esta integração de ferramenta. Este nome é exibido na cadeia de ferramentas.
URL do servidor: a URl do servidor para a instância do HashiCorp Vault. Por exemplo, https://<vault-service>.<org>.com:8200.
URL de integração: a URL para a qual se deseja navegar ao clicar no azulejo da integração do HashiCorp Vault.
Caminho de segredos: o caminho de montagem no qual os segredos são armazenados na instância do HashiCorp Vault.
Método de autenticação: o método de autenticação da instância do HashiCorp Vault. Use o AppRole.
ID da função: o identificador que seleciona a AppRole em relação à qual as demais credenciais serão avaliadas.
ID secreta: Credencial que é exigida por padrão para qualquer login (com secret_id) e que deve ser sempre secreta.

Os templates também vêm com uma integração de ferramentas IBM® Key Protect for IBM Cloud®:

Key Protect formulário de integração de ferramentas com campos obrigatórios e valores de exemplo — Integração da ferramentaIBM Key Protect

Se você armazenou o role id e secret id em Key Protect com antecedência, então você poderá selecionar a instância Key Protect que contém aqueles segredos na placa de ferramenta, conforme mostrado na Figura 2. Depois que isso for feito, será possível clicar nos ícones de chave nos campos ID da função e ID do segredo no cartão da ferramenta HashiCorp Vault e usar o selecionador para aplicar os segredos a esses campos.

Da mesma forma, quaisquer outros segredos usados na cadeia de ferramentas têm um ícone de chave anexado ao campo de texto. Você pode usar o mesmo controle de seleção para aplicar os segredos do HashiCorp Vault a todas as instâncias restantes.

Recuperação de segredos de IBM Cloud Secrets Manager

Use o comando get_env para acessar o segredo de forma segura. Esse método recupera o segredo sem expô-lo em registros.

Tipos de segredos suportados

Atualmente, oferecemos suporte à obtenção dos seguintes tipos de segredos das propriedades do ambiente no site Secrets Manager:

Arbitrário
Credenciais do IAM
Valor da chave

Uso:

  export SECRET_VALUE=$(get_env "secret_key" "")

Nesse exemplo:

secret_key é o nome usado para armazenar o segredo.
SECRET_VALUE mantém o valor secreto recuperado para uso posterior.

Dependendo do tipo de segredo, o get_env recupera valores específicos:

Recuperação de segredo arbitrário

  {
    "name": "my-secret",
    "secret_type": "arbitrary",
    ...
    "payload": "The quick brown fox jumped over the lazy dog."
  }

Se get_env for usado com my-secret, ele recupera o valor de payload.

Recuperação do segredo de iam_credentials

  {
    "name": "my-iam-credentials",
    "secret_type": "iam_credentials",
    ...
    "api_key": "RmnPBn6n1dzoo0v3kyznKEpg0WzdTpW9lW7FtKa017_u",
    "api_key_id": "ApiKey-dcd0b857-b590-4507-8c64-ae89a23e8d76",
    "service_id": "ServiceId-bb4ccc31-bd31-493a-bb58-52ec399800be"
  }

Se get_env for usado com my-iam-credentials, ele recupera o api_key.

Recuperação de segredo de valor-chave

  {
    "name": "my-kv-secret",
    "secret_type": "key-value",
    ...
    "data": "{\"key\":\"value\"}"
  }

Se get_env for usado com my-kv-secret, ele recuperará o value dentro do par de valores-chave