Bei Upgrade von 7.1 auf 7.2 wurde cloud-init aktiviert -> führt zu massiven Problemen

[jalfe]

Moin,

Wir haben ein 5-Node Setup und wollten heute morgen von 7.1-10 auf 7.2 upgraden. Wir haben die erste Node vorbereitet, das bedeutete in unserem Falle, dass wir die Windows-Maschinen darauf herunter gefahren haben und wir eine Kubernetes Node ebenfalls cordoned, drained und herunter gefahren haben. Die Windows Maschinen ziehen wir nicht innerhalb des Clusters um, da wir nicht die Lizenzen dafür haben und die Kubernetes Node müssen wir herunter fahren, da wir eine Platte von dem PVE-Node als Hardware in die VM eingehangen haben, da wir in dem Kubernetes was dort Läuft ein rook-ceph laufen haben. Würden wir das nicht machen, hätten wir sonst ein ceph im ceph und somit eine unnötige Speicher-Redundanz.
Alle Linux-VMs die wir haben, sind mit cloud-init konfiguriert. Auch die Kubernetes-Node.
Das Upgrade haben wir auf der Linux-Konsole über apt durchgeführt.

Nach dem Neustart kam die frisch geupgradete PVE-Node mit einer Identitätskriese wieder ans leben, denn sie denkt nun, sie sei die erwähnte Kubernetes-Node. Die Node hat sich die korrekte IP genommen, hat jedoch scheinbar cloud-init Einstellungen aus der Kubernetes Node übernommen. Genau diese Kubernetes Node hat als einzige Node den cloud-init im ZFS der PVE-Node, da wir, wie erwähnt, die Kubernetes Node aufgrund der Hardware-Zugehörigkeit über die Festplatte zu der PVE-Node, nicht migrieren.

Wenn versucht wird cloud-init zu deaktivieren und über systemctl abzuschalten, ist es beim nächsten Boot wieder da und alle Einstellungen (z.B. Hostname wieder ändern) sind überschrieben worden. Zudem meldet sich die PVE-Node nicht korrekt bei den anderen an, somit kann ich auch nicht die cloud-init aus dem local-zfs in das ceph des PVE verschieben.

Warum greift sich die PVE-Node überhaupt die cloud-init Einstellungen aus dem zfs nach dem Upgrade? Warum ist cloud-init aktiviert nach dem Upgrade?

 

[jalfe]

Über die Management-Konsole haben wir den alten (5.13.19-6-pve) Kernel gewechselt. Vorher haben wir in der cloud-init conf die Option preserve_hostname auf true gesetzt. Nun ist cloud-init immernoch aktiv, aber die PVE-Node scheint damit ihre Identitätskrise zu überwinden.

Im Anschluss habe ich die cloud-init aus der Hardware der Kubernetes VM entfernt um PVE Ceph Storage neu angelegt, so dass nichts mehr im lokalen zfs zu finden ist.

Dann haben wir wieder in den 5.15.35-1-pve Kernel gebooted, in der Hoffnung, dass das Problem damit behoben ist und es scheint damit tatsächlich behoben zu sein - zumindest läuft es nun erstmal.

Dennoch bleibt die Frage offen: Wenn ein cloud-init im local-zfs vorhanden ist, warum wird es nach dem Upgrade gegriffen und verwendet?

 

[jalfe]

Wir haben mit dem Wissen nun die zweite der 5 Nodes geupgraded und haben vorher das local-zfs aufgeräumt, so dass keine cloud-init (und andere) darin vorhanden sind. In dem Falle ist das Upgrade problemlos durchgelaufen.

Auf der letzten Node haben wir allerdings noch eine lokale Belegung im zfs, die wir aufgrund der Größe nicht auflösen können. Wir hoffen, dadurch dass es kein cloud-init Volume ist, dass es hierbei nicht zu Komplikationen kommt.

 

[jalfe]

Auch die letzte Node, welche 2 Festplatten einer VM im local-zfs hat, ist durch gelaufen. Es scheint das Problem also exklusiv damit vorzuliegen, wenn man ein cloud-init Volume im local-zfs hat.

Wenn noch weitere Informationen für ein Nachstellen oder Debugging benötigt werden, kann ich die gern bereit stellen.

Zusammengefasst besteht der Verdacht, dass mit einem Upgrade von 7.1 auf 7.2 das cloud-init ein Verhalten an den Tag legt, so dass es sich das erst-Beste cloud-init Volume aus dem local-zfs schnappt (wenn vorhanden) und dieses auf dem Proxmox-Host anwendet. Man kann das mit einem starten in den alten Kernel und dem setzen von preserve_hostname-Flag in der cloud-init config wieder zurück setzen. Dennoch scheint mir das Problem von siginfikanter Relevanz zu sein und auch potentielle Sicherheitsprobleme mit sich zu bringen, da die SSH-Schlüssel aus dem cloud-init Volume entsprechend mit an den proxmox-Host übertragen werden. Somit können versehentlich hohe Privilegien verteilt werden.

 

[aaron]

Ist auf den Nodes selbst Cloudinit installiert? apt search cloud-init

Das sollte nämlich eigentlich nicht der Fall sein.

 

[jalfe]

Auf den Nodes ist überall cloud-init installiert. Wir hatten bis vor ca. 3 Monaten nur 3 Nodes. Und haben dann noch 2 dazu gebaut. Auch bei den "frisch" installierten, ist cloud-init mit installiert. Dieses wurde nicht manuell hinterher installiert.

 

[aaron]

Wie wurden die Nodes installiert? Mit dem Proxmox VE Installer? Dann sollte das cloud-init Paket nicht installiert sein.

Gibt es vielleicht andere Möglichkeiten, wie das cloud-init Paket auf die Nodes gekommen ist? Ansible oder ähnliches, das zum Beispiel ein Grundset an weiteren Paketen installiert?

 

[jalfe]

Die Nodes wurden mit dem Installer von der Website installiert. Also über die ISO.

Wir haben die Ansible Rollen bereits geprüft und konnten darüber nichts fest stellen.

Davon abgesehen, sollt es doch egal sein ob cloud-init verwendet wird oder nicht nicht - Es sollte sich doch nicht das erst-beste cloud-init image von PVE gegriffen werden um es dann einfach anzuwenden - oder ist das ein gewolltes Verhalten?

 

[tom]

Die Nodes wurden mit dem Installer von der Website installiert. Also über die ISO.

Unsere Proxmox VE ISO installiert ganz sicher kein cloud-init. Von welcher ISO und von welcher "Website" denn genau?

sha256 prüfen, ob hier wirklich unser verwendet wird.
=> https://www.proxmox.com/en/downloads/item/proxmox-ve-7-2-iso-installer

cloud-init muss wohl von irgendwem nachinstalliert worden sein.

 

[jalfe]

Von eben jener Website. Aber natürlich war es damals ein 7.1er Release und die sha-Summen stimmten damals ebenfalls. Heute kann ich das leider nicht mehr Nachvollziehen.

Wir haben insgesamt 8 Knoten mit Proxmox. Ich habe auf den Knoten folgendes geprüft:

root@pve-ni-01:/var/log/apt# find . -name history.log.\*.gz -print0 | xargs -0 zgrep -B 2 "cloud-init"
./history.log.1.gz-
./history.log.1.gz-Start-Date: 2022-04-27  14:42:45
./history.log.1.gz:Commandline: /usr/bin/apt-get -y -o Dpkg::Options::=--force-confdef -o Dpkg::Options::=--force-confold install vim tree ncdu jq xmlstarlet cloud-init git tmux screen
./history.log.1.gz:Install: lsb-release:amd64 (11.1.0, automatic), python3-blinker:amd64 (1.4+dfsg1-0.3, automatic), libonig5:amd64 (6.9.6-1.1, automatic), git:amd64 (1:2.30.2-1), vim:amd64 (2:8.2.2434-3+deb11u1), libgpm2:amd64 (1.20.7-8, automatic), python3-importlib-metadata:amd64 (1.6.0-2, automatic), xmlstarlet:amd64 (1.6.1-2.1), libeatmydata1:amd64 (105-9, automatic), python3-jsonpatch:amd64 (1.25-3, automatic), cloud-guest-utils:amd64 (0.31-2, automatic), python3-more-itertools:amd64 (4.2.0-3, automatic), python3-attr:amd64 (20.3.0-1, automatic), python3-jsonschema:amd64 (3.2.0-3, automatic), python3-oauthlib:amd64 (3.1.0-2, automatic), cloud-init:amd64 (20.4.1-2+deb11u1), net-tools:amd64 (1.60+git20181103.0eebece-1, automatic), python3-json-pointer:amd64 (2.0-2, automatic), python3-jinja2:amd64 (2.11.3-1, automatic), vim-runtime:amd64 (2:8.2.2434-3+deb11u1, automatic), eatmydata:amd64 (105-9, automatic), ncdu:amd64 (1.15.1-1), jq:amd64 (1.6-2.1), python3-configobj:amd64 (5.0.6-4, automatic), python3-setuptools:amd64 (52.0.0-4, automatic), libjq1:amd64 (1.6-2.1, automatic), python3-pyrsistent:amd64 (0.15.5-1+b3, automatic), tmux:amd64 (3.1c-1+deb11u1), git-man:amd64 (1:2.30.2-1, automatic), tree:amd64 (1.8.0-1+b1), screen:amd64 (4.8.0-6), python3-zipp:amd64 (1.0.0-3, automatic), libutempter0:amd64 (1.2.1-2, automatic)

Entsprechend wurde das im letzten Monat installiert. Auf allen Knoten ist ein kurzer Abstand zueinander (-+10 Minuten), was für eine automatische Installation spricht. Woher diese kommt, müssen wir nun noch intern klären. Mein Bauchgefühl sagt, dass es von Ansible-Entwicklungen kommt, die an einer Stelle schief gegangen sind - das es damals nicht aufgefallen ist und bevor es auffallen konnte schon wieder gefixed wurde. Vielen Dank für den Hinweis!

Wir haben nun cloud-init auf absent gesetzt, damit es nicht wieder installiert wird - somit können Rechte nicht an irgendeinem Punkt eskaliert werden.

Meiner Meinung nach ist die Herkunft der Installation aber auch zweitrangig und die Frage, ob das Beschriebene Verhalten mit einer cloud-init Installation auf einem PVE-Host so von PVE gewollt ist, ist die Wichtigere. Einen Hinweis dazu habe ich leider nicht finden können.

 

[megaloblast]

Ich weiß nicht wie cloud-init die datasource/Disk wählt, die die cloud-init Daten enthält, aber ich vermute das ist das normale Verhalten. Eventuell gibt /run/cloud-init* Aufschluss.

Eine Rechteeskalation würde ich nicht befürchten, weil im Normalfall nur Admins die Disk-Konfiguration der Cluster Nodes ändern dürfen.

* Aus der cloud-init FAQ:

Where are the logs?​

Cloud-init uses two files to log to:

• /var/log/cloud-init-output.log: captures the output from each stage of cloud-init when it runs
• /var/log/cloud-init.log: very detailed log with debugging output, detailing each action taken
• /run/cloud-init: contains logs about how cloud-init decided to enable or disable itself, as well as what platforms/datasources were detected. These logs are most useful when trying to determine what cloud-init ran or did not run.

 

[jalfe]

Im Standard ist cloud-init so konfiguriert, dass es alles mögliche in /dev/ sucht, bis es was findet, was so aussieht, als könnte cloud-init das verwenden. Im besten Falle ist das natürlich die gewollte cloud-init partition. Im unserem Falle ist es allerdings /dev/zd* gewesen, also eine lokale zfs-Partition.

Dem "normalerweise" Stimme ich zu. Jedoch könnte man eine Rolle erstellen, in der man die Hardware anpassen darf (wenn man z.B. eine 1:1 Beziehung von VM und Host hat), jedoch eigentlich nicht Zugriff auf den Host haben sollte. In der Konstellation könnte man schon Rechte eskalieren. Der Vektor ist zwar gering, aber nicht auszuschließen.

 

[jalfe]

Zudem ist uns aufgefallen, dass sich die ServerID in dem Prozess geändert hat und wir diese in der Subscription wieder anpassen mussten. Was hat denn in dem Prozess den wechsel der ServerID ausgelöst?

 

[aaron]

Da wird cloudinit wohl auch den ssh host rsa key getauscht/neu generiert haben, was dann zu einer neuen Server ID geführt hat.
Ich würde auf der Node sicherheitshalber noch ein pvecm updatecerts machen, damit evtl. geänderte Keys und Fingerprints wieder in die know_hosts/authorized_keys eingetragen werden.