Intégration de la signature de code dans le cloud avec CircleCI

Ce didacticiel montre comment eSigner est intégré à CircleCI pour la signature de code automatisée.

eSigner est l'environnement cloud de SSL.com pour la signature de code. Les clés de signature et les certificats sont hébergés en toute sécurité dans le cloud par SSL.com et sont accessibles pour la signature à partir de n'importe quel appareil connecté à Internet, faisant ainsi d'eSigner l'une des meilleures plates-formes pour la signature de code d'entreprise. La boîte à outils eSigner comprend CodeSignTool qui est un utilitaire de ligne de commande pour Signature de code EV certificats et est idéal pour créer des processus de signature automatisés dans diverses plates-formes d'intégration continue/livraison continue (CI/CD), y compris CircleCI. 

Variables d'environnement

• USERNAME: nom d'utilisateur du compte SSL.com. (Obligatoire)
• MOT DE PASSE: Mot de passe du compte SSL.com (Requis)
• CREDENTIAL_ID: ID d'identification pour la signature du certificat. Si credential_id est omis et que l'utilisateur n'a qu'un seul certificat de signature de code eSigner, CodeSignTool utilisera celui-ci par défaut. Si l'utilisateur possède plusieurs certificats de signature de code, ce paramètre est obligatoire. (Obligatoire)
• TOTP_SECRET: Secret OAuth TOTP. Vous pouvez accéder à des informations détaillées sur https://www.ssl.com/how-to/automate-esigner-ev-code-signing (Requis)
• ENVIRONNEMENT_NAME : Environnement 'TEST' ou 'PROD'. (Obligatoire)

Contributions

• chemin_fichier_entrée: Chemin de l'objet code à signer. (Obligatoire)
• chemin_rép_sortie: Répertoire où le ou les objets de code signés seront écrits. Si output_path est omis, le fichier spécifié dans -file_path sera remplacé par le fichier signé.

Préparer les composants du workflow (Signature de DLL de code .NET)

1. Créer un dossier .circleci

Dans votre espace de travail de signature de code, créez un dossier .circleci. En dessous, créez un fichier config.yml.

2. Définir la version CI

Version: 2.1

 

3.  Invoquez des tâches via des workflows. Les workflows orchestrent un ensemble de tâches à exécuter. Les tâches pour ce pipeline sont configurées ci-dessous

Voir: https://circleci.com/docs/2.0/configuration-reference/#workflows

flux de travail :

 

4. Écrivez le nom du flux de travail.

  point net:

 

5. Dans le flux de travail, vous définissez les tâches que vous souhaitez exécuter.

 jobs : - build - sign : requiert : - build

 

Définir l'étape de construction

6. Définissez une tâche à appeler ultérieurement dans un workflow.

 (Voir : https://circleci.com/docs/2.0/configuration-reference/#jobs)

emplois : construire :

 

7. Créer une variable d'environnement

• Les variables d'environnement sont utilisées pour rendre les échantillons plus lisibles. Dans la capture d'écran ci-dessus d'un exemple de flux de travail de signature, le PROJECT_NAME, PROJECT_VERSION et DOTNET_VERSION ont éventuellement été omis. La signature peut toujours se poursuivre même avec ces omissions.  

  environnement : PROJECT_NAME : HelloWorld PROJECT_VERSION : 0.0.1 DOTNET_VERSION : 3.1 WORKSPACE : /home/circleci/project

 

8.  Définissez un exécuteur Docker : (https://circleci.com/docs/2.0/executor-types/)

    # Vous pouvez spécifier une image de Dockerhub ou utiliser l'une de nos images pratiques du Developer Hub de CircleCI.

 menu fixe : - image : mcr.microsoft.com/dotnet/sdk:3.1-bullseye

 

9. Placez le répertoire de travail pour le travail

  répertoire_de_travail : /home/circleci/project

 

10. Ajouter des étapes au travail

    Voir : https://circleci.com/docs/2.0/configuration-reference/#steps

  étapes:

 

11.  Extrayez le code source afin que le workflow puisse y accéder.

    - vérifier

 

12. Créer un répertoire d'artefacts pour stocker des fichiers d'artefacts signés et non signés

    - run : nom : commande Créer un répertoire d'artefacts : | mkdir -p ${WORKSPACE}/artefacts mkdir -p ${WORKSPACE}/packages

 

13.  Créez un projet ou une solution dotnet et toutes ses dépendances.

      - run : name : Build Dotnet Project Command : dotnet build dotnet/${PROJECT_NAME}.csproj -c Release

 

14. Copier l'artefact dans le répertoire des artefacts

• Dans cet exemple de workflow de signature écrite, plusieurs types de projets ont été créés. C'est pourquoi les fichiers des différents types de projets ont été conservés en créant des sous-dossiers. Un sous-dossier nommé 'dotnet' a été créé pour les projets Dotnet. Dans la capture d'écran de démonstration ci-dessus, il n'était pas nécessaire de créer un sous-dossier nommé "dotnet", il n'a donc pas été inclus dans le script.

  - run : nom : Commande Copier les artefacts : | cp dotnet/bin/Release/netcoreapp${DOTNET_VERSION}/${PROJECT_NAME}-${PROJECT_VERSION}.dll ${WORKSPACE}/packages/HelloWorld.dll

 

15. Conserver l'artefact dans le répertoire des artefacts pour signature

  - persist_to_workspace : racine : . chemins : - packages/*

 

Définir l'étape de signature

16. Définir la tâche de signature

 signe:

 

17. Créer une variable d'environnement

• Dans la capture d'écran ci-dessus, la commande sign a été définie directement dans le script sign et non sous les variables d'environnement. BLes deux méthodes peuvent signer correctement avec CircleCI.
• Les variables d'environnement sont utilisées pour rendre les échantillons plus lisibles. Dans la capture d'écran ci-dessus de l'exemple de flux de travail, certaines variables n'étaient éventuellement pas incluses. La signature peut toujours se poursuivre même avec ces omissions.  

    environnement : ENVIRONMENT_NAME : PROD COMMAND : sign WORKSPACE : /home/circleci/project

 

18.     Placez le répertoire de travail pour le travail sur Circle-CI

 répertoire_de_travail : /home/circleci/project

 

19. Nom de l'artefact pour la signature

• La valeur 'artifact-name' est une option pour plusieurs projets. Le paramètre 'artifact-name' a été ajouté afin que la même partie de signature puisse être utilisée pour tous les types de projets. Étant donné que l'exemple de la capture d'écran est basé sur un seul projet, il n'était pas nécessaire de l'inclure.

    paramètres : nom-artefact : type : chaîne par défaut : ''

 

20. Définissez un exécuteur docker :

 Pour une référence supplémentaire, voir : https://circleci.com/docs/2.0/executor-types/

       Vous pouvez spécifier une image de Dockerhub ou utiliser l'une de nos images pratiques du Developer Hub de CircleCI.

       Assurez-vous de mettre à jour la balise d'image Docker ci-dessous vers la version openjdk de votre application.

       Une liste des images CircleCI Docker Convenience disponibles est disponible ici : https://circleci.com/developer/images/image/cimg/openjdk

   docker : - image : cimg/openjdk:17.0.3

 

21. Ajouter des étapes au travail

      Pour une référence supplémentaire, voir : https://circleci.com/docs/2.0/configuration-reference/#steps

    étapes:

 

22. Créer un répertoire d'artefacts pour stocker des fichiers d'artefacts signés et non signés

  - run : nom : commande Créer un répertoire d'artefacts : | mkdir -p ${WORKSPACE}/artefacts mkdir -p ${WORKSPACE}/packages

 

23. Joindre à l'espace de travail afin d'accéder au fichier d'artefact

   - attach_workspace : à : /home/circleci/project

 

24. Activer Docker pour CodeSigner sur Circle-CI

 - setup_remote_docker : nom : version de Setup Remote Docker : 19.03.13 docker_layer_caching : vrai

 

25. Extraire l'image Docker Codesigner du registre Github

        - run : nom : Commande Docker Pull Image : | docker pull ghcr.io/sslcom/codedesigner: dernier docker pull alpin: 3.4

 

26. Écrivez l'étape où l'artefact sera signé avec CodeSignTool.

 - run : nom : Signer le fichier d'artefacts commande : | docker create -v /codesign/packages --name codesign-in alpine:3.4 /bin/true docker create -v /codesign/artifacts --name codesign-out alpine:3.4 /bin/true docker cp ${WORKSPACE}/packages /<< parameters.artifact-name >> codesign-in:/codesign/packages docker run -i --rm --dns 8.8.8.8 --network host --volumes-from codesign-in --volumes-from codesign- out -e USERNAME=${USERNAME} -e PASSWORD=${PASSWORD} -e CREDENTIAL_ID=${CREDENTIAL_ID} -e TOTP_SECRET=${TOTP_SECRET} -e ENVIRONMENT_NAME=${ENVIRONMENT_NAME} ghcr.io/sslcom/codesigner:latest ${COMMAND} -input_file_path=/codesign/packages/<< parameters.artifact-name >> -output_dir_path=/codesign/artifacts docker cp codesign-out:/codesign/artifacts/<< parameters.artifact-name >> ${ WORKSPACE}/artifacts/<< parameters.artifact-name >>

 

27. Écrivez l'étape pour que votre artefact soit téléchargé à partir de votre flux de travail, ce qui vous permet de partager des données entre les travaux et de stocker des données une fois qu'un flux de travail est terminé

    - store_artifacts : nom : Télécharger les fichiers signés chemin : /home/circleci/project/artifacts/<< parameters.artifact-name >> destination : << parameters.artifact-name >>

 

Créer un nouveau référentiel sur la ligne de commande

Copiez les composants de la commande push depuis l'emplacement de votre projet sur votre compte GitHub

Inclure tous les composants de commande push sur votre éditeur

Configurer un projet sur CircleCI en utilisant le référentiel intégré à GitHub

Définir toutes les variables d'environnement

Pendant que le projet est en cours d'exécution, cliquez sur le bouton Paramètres du projet suivi de Variables d'environnement pour définir les variables

Placez les valeurs pour chaque variable

Cliquez  Ajouter une variable d'environnement bouton pour ajouter les noms et les valeurs de toutes les variables requises pour le projet.

Attendre que le projet soit construit

Cliquez sur Persistance dans l'espace de travail

Attendez brièvement que l'archive de l'espace de travail soit téléchargée avec succès.

Cliquez sur le bouton de signature

Attendez que le Docker distant soit configuré

Cela peut prendre plus d'une minute, selon la taille du fichier

Attendez que les artefacts soient signés

Cliquer sur Artefacts languette

Si vous cliquez Artefacts, vous pourrez voir le fichier que vous avez signé avec succès. Vous serez également informé par CircleCI de la signature réussie du code.

Exemple de pipeline CircleCI

Découvrez l'exemple de pipeline CircleCI que nous avons créé sur github.com/SSLcom/codedesigner-circleci-sample

Autres guides d'intégration de la signature à distance CI/CD

• Intégration de la signature de code dans le cloud avec les actions GitHub
• Intégration de la signature de code dans le cloud avec GitLab CI
• Intégration de la signature de code dans le cloud avec Jenkins CI
• Intégration de la signature de code dans le cloud avec Travis CI
• Intégration de la signature de code dans le cloud avec Azure DevOps
• Intégration de la signature de code dans le cloud avec BitBucket
• Automatisation de la signature de code dans le cloud avec les services CI/CD

Besoin de solutions personnalisées ? 

Grâce à nos connaissances spécialisées et à notre personnel d'assistance cinq étoiles, nous sommes prêts et disposés à travailler avec vous sur des solutions personnalisées ou des remises de signature de gros volumes au niveau de l'entreprise. Remplissez le formulaire ci-dessous et nous vous contacterons.