Gestión de secretos en las cadenas de herramientas

Las integraciones de herramientas en sus cadenas de herramientas de CI y CD requieren secretos, por ejemplo, contraseñas, claves API, certificados u otros tokens. Por ejemplo, una clave de API de IBM Cloud® realiza tareas básicas de interconexión, como iniciar sesión en IBM Cloud. De forma similar, la clave de API de ID de servicio escribe pruebas en el grupo en la instancia del almacén de objetos en la nube.

Por motivos de seguridad, estos secretos no deben revelar la identidad o la cuenta de una persona, ya que las personas a menudo tienen permisos de acceso mayores que el requisito de automatización de la cadena de herramientas real. La afiliación con la identidad o cuenta de una persona también violaría el principio de seguridad de "menor privilegio". Además, a menudo las personas cambian de función o incluso de empresa y hay que eliminar sus credenciales, lo que podría romper la automatización de la cadena de herramientas. Al utilizar una identidad afiliada específicamente para fines de automatización, se proporciona una separación de funciones entre la automatización y las personas que utilizan la automatización.

En cambio, los secretos que se utilizan para los recursos que no son de IBM Cloud (como GitHub Enterprise ) deben estar afiliados a un ID funcional dentro de su empresa con sólo el acceso apropiado que necesitan las cadenas de herramientas. Del mismo modo, los secretos de los recursos de IBM Cloud deben estar afiliados a una clave API de ID de servicio de IAM que esté afiliada a un ID de servicio de IAM. Los permisos de acceso al ID de servicio de IAM deben tener el mínimo privilegio requerido por las cadenas de herramientas.

La gestión de credenciales como estas debe realizarse de forma segura y de conformidad con las prácticas recomendadas de gestión de secretos. En concreto, esto significa guardar los secretos requeridos en una cámara acorazada utilizando un proveedor aprobado de cámaras acorazadas dentro de los límites, como IBM Cloud® Secrets Manager, IBM® Key Protect o HashiCorp Vault y, a continuación, vincular los secretos de la cadena de herramientas a esos recursos.

Las capacidades de gestión de secretos que se proporcionan en la configuración de la cadena de herramientas y las interfaces de usuario de canalización permiten la selección de secretos de bóveda mediante el uso de integraciones de secretos para IBM Cloud® Secrets Manager, IBM® Key Protect, o HashiCorp Vault. Utilizando el diálogo Selector de secretos, una cadena de herramientas o un editor de interconexiones puede seleccionar secretos con nombre de una integración de secretos enlazada que esté configurada por CRN (Nombre de recurso de nube) o por nombre, y que se resuelva por referencia en el tiempo de ejecución dentro de la cadena de herramientas y el conducto. Después de elegir un secreto, se inyecta un CRN o una referencia de secreto canónico en la correspondiente cadena de herramientas o propiedad segura de conducto donde el formato es crn:v1:...secret:<secret-guid> si se trata de una integración de Secrets Manager que se ha configurado mediante CRN, o bien {vault::integration-name.secret-name} si se trata de una integración de caja fuerte que utiliza cualquiera de los proveedores soportados y se ha configurado por nombre.

El formato de referencia por nombre canónico actualmente no resuelve un secreto que incluya el carácter de punto en el nombre de secreto porque este carácter se utiliza para delimitar cada sección de la vía de acceso canónica.

Independientemente del tipo de referencia de secreto que se utilice, ya sea por CRN o por nombre, los componentes de la interfaz de usuario frontal y el diálogo Selector de secretos sólo utilizan una referencia de secreto. El valor resuelto de una referencia de secreto por CRN o por nombre nunca se expone al componente frontal y siempre se resuelve dinámicamente en tiempo de ejecución dentro de una cadena de herramientas y un conducto basados en una autorización permitida que está disponible (configurada utilizando autorizaciones y políticas de acceso de IAM).

En IBM Cloud®, el proceso dinámico de resolución de por CRN y por nombre referencias de secretos en cadenas de herramientas y conductos se realiza utilizando puntos finales privados virtuales (VPE) internos a todas las instancias de proveedor de IBM Cloud® Secrets Manager y IBM® Key Protect en todas las regiones. Esto garantiza que todos los datos de solicitud y respuesta entre cadenas de herramientas, interconexiones y las instancias de proveedor IBM Cloud® Secrets Manager y IBM® Key Protect se mantengan dentro de la red IBM Cloud privada dentro del límite y no viajen a través de ningún canal de red pública.

Además de seleccionar manualmente los secretos elegidos uno por uno de las integraciones de secretos enlazados en una cadena de herramientas, también está disponible la opción de utilizar un Secret Hint. Esta opción permite que una plantilla de cadena de herramientas esté predefinida con nombres de secretos sugeridos (también conocidos como Hints) que son una referencia de secreto de formato corto. El formato de una sugerencia secreta es {vault::secret-name}, por lo que no se incluye ningún nombre de integración secreta. Esto proporciona flexibilidad al autor de la cadena de herramientas en que todos los nombres de secreto necesarios se pueden rellenar previamente en un toolchain.yml y, a continuación, estos nombres se resuelven automáticamente en cualquier integración de secretos que se haya configurado para la cadena de herramientas.

Como se ha descrito anteriormente, puede configurar Secrets Manager para que haga referencia a secretos por CRN. Para más información, consulte Nombres de recursos en la nube(CRN). Este formato permite una mayor flexibilidad porque puede hacer referencia a secretos de una instancia de Secrets Manager en una cuenta diferente si existe la autorización correcta. Para obtener más información, consulte Configuración de Secrets Manager.

A continuación se describen los secretos que se utilizan tanto en la IC como en la DC:

Un Hint es un nombre predeterminado sugerido que se resuelve automáticamente contra el primer secreto coincidente con el mismo nombre en cualquiera de las integraciones de secretos por nombre disponibles que estén vinculadas a la cadena de herramientas.

Secretos de interconexión de DevSecOps

SecretosDevSecOps

Secreto	Sugerencia	Información
Clave de API de IBM Cloud	ibmcloud-api-key	Requerido: CI & CD Se utiliza para autenticarse con la nube pública IBM y realizar una amplia gama de operaciones
Clave privada GPG	signing_key	Necesario: Sólo CI Se trata del certificado que se utiliza para firmar las imágenes creadas por el canal CI
Clave de API de servicio de trabajador privado de IBM	private-worker-service-api-key	Requerido: Solo CI Una clave API de ID de servicio Se utiliza para ejecutar cargas de trabajo de canalización de entrega en un servicio de trabajador privado de Tekton
Señal de acceso de GitHub	git-token	Opcional: CI & CD Se utiliza para autenticarse con GitHub y proporcionar acceso a los repositorios
Señal de API de Artifactory	artifactory-token	Necesario: CI & CD Se utiliza para acceder a las imágenes utilizadas por las tareas de conducto
Webhook Slack	slack-webhook	Opcional: CI y CD Este webhook es necesario si decide utilizar la integración de la herramienta Slack para publicar notificaciones de estado de la cadena de herramientas
Señal de API de ServiceNow	servicenow-api-token	Necesario: sólo CD Se utiliza para acceder a Service Now para operaciones de gestión de cambios
ID de rol de HashiCorp Vault	role-id	Requerido: CI & CD Se utiliza para autenticarse con el servidor HashiCorp Vault
ID de secreto de HashiCorp Vault	secret-id	Requerido: CI & CD Se utiliza para autenticarse con el servidor HashiCorp Vault
Clave de API del escritor de IBM Cloud Object Storage	cos-api-key	Necesario: CI & CD Se utiliza para autenticarse con el servicio Object Storage-Esta clave debe tener writer permiso
IBM Cloud Object Storage Clave API de lector	backup-cos-api-key	Necesario: CI & CD Se utiliza para autenticarse con el servicio Object Storage-Esta clave debe tener Reader permiso
Señal de autenticación o contraseña de SonarQube	sonarqube-password	Opcional: CI Se utiliza para autenticarse con el analizador de código fuente SonarQube

Si está utilizando un servidor HashiCorp Vault, asegúrese de que la integración de la herramienta HashiCorp Vault utiliza el método AppRole Auth Method. Cuando utilice el método de autenticación AppRole, necesitará role-id y secret-id para integrar correctamente el servidor de HashiCorp Vault con la cadena de herramientas. Dado que role-id y secret-id son secretos en sí mismos, se recomienda almacenarlos utilizando una integración de herramientas IBM Key Protect para que puedan recuperarse y aplicarse de forma segura en el flujo de trabajo de la cadena de herramientas. Todos los demás secretos de la cadena de herramientas deben almacenarse y recuperarse utilizando la integración de herramientas HashiCorp Vault.

Si la propiedad de entorno de canalización git-token no está establecida, por defecto se utiliza ibmcloud-api-key para recuperar el token de acceso Git Repos and Issue Tracking. Sin embargo, si ibmcloud-api-key no tiene acceso a git, se debe establecer git-token.

Configuración de los almacenes de secretos

Con IBM Cloud, puede elegir entre varias ofertas de gestión de secretos y protección de datos que le ayudarán a proteger sus datos confidenciales y centralizar sus secretos. Puede elegir entre las integraciones de caja fuerte en función de sus requisitos, tal como se explica en Gestión de secretos de IBM Cloud. Esta documentación proporciona información sobre los requisitos previos y sobre cómo utilizar una lista de nombres secretos prescritos que también se conocen como pistas. Mediante el uso de sugerencias en una plantilla, se puede llenar automáticamente una cadena de herramientas con secretos configurados previamente sin necesidad de seleccionarlos manualmente desde varias integraciones de caja fuerte conectadas a la cadena de herramientas.

Utilice IBM Cloud® Secrets Manager para almacenar y aplicar de forma segura secretos como claves API, firma de imágenes o credenciales de HashiCorp Vault que formen parte de su cadena de herramientas.

Las plantillas también se proporcionan con una integración de la herramienta HashiCorp Vault como en el ejemplo siguiente:

Para utilizar HashiCorp Vault, debe proporcionar la siguiente información:

• Nombre: un nombre para esta integración de herramientas. El nombre se visualiza en la cadena de herramientas.
• URL de servidor: el URL del servidor para la instancia de HashiCorp Vault. Por ejemplo, https://<vault-service>.<org>.com:8200.
• URL de integración: el URL al que desea navegar cuando pulse el mosaico de integración de HashiCorp Vault.
• Vía de acceso de secretos: la vía de acceso de montaje en la que se almacenan los secretos en la instancia de HashiCorp Vault.
• Método de autenticación: el método de autenticación para la instancia de HashiCorp Vault. Utilice AppRole.
• ID de rol: el identificador que selecciona el valor de AppRole contra el que se evalúan las otras credenciales.
• ID secreto: Credencial que se requiere por defecto para cualquier inicio de sesión (con secret_id) y que se pretende que sea siempre secreta.

Las plantillas también se proporcionan con una integración de herramientas de IBM® Key Protect for IBM Cloud®:

Si ha almacenado role id y secret id en Key Protect por adelantado, puede seleccionar la instancia de Key Protect que contiene estos secretos en la tarjeta de herramienta tal como se muestra en la figura 2. Una vez hecho esto, puede pulsar los iconos de clave en los campos id de rol e id de secreto en la tarjeta de herramienta de caja fuerte de HashiCorp y utilizar el selector para aplicar los secretos a esos campos.

Del mismo modo, cualquier otro secreto que se utilice en la cadena de herramientas tiene un icono de llave que se adjunta al campo de texto. Puede utilizar el mismo control de selección para aplicar los secretos de bóveda de HashiCorp a todas las instancias restantes.

Recuperar secretos de IBM Cloud Secrets Manager

Utilice el comando get_env para acceder al secreto de forma segura. Este método recupera el secreto sin exponerlo en los registros.

Tipos de secretos soportados

Actualmente, podemos obtener los siguientes tipos de secretos de las propiedades del entorno en Secrets Manager:

• Arbitrario

• Credenciales de IAM

• Clave-valor

Uso:

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

En este ejemplo:

• secret_key es el nombre utilizado para almacenar el secreto.

• SECRET_VALUE guarda el valor secreto recuperado para su uso posterior.

Dependiendo del tipo de secreto, get_env recupera valores específicos:

Recuperar un secreto arbitrario

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

Si get_env se utiliza con my-secret, recupera el valor payload.

Recuperación de iam_credentials Secret

  {
    "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"
  }

Si get_env se utiliza con my-iam-credentials, recupera el api_key.

Recuperar clave-valor Secreto

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

Si get_env se utiliza con my-kv-secret, recupera el value dentro del par clave-valor