{"id":4353,"date":"2026-06-29T07:00:00","date_gmt":"2026-06-29T05:00:00","guid":{"rendered":"https:\/\/www.my-it-brain.de\/wordpress\/?p=4353"},"modified":"2026-06-26T09:52:12","modified_gmt":"2026-06-26T07:52:12","slug":"kernel-live-patching-fuer-red-hat-enterprise-linux-rhel","status":"publish","type":"post","link":"https:\/\/www.my-it-brain.de\/wordpress\/kernel-live-patching-fuer-red-hat-enterprise-linux-rhel\/","title":{"rendered":"Kernel Live Patching f\u00fcr Red Hat Enterprise Linux (RHEL)"},"content":{"rendered":"\n<p>Dieser Artikel richtet sich an jene, die sich f\u00fcr das Thema <a href=\"https:\/\/de.wikipedia.org\/wiki\/Kernel_Live_Patching\">Kernel Live Patching (KLP)<\/a> interessieren.<\/p>\n\n\n\n<p>Im ersten Teil des Artikels stelle ich dar, wann KLP in meinen Augen keine gute L\u00f6sung darstellt und man auf den Einsatz nach M\u00f6glichkeit verzichten sollte. Wissend, dass es manchmal nicht anders geht, beschreibe ich im zweiten Teil am Beispiel von RHEL 9, wie KLP eingerichtet und genutzt werden kann.<\/p>\n\n\n\n<p><em>Transparenzhinweis:<\/em> Ich arbeite als <a href=\"https:\/\/www.my-it-brain.de\/wordpress\/was-tut-ein-technical-account-manager-tam-bei-red-hat\/\" data-type=\"post\" data-id=\"3723\">Technical Account Manager (TAM)<\/a> f\u00fcr die Firma <a href=\"https:\/\/www.redhat.com\/de\/global\/dach\">Red Hat<\/a>, welche die Distribution <a href=\"https:\/\/de.wikipedia.org\/wiki\/Red_Hat_Enterprise_Linux\">Red Hat Enterprise Linux (RHEL)<\/a> herausgibt. Dieser Artikel spiegelt meine pers\u00f6nliche Meinung wider, welche mit der meines Arbeitgebers \u00fcbereinstimmen kann, dies jedoch nicht in jedem Fall muss.<\/p>\n\n\n\n<p>Der Userspace wird in diesem Artikel ausgeklammert, um den Umfang nicht zu sprengen. Ich werde diesen in einem folgenden Artikel aufgreifen.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Warum bzw. wann man Kernel Live Patching nicht nutzen sollte<\/h2>\n\n\n\n<p>Folgende Gr\u00fcnde sollten nicht zur Nutzung von KLP f\u00fchren, sondern auf andere Weise adressiert werden:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Angst vor dem Serverneustart<\/li>\n\n\n\n<li>Eine Softwarearchitektur, die Serverneustarts nicht vorsieht\/zul\u00e4sst<\/li>\n\n\n\n<li>Ungekl\u00e4rte Abh\u00e4ngigkeiten in vernetzten Systemen<\/li>\n\n\n\n<li>Der Glaube, mit KLP nie wieder neustarten zu m\u00fcssen<\/li>\n<\/ul>\n\n\n\n<p>Angst ist in der IT ein ganz schlechter Ratgeber. Hier sollte unbedingt die Ursache und nicht das Symptom behandelt werden. Denn Serverneustarts k\u00f6nnen auch noch aus folgenden Gr\u00fcnden passieren bzw. notwendig werden:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Der Server verliert vor\u00fcbergehend die Stromversorgung<\/li>\n\n\n\n<li>Eine <a href=\"https:\/\/de.wikipedia.org\/wiki\/Kernel_panic\">Kernel Panic<\/a> bringt das System zum Absturz<\/li>\n\n\n\n<li>Ein nicht mehr reagierendes System muss durch einen Reset neugestartet werden<\/li>\n\n\n\n<li>Umzug der Hardware an einen neuen Standort<\/li>\n<\/ul>\n\n\n\n<p>Dies sind nur vier Gr\u00fcnde, die mir sofort in den Sinn kommen. Wenn wir l\u00e4nger dar\u00fcber nachdenken, fallen uns bestimmt noch viele weitere ein (erg\u00e4nzt diese gern in den Kommentaren). Wichtig ist zu verstehen, dass Serverneustarts aus verschiedenen Gr\u00fcnden passieren und per se nicht schlimm sind.<\/p>\n\n\n\n<p>Wenn die Softwarearchitektur keine Neustarts einzelner Komponenten zul\u00e4sst, hat man ein ganz anderes Problem, welches dringend adressiert werden sollte. Soetwas wie 100%-tige Verf\u00fcgbarkeit gibt es nicht. Hier ist in meinen Augen zu kl\u00e4ren, ob es wirklich an der Anwendung oder eher an nicht verhandelten Wartungsfenstern liegt. KLP ist hier keine L\u00f6sung, da die H\u00e4ufigkeit von Neustarts nur reduziert bzw. das Problem in die Zukunft verschoben wird.<\/p>\n\n\n\n<p>Viele Sysadmins sind faul und das ist gut so. Motiviert es diese Personengruppe doch, manuelle T\u00e4tigkeiten zu automatisieren und sich die Arbeit zu erleichtern. Diese Faulheit darf allerdings nicht dazu f\u00fchren, dass man sich vor der Analyse komplexer und vernetzter Systeme dr\u00fcckt. Abh\u00e4ngigkeiten k\u00f6nnen analysiert und in den meisten F\u00e4llen aufgel\u00f6st werden. Sind sie bekannt, kann man sie im Patchprozess ber\u00fccksichtigen und den Vorgang inkl. Neustarts automatisieren. Auch in diesem Fall verz\u00f6gert KLP das Unvermeidliche nur.<\/p>\n\n\n\n<p>Kernel Live Patching k\u00fcmmert sich, wie der Name schon sagt, nur um den Kernel. Was ist mit dem Userspace? Auch hier gibt es sicherheitskritische Bibliotheken und Anwendungen, wie z.B. <code>openssl<\/code>, <code>gnutls<\/code> oder die <code>glibc<\/code>, welche bei erkannten Schwachstellen zeitnah abgesichert werden m\u00fcssen, um die Sicherheit des Systems nicht zu gef\u00e4hrden.<\/p>\n\n\n\n<p>Neustarts sind per se nicht schlecht. Wer seine Server regelm\u00e4\u00dfig neustartet, gewinnt Vertrauen, dass diese auch wieder hochfahren und ihre Dienste korrekt erbringen. Schlummernde Probleme werden schneller erkannt und t\u00fcrmen sich nicht zu einem St\u00f6rfall auf, der nur darauf wartet, im ung\u00fcnstigsten Moment zu passieren. Und im Optimalfall sind die Dienste so entworfen worden, dass der Ausfall\/Neustart eines einzelnen Servers nicht automatisch zu einer Nichtverf\u00fcgbarkeit des Dienstes f\u00fchrt.<\/p>\n\n\n\n<p>Ich m\u00f6chte mein Pl\u00e4doyer f\u00fcr Serverneustarts an dieser Stelle beenden und mich zwei Szenarios zuwenden, in denen KLP die Schmerzen des IT-Betriebs lindern kann.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Wann Kernel Live Patching Sinn macht<\/h2>\n\n\n\n<p>F\u00fcr besonders gesch\u00e4ftskritische IT-Dienste existieren h\u00e4ufig <a href=\"https:\/\/de.wikipedia.org\/wiki\/Service-Level-Agreement\">Service-Level-Agreements (SLA)<\/a>, die eine sehr hohe Verf\u00fcgbarkeit garantieren. Verst\u00f6\u00dfe gegen diese SLA werden von den Stakeholdern meist nicht toleriert und sind in manchen F\u00e4llen mit Vertragsstrafen belegt. Zwar gilt auch hier, dass das Problem eher in der Softwarearchitektur liegt, doch hilft dies den Sysadmins nicht, die mit dem Betrieb beauftragt sind. Sie m\u00fcssen irgendwie damit umgehen, bis eine bessere L\u00f6sung gefunden wird. Hier kann KLP eine Notl\u00f6sung sein, um Sicherheitsrisiken im Betrieb zu reduzieren und SLA-Verst\u00f6\u00dfe zu vermeiden.<\/p>\n\n\n\n<p>Angelehnt an die SLA spielt die Zeit, die ein Server f\u00fcr einen Neustart ben\u00f6tigt, eine Rolle. W\u00e4hrend die meisten VMs in Sekunden oder 1-2 Minuten neustarten, dauert dieser Vorgang bei Hardwareservern manchmal deutlich l\u00e4nger. Im Feld werden hier vereinzelt Zeiten zwischen 10-20 Minuten beobachtet (pro Server). M\u00fcssen mehrere Server f\u00fcr einen IT-Dienst sequentiell neugestartet werden, summieren sich die Zeiten schnell auf und machen gr\u00f6\u00dfere Wartungsfenster erforderlich. KLP kann helfen, die Anzahl der langen Wartungsfenster zu reduzieren.<\/p>\n\n\n\n<p>Es gibt Systeme, f\u00fcr deren Start ein manueller Eingriff durch Sysadmins notwendig ist. Dies kann z.B. die Eingabe eines BIOS-, Grub-, LUKS- oder UEFI-Passworts sein. Dies ist aufw\u00e4ndig und l\u00e4stig, l\u00e4sst sich aber leider nicht in allen F\u00e4llen wegautomatisieren. Auch hier erscheint es legitim, die Anzahl der manuellen Eingriffe durch den Einsatz von KLP zu minimieren.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Kernel Live Patching f\u00fcr RHEL 9 konfigurieren<\/h2>\n\n\n\n<p>Um mich f\u00fcr die Konfiguration vorzubereiten, habe ich folgende drei Quellen studiert:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><a href=\"https:\/\/docs.redhat.com\/en\/documentation\/red_hat_enterprise_linux\/9\/html\/managing_monitoring_and_updating_the_kernel\/applying-patches-with-kernel-live-patching_assembly_managing-kernel-command-line-parameters-with-uki\">Chapter&nbsp;9.&nbsp;Applying patches with kernel live patching<\/a><\/li>\n\n\n\n<li><a href=\"https:\/\/access.redhat.com\/articles\/7057149\">Kernel Live Patch Support Cadence Update<\/a> (Login erforderlich)<\/li>\n\n\n\n<li><a href=\"https:\/\/access.redhat.com\/articles\/4499631\">Kernel Live Patch life cycles<\/a> (Login erforderlich)<\/li>\n<\/ul>\n\n\n\n<p>Die wichtigsten Erkenntnisse daraus sind f\u00fcr mich:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Nicht jeder RHEL-Kernel erh\u00e4lt Live-Patches<\/li>\n\n\n\n<li>An jedem 1. M\u00e4rz, Juni, September und Dezember (jedes Quartal) wird f\u00fcr jedes unterst\u00fctzte RHEL-Release ein Kernel festgelegt, welcher Live-Patches erh\u00e4lt<\/li>\n\n\n\n<li>F\u00fcr jeden dieser Kernel verspricht Red Hat ein Jahr lang Updates f\u00fcr CVEs, die nach Red Hats Ermessen als <em>critical<\/em> oder <em>important<\/em> kategorisiert wurden (siehe <a href=\"https:\/\/access.redhat.com\/security\/updates\/classification\">Severity Ratings<\/a>)<\/li>\n<\/ul>\n\n\n\n<p>Dass Red Hat f\u00fcr ausgew\u00e4hlte Kernel-Releases ein Jahr lang Live-Patches bereitstellt, l\u00e4sst nicht den Schluss zu, nur noch einmal pro Jahr neustarten zu m\u00fcssen. Denn:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>CVEs der Kategorien <em>moderate<\/em> und <em>low<\/em> werden gar nicht adressiert<\/li>\n\n\n\n<li>Man erh\u00e4lt keinerlei Bugfixes und keinerlei Produktverbesserungen (Red Hat Enhancement Advisories (RHEA))<\/li>\n<\/ul>\n\n\n\n<p>Die Planung eines Neustarts wird jedoch ggf. vereinfacht.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Konfiguration von Kernel Live Patching f\u00fcr ein Labor-System<\/h3>\n\n\n\n<p>Ich habe ein Labor-System mit RHEL 9 auserkoren, welches als Hypervisor f\u00fcr einige Libvirt\/KVM-VMs genutzt wird.<\/p>\n\n\n\n<p>Dieses l\u00e4uft aktuell mit dem Kernel <code>5.14.0-687.15.1.el9_8.x86_64<\/code>, welcher laut <a href=\"https:\/\/access.redhat.com\/articles\/4499631\">Kernel Live Patch life cycles<\/a> kein Kernel ist, f\u00fcr den KLP angeboten wird. Es ist also zuerst der <code>kernel-5.14.0-687.10.1<\/code> zu installieren. Anschlie\u00dfend folge ich der <a href=\"https:\/\/docs.redhat.com\/en\/documentation\/red_hat_enterprise_linux\/9\/html\/managing_monitoring_and_updating_the_kernel\/applying-patches-with-kernel-live-patching_assembly_managing-kernel-command-line-parameters-with-uki#subscribing-the-currently-installed-kernels-to-the-live-patching-stream_applying-patches-with-kernel-live-patching\">Dokumentation<\/a>, um den Live-Patch-Stream f\u00fcr diesen Kernel zu aktivieren (siehe folgender Codeblock).<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>~]$ sudo dnf search kernel-5.14.0-687.10.1.el9_8\nUpdating Subscription Management repositories.\nLast metadata expiration check: 0:04:34 ago on Tue 23 Jun 2026 11:31:09 AM CEST.\n================ Summary Matched: kernel-5.14.0-687.10.1.el9_8 ================\nkpatch-patch-5_14_0-687_10_1.x86_64 : Initial empty kpatch-patch for\n                                    : kernel-5.14.0-687.10.1.el9_8.x86_64\n~]$ sudo dnf install kpatch-patch-5_14_0-687_10_1.x86_64<\/code><\/pre>\n\n\n\n<p>Wie im obigen Codeblock zu sehen, handelt es sich dabei um den initialen und leeren <code>kpatch-patch<\/code>. Das System hat also noch keinen Fix erhalten, sondern ist lediglich darauf vorbereitet.<\/p>\n\n\n\n<p>Im jetzigen Zustand w\u00fcrde DNF das System bei einem Update jedoch auf die letzte verf\u00fcgbare Kernelversion aktualisieren, welche keine Live-Patches erh\u00e4lt. Da dies von mir nicht gew\u00fcnscht ist, aktiviere ich einen Filter, der zuk\u00fcnftig nur noch KLP-f\u00e4hige Kernel anzeigt. Der folgende Codeblock zeigt den Zustand vor der Aktivierung des Filters, die Aktivierung selbst und den Zustand danach.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>~]$ sudo dnf kpatch status\nUpdating Subscription Management repositories.\nLast metadata expiration check: 0:04:36 ago on Tue 23 Jun 2026 11:43:44 AM CEST.\nKpatch update setting: auto-update\nKpatch filter setting: no-filter\nDependencies resolved.\nNothing to do.\nComplete!\n\n~]$ sudo dnf kpatch auto-filter\nUpdating Subscription Management repositories.\nKpatch filter setting: auto-filter\n\n~]$ sudo dnf kpatch status\nPlease note, kpatch filter is enabled, only kpatch supported kernels are shown.\nKpatch update setting: auto-update\nKpatch filter setting: auto-filter\nDependencies resolved.\nNothing to do.\nComplete!<\/code><\/pre>\n\n\n\n<p>Zum Abschluss ein Neustart und mein System l\u00e4uft mit dem richtigen Kernel <code>5.14.0-687.10.1.el9_8.x86_64<\/code>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Aufr\u00e4umarbeiten<\/h3>\n\n\n\n<p>Aktuell sind auf meinem System noch Kernel-Pakete installiert, die f\u00fcr KLP nicht vorgesehen sind, aber bei einem <code>dnf update<\/code> aktualisiert werden w\u00fcrden:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>~]# dnf list --installed kernel*\nUpdating Subscription Management repositories.\nPlease note, kpatch filter is enabled, only kpatch supported kernels are shown.\nInstalled Packages\nkernel.x86_64              5.14.0-611.55.1.el9_7 @rhel-9-for-x86_64-baseos-rpms\nkernel.x86_64              5.14.0-687.10.1.el9_8 @rhel-9-for-x86_64-baseos-rpms\nkernel.x86_64              5.14.0-687.15.1.el9_8 @rhel-9-for-x86_64-baseos-rpms\nkernel-core.x86_64         5.14.0-611.55.1.el9_7 @rhel-9-for-x86_64-baseos-rpms\nkernel-core.x86_64         5.14.0-687.10.1.el9_8 @rhel-9-for-x86_64-baseos-rpms\nkernel-core.x86_64         5.14.0-687.15.1.el9_8 @rhel-9-for-x86_64-baseos-rpms\nkernel-devel.x86_64        5.14.0-611.38.1.el9_7 @rhel-9-for-x86_64-appstream-rpms\nkernel-devel.x86_64        5.14.0-611.55.1.el9_7 @rhel-9-for-x86_64-appstream-rpms\nkernel-devel.x86_64        5.14.0-687.15.1.el9_8 @rhel-9-for-x86_64-appstream-rpms\nkernel-headers.x86_64      5.14.0-687.15.1.el9_8 @rhel-9-for-x86_64-appstream-rpms\nkernel-modules.x86_64      5.14.0-611.55.1.el9_7 @rhel-9-for-x86_64-baseos-rpms\nkernel-modules.x86_64      5.14.0-687.10.1.el9_8 @rhel-9-for-x86_64-baseos-rpms\nkernel-modules.x86_64      5.14.0-687.15.1.el9_8 @rhel-9-for-x86_64-baseos-rpms\nkernel-modules-core.x86_64 5.14.0-611.55.1.el9_7 @rhel-9-for-x86_64-baseos-rpms\nkernel-modules-core.x86_64 5.14.0-687.10.1.el9_8 @rhel-9-for-x86_64-baseos-rpms\nkernel-modules-core.x86_64 5.14.0-687.15.1.el9_8 @rhel-9-for-x86_64-baseos-rpms\nkernel-tools.x86_64        5.14.0-687.15.1.el9_8 @rhel-9-for-x86_64-baseos-rpms\nkernel-tools-libs.x86_64   5.14.0-687.15.1.el9_8 @rhel-9-for-x86_64-baseos-rpms<\/code><\/pre>\n\n\n\n<p>Um aufzur\u00e4umen, habe ich alle \u00fcberfl\u00fcssigen Pakte entfernt, bis nur noch der KLP-f\u00e4hige Kernel vorhanden ist:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>~]# dnf list --installed kernel*\nUpdating Subscription Management repositories.\nPlease note, kpatch filter is enabled, only kpatch supported kernels are shown.\nInstalled Packages\nkernel.x86_64                5.14.0-687.10.1.el9_8   @rhel-9-for-x86_64-baseos-rpms\nkernel-core.x86_64           5.14.0-687.10.1.el9_8   @rhel-9-for-x86_64-baseos-rpms\nkernel-modules.x86_64        5.14.0-687.10.1.el9_8   @rhel-9-for-x86_64-baseos-rpms\nkernel-modules-core.x86_64   5.14.0-687.10.1.el9_8   @rhel-9-for-x86_64-baseos-rpms<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Verhalten bei zuk\u00fcnftigen Updates<\/h3>\n\n\n\n<p>Durch den konfigurierten kpatch-Filter werden bei zuk\u00fcnftigen Updates nur Kernel aufgef\u00fchrt, die KLP-f\u00e4hig sind. Wird ein KLP ver\u00f6ffentlicht, erscheint dieser als <code>kpatch-patch<\/code> in der Ausgabe von <code>dnf up<\/code>`. Der folgende (gek\u00fcrzte) Codeblock zeigt dies beispielhaft.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>~]# dnf up\nUpdating Subscription Management repositories.\nPlease note, kpatch filter is enabled, only kpatch supported kernels are shown.\nDependencies resolved.\n===================================================================================\n Package       Arch   Version               Repository                        Size\n===================================================================================\nUpgrading:\n\u2026\nkpatch-patch-5_14_0-687_10_1 x86_64 1-1.el9_8 rhel-9-for-x86_64-baseos-rpms   22 k\n\u2026<\/code><\/pre>\n\n\n\n<p>Mit dem Befehl aus dem n\u00e4chsten Codeblock kann kontrolliert werden, welche KLP aktuell installiert sind und welche CVEs sie adressieren.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>~]# kpatch list\nLoaded patch modules:\nkpatch_5_14_0_687_10_1_1_1 &#91;enabled]\n\tCVE-2026-43037\n\nInstalled patch modules:\nkpatch_5_14_0_687_10_1_1_1 (5.14.0-687.10.1.el9_8.x86_64)<\/code><\/pre>\n\n\n\n<p>Obige Ausgabe best\u00e4tigt, dass ein KLP aktiv ist, der die kritische Schwachstelle <a href=\"https:\/\/access.redhat.com\/security\/cve\/cve-2026-43037\">CVE-2026-43037<\/a> schlie\u00dft.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Fazit<\/h2>\n\n\n\n<p>KLP funktioniert und ist einfach einzurichten. Es ist nicht in jedem Fall die richtige L\u00f6sung und l\u00f6st nicht alle Probleme, kann jedoch in manchen F\u00e4llen die Schmerzen im IT-Betrieb lindern.<\/p>\n\n\n\n<p>Der Userspace wurde ausgeklammert, um den Umfang dieses Artikels nicht zu sprengen. Dies hebe ich mir f\u00fcr einen folgenden Artikel auf.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Dieser Artikel richtet sich an jene, die sich f\u00fcr das Thema Kernel Live Patching (KLP) interessieren. Im ersten Teil des Artikels stelle ich dar, wann KLP in meinen Augen keine gute L\u00f6sung darstellt und man auf den Einsatz nach M\u00f6glichkeit verzichten sollte. Wissend, dass es manchmal nicht anders geht, beschreibe ich im zweiten Teil am<span class=\"continue-reading\"> <a href=\"https:\/\/www.my-it-brain.de\/wordpress\/kernel-live-patching-fuer-red-hat-enterprise-linux-rhel\/\">[Weiterlesen&#8230;]<\/a><\/span><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_metis_text_type":"standard","_metis_text_length":12622,"_post_count":0,"footnotes":""},"categories":[95],"tags":[937,936,430,60],"class_list":["post-4353","post","type-post","status-publish","format-standard","hentry","category-security-2","tag-kernel-live-patching","tag-kpatch","tag-osbn","tag-ubuntu"],"public_identification_id":"e8a154391d0b450d8a80265edf00fae0","private_identification_id":"1515437cd9674059ad56c1d446a5a59f","_links":{"self":[{"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/posts\/4353","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/comments?post=4353"}],"version-history":[{"count":8,"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/posts\/4353\/revisions"}],"predecessor-version":[{"id":4366,"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/posts\/4353\/revisions\/4366"}],"wp:attachment":[{"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/media?parent=4353"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/categories?post=4353"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/tags?post=4353"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}