Wenn dieser Artikel erscheint, habe ich das Bielefelder IT-Service-Zentrum (BITS) der Universität Bielefeld und damit den öffentlichen Dienst nach acht Jahren verlassen. Seit dem 1. März arbeite ich als Senior Technical Account Manager – Platforms für die Red Hat GmbH in München. Ja, ich bin jetzt tatsächlich auf dem besten Weg, ein echter Red Hatter zu werden.
Warum?
Seit 2016 arbeite ich beruflich mit Red Hat Enterprise Linux (RHEL). Und seit 2019 bin ich stolz, zu den Red Hat Accelerators zu gehören. Beruflich habe ich mich jedoch nicht nur um Linux gekümmert.
Es fielen noch etliche weitere Themen in meinen Aufgabenbereich. In mir wuchs jedoch der Wunsch, meinen beruflichen Schwerpunkt in Richtung Linux und Open Source zu verlagern. So ist meine Motivation zum Jobwechsel, dass ich nun in einem Unternehmen arbeite, wo ich von Linux- und Open-Source-Experten umgeben bin. Hier kann ich jeden Tag mit und an Technologien arbeiten, die mich interessieren und meinen Kunden dabei helfen, diese in ihrem Umfeld optimal einzusetzen. Darüber hinaus habe ich hier die besten Chancen, mein Wissen zu erweitern und zu vertiefen. Dies freut mich sehr.
Hey, ich tue Dinge für und mit Open Source und werde dafür bezahlt. Was kann sich ein Linux-Nerd denn mehr wünschen?
Was ändert sich für das BITS?
Na hoffentlich nichts. :-)
Ich hoffe, dass ich euch in guter Erinnerung bleibe und euch von Zeit zu Zeit besuchen darf. Ich beobachte übrigens den Mensaplan. Wenn mal wieder der Burrito mit Wedges auf dem Speiseplan steht, begleite ich die Post-Pandemische-Peer-Group-01 gern zum Essen. ;-)
Was ändert sich für Red Hat?
Ich hoffe, dass durch meine Anstellung nicht gleich ein Ruck durch das ganze Unternehmen geht. Mein Team hat mit mir jetzt ein Mitglied mehr, welches neugierig ist, jeden Tag dazulernen möchte und bereit ist, euch mit Fragen zu löchern.
Habt vielen Dank für den tollen Empfang und die Aufnahme in den ersten Tagen. Ich freue mich auf die weitere Zusammenarbeit mit euch und darauf noch viele weitere Kolleg*innen kennenzulernen.
Was ändert sich für My-IT-Brain?
Hier ändert sich auch nichts. Dies ist und bleibt mein persönlicher Blog, in dem ich meine Meinung zu allen Themen schreibe, die mich interessieren. Die Artikel spiegeln dabei meine persönlichen Ansichten wider. Diese können mit denen meines Arbeitgebers übereinstimmen, müssen dies aber nicht.
Evtl. wird es hier in der nächsten Zeit ruhiger, während ich mich voll und ganz auf das Onboarding bei Red Hat konzentriere. In Zukunft dürft ihr aber wieder mit Artikeln, Anleitungen und Wochenend-Projekten rund um Linux und Open Source rechnen.
Wenn sich die Artikel zukünftig thematisch stärker mit RHEL und Fedora beschäftigen, liegt dies schlicht daran, dass ich mich mit diesen Distributionen stärker beschäftige als mit anderen. Berufliches und privates Interesse liegen bei mir schon immer eng beieinander.
Jetzt stürze ich mich ins Onboarding und versuche, so viel wie möglich von dieser neuen Welt im ersten Anlauf aufzunehmen. Bis neulich. :-)
In seiner heutigen Presseerklärung gibt Red Hat den offiziellen Start des Red Hat Accelerators Programms bekannt.
Die Red Hat Accelerators sind eine einzigartige Gemeinschaft, bestehend aus Open Source IT-Enthusiasten. Ich bin stolz Mitglied dieser Gemeinschaft zu sein. Dadurch habe dich die Möglichkeit:
Mich mit Gleichgesinnten zu vernetzen
Frühzeitig einen Blick auf neue Technologien und Entwicklungen von Red Hat zu werfen
Mit Experten von Red Hat zu interagieren
Die Produktentwicklung mit zu beeinflussen
Wir sind Kunden und Partner, welche gern über IT-Themen diskutieren, uns austauschen und Red Hat ehrliches Feedback zur ihren Produkten zukommen lassen.
Und diese Möglichkeiten stehen auch Dir offen!
Wenn auch Du ein Teil dieser außergewöhnlichen Gemeinschaft werden möchtest, erfährst du alles notwendige für deine Bewerbung unter diesem Link.
Vielen Dank an Andi, Grace und Jeff, welche alles dafür geben, damit wir uns in diesem Programm wohlfühlen.
Nein, dies ist nicht der Titel eines Kinofilms mit schnellen Autos. Dies ist der fünfte Artikel über meinen Test von Red Hat Insights. In diesem beschäftige ich mich mit den Anwendungen Patch und Drift.
Patch
So simpel wie der Name, ist auch die Funktion, die sich hinter diesem Menüpunkt verbirgt.
In Bild 1 würde man eine Übersicht der verfügbaren Red Hat Advisories sehen, welche auf den verbundenen Systemen noch nicht installiert sind. Da in diesem Fall alle angebundenen Systeme voll durchgepatcht sind, gibt es hier aktuell nichts zu sehen.
Bild 1: Übersicht verfügbarer Advisories
Bild 2: Anzahl verfügbarer Advisories pro System
Bild 2 zeigt die verfügbaren Advisories pro Host. Auch hier gibt es aktuell nichts zu sehen, da die Systeme gerade aktualisiert wurden.
Ich habe vorstehend zwei Sätze gestrichen. Zwar waren meine Systeme durchgepatcht. Dass Patch keine Advisories anzeigt hat jedoch einen anderen Grund. Patch funktioniert nur dann korrekt, wenn die angebundenen Systeme die original RHEL-Upstream-Repos verwenden. In meinem Fall werden diese jedoch über einen lokalen Spiegelserver bereitgestellt. Obwohl dieser ebenfalls über sämtliche Erratas verfügt, werden diese von Patch nicht berücksichtigt. Siehe hierzu auch Bugzilla 1843860.
Diese Anwendung ist ganz nett, stellt allein aber keinen Grund für eine Nutzung von Insights dar. Zum einen können Errata-Informationen im Customer Portal per E-Mail abonniert werden und zum anderen kann auf jedem System mittels sudo yum updateinfo list geprüft werden, ob Advisories verfügbar sind. Und darüber hinaus funktioniert die Anwendung wie oben erwähnt in meiner Umgebung auch gar nicht.
In unserer Umgebung stellen wir mittels unseres Patch-Managements sicher, dass mindestens einmal im Monat alle verfügbaren Red Hat Security Advisories auf unseren Systemen installiert werden. Es schmerzt mich daher nicht, Patch nicht nutzen zu können.
Drift
Wer die Hostprofile von VMware kennt und schätzt, wird sich hier schnell wiederfinden. Unter diesem Punkt können Systeme miteinander verglichen und auf Unterschiede hin untersucht werden. Darüber hinaus ist die Erstellung von Baselines möglich, gegen die weitere Systeme geprüft und abgeglichen werden können.
Bild 3 zeigt den Vergleich zweier Systeme. Dabei wurde die Anzeige auf Unterschiede und unvollständige Datensätze gefiltert. So sieht man zum Beispiel, dass unzip nur auf einem der beiden Hosts installiert ist.
Bild 3: Gefilterte Ansicht von zwei Systemen in Drift Comparison
Darüber hinaus zeigt Bild 3, dass auf den beiden Systemen Pakete gleichen Namens jedoch für verschiedene Architekturen installiert sind. In diesem Fall trügt die Anzeige jedoch. Denn die drei genannten Pakete sind jeweils für i686 als auch für x86_64 auf beiden Systemen installiert.
In der getesteten Version bietet Drift noch keine Unterstützung multipler Werte für einen sogenannten fact. Es ist geplant diese Funktionalität in einem kommenden Release hinzuzufügen. Siehe dazu auch Bugzilla 1841561.
Ich tue mich ein wenig schwer damit, diese Anwendung zu bewerten. Auf der einen Seite bietet sie eine nette Möglichkeit Systeme miteinander zu vergleichen, auf der anderen Seite habe ich sie bis heute nicht vermisst. Für Vergleiche von Paketlisten und Konfigurationsdateien bevorzuge ich doch immer noch althergebrachte Kommandozeilen-Werkzeuge. Ich tendiere daher dazu — wie zuvor schon bei Patch — zu sagen: „Nette Zusatz-Funktion. Jedoch allein kein Grund Insights zu nutzen.“
Mit diesem Blick auf Patch und Drift endet meine Erkundung von Red Hat Insights. In einem folgenden Artikel werde ich schildern, wie die Systeme wieder aus Insights entfernt werden können und eine persönliche Bewertung vornehmen.
Dies ist der vierte Artikel in meiner Serie über Red Hat Insights. In diesem beschäftige ich mich mit der Möglichkeit meine Systeme auf Compliance prüfen zu können.
Hinweis: Um Systeme auf Compliance prüfen zu können, müssen neben dem insights-client auch die Pakete openscap-scanner und scap-security-guide auf den jeweiligen Systemen installiert sein.
Compliance bedeutet vereinfacht ausgedrückt, Regeln einzuhalten bzw. Vorgaben zu erfüllen. Demnach benötigt man eine Richtlinie mit einem Regelwerk gegen welches man seine Systeme abgleichen kann. Diese Regelwerke findet man häufig in Form von Standards wie z.B. PCI-DSS, HIPAA (en) oder SOX. Bevor man eine entsprechende Richtlinie (Policy) erstellt bzw. ausgewählt hat, gibt es daher im Insights-Dashboard auch noch nichts zu sehen (siehe Bild 1).
Bild 1: Einstieg in die Compliance-Funktion innerhalb von Red Hat Insights.
Als erstes ist daher eine Policy zu erstellen. Hierbei wird man von einem Assistenten durch die verschiedenen Dialoge geführt (siehe Bild 2-7). Für meinen Test habe ich eine SCAP-Policy für RHEL 7 Systeme mit dem „Standard System Security Profile for Red Hat Enterprise Linux 7“ erstellt (vgl. Bild 2 und 3). Selbstbewusst und ohne zu wissen, was mich erwartet, habe ich den Compliance Threshold auf 96 Prozent festgelegt (vgl. Bild 4). Im nächsten Schritt (Bild 5) werden die im Profil enthaltenen Regeln aufgelistet, mit der Möglichkeit sich zu jeder Regel eine detaillierte Beschreibung anzeigen lassen zu können. An dieser Stelle können einzelne Regeln deaktiviert werden, sofern man diese für unwichtig erachtet. Für diesen Test lasse ich alle Regeln aktiviert und bin auf das Ergebnis gespannt.
Bild 6 zeigt den Auswahldialog, in dem Systeme der zu erstellenden Policy zugewiesen werden. Grundsätzlich kann man verschiedene Policies für unterschiedliche Systeme verwenden oder einzelne Systeme nach mehren Policies auditieren lassen. Für diesen Test wurden alle 13 Systeme der aktuellen Policy zugewiesen.
Bild 2: Erstellen einer SCAP-Policy für RHEL 7
Bild 3: Auswahl eines SCAP-Profils
Bild 4: Details des ausgewählten SCAP-Profils und Einstellung des Compliance-Thresholds
Bild 5: Übersicht über die im ausgewählten Profil enthaltenen Regeln, mit der Möglichkeit einzelne Regeln zu deaktivieren
Bild 6: Auswahl von Systemen, welche der neuen Policy hinzugefügt werden sollen
Bild 7: Zusammenfassung der Einstellungen
Bild 8: Übersicht der vorhandenen SCAP-Policies mit Anzahl zugewiesener Systeme und Compliance-Threshold
Zum Abschluss des Assistenten wird noch einmal eine Zusammenfassung angezeigt (Bild 7), bevor die Policy erstellt wird. Anschließend kann man die soeben erstellte Policy in der Übersicht wiederfinden (vgl. Bild 8).
Compliance-Scan ausführen
In vorstehendem Abschnitt wurde eine SCAP-Policy erstellt und mit den vorhandenen Systemen verknüpft. Um die Systeme nun auf Compliance zu prüfen, ist der insights-client auf jedem System mit der Option --compliance zu starten. Der folgende Code-Block zeigt beispielhaft einen interaktiven Aufruf.
# insights-client --compliance
Running scan for xccdf_org.ssgproject.content_profile_standard... this may take a while
Uploading Insights data.
Successfully uploaded report for foo.example.com.
#
Möchte man seine Systeme regelmäßig mit dem Compliance-Scan prüfen, kann dies über einen Cronjob oder durch ein regelmäßig auszuführendes Ansible-Playbook gelöst werden.
Hinweis: Es handelt sich dabei nicht um den normalen Scan des insights-client, welcher täglich ausgeführt wird und Informationen an den SaaS-Dienst übermittelt.
Der hochgeladene Report ist wenige Minuten später im Compliance-Menü des Insights-Dashboards sichtbar.
Compliance-Reports im Insights-Dashboard
Das Insights-Dashboard bietet die aus den vorhergehenden Artikeln bekannte tabellarische Übersicht auch im Compliance-Menü. Hierüber gelangt man zu einer Ansicht, welche die Systeme mit ihrem jeweiligen Compliance-Score und der Anzahl nicht eingehaltener Regeln auflistet (siehe Bild 9).
Bild 10 zeigt einen Ausschnitt eines Reports für ein ausgewähltes System. Hier werden die Compliance-Regeln mit Name und ID aufgeführt. Darüber hinaus erkennt man auf einen Blick die Severity, ob der Test bestanden wurde und ob ein Ansible-Remediation-Playbook existiert.
Bild 9: Übersicht der zur SCAP-Policy vorliegenden Reports aller Systeme
Bild 10: Compliance-Report für ein ausgewähltes System
In Bild 10 wurde eine Regel exemplarisch aufgeklappt, um die dahinter liegenden Informationen anzuzeigen. Diesen kann man entnehmen, welche Einstellungen vorhanden sein müssen, um diese konkrete Regel zu erfüllen. Man erhält an dieser Stelle daher nicht nur allgemeine Hinweise, sondern zudem explizite Handlungsempfehlungen. Darüber hinaus gibt es zu jeder Regel einen Hinweis, warum es sinnvoll erscheint, die empfohlenen Maßnahmen umzusetzen.
In diesem Test hat übrigens keines der 13 Systeme den vorgegebenen Compliance-Score erreicht. Dabei erreichten acht Systeme einen Score zwischen 80-85%, drei lagen bei 70-75% und zwei Systeme erreichten lediglich einen Score von 43-48%.
Das Ergebnis ist nun aber nicht so schlimm, wie es auf den ersten Blick aussieht. Denn einige der im verwendeten Profil geforderten Einstellungen sind in unserem Fall mitbestimmungspflichtig und müssen im Vorfeld einer möglichen Umsetzung mit dem Personalrat abgestimmt werden.
Fazit
Zwar sind unsere Systeme Stand heute an keine konkrete Policy gebunden, doch macht es in meinen Augen durchaus Sinn sich an einigen dieser Policies zu orientieren und deren sinnvoll erscheinenden Regeln einzuhalten. Ihnen blind zu folgen ist hingegen nicht sinnvoll. Oder wie mein Kollege sagte: „Man muss sich vielleicht nicht unbedingt wie eine Bank verhalten, wenn man keine Bank ist. :) „
Zur Erstellung von Compliance-Reports und der Ableitung einer Konfigurations-Baseline aus diesen hätte es des Insights-Dashboards nicht bedurft. Mit dem openscap-scanner und dem scap-security-guide können Reports für ausgewählte SCAP-Profile auch lokal auf jedem System erstellt und analysiert werden. Gerade bei der Erstellung einer Baseline lassen sich dabei Erkenntnisse von wenigen ausgewählten Systemen auf eine größere Gruppe von Hosts in der eigenen Infrastruktur übertragen.
Das Insights-Dashboard bietet an dieser Stelle den Mehrwert, alle relevanten Informationen an einer Stelle vorliegen bzw. verlinkt zu haben. Der Wechsel zwischen verschiedenen Anwendungen entfällt und Ergebnisse lassen sich leichter miteinander vergleichen.
Die verfügbaren Ansible-Remediation-Playbooks machen einen soliden Eindruck und sind geeignet, notwendige Einstellungen zu setzen, um eine konkrete Regel einzuhalten. Ich selbst führe diese jedoch nicht direkt in meiner Infrastruktur aus, sondern nutze sie lediglich als Ausgangspunkt für eigene Playbooks und Vorlagen. So fällt der Lerneffekt für mich persönlich größer aus.
Nach der Einführung in Red Hat Insights und dem Blick auf den Advisor nehme ich in diesem Artikel das Schwachstellen-Management von Insights unter die Lupe.
Bild 1: Übersicht im Insights Dashboard
Bereits das Dasboard zeigt eine Box namens Vulnerability. Bild 1 zeigt, dass wir offensichtlich von 13 Schwachstellen betroffen sind. Diese sehen wir uns jetzt näher an. Dies geht wie üblich über den Link in der Box oder im Menü am linken Rand.
In der Vulnerability-Ansicht erwartet uns die gewohnte tabellarische Ansicht (vgl. Bild 2). Hier werden CVEs mit ihrer ID, dem Datum der Veröffentlichung, einer Bewertung des Impacts, dem CVSS base score und der Anzahl der betroffenen Systeme aufgeführt. Darüber hinaus hat man die Möglichkeit ein Business Risk und einen Status für ausgewählte oder alle CVEs zu vergeben (siehe gelbe Markierung in Bild 2).
Bild 2: Übersicht gefundener Schwachstellen mit Angabe von Impact, CVSS score und betroffener Systeme
Während man mit dem Business Risk festlegt, wie hoch man das Risiko einschätzt (vgl. Bild 3), hinterlegt man beim Status, wie mit der Behandlung der Schwachstelle(n) verfahren wird (siehe Bild 4).
Bild 3: Bewertung des Business RiskBild 4: Mit Hilfe des Status kann der Bearbeitungsstand dokumentiert werden.
Wie im Advisor erhält man auch hier zu jeder CVE-ID eine Detailansicht mit Beschreibung des CVE, Bewertung und Übersicht der Angriffsvektoren (siehe Bild 5), sowie Verweisen zur Wissensdatenbank von Red Hat, wo ausführliche Informationen rund um den CVE und existierende Erratas zu finden sind.
Bild 5: Detailansicht eines ausgewählten CVE
Bewertung des Schwachstellen-Managements
Stand heute betreiben wir kein aktives Schwachstellen-Management. Um ein gewisses Niveau an Sicherheit zu gewährleisten, nutzen wir ein Patchmanagement für RHEL, welches ich aus Bordmitteln unter Nutzung der Ansible Engine entwickelt habe. Dieses sorgt dafür, dass verfügbare Red Hat Security Advisories einmal im Monat auf allen RHEL-Systemen zwangsinstalliert werden, sofern diese noch fehlen.
Diesem Patch-Management ist es zu verdanken, dass auf den 13 angebundenen Testsystemen auch insgesamt nur 13 Schwachstellen gefunden wurden und darunter keine mit einem Score >= 8 gewesen ist.
Unter den im Dashboard aufgeführten Systemen waren Systeme einer Testinfrastruktur, die nicht an das zentrale Patchmanagement angebunden sind und nur unregelmäßig gepatcht werden. Insights hat mir hier vor Augen geführt, dass das Risiko viel zu groß ist, dass diese Systeme einfach vergessen werden. Deshalb wurden diese Hosts nun auch umgehend mit ins Patchmanagement aufgenommen.
Diese Schwachstellen haben gemeinsam, dass sie sich nicht einfach durch die Installation eines Updates schließen lassen. Da es sich um virtuelle Maschinen (VM) auf einem vSphere-Cluster handelt ist eine Kombination von Maßnahmen erforderlich, um die Schwachstellen zu mitigieren.
In diesem konkreten Fall müssen die betroffenen VMs lediglich einmal Aus- und wieder Eingeschaltet werden, da ein Teil der Mitigation in vSphere bereits vorhanden war. Dadurch werden neue CPU-Funktionen an das Gast-Betriebssystem propagiert und die Mitigation ist abgeschlossen.
Leider muss ich eingestehen, dass diese Schwachstellen ohne Insights noch lange Zeit unentdeckt geblieben wären.
Nun muss ich davon ausgehen, dass in unserer Umgebung noch weitere verwundbare Systeme existieren. Da ich diese nicht an Insights anbinden darf, werde ich diese mit einem von Red Hat bereitgestellten Skript ausfindig machen. Das Red Hat eben solche Skripte zur Verfügung stellt, um sich auch ohne Insights wirksam selbst helfen zu können, schätze ich an Red Hat sehr. Es gibt da draußen noch einige Unternehmen, die diesem Beispiel ruhig folgen dürfen.
Persönlich halte ich aktives Schwachstellen-Management für sinnvoll. Nur durch kontinuierliche Kontrolle können Schwachstellen gefunden, bewertet und entsprechend behandelt werden. Gleichzeitig dient es der Überprüfung, ob bzw. wie bereits getroffene Maßnahmen zur strukturellen Verbesserung des Sicherheits-Niveaus (z.B. ein Patchmanagement) wirken.
Bild 6: Alle erkannten Schwachstellen wurden geschlossen
Bild 6 zeigt, dass gegenwärtig keine offenen Schwachstellen mehr existieren. Dies sollte stets das Ziel sein.
Mir selbst hat der Test des Schwachstellen-Managements Freude bereitet und die gefundenen Schwachstellen konnten innerhalb kurzer Zeit geschlossen werden.
Der nächste Artikel dieser Reihe wird sich dem Compliance-Service widmen.
In der Einführung in Red Hat Insights habe ich kurz umrissen, worum es sich bei dieser SaaS-Anwendung handelt und wie man RHEL-Systeme einrichtet, um den Dienst nutzen zu können. Dieser Artikel widmet sich dem Menüpunkt „Advisor“ im Insights-Dashboard.
Das Dashboard gibt einen Überblick darüber, wie viele Systeme aktuell in Insights eingebunden sind, ob es Probleme mit bekannten Systemen gibt, den Patch-Status, Schwachstellen, Compliance-Status, durchgeführte Remediations und Advisor recommendations. Letztere sind Gegenstand dieses Artikels und werden im Folgenden einer genauen Betrachtung unterzogen.
Advisor recommendations bedeutet auf Deutsch soviel wie „Empfehlungen eines Ratgebers“. Der Ratgeber (Advisor) ist in diesem Fall die Firma Red Hat, welche mit Machine Learning Algorithmen, ihrer Erfahrung und dem aus Kunden-Support-Fällen gesammelten Wissen, Ratschläge zur Systemkonfiguration und Hinweise auf Konfigurationsfehler unterbreitet.
Das Dashboard in Bild 1 zeigt, dass Insights für die 13 verbundenen Systeme insgesamt 5 Empfehlungen bereithält, mit denen die Systemkonfiguration verbessert werden kann.
Über das Menü am linken Rand oder den Link im Feld der Advisor recommendations gelangt man auf die Unterseite des Ratgebers, welcher die Empfehlungen in einer Übersicht mit Bewertung darstellt (siehe Bild 2).
Bild 2: Übersicht der Advisor Recommendations
Die tabellarische Übersicht in Bild 2 zeigt die Empfehlungen mit einer kurzen Beschreibung, seit wann diese Empfehlung im Insights existiert, eine Risikobewertung, wie viele Systeme davon betroffen sind und ob ein Ansible-Playbook existiert, mit dem das beschriebene Problem in der eigenen Infrastruktur behoben werden kann.
Auf die einzelnen Funktionen der Seite aus Bild 2 werde ich im Folgenden näher eingehen, während ich eine Bewertung der angezeigten Empfehlungen vornehme.
Als erstes sticht mir der zweite Punkt ins Auge. Mit einem Klick auf den Pfeil vor der Beschreibung werden weitere Details eingeblendet (siehe Bild 3). Hier erfährt man, dass es vermutlich kein Problem darstellt, wenn man zum jetzigen Zeitpunkt kein In-Place-Upgrade auf RHEL 8 durchführt und dass ein Upgrade vermutlich ein Wartungsfenster mit Downtime benötigt. Weitere Informationen bietet der verlinkte Knowledge-Base-Artikel.
Bild 3: Detailansicht eines Eintrags und Funktion zum Deaktivieren dieser Empfehlung
Ich persönlich bewerte die in Bild 3 ausgewählte Empfehlung als unnütz. RHEL 7 ist immer noch ein Release unter Wartung, welches Sicherheits-Aktualisierungen erhält. Dass RHEL 8 inzwischen in Version 8.2 erschienen ist und mit neuen Funktionen und Verbesserungen aufwartet, ist bekannt, aber kein Grund für übereilte Upgrades. Darüber hinaus führen wir im BITS in der Regel keine In-Place-Upgrades durch. Stattdessen installieren wir eine neue virtuelle Maschine (VM), migrieren Daten und Dienste und schalten anschließend den alten Host ab.
Zum Glück muss man sich von unbedeutenden Meldungen nicht ewig nerven lassen. Wie in Bild 3 zu sehen, bietet Insights die Möglichkeit, Meldungen einfach zu deaktivieren. Sehr schön empfinde ich dabei, dass man einen Grund angeben kann (siehe Bild 4). So wird man auch nach Wochen oder gar Monaten daran erinnert, warum man einen Eintrag deaktiviert hat.
Bild 4: Insights bietet die Möglichkeit einen Grund für die Deaktivierung einer Empfehlung anzugeben
Anschließend wird der Eintrag in der Übersicht nicht mehr angezeigt (vgl. Bild 5).
Bild 5: Mit dem automatisch aktivierten Filter werden nur noch aktive Einträge angezeigt. Deaktivierte Elemente werden ausgeblendet.
Nach dem Deaktivieren eines Eintrags kam mir sofort die Frage in den Sinn, wo ich diese denn wohl wiederfinden kann. Dies ist über die Filtereinstellungen im oberen Bereich der Seite möglich (siehe Bild 6).
Bild 6: Anzeige der deaktivierten Elemente
An dieser Stelle möchte ich erwähnen, dass das Insights-Team die entsprechende Empfehlung nach meiner Rückmeldung komplett aus Insights entfernt hat. Schön, dass man als Kunde hier Gehör findet.
Bewertung der weiteren Empfehlungen
Es bleiben noch vier weitere Empfehlungen, die ich im Folgenden für meine konkrete Umgebung bewerten will. Alle vier haben gemein, dass ich vermutlich nie bewusst nach diesen Konfigurationseinstellungen gesucht hätte. Und zumindest zwei sind dabei, bei denen ein genauerer Blick lohnt. Und mit diesen fange ich an.
OS boot failure occurs due to uncertain disk discovery order when /dev/sdN format device names are used in /etc/fstab
Hier wird auf eine Konfiguration hingewiesen, die im ungünstigsten Fall den Bootvorgang eines Hosts verhindert. Eine Einstufung als „Important“ ist daher nachvollziehbar. Lässt ein System, das nicht startet, doch regelmäßig den Puls und Adrenalinspiegel eines Sysadmin steigen.
Um mir das (mögliche) Problem näher erläutern zu lassen, rufe ich aus der Detailansicht den dort verlinkten Knowledge-Base-Artikel auf. Dabei fällt mir auf, dass, obwohl ich ausschließlich RHEL 7 Systeme verwende, auf einen Artikel verlinkt wird, der nur für RHEL 6 gilt. Immerhin findet sich in diesem eine Referenz zum entsprechenden Artikel für RHEL 7. Hier hätte man gleich passend verlinken können.
Die beiden betroffenen Systeme sind schon einige Zeit in Betrieb und haben bereits mehrere Neustarts ohne Probleme überstanden. Das potenzielle Problem scheint sich zumindest in unserer Umgebung nicht negativ auszuwirken.
Insights bietet für diesen Fall die Erstellung eines Ansible-Remediation-Playbooks an, mit welchem das Konfigurationsproblem behoben werden kann. Da ich in diesem Fall nicht der System-Betreiber für die beiden aufgeführten Systeme bin, kann ich dies jedoch nicht ohne Rücksprache mit dem entsprechenden Kollegen zur Ausführung bringen.
Ich habe den entsprechenden System-Betreiber über dieses Ereignis benachrichtigt, ihm die mögliche Lösung weitergeleitet und ihm die Entscheidung überlassen, wie er weiter damit verfahren möchte. Dieser hat sich für den Hinweis bedankt und das Problem sofort behoben.
In einem späteren Artikel werde ich mich noch damit beschäftigen, wie ich Kollegen Zugriff auf das Insights-Dashboard gewähren kann, so dass diese ihre Systeme darin selbst verwalten und untersuchen können.
Traffic occurs or services are allowed unexpectedly when firewall zone drifting is enabled
Dies ist aus meiner Sicht wirklich ein interessanter Fund. Denn er weist darauf hin, dass womöglich Kommunikation durch die lokale Host-Firewall erlaubt wird, obwohl dies nicht beabsichtigt ist (vgl. Bild 7).
Bild 7: Recommendations lassen sich über den Pfeil am Anfang einer Zeile aufklappen, um weitere Informationen zu sehen.
Auch hier liefert der verlinkte Knowledge-Base-Artikel ausführliche Informationen.
Ich werde diesen Punkt auf jeden Fall mit dem betroffenen Kollegen thematisieren. Ich denke, dass hier ein kleiner Wissenstransfer angebracht ist, da nach meiner Einschätzung auch weitere Kollegen sich des konkreten Verhaltens nicht bewusst sind. Von daher bewerte ich diesen Ratschlag als gut und sinnvoll.
Ein Punkt übrigens, der mir am Insights-Dashboard allgemein gut gefällt, ist, dass ich jederzeit anzeigen lassen kann, wie viele Systeme betroffen sind und noch wichtiger, welche dies sind (siehe Bild 8).
Dies ist eine Meldung mit niedriger Risiko-Einstufung und so werden wir sie auch behandeln. Bei den betroffenen Systemen handelt es sich um Test-Systeme. Der System-Betreiber hat hier bewusst auf die Implementierung von TLS/SSL verzichtet.
Dieser Punkt stellt sich wider Erwarten als interessant heraus. Wir betreiben eigene Repositories, welche nur innerhalb unserer Einrichtung verwendet werden. Um den Aufwand zu minimieren, verzichten wir bei diesen auf die Signierung der Pakete.
Überraschend ist jedoch der Umstand, dass bei einigen Hosts auch die GPG-Signatur-Überprüfung für ein gespiegeltes RHEL-Repo deaktiviert ist. Um dies herauszufinden, muss man sich nicht erst zu einem betroffenen System verbinden und dies untersuchen. Es genügt ein Klick auf den Hostnamen in der Liste der betroffenen Systeme (vgl. Bild 8), um zu einer Ansicht zu gelangen, die neben einer ausführlichen Beschreibung auch einen Lösungsweg anbietet.
Insights bietet nicht nur Unterstützung dabei herauszufinden, was falsch ist, sondern auch wie man das Problem abstellt. Ich werde im Laufe des Tests fortlaufend überprüfen, wie häufig Insights hier mit sinnvollen Lösungen aufwarten kann.
Neu hinzugekommen und daher in obigen Bildern noch nicht enthalten ist dieser Hinweis auf ein Problem, welches die Leistung des Systems beim Bootvorgang reduzieren kann.
Insights hat diesen Incident erkannt, nachdem das betroffene System neugestartet wurde, der insights-client erneut gelaufen ist und Insights eine entsprechende Meldung in /var/log/messages gefunden hat.
Das Problem selbst ist uns seit langem bekannt. Es fällt allerdings in die Kategorie: „Gucken wir uns an, wenn wir mal Zeit haben.“ Also vermutlich nie. Zum Glück booten unsere VMs innerhalb weniger Sekunden und es wird hier kein Problem wahrgenommen.
Zwischenfazit
Ich stehe noch am Anfang unseres Tests. Die bisherigen Erkenntnisse lassen daher noch keine abschließende Bewertung zu, ob ein dauerhafter und ausgedehnter Einsatz von Insights gerechtfertigt ist.
Als erster Eindruck bleibt eine benutzerfreundliche Oberfläche, welche eine intuitive Bedienung gestattet. Der Advisor enthält bis jetzt neben einigen belanglosen Empfehlungen auch interessante Hinweise.
Bei Red Hat Insights handelt es sich um eine SaaS-Anwendung, welche Nutzern von RHEL-Subskriptionen kostenlos zur Verfügung steht.
Dieser Artikel bietet eine kurze Einführung in Red Hat Insights, zeigt, wie RHEL-Systeme in den Cloud-Dienst eingebunden werden und führt wichtige Dokumente und Quellen zum Dienst auf.
Hinweis: Ich teste den Dienst im Rahmen meiner beruflichen Tätigkeit im Bielefelder IT-Service Zentrum (BITS) der Universität Bielefeld.Dieser Artikel spiegelt meine persönliche Ansicht zu Red Hat Insights wider. Des Weiteren weise ich darauf hin, dass ich Mitglied der Red Hat Accelerators Community bin (siehe „Zu meiner Person“).
Was ist Red Hat Insights?
Red Hat Insights, im folgenden Text auch kurz Insights genannt, ist ein von der Firma Red Hat angebotener Cloud-Service, welcher der proaktiven Analyse von Umgebungen mit Red Hat Enterprise Linux (RHEL) dient. Als Ergebnis dieser proaktiven Analyse erhält der Systemadministrator Hinweise auf vorhandene Konfigurationsprobleme, Sicherheitslücken und Schwachstellen sowie Handlungsempfehlungen, wie diese behoben werden können.
An Insights angebundene Systeme werden vom lokal installierten Insights-Client gescannt und gegen ein Regelwerk abgeglichen, um potenzielle Risiken in Bezug auf die System-Leistung, Skalierbarkeit, Verfügbarkeit und Sicherheit zu identifizieren und zu melden. Red Hat ist dabei bestrebt, die Sammlung persönlicher Daten zu vermeiden.
Neben dem Reporting können über diesen Service auch Ansible-Playbooks zur Mitigation erkannter Probleme generiert und von einer on-premise vorhandenen Ansible Engine ausgeführt werden. Das Regelwerk wird von der Firma Red Hat gepflegt und stetig erweitert.
Seit 2019 ist Insights in allen aktiven RHEL-Subskriptionen enthalten. Somit entstehen keine zusätzlichen Kosten durch die Nutzung des Dienstes. Insights kann in RHEL-Installation verwendet werden, unabhängig davon, ob diese on-premise, in privaten oder öffentlichen Clouds betrieben werden.
Die Produktdokumentation und eine FAQ-Sektion finden sich unter den folgenden URLs:
Wer noch keine Zugangsdaten für die vorstehend verlinkten Seiten besitzt, kann sich für eine kostenlose Red Hat Developer Subscription registrieren. Mit dieser erhält man auch Zugriff zur Red Hat Wissensdatenbank.
Ob Red Hat Insights den Mehrwert bietet, den es verspricht, versuche ich gerade in einem zeitlich und vom Umfang her begrenzten Test herauszufinden. Mit den folgenden Schritten könnt ihr euch auch selbst ein Bild davon machen.
Datenschutz und Datensicherheit
Für uns ist die Nutzung eines SaaS-Dienstes wie Insights nicht ganz unproblematisch. Wer die vorstehend verlinkte Dokumentation liest, wird schnell feststellen, dass zur Erbringung des Dienstes jeder angebundene Host eine Menge Daten sammelt und an den Cloud-Dienst überträgt. Dies ist einerseits erforderlich, damit der Service funktioniert. Denn ohne zu analysierende Daten kann es keine Hinweise und Empfehlungen geben. Anderseits kann man anhand der übertragenen Daten eine ziemlich genaue Karte der Netzwerkinfrastruktur zeichnen.
Insights selbst wird auf OpenShift Dedicated in AWS (US East) gehostet. Aktuell gibt es keinerlei Pläne, den Dienst in weiteren Regionen zu hosten.
Der insights-client bietet mit den Optionen --no-upload bzw. --offline die Möglichkeit, Daten lokal zu sammeln, ohne diese an den Cloud-Dienst zu übertragen. Als Sysadmin hat man so die Möglichkeit, im Vorfeld zu inspizieren, welche Daten gesammelt wurden. Dazu gibt es die Möglichkeit, eine Blacklist zu pflegen und zu spezifizieren, welche Daten von der Sammlung und Übertragung auszuschließen sind.
Die folgende Datei beinhaltet eine Baumansicht der Dateien und Informationen, die ein insights-client auf einem System mit installiertem MediaWiki gesammelt hat. Darunter befinden sich z.B. diverse Konfigurationsdateien und mit Hilfe verschiedener Kommandos gesammelte Informationen.
Stellt man sich den Betrieb von 100 RHEL-Servern vor, welche verschiedenste Dienste erbringen, wird jedoch deutlich, dass eine manuelle Kontrolle und Pflege individueller Blacklists für alle Systeme nicht leistbar ist. Zumal sich das Regelwerk, welches die zu sammelnden Daten bestimmt, dynamisch ändert und eine Prüfung vor jedem Upload erfolgen müsste.
Leider existiert Stand heute keine on-premise Appliance, welche die Nutzung des Dienstes innerhalb des eigenen Perimeters ermöglichen würde. Auch eine Whitelist für den insights-client existiert (noch) nicht. Letzteres würde dem Nutzer noch mehr Kontrolle über die Daten-Sammlung/-Übertragung geben. So könnte er einmal definieren, was übertragen werden darf und müsste nicht fürchten, dass bereits einige Tage später weitere Daten ohne sein Wissen gesammelt und übertragen werden.
Sowohl den Wunsch nach einer on-premise Appliance, als auch den Vorschlag zur Einführung einer Whitelist, habe ich dem Insights-Team gemeldet. Die Meldung wurde nach meinem Empfinden konstruktiv aufgenommen. Und auch wenn mein größter Wunsch nach der Appliance kurz- und mittelfristig nicht realisiert werden wird, fühle ich mich als Nutzer ernst genommen und habe das Gefühl, dass mein Feedback willkommen ist.
Red Hat beschreibt in oben verlinkter Dokumentation, dass der Dienst keine persönlichen Daten sammelt. So sind /etc/{passwd,group,shadow} sowie /home nicht in den gesammelten Daten enthalten. Auch werden keine vollständigen Logdateien an den Dienst übertragen. Generell legt Red Hat sehr viele Informationen über den Dienst offen und handelt hier sehr transparent. Das Unternehmen verhält sich in dieser Hinsicht vorbildlich.
Wenn ein Client keine Daten mehr übermittelt, werden die zuletzt von ihm empfangenen Daten nach 14 Tagen automatisch gelöscht. Wird ein Client aus Insights entfernt, werden die für diesen Client gespeicherten Daten ebenfalls gelöscht.
Nichtsdestotrotz verliert man die Gewalt über einmal übertragene Daten. Man muss dem Anbieter wie bei jedem SaaS-Dienst vertrauen, dass er sich an die eigenen Zusicherungen und Versprechen hält.
Möchtet ihr Insights in eurer Dienststelle oder eurem Betrieb testen, rate ich euch deshalb, sprecht zuerst mit der/dem Informationssicherheitsbeauftragten und Datenschutzbeauftragten und eurer/eurem Vorgesetzten über das Thema.
Trotz aller Bedenken bietet Insights die Chance, Kenntnis über Probleme und Schwachstellen zu erlangen, die bisher unbekannt sind und ein größeres Sicherheitsrisiko darstellen als die regelmäßige Datenübertragung an Insights. Ob der Nutzen überwiegt, muss allerdings jede Organisation für sich selbst beurteilen.
Einrichtung von Red Hat Insights auf Red Hat Enterprise Linux
Die folgenden Schritte setzen voraus, dass die verwendeten RHEL-Systeme registriert sind und über eine gültige Subskription verfügen.
Manuelle Einrichtung
Um den vollen Funktionsumfang von Insights nutzen zu können, werden die folgenden Pakete installiert:
Die Installation des OpenSCAP-Scanners und des SCAP-Security-Guides sind optional. Diese Pakete sind erforderlich, um den Compliance Service nutzen zu können. Da der insights-client in RHEL 8 bereits integriert ist, muss dieser hier nicht gesondert installiert werden.
Um die Einrichtung des insights-client abzuschließen und gesammelte Daten an den SaaS-Dienst zu übertragen, genügt es, das folgende Kommando auszuführen:
$ sudo insights-client --register
Automatisierte Einrichtung mit Ansible
Um die notwendigen Schritte zur Einrichtung nicht auf jedem Host manuell ausführen zu müssen, kann folgendes Ansible-Playbook verwendet werden.
---
- hosts: rh-insights-poc # Gruppe aus dem Ansible-Inventory
tasks:
- name: Make sure required packages are present
yum:
name:
- openscap-scanner
- scap-security-guide
- insights-client
state: latest
- name: Register insights-client
command: insights-client --register
Für meine Zwecke reicht obiges Playbook. Alternativ gibt es auf Ansible Galaxy eine Rolle mit deutlich größerem Funktionsumfang: redhatinsights.insights-client
Sind die Systeme eingerichtet und registriert, ist es an der Zeit, sich unter der URL https://cloud.redhat.com einzuloggen und das Insights Dashboard zu erkunden.
Startseite unter https://cloud.redhat.com
An dieser Stelle lasse ich euch vorerst mit dem Dashboard allein. Im nächsten Artikel dieser kleinen Reihe werde ich mich mit dem Inisghts Advisor befassen.
Es muss nicht immer gleich der Red Hat Sattelite Server sein, um einen lokalen Spiegelserver für die Installation von RPM-Paketen bereitzustellen.
Auf GitHub habe ich im Repository „Poor man’s RHEL mirror“ eine kleine Sammlung von Bash-Skripten zusammengestellt, mit denen sich ein Spiegelserver für RHEL-Repositories aufbauen lässt. Mit diesem können RHEL-Repositories, für welche man eine gültige Subskription besitzt, auf einen Host im lokalen Netzwerk synchronisiert und deren Pakete anderen RHEL-Servern im LAN zur Verfügung gestellt werden.
Neben der reinen Spiegelung können mit den auf GitHub bereitgestellten Skripten weitere lokale Stage-Repositories eingerichtet werden, mit denen sich die Verfügbarkeit von Paketen für einzelne Stages steuern lässt. Zusätzlich bietet das Projekt Skripte, um eigene YUM-Repositories zu erstellen, um zum Beispiel eigene Pakete darüber bereitstellen zu können. Des Weiteren wurde die Möglichkeit berücksichtigt, die Red Hat Errata Informationen in die lokalen RHEL-Repositories zu integrieren, um die --advisory Option für YUM auch auf Systemen nutzen zu können, die über keine eigene Verbindung zum Internet verfügen.
Warum ist dieses Projekt nützlich?
Es schont die eigene Internetverbindung, da Pakete nur einmal aus dem Internet heruntergeladen und anschließend im LAN zur Verfügung gestellt werden.
Es unterstützt bei der Erstellung eines YUM-Repositories zur Bereitstellung von RPM-Paketen.
Es unterstützt das Staging-Konzept, in dem es die Möglichkeit bietet, stage-spezifische Repositories bereitzustellen.
Es implementiert die Red Hat Errata Informationen in die gespiegelten RHEL-Repos, so dass diese von angebundenen Servern genutzt werden können, die über keine eigene Internetverbindung verfügen.
Es entstehen keine Zusatzkosten, da alle notwendigen Werkzeuge in den Repos einer RHEL-Standard-Subskription enthalten sind.
Wer kann dieses Projekt nutzen?
Das Projekt selbst steht unter der MIT-Lizenz und kann unter deren Bedingungen frei genutzt, modifiziert und weiter verteilt werden.
Für den Betrieb des Spiegelservers ist der Besitz einer gültigen RHEL-Subskription Voraussetzung. Denn es können nur jene Repos gespiegelt werden, für die eine gültige Subskription vorhanden ist. Auch alle an den Spiegelserver angeschlossenen Systeme müssen über eine entsprechende und gültige Subskription verfügen.
Bei Fragen zu Subskriptionen helfen die folgenden Seiten weiter:
Um mit diesem Projekt einen Spiegelserver aufsetzen und betreiben zu können, sind gewisse Kenntnisse erforderlich. Zu diesen zählen die Installation eine RHEL-Systems inkl. Registrierung, das Hinzufügen von Subskriptionen und die Installation von Paketen. Informationen hierzu bietet die Product Documentation for Red Hat Enterprise Linux 7.
Wie ist das GitHub-Repository zu diesem Projekt aufgebaut?
Das GitHub-Repository beinhaltet ein README, welches einen Überblick über das Projekt und eine Kurzbeschreibung der einzelnen Skripte in englischer Sprache beinhaltet. Im Master-Branch befindet sich die letzte stabile Version des Projekts. Weiterentwicklungen und Fehlerkorrekturen werden im Dev-Branch gepflegt und nach einer Testphase in den Master-Branch übernommen.
Sorgen, Nöte und Anträge sowie gefundene Fehler dürfen gern über die Issue-Funktion oder in den Kommentaren zu diesem Beitrag gemeldet werden.
An dieser Stelle folgt eine Beschreibung in deutscher Sprache, wie ein Spiegelserver mit diesem Projekt aufgebaut werden kann. Dabei handelt es sich um keine Schritt-für-Schritt-Anleitung und es werden grundlegende Kenntnisse über den Betrieb eines RHEL-Servers und die Installation sowie Konfiguration von Paketen vorausgesetzt.
Einrichtung eines Spiegelservers für arme Sysadmins
Um das Projekt nutzen zu können, benötigt man eine RHEL-Installation mit gültiger Subskription, auf welcher mindestens die folgenden Pakete installiert sein müssen:
reposync und createrepo, um RHEL-Repos synchronisieren und eigene Repos erstellen zu können
git zum Klonen des hier beschriebenen Projekts
Die Gruppe Basic Web Server oder einen anderen Webserver eurer Wahl, um die gespiegelten Repos über HTTP im LAN bereitstellen zu können
Zu Beginn sind die Dateien aus dem oben genannten GitHub-Repository in einem Verzeichnis auf dem lokalen Host bereitzustellen. Anschließend ist das Projekt zu konfigurieren. Die dazu notwendigen Schritte werden in den folgenden Abschnitten erläutert.
CONFIG.SAMPLE
Hierbei handelt es sich um die Hauptkonfigurationsdatei. Diese ist in CONFIG umzubenennen bzw. zu kopieren und zu editieren. In dieser Datei werden die Variablen gesetzt, die von den verschiedenen Shell-Skripten verwendet werden. Darunter sind z.B. Angaben, welche Repos gespiegelt werden und wo die Dateien gespeichert werden sollen.
Die Datei ist mit Kommentaren versehen und sollte weitgehend selbsterklärend sein (was für alle weiteren Dateien gilt).
create_yum_repo.sh
Dieses Skript kann genutzt werden, um ein eigenes YUM-Repository zu erstellen, über welches RPM-Pakete bereitgestellt werden können. Der Name des zu erstellenden Repos kann dem Skript als Parameter übergeben werden.
do_reposync.sh
Dies ist das Herzstück des Projekts. Es kümmert sich um die Spiegelung der RHEL-Repos. Die notwendigen Parameter werden in der Datei CONFIG konfiguriert.
Das Skript lädt nur die aktuellen Pakete aus den Repos herunter, löscht aus den Upstream-Repos entfernte Pakete jedoch nicht automatisch auf dem lokalen Host. Dies ist meinen persönlichen Anforderungen geschuldet. Es ist nicht ausgeschlossen, dass ich diese Parameter in Zukunft ebenfalls konfigurierbar gestalte.
Um die heruntergeladenen Pakete im LAN zur Verfügung zu stellen, muss das BASEDIR (siehe CONFIG) über einen Webserver zugreifbar gemacht werden.
refresh_repo.sh
Werden einem Repo neue RPM-Dateien hinzugefügt, muss die Metadaten-Datenbank aktualisiert werden, damit Klienten die neuen Pakete auch finden können. Um diese Aktualisierung kümmert sich eben dieses Skript.
rsync_repo.sh
Mit diesem Skript lassen sich Repos auf dem lokalen System synchronisieren. Dabei werden die Dateien jedoch nicht 1:1 kopiert, sondern Hardlinks erstellt. Dies spart bei der Verwendung mehrerer Repos für unterschiedliche Stages Speicherplatz.
Neben dem kompletten Sync eines Repos ist es auch möglich, dem Skript eine Datei zu übergeben, welche die Namen der Pakete enthält, welche in ein weiteres Repo „transportiert“ werden sollen.
Wrapper-Scripts
In meiner Umgebung arbeiten wir mit bis zu vier verschiedenen Stages (E, I, Q und P). Für jede dieser Stages wird ein eigenes Stage-Repo des Upstream rhel-7-server-rpms erzeugt. Um diese Stage-Repos zu aktualisieren, werden die folgenden Skripte verwendet:
update_rhel-e-stage.sh
update_rhel-i-stage.sh
update_rhel-q-stage.sh
update_rhel-p-stage.sh
Jede Stage wird mit den Paketen aus der vorhergehenden aktualisiert. So ruft z.B. update_rhel-e-stage.sh das Skript rsync_repo.sh, um die Pakete aus dem lokalen Spiegel des Upstreams rhel-7-server-rpms zu importieren. update_rhel-i-stage.sh verwendet dementsprechend die rhel-e-stage als Quelle usw.
Diese Konfiguration ist für meinen Anwendungsfall optimiert. Die Verwendung der Skripte ist optional. Der Spiegelserver funktioniert auch ohne diese Wrapper-Scripts.
update_mirror_packages_and_erratas.sh
Dieses Skript aktualisiert die Pakete in den Repos des lokalen Spiegelservers inkl. der Red Hat Errata Informationen. Letztere ermöglichen es, die Erratas (RHSA, RHBA und RHEA) auch Systemen verfügbar zu machen, welche über keine Verbindung zum Internet verfügen.
Das Skript ist in der Standardeinstellung auf meinen Anwendungsfall optimiert und aktualisiert am Ende alle vorhandenen RHEL-Stage-Repos. Wer diese Funktion nicht benötigt, kann sie durch Auskommentieren der Zeilen 45 und 46 im Skript deaktivieren.
Anschließend kann ein Cronjob erstellt werden, welcher das Skript ausführt, um den Spiegelserver regelmäßig gemäß der eigenen Anforderungen zu aktualisieren.
Die gespiegelten Repos verfügbar machen
Hat man die Repos seiner Wahl gespiegelt, ergibt sich je nach Konfiguration eine Verzeichnisstruktur ähnlich der folgenden.
Das Verzeichnis rhel-7-test-mirror aus obigen Beispiel enthält die gespiegelten Repos als Unterverzeichnisse. Dieses Verzeichnis sollte über einen Webserver zugreifbar gemacht werden, um die Pakete den Clients im lokalen Netzwerk verfügbar zu machen.
Im obigen Listing ist eine Datei namens rhel-e-stage.repo zu sehen. Dabei handelt es sich um eine Repo-Datei, welche heruntergeladen und im Verzeichnis /etc/yum.repos.d/ platziert werden kann, um wie in diesem Beispiel das Repo rhel-e-stage zu aktivieren.
Aufbau einer Repo-Datei
Das folgende Listing zeigt die kommentierte Repo-Datei aus dem vorstehenden Abschnitt. Sie kann als Muster für weitere eigene Repo-Dateien dienen.
[rhel-e-stage] # Repo ID
baseurl = http://example.com/rhel-7-test-mirror/rhel-e-stage/
gpgcheck = 1
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
name = Repo for rhel-7-server-rpms (Test)
Fragen, Sorgen, Nöte und Anträge
Das Projekt und die enthaltene Software werden so wie sie sind unter der angegebenen Lizenz zur Verfügung gestellt.
Fragen, Sorgen, Nöte und Anträge können sowohl hier in den Kommentaren zum Artikel, als auch auf Github hinterlassen werden.
Ich hoffe, dass dieses Projekt euch (weiterhin) nützlich ist und freue mich über Rückmeldungen, wie es euch gefällt.
Als Linux-Distribution für den Betrieb im Rechenzentrum fiel unsere Wahl vor einiger Zeit auf Red Hat Enterprise Linux. Zu meinen Aufgaben gehört es, ein Patch-Management für diese Systeme zu entwickeln, welches die folgenden Anforderungen erfüllt:
Die zu aktualisierenden Hosts werden in Gruppen im Ansible Inventory verwaltet. Eine Gruppe entspricht dabei einer Stage/Phase für das Patch-Management.
An definierten Stichtagen sollen automatisiert fehlende Sicherheitsaktualisierungen auf den Systemen in den verschiedenen Stages/Phasen eingespielt werden können.
Dabei sollen ausschließlich Pakete aktualisiert werden, für die Red Hat Security Advisory veröffentlicht wurden.
Wenn Pakete aktualisiert wurden, soll der Host anschließend neugestartet werden.
Mit den Anregungen meines Arbeitskollegen habe ich dazu das folgende Playbook erstellt, welches die Rolle rhel-patchmanagement auf allen Hosts mit einem Red Hat Betriebssystem ausführt:
---
- hosts: all
tasks:
- name: Group by OS
group_by: key=os_{{ ansible_distribution }}
changed_when: False
- hosts: os_RedHat
roles:
- rhel-patchmanagement
Die Rolle rhel-patchmanagement besteht aus den beiden folgenden Dateien:
Obiges Listing gibt ein kurzes Beispiel, wie die Red Hat Security Advisory (RHSA) Nummern einer Variablen zugewiesen werden können. Die Variable rhsa_to_install wird dann in der Task-Datei verwendet.
roles/patch_rhel/tasks/main.yml:
---
- name: Install Red Hat Security Advisory (RHSA)
command: yum -y update-minimal --advisory {{ rhsa_to_install }}
register: yum_output
- debug: var=yum_output
- name: Reboot Host if packages were updated
shell: sleep 2 && shutdown -r now "Ansible updates triggered"
async: 1
poll: 0
ignore_errors: true
when: ('"Complete!" in "{{ yum_output.stdout_lines[-1] }}"') or
('"Komplett!" in "{{ yum_output.stdout_lines[-1] }}"')
- name: waiting for access server
local_action: wait_for
host={{ inventory_hostname }}
state=started
port=22
delay=30
timeout=300
connect_timeout=15
Zuerst wird das Kommando zur Aktualisierung der zu den angegebenen RHSA gehörenden Pakete auf den Hosts ausgeführt. Dabei wird die Ausgabe des Kommandos yum auf den Hosts der Variable yum_output zugewiesen.[6. Registered Variables] Diese Variable wird im nächsten Schritt ausgewertet, um zu ermitteln, ob Pakete aktualisiert wurden. Ist dies der Fall, wird der Host neugestartet.
Erklärung: Wurden Pakete aktualisiert, steht in der letzten Zeile der YUM-Ausgabe der Ausdruck „Complete!“. "{{ yum_output.stdout_lines[-1] }}" dereferenziert die Variable und liefert die Ausgabe des YUM-Kommandos als Liste zurück. Dabei wird in diesem Fall auf das letzte Element der Liste zugegriffen. Enthält diese Zeile den genannten Ausdruck, wird der Host neugestartet. Hinweis: Die zweite Zeile der when-Bedingung aus dem oberen Listing dient der Behandlung einer deutschsprachigen Ausgabe. In diesem Fall wird das Schlüsselwort „Komplett!“ ausgegeben und in der Variable gespeichert.
Der letzte Task wartet 30 Sekunden ab, um dem Host Zeit für den Neustart zu geben und prüft, ob eine Verbindung hergestellt werden kann. Damit soll sichergestellt werden, dass der Host nach dem Neustart wieder korrekt hochfährt.
Damit sind die Anforderungen aus Punkt 2 und 3 erfüllt. Um auch noch die Anforderung aus Punkt 1 zu erfüllen, setze ich folgendes Wrapper-Skript ein, welches das Playbook zu den definierten Stichtagen ausführen soll:
#!/bin/sh
DOM=`date +%d`
DOW=`date +%w`
LOG="/var/log/ansible/patch_run_`date +%Y-%m-%d`.log"
SETUP_LOG="/var/log/ansible/setup_patch_run_`date +%Y-%m-%d`.log"
SSH_KEY="/pfad/zum/ssh-key"
PLAYBOOK="/data/ansible/patch_rhel.yml"
CREATEVARS="/pfad/zu/roles/rhel-patchmanagement/create_vars.sh"
# Run Patch-Management ad-hoc in the specified phase.
# Example: './run_rhel_patch_mgmt.sh NOW rhel-patch-phase1'
if [ "${1}" = "NOW" ] && [ -n "${2}" ]
then
ansible-playbook $PLAYBOOK --private-key=$SSH_KEY --limit="${2}" >>$LOG 2>&1
exit
fi
if [ "${1}" = "NOW" ] && [ -z "${2}" ]
then
echo "ERROR: Second argument is missing."
echo "Example: './run_rhel_patch_mgmt.sh NOW rhel-patch-phase1'"
exit
fi
# Setup the next patchcycle
if [ "$DOW" = "2" ] && [ "$DOM" -gt 0 ] && [ "$DOM" -lt 8 ]
then
$CREATEVARS > $SETUP_LOG 2>&1
fi
# Patchcycle of the rhel-patch-phase1 on the second Tuesday of a month
if [ "$DOW" = "2" ] && [ "$DOM" -gt 7 ] && [ "$DOM" -lt 15 ]
then
ansible-playbook $PLAYBOOK --private-key=$SSH_KEY --limit=rhel-patch-phase1 > $LOG 2>&1
fi
# Patchcycle of the rhel-patch-phase2 on the third Tuesday of a month
if [ "$DOW" = "2" ] && [ "$DOM" -gt 14 ] && [ "$DOM" -lt 22 ]
then
ansible-playbook $PLAYBOOK --private-key=$SSH_KEY --limit=rhel-patch-phase2 > $LOG 2>&1
fi
# Patchcycle of the rhel-patch-phase3 on the fourth Tuesday of a month
if [ "$DOW" = "2" ] && [ "$DOM" -gt 21 ] && [ "$DOM" -lt 29 ]
then
ansible-playbook $PLAYBOOK --private-key=$SSH_KEY --limit=rhel-patch-phase3 > $LOG 2>&1
fi
# Patchcycle of the rhel-patch-phase4 on the fourth Wednesday of a month
if [ "$DOW" = "3" ] && [ "$DOM" -gt 21 ] && [ "$DOM" -lt 30 ]
then
ansible-playbook $PLAYBOOK --private-key=$SSH_KEY --limit=rhel-patch-phase4 > $LOG 2>&1
fi
Mit diesem Wrapper-Skript möchte ich dafür sorgen, dass an jedem 2. Dienstag im Monat die RSHA-Aktualisierungen auf den Hosts in der rhel-patch-phase1, jeden 3. Dienstag in der rhel-patch-phase2, jeden 4. Dienstag in der rhel-patch-phase3 und jeden 4. Mittwoch in rhel-patch-phase4 installiert werden.
So kann sichergestellt werden, dass die Informationen aus den RHSA alle Hosts erreichen. Gleichzeitig wird den Betreibern der Hosts die Gelegegnheit gegeben, die Aktualisierungen bis zu den genannten Stichtagen selbst einzuspielen. Damit sollte ich auch an Punkt 1 einen Haken dran machen können.
Die Ansible-Rolle und dazugehörende Skripte und Beispiel-Dateien findet ihr auf:
