TOC

Comment configurer GoCD avec Let’s Encrypt SSL Certificates sur Ubuntu 16.04

introduction

GoCD est une puissante plate-forme d’intégration et de distribution continue conçue pour automatiser les processus de test et de publication. Avec de nombreuses fonctionnalités avancées telles que la possibilité de comparer des versions, de visualiser des workflows complexes et d’automatiser le suivi des versions, Google GoCD est un outil flexible qui permet aux équipes de fournir des logiciels bien testés aux environnements de production.

Dans le dernier article, nous avons installé le serveur GoCD, configuré un agent, et l’authentification configurée. Dans ce guide, nous allons configurer GoCD pour qu’il utilise un certificat de confiance Let’s Encrypt SSL afin d’empêcher les avertissements du navigateur lors de l’accès à l’interface Web. Nous fournirons des instructions pour deux configurations possibles différentes.

La première méthode consiste à installer un serveur Web Nginx en tant que proxy inverse qui transférera les connexions au point de terminaison HTTP de GoCD. Ce choix offre une expérience plus transparente de Let’s Encrypt et sera probablement la meilleure option pour la plupart des gens.

La deuxième méthode dont nous discuterons consistera à acquérir un certificat de Let’s Encrypt, puis à remplacer le certificat utilisé par le point de terminaison HTTPS de GoCD. Bien que cela supprime la nécessité d’un serveur Web distinct, permettant éventuellement d’économiser des ressources, GoCD utilise le référentiel de certificats Java du fichier de clés Java qui n’est pas directement compatible avec le format de certificat proposé par Let’s Encrypt. Nous devrons créer un script pour convertir automatiquement les certificats au format attendu à chaque renouvellement. Cette option est préférable si votre serveur dispose de peu de ressources et si vous souhaitez tout allouer à GoCD.

Conditions préalables

Si vous n’avez pas encore de serveur GoCD configuré sur Ubuntu 16.04, vous devrez en configurer un avant de démarrer ce guide. Le serveur de base nécessite * au moins 2 Go de RAM et 2 cœurs de processeur *. GoCD a également besoin d’une partition ou d’un disque dédié à utiliser pour le stockage d’artefacts. Vous pouvez apprendre à configurer cet espace supplémentaire à l’aide de l’un de ces deux guides:

Une fois le serveur configuré, vous pouvez effectuer une configuration initiale et installer GoCD à l’aide de ces guides:

Pour acquérir un certificat SSL auprès de Let’s Encrypt, votre serveur devra avoir un * nom de domaine *.

Les autres exigences dépendent de la méthode que vous souhaitez utiliser et seront expliquées dans les sections appropriées. Lorsque vous êtes prêt à continuer, choisissez la méthode que vous souhaitez utiliser et suivez les instructions associées.

Option 1: Configuration de Nginx en tant que proxy inverse pour GoCD

Si vous souhaitez configurer Nginx en tant que proxy inverse se terminant par SSL pour GoCD, suivez cette section. Dans cette configuration, Nginx sera configuré pour desservir le trafic HTTPS à l’aide du certificat Let’s Encrypt. Il décryptera les connexions client puis transférera le trafic vers l’interface Web de GoCD à l’aide du protocole HTTP standard. Cela nécessite des frais supplémentaires pour l’interface Nginx, mais c’est une approche plus simple.

Exigences supplémentaires

Si vous souhaitez utiliser Nginx en tant que proxy inverse pour GoCD, vous devez d’abord installer Nginx et le client Let’s Encrypt, puis demander un certificat pour votre domaine. Ces tutoriels fournissent les étapes nécessaires à l’obtention d’un certificat et à la configuration de votre serveur Web:

Une fois que vous avez terminé les guides ci-dessus, GoCD doit toujours être accessible à l’aide du certificat auto-signé en accédant à + ​​https: //: 8154 + et la page Nginx par défaut doit être affichée à l’aide du certificat Let’s Encrypt lorsque vous supprimez le port. spécification.

Nous pouvons maintenant configurer Nginx pour que les requêtes proxy soient envoyées au backend GoCD afin que les connexions client soient chiffrées avec le certificat Let’s Encrypt.

Configuration de Nginx To Proxy sur l’interface Web HTTP de GoCD

Nous avons téléchargé un certificat SSL depuis Let Encrypt et avons configuré Nginx pour qu’il utilise ce certificat lors du traitement de demandes sur le port SSL par défaut. Notre prochaine étape consiste à configurer Nginx pour envoyer ces demandes par proxy à l’interface Web HTTP habituelle de GoCD, disponible sur le port 8153.

Pour commencer, ouvrez le fichier de blocage du serveur Nginx par défaut, configuré pour utiliser votre certificat Let’s Encrypt:

sudo nano /etc/nginx/sites-available/default

En haut du fichier, en dehors du bloc + serveur +, ouvrez une nouvelle section + upsteam +. Nous appellerons ce bloc + gocd + afin de pouvoir le reconnaître facilement ultérieurement. À l’intérieur, spécifiez l’adresse que Nginx peut utiliser pour contacter l’interface HTTP de GoCD. Dans notre cas, cela utiliserait le périphérique de bouclage local, donc l’adresse complète devrait être +127.0.0.1: 8153 +:

/ etc / nginx / sites-available / default

server {
   . . .

Ensuite, dans le bloc + serveur +, recherchez le bloc + emplacement / +. À l’intérieur, commentez la directive + try_files afin que nous puissions spécifier votre configuration de proxy. A la place de la ligne + try_files +, ajoutez une passe proxy à l’amont + gocd + que nous avons défini, en utilisant le protocole + http: // +. Incluez le fichier + proxy_params + pour définir les autres paramètres de proxy requis par notre bloc d’emplacement:

/ etc / nginx / sites-available / default

. . .

server
   . . .

   location / {
       try_files $uri $uri/ =404;


   }

   . . .

Enregistrez et fermez le fichier lorsque vous avez terminé.

Une fois que vous êtes revenu sur la ligne de commande, vérifiez les erreurs de syntaxe dans la configuration de Nginx en tapant:

sudo nginx -t

Si aucune erreur n’est trouvée, redémarrez le service Nginx en tapant:

sudo systemctl restart nginx

Votre interface Web GoCD devrait maintenant être accessible via votre nom de domaine habituel avec le protocole + https: // +.

Le dernier élément que nous devons ajuster est le paramètre URL du site dans l’interface Web de GoCD.

Mise à jour de l’URL du site GoCD pour utiliser la nouvelle adresse

Une fois que vous avez redémarré Nginx, la seule tâche à accomplir consiste à modifier le paramètre URL du site que GoCD utilise en interne pour créer les liens appropriés.

Rendez-vous sur le domaine de votre serveur GoCD dans votre navigateur Web et connectez-vous si nécessaire:

https://

Ensuite, cliquez sur * ADMIN * dans la barre de menus supérieure et sélectionnez * Configuration du serveur * dans le menu déroulant:

image: https: //assets.digitalocean.com/articles/gocd_ssl_1604/config_server_link.png [lien de configuration du serveur GoCD]

Dans la section * Gestion du serveur *, modifiez l’URL * du site * pour supprimer de la fin la spécification du port +: 8154 +. Si vous utilisiez auparavant une adresse IP au lieu d’un nom de domaine, modifiez l’URL pour qu’elle utilise également votre nom de domaine:

image: https: //assets.digitalocean.com/articles/gocd_ssl_1604/site_url_setting.png [Paramètre d’URL de site GoCD]

Faites défiler vers le bas de la page et cliquez sur * SAVE * pour appliquer le changement immédiatement. Votre site est maintenant configuré pour envoyer par proxy toutes les demandes de votre domaine via Nginx vers l’interface utilisateur Web de GoCD.

Option 2: Configuration du SSL natif du GoCD pour l’utilisation des certificats de chiffrement de Let

Suivez cette section si vous souhaitez configurer le serveur Web de GoCD pour utiliser les certificats Let Encrypt. Dans cette configuration, nous allons remplacer le certificat auto-signé déjà utilisé par le serveur GoCD par un certificat de confiance fourni par Let’s Encrypt. Pour ce faire, nous devons toutefois convertir les fichiers de certificat dans un nouveau format et les importer dans un fichier de clés Java. Nous allons créer un script afin que le processus puisse être répété chaque fois que les fichiers de certificat sont renouvelés.

Exigences supplémentaires

Si vous souhaitez gérer toutes les opérations SSL à partir de GoCD, vous devez télécharger un certificat à partir de Let’s Encrypt sans la procédure de configuration du serveur Web. Suivez ce guide pour télécharger le client approprié et obtenir un certificat pour votre domaine:

Une fois que vous avez terminé les guides ci-dessus, GoCD doit toujours être accessible à l’aide du certificat auto-signé en accédant à + ​​https: //: 8154 + et les fichiers de certificat fournis de Let’s Encrypt doivent être disponibles dans le répertoire `+ / etc / letsencrypt. / live / + `répertoire.

Création du script de conversion de certificat

GoCD utilise un Java Keystore pour gérer les certificats SSL. Malheureusement, il s’agit d’un format différent de celui utilisé par Let’s Encrypt. Pour utiliser nos certificats Let’s Encrypt avec GoCD, nous devrons les convertir en utilisant une procédure très spécifique.

En raison de la complexité de la procédure et de la nécessité de convertir les certificats à chaque renouvellement, nous allons créer un script pour automatiser la procédure. Dans le répertoire + / usr / local / bin +, créez et ouvrez un script appelé + convert_certs_for_gocd.sh + dans votre éditeur de texte:

sudo nano /usr/local/bin/convert_certs_for_gocd.sh

À l’intérieur, collez le script suivant. Le seul paramètre à mettre à jour est la valeur de la variable + base_domain +. Définissez cela sur le nom de domaine de votre serveur GoCD (il doit correspondre à la valeur du répertoire dans + / etc / letsencrypt / live / +):

/usr/local/bin/convert_certs_for_gocd.sh

#!/bin/bash

base_domain=""
le_directory="/etc/letsencrypt/live/${base_domain}"
working_dir="$(mktemp -d)"
gocd_pass="serverKeystorepa55w0rd"


clean_up () {
   rm -rf "${working_dir}"
}

# Use this to echo to standard error
error () {
   printf "%s: %s\n" "$(basename "${BASH_SOURCE}")" "${1}" >&2
   clean_up
   exit 1
}

trap 'error "An unexpected error occurred."' ERR

copy_cert_files () {
   cp "${le_directory}/fullchain.pem" "${working_dir}"
   cp "${le_directory}/privkey.pem" "${working_dir}"
}

convert_to_pkcs12 () {
   openssl_pkcs12_args=(
       "pkcs12"
       "-inkey" "${working_dir}/privkey.pem"
       "-in" "${working_dir}/fullchain.pem"
       "-export"
       "-out" "${working_dir}/${base_domain}.crt.pkcs12"
       "-passout" "pass:${gocd_pass}"
   )
   openssl "${openssl_pkcs12_args[@]}"
}

import_to_keytool () {
   keytool_args=(
       "-importkeystore"
       "-srckeystore" "${working_dir}/${base_domain}.crt.pkcs12"
       "-srcstoretype" "PKCS12"
       "-srcstorepass" "${gocd_pass}"
       "-destkeystore" "${working_dir}/keystore"
       "-srcalias" "1"
       "-destalias" "cruise"
       "-deststorepass" "${gocd_pass}"
       "-destkeypass" "${gocd_pass}"
   )
   keytool "${keytool_args[@]}"
}

install_new_keystore () {
   cp /etc/go/keystore /etc/go/keystore.bak
   mv "${working_dir}/keystore" "/etc/go/keystore"
   chown go:go /etc/go/keystore
   systemctl restart go-server
}

if (( EUID != 0 )); then
   error "This script requires root privileges"
fi

copy_cert_files && convert_to_pkcs12 && import_to_keytool && install_new_keystore && clean_up

Examinons exactement ce que fait ce script.

Au début, nous avons défini quelques variables pour rendre notre script plus facile à utiliser. Nous définissons le nom de domaine des certificats que nous souhaitons convertir et une variable qui se développe dans le répertoire de certificats Let’S Encrypt. Nous créons un répertoire de travail temporaire avec la commande + mktemp + et attribuons la valeur à une autre variable. GoCD requiert que tous ses mots de passe du fichier de clés Java soient «+ serverKeystore». `, nous définissons une autre variable pour contenir cette valeur.

Ensuite, nous définissons une fonction qui supprime le répertoire temporaire lorsqu’il est appelé. Nous l’utilisons à la fin de notre script pour nettoyer après nous-mêmes et également lorsque des erreurs inattendues se produisent. Pour accomplir cette seconde possibilité, nous créons une autre fonction qui affiche un message d’erreur et nettoie avant de quitter. Nous utilisons la commande + trap + pour appeler cette fonction automatiquement chaque fois qu’une erreur est générée.

Ensuite, nous créons les fonctions qui effectuent la conversion réelle. La première fonction configure notre espace de travail en copiant la clé privée et le certificat de chaîne complète dans le répertoire de travail. La fonction + convert_to_pkcs12 + utilise + openssl + pour joindre le fichier de certificat de chaîne complet et le fichier de clé privée du fichier combiné https://en.wikipedia.org/wiki/PKCS_12 utilisé par le keytool. Ce processus nécessite un mot de passe d’exportation. Nous utilisons donc la variable de mot de passe GoCD.

La fonction suivante importe le nouveau fichier PKCS 12 dans un fichier de clés Java. Nous importons le fichier et fournissons le mot de passe d’exportation. Nous fournissons ensuite le même mot de passe pour les différents mots de passe du fichier de clés. Enfin, la dernière fonction copie le nouveau fichier + keystore + dans le répertoire + / etc / go + (après avoir sauvegardé l’ancien + keystore +), ajuste la propriété du fichier et redémarre le serveur GoCD.

À la fin du script, nous vérifions que le script est appelé avec les autorisations appropriées en vérifiant si l’ID utilisateur effectif est «0», ce qui signifie «avec les mêmes autorisations que root». Appelez ensuite les fonctions dans l’ordre approprié pour convertir correctement les certificats et installer le nouveau fichier + keystore +.

Lorsque vous avez terminé, enregistrez et fermez le fichier pour continuer.

Effectuer la conversion initiale

Maintenant que nous avons un script de conversion, nous devrions l’utiliser pour effectuer la conversion initiale du certificat.

Tout d’abord, marquez le script comme étant exécutable afin qu’il puisse être exécuté directement sans appeler un interprète:

sudo chmod +x /usr/local/bin/convert_certs_for_gocd.sh

Maintenant, appelez le script avec + sudo + pour effectuer la conversion initiale, installez le fichier + keystore + généré et redémarrez le processus GoCD.

sudo /usr/local/bin/convert_certs_for_gocd.sh

Étant donné que le serveur GoCD doit redémarrer, le processus peut prendre un certain temps. Une fois le script terminé, le serveur peut attendre quelques instants avant d’être prêt à écouter les connexions. Vous pouvez regarder les ports actuellement utilisés par les applications en tapant:

sudo watch netstat -plnt

Cette vue affiche les ports TCP sur lesquels les applications écoutent actuellement avec une fréquence d’actualisation de deux secondes. Lorsque GoCD commence à écouter les ports 8153 et 8154, l’écran doit ressembler à ceci:

OutputEvery 2.0s: netstat -plnt                                                    Thu Jul 27 20:16:20 2017

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      1736/sshd
tcp6       0      0 :::22                   :::*                    LISTEN      1736/sshd
tcp6       0      0 :::                 :::*                    LISTEN      8942/java
tcp6       0      0 :::                 :::*                    LISTEN      8942/java

Une fois que les ports 8153 et 8154 sont présents, appuyez sur * CTRL-C * pour quitter l’affichage.

Une fois que l’application a commencé à écouter les connexions, vérifiez l’interface Web en visitant votre domaine GoCD sur le port 8154 à l’aide de HTTPS:

https://:8154

Auparavant, lors de l’accès à cette page, une icône dans la barre d’adresse indiquait que le certificat n’était pas fiable (notez que l’indicateur visuel de votre navigateur peut être différent):

image: https: //assets.digitalocean.com/articles/gocd_ssl_1604/ssl_cert_not_trusted_icon.png [Icône de certificat SSL Chrome non approuvé]

Lors de votre première visite, vous deviez probablement cliquer sur un écran d’avertissement de votre navigateur:

image: https: //assets.digitalocean.com/articles/gocd_install_1604/browser_ssl_warning.png [avertissement SSL du navigateur]

Maintenant que nous avons remplacé le certificat auto-signé par un certificat approuvé fourni par Let’s Encrypt, le navigateur indiquera que le certificat est approuvé et que les utilisateurs n’auront pas à ignorer un avertissement du navigateur pour accéder au site. Notez que le navigateur précédent peut être mis en cache par votre navigateur jusqu’à la fermeture de votre onglet, fenêtre ou session en cours:

image: https: //assets.digitalocean.com/articles/gocd_ssl_1604/ssl_cert_trusted_icon.png [Icône de confiance du certificat SSL Chrome]

Cela signifie que GoCD a pu utiliser le certificat Let’s Encrypt que nous avons converti.

Configuration d’un crochet de renouvellement automatique

Maintenant que nous avons vérifié que notre script a converti correctement les actifs de certificat, nous pouvons nous assurer que + certbot + appelle notre script chaque fois que le certificat est renouvelé.

Ouvrez le fichier de configuration de renouvellement de votre domaine dans le répertoire + / etc / letsencrypt / renew + en tapant:

sudo nano /etc/letsencrypt/renewal/.conf

A l’intérieur, dans la section + [renewparams] + du fichier, ajoutez un paramètre de ligne + renew_hook + à l’emplacement de votre script:

/etc/letsencrypt/renewal/exemple.com.conf

. . .
[renewalparams]
. . .
renew_hook = /usr/local/bin/convert_certs_for_gocd.sh

Le logiciel + certbot + installe un travail + cron + qui vérifie si des certificats doivent être renouvelés deux fois par jour. Après le renouvellement d’un certificat, le script spécifié par + renew_hook + sera exécuté. De cette manière, nous pouvons nous assurer que GoCD utilise toujours le dernier certificat valide acquis auprès de Let’s Encrypt.

Enregistrez et fermez le fichier lorsque vous avez terminé.

Vous pouvez vérifier que vous n’avez pas introduit d’erreurs de syntaxe dans le fichier en effectuant une procédure sèche de renouvellement. Notez que ceci n’exécutera pas notre script de conversion de certificat, mais il affichera un avis l’informant de son ignorance:

sudo certbot renew --dry-run
OutputSaving debug log to /var/log/letsencrypt/letsencrypt.log

-------------------------------------------------------------------------------
Processing /etc/letsencrypt/renewal/.conf
-------------------------------------------------------------------------------
Cert not due for renewal, but simulating renewal for dry run
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for
Waiting for verification...
Cleaning up challenges


-------------------------------------------------------------------------------
new certificate deployed without reload, fullchain is
/etc/letsencrypt/live//fullchain.pem
-------------------------------------------------------------------------------
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates below have not been saved.)

Congratulations, all renewals succeeded. The following certs have been renewed:
 /etc/letsencrypt/live//fullchain.pem (success)
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates above have not been saved.)

La sortie ci-dessus vérifie que les modifications apportées n’empêchent pas le renouvellement du certificat. La sortie indique également que le raccord de renouvellement est dirigé vers l’emplacement de script correct.

Conclusion

Dans ce guide, nous avons présenté deux manières différentes de sécuriser une installation GoCD avec un certificat SSL approuvé de Let’s Encrypt. La première méthode consistait à configurer le certificat avec Nginx, puis à transmettre le trafic par proxy à l’interface Web de GoCD. La deuxième option convertissait les fichiers de certificat Let’s Encrypt au format PKCS 12 et les importait dans un fichier de clés Java à utiliser par GoCD de manière native. Les deux options sécurisent l’interface Web de GoCD avec un certificat de confiance, mais elles y parviennent à l’aide de stratégies différentes et avec des compromis uniques. L’approche qui vous convient dépendra en grande partie des besoins et des objectifs de votre équipe.

Related