Meilleures pratiques pour la mise à jour des machines Ubuntu EC2

12

Suite à la récente vulnérabilité de cœur d'OpenSSL, je voudrais garder mes machines EC2 régulièrement mises à jour. L'approche naïve serait de définir une tâche cron horaire pour les mises à jour de sécurité ( sudo apt-get update && sudo unattended-upgrade).

Y a-t-il des risques à le faire? Existe-t-il un mécanisme de mise à jour recommandé pour les machines EC2?

unattended-upgrades

— Adam Matan
source

13

Le package de mises à niveau sans assistance est le moyen standard d'appliquer automatiquement des correctifs de bogues et des correctifs de sécurité importants dans Ubuntu.

Je recommande d'installer cela sur chaque système Ubuntu:

sudo apt-get update &&
sudo apt-get install unattended-upgrades

Vous n'avez pas besoin de créer votre propre tâche cron. Le package en installe un pour vous.

Vous pouvez modifier la configuration par défaut si vous souhaitez modifier son comportement: https://help.ubuntu.com/lts/serverguide/automatic-updates.html

— Eric Hammond
source

Avez-vous des réflexions sur l'opportunité de le faire sur un serveur de production? Cela me rend nerveux d'avoir des changements appliqués discrètement et risque de voir la mise à jour échouer ou introduire des problèmes.

— ianjs

3

Par «chaque», j'entendais aussi les systèmes de production. J'applique automatiquement les correctifs de sécurité Ubuntu depuis de nombreuses années et je ne me souviens d'aucun problème grave. Cela me rend nerveux d'avoir un serveur de production assis sans correctifs aux problèmes de sécurité connus et risque de les faire exploiter. Cela dit, chaque situation a des besoins différents, il est donc préférable de passer par une phase de test rigoureuse pour chaque patch. Soyez conscient, cependant, qu'ils sont libérés tout le temps, donc vous serez occupé.

— Eric Hammond

1

Je ne le conseille pas sauf si vous avez une configuration redondante / cluster. Les procédures de mise à jour d'Ubuntu ne sont pas à la hauteur, j'ai arrêté plusieurs fois les services et plus récemment même un secteur de démarrage cassé ... Et nous n'avons rien de spécial - juste Apache en tant que proxy inverse et applications Tomcat.

— dualed

1

Nous utilisons unattended-upgradesde 2015 à 2020 sans aucun problème. Nous avons une petite configuration (sur DigitalOcean) avec:

nginx
mysql-server
php5-fpm php5-curl php5-mysql

Sur la base de bonnes performances passées, effectuer des mises à jour de cette manière semble plus sûr que de ne pas le faire. Mais ce n'est pas nécessairement une garantie pour l'avenir!

Ce n'est peut-être pas une si bonne idée apache, d'après les rapports d'autres utilisateurs et mon expérience passée des apachemises à jour. [Voir ci-dessus, et ici ]

Avec unattended-upgrades, une intervention manuelle sera toujours requise lorsque la version approchera EOL .

(Mis à part la question: d'après mon expérience avec TWiki, WordPress et Jenkins, la mise à jour de ces applications est en fait plus préoccupante que le système d'exploitation lui-même, bien que nous devrions bien sûr faire les deux. Pour la tranquillité d'esprit, vous pouvez mettre en sandbox des applications accessibles sur Internet en tant que processus non root s'exécutant dans un conteneur Docker.)

Mais comme vous avez posé des questions sur les meilleures pratiques , l'approche principale recommandée dans la documentation AWS est la suivante:

Créez et démarrez de nouvelles instances pour remplacer vos instances en ligne actuelles. Supprimez ensuite les instances actuelles.

Les nouvelles instances disposeront du dernier ensemble de correctifs de sécurité installés lors de l'installation.

(Février 2020)

Cela peut être fait dans le cadre d'une stratégie de déploiement bleu-vert . L'avantage ici est que vous pouvez exécuter des tests sur votre nouveau serveur avant de commuter le trafic. Si vos tests sont approfondis, alors en théorie, vos mises à jour peuvent être entièrement automatisées, vérifiées avant d'être mises en ligne, et sans temps d'arrêt.

Autres avantages:

Les tests peuvent vous donner un avertissement avancé si une attention humaine est requise (par opposition à unattended-upgrades, lorsque les avertissements ne proviennent que de vos utilisateurs une fois le problème résolu!)
Si votre système est compromis ou si vous décidez de changer de fournisseur, cette approche devrait faciliter le déploiement d'un nouveau déploiement. Votre stratégie de déploiement est scriptée, plutôt que la mémoire ancienne.

Mais bien sûr, il faut plus de configuration pour cette approche que la simple installation unattended-upgradeset plus de complexité, il y a donc encore place à l'erreur.

AWS mentionne également l'exécution de la "commande de mise à jour des dépendances de pile", qui semble être leur façon officielle de faire quelque chose de similaire unattended-upgrades. Il semble que cela puisse être déclenché à partir de leur interface Instances, mais je ne sais pas si cela peut être automatisé.

— joeytwiddle
source