One place for hosting & domains

      Empfohlene

      Empfohlene Schritte zum Härten von Apache unter FreeBSD 12.0


      Der Autor wählte den Free and Open Source Fund, um eine Spende im Rahmen des Programms Write for DOnations zu erhalten.

      Einführung

      Die standardmäßige Installation eines Apache-HTTP-Servers ist zwar bereits sicher, seine Konfiguration kann jedoch mit einigen Änderungen erheblich verbessert werden. Sie können bereits vorhandene Sicherheitsmechanismen ergänzen, indem Sie z. B. Schutzmechanismen für Cookies und Header einrichten, damit Verbindungen auf der Client-Ebene des Benutzers nicht manipuliert werden können. Dadurch können Sie die Möglichkeiten mehrerer Angriffsmethoden wie Cross-Site Scripting (auch als XSS bezeichnet) drastisch reduzieren. Sie können auch andere Arten von Angriffen verhindern, wie z. B. Cross-Site Request Forgery, Session Hijacking und Denial-of-Service-Angriffe.

      In diesem Tutorial werden Sie einige empfohlene Schritte implementieren, um die Informationen zu reduzieren, die auf Ihrem Server verfügbar sind. Sie werden die Verzeichnislisten verifizieren und die Indizierung deaktivieren, um den Zugriff auf Ressourcen zu überprüfen. Außerdem ändern Sie den Standardwert der Anweisung timeout, um das Risiko von Angriffen wie Denial of Service zu verringern. Des Weiteren deaktivieren Sie die TRACE-Methode, damit Sitzungen nicht zurückverfolgt und gehackt werden können. Abschließend sichern Sie Header und Cookies.

      Die meisten Konfigurationseinstellungen werden auf die Hauptkonfigurationsdatei des Apache HTTP angewendet, die sich in /usr/local/etc/apache24/httpd.conf befindet.

      Voraussetzungen

      Bevor Sie diese Anleitung beginnen, benötigen Sie Folgendes:

      Mit diesen Voraussetzungen haben Sie ein FreeBSD-System mit einem Stack, der Webinhalt mit allem in PHP Geschriebenen, wie wesentliche CMS-Software, bereitstellen kann. Außerdem haben Sie sichere Verbindungen über Let’s Encrypt verschlüsselt.

      Reduzieren der Serverinformationen

      Das Betriebssystem-Banner ist eine Methode, die von Computern, Servern und Geräten aller Art zur Präsentation in Netzwerken verwendet wird. Bösartige Akteure können diese Informationen verwenden, um relevante Systeme anzugreifen. In diesem Abschnitt reduzieren Sie die Menge an Informationen, die von diesem Banner veröffentlicht werden.

      Anweisungssätze​​​ kontrollieren, wie diese Informationen angezeigt werden. Zu diesem Zweck ist die Anweisung ServerTokens wichtig: Sie zeigt standardmäßig dem Client, zu dem die Verbindung hergestellt wird, alle Details über das Betriebssystem sowie die kompilierte Module an.

      Sie verwenden ein Netzwerk-Scanning-Tool um zu prüfen, welche Informationen derzeit angezeigt werden, bevor Sie alle Änderungen vornehmen. Um nmap zu installieren, führen Sie den folgenden Befehl aus:

      Um die IP-Adresse Ihres Servers zu erhalten, können Sie den folgenden Befehl ausführen:

      • ifconfig vtnet0 | awk '/inet / {print $2}'

      Sie können die Antwort des Webservers mit dem folgenden Befehl überprüfen:

      • nmap -sV -p 80 your-server-ip

      Rufen Sie zum Ausführen eines Scans nmap auf (folglich das Flag -s), um die Version (das Flag -V) auf Port 80 (das Flag -p) auf der gegebenen IP oder Domäne anzuzeigen.

      Sie erhalten Informationen über Ihren Webserver, ähnlich wie die folgenden:

      Output

      Starting Nmap 7.80 ( https://nmap.org ) at 2020-01-22 00:30 CET Nmap scan report for 206.189.123.232 Host is up (0.054s latency). PORT STATE SERVICE VERSION 80/tcp open http Apache httpd 2.4.41 ((FreeBSD) OpenSSL/1.1.1d-freebsd Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 7.59 seconds

      Diese Ausgabe zeigt, dass Informationen wie das Betriebssystem, die Apache-HTTP-Version und OpenSSL sichtbar sind. Damit können Angreifer Informationen über den Server erhalten (zum Beispiel ein Sicherheitsrisiko in der Software, die auf dem Server ausgeführt wird) und die richtigen Tools für den Angriff auswählen.

      Platzieren Sie die Anweisung ServerTokens in die Hauptkonfigurationsdatei, da sie nicht standardmäßig konfiguriert ist. Weil diese Konfiguration fehlt, zeigt Apache HTTP die vollständigen Informationen über den Server als Dokumentationszustand an. Um die Informationen zu begrenzen, die über Ihren Server und Ihre Konfiguration preisgegeben werden, platzieren Sie die Anweisung ServerTokens in die Hauptkonfigurationsdatei.

      Platzieren Sie diese Anweisung nach der ServerName-Eingabe in die Konfigurationsdatei. Führen Sie den folgenden Befehl aus, um die Anweisung zu suchen:

      • grep -n 'ServerName' /usr/local/etc/apache24/httpd.conf

      Danach können Sie die Zeilennummer mit vi suchen:

      Output

      226 #ServerName www.example.com:80

      Führen Sie den folgenden Befehl aus:

      • sudo vi +226 /usr/local/etc/apache24/httpd.conf

      Fügen Sie die folgende hervorgehobene Zeile hinzu:

      /usr/local/etc/apache24/httpd.conf

      . . .
      #ServerName www.example.com:80
      ServerTokens Prod
      

      Speichern und schließen Sie die Datei mit :wq und der EINGABETASTE.

      Durch die Einstellung der Anweisung ServerTokens auf Prod wird lediglich angezeigt, dass dies ein Apache-Webserver ist.

      Damit dies in Kraft tritt, starten Sie den Apache-HTTP-Server neu:

      Um die Änderungen zu testen, führen Sie den folgenden Befehl aus:

      • nmap -sV -p 80 your-server-ip

      Sie sehen eine ähnliche Ausgabe wie die folgende, mit weniger Informationen über Ihren Apache-Webserver:

      Output

      Starting Nmap 7.80 ( https://nmap.org ) at 2020-01-22 00:58 CET Nmap scan report for WPressBSD (206.189.123.232) Host is up (0.056s latency). PORT STATE SERVICE VERSION 80/tcp open http Apache httpd Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 7.59 seconds

      Sie haben gesehen, welche Informationen der Server vor der Änderung preisgegeben hat, und Sie haben dies nun auf ein Minimum reduziert. Dadurch geben Sie einem externen Akteur weniger Hinweise über Ihren Server. Im nächsten Schritt verwalten Sie die Verzeichnislisten für Ihren Webserver.

      Verwalten von Verzeichnislisten

      In diesem Schritt stellen Sie sicher, dass die Verzeichnisliste korrekt konfiguriert ist, damit die gewünschten Informationen über das System öffentlich verfügbar und die übrigen geschützt sind.

      Anmerkung: Wenn ein Argument deklariert ist, ist es aktiv, aber das + kann visuell untermauern, dass es tatsächlich aktiviert ist. Wenn ein Minuszeichen - eingegeben wird, wird das Argument verweigert, z. B. Options -Indexes.

      Argumente mit + und/oder - können nicht kombiniert werden – dies wird als schlechte Syntax in Apache HTTP erachtet und könnte beim Starten verweigert werden.

      Durch Hinzufügen der Anweisung Options -Indexes wird der Inhalt im Datenpfad /usr/local/www/apache24/data so eingestellt, dass (read listed) nicht automatisch indiziert wird, wenn keine .html-Datei vorhanden ist, sowie nicht gezeigt wird, wenn eine URL diesem Verzeichnis zugeordnet ist. Dies gilt auch bei der Verwendung von virtuellen Host-Konfigurationen wie z. B. jener, die für das Tutorial über Voraussetzungen für das Let’s-Encrypt-Zertifikat verwendet werden.

      Sie richten die Anweisung Options mit dem Argument -Indexes und der Anweisung +FollowSymLinks ein, wodurch symbolische Links besucht werden können. Sie verwenden das Symbol +, um die Konventionen von Apache HTTP zu befolgen.

      Führen Sie den folgenden Befehl aus, um die Zeile zu suchen, die in der Konfigurationsdatei bearbeitet werden soll:

      • grep -n 'Options Indexes FollowSymLinks' /usr/local/etc/apache24/httpd.conf

      Sie werden eine Ausgabe ähnlich der folgenden sehen:

      Output

      263 : Options Indexes FollowSymLinks

      Führen Sie diesen Befehl aus, um direkt auf die Zeile zur Bearbeitung zuzugreifen:

      • sudo vi +263 /usr/local/etc/apache24/httpd.conf

      Bearbeiten Sie nun die Zeile gemäß der Konfiguration:

      /usr/local/etc/apache24/httpd.conf

      . . .
      #
      Options -Indexes +FollowSymLinks
      
      #
      . . .
      

      Speichern und schließen Sie die Datei mit :wq und der EINGABETASTE.

      Starten Sie Apache HTTP zur Implementierung dieser Änderungen neu:

      Auf Ihrer Domäne im Browser sehen Sie eine „Zugriff verboten“-Nachricht, auch als Fehler 403 bekannt. Grund dafür sind Ihre Änderungen. Durch die Eingabe von -Indexes in die Anweisung Options wurde die Funktion Auto-Index von Apache HTTP deaktiviert und daher gibt es im Datenpfad keine index.html-Datei.

      Das können Sie lösen, indem Sie eine index.html-Datei im VirtualHost ablegen, den Sie im Tutorial​​​ über Voraussetzungen für das Let’s-Encrypt-Zertifikat aktiviert haben. Verwenden Sie den Standardblock innerhalb von Apache HTTP und legen Sie ihn im gleichen Ordner wie die DocumentRoot ab, die Sie im virtuellen Host deklariert haben.

      /usr/local/etc/apache24/extra/httpd-vhosts.conf

      <VirtualHost *:80>
          ServerAdmin your_email@your_domain.com
          DocumentRoot "/usr/local/www/apache24/data/your_domain.com"
          ServerName your_domain.com
          ServerAlias www.your_domain.com
          ErrorLog "/var/log/your_domain.com-error_log"
          CustomLog "/var/log/your_domain.com-access_log" common
      </VirtualHost>
      

      Verwenden Sie hierzu den folgenden Befehl:

      • sudo cp /usr/local/www/apache24/data/index.html /usr/local/www/apache24/data/your_domain.com/index.html

      Jetzt sehen Sie die Nachricht It works! beim Besuch Ihrer Domäne.

      In diesem Abschnitt haben Sie der Anweisung Indexes Beschränkungen hinzugefügt, um nicht automatisch unbeabsichtigten Inhalt einzutragen und anzuzeigen. Wenn nun keine index.html-Datei im Datenpfad ist, erstellt Apache HTTP nicht automatisch ein Verzeichnis des Inhalts. Im nächsten Schritt gehen Sie über das Verbergen von Informationen hinaus und passen verschiedene Anweisungen an.

      Den Wert der Timeout-Anweisung verringern

      Die Anweisung Timeout legt das Limit für die Zeit fest, die Apache HTTP auf eine neue Eingabe/Ausgabe wartet, bevor die Verbindungsanforderung fehlschlägt. Dieser Fehler kann aufgrund von verschiedenen Umständen auftreten, wie z. B. Pakete, die nicht beim Server ankommen, oder Daten, die vom Client nicht als empfangen bestätigt werden.

      Standardmäßig ist das Zeitlimit auf 60 Sekunden eingestellt. In Umgebungen, in denen das Internet langsam ist, kann dieser Standardwert sinnvoll sein. Eine Minute ist jedoch ziemlich lange, insbesondere dann, wenn der Server Benutzer mit schnellerem Internet abdeckt. Außerdem kann die Zeit, in der der Server die Verbindung nicht schließt, für Denial-of-Service-Angriffe (DoS) ausgenützt werden. Wenn es zu einer Vielzahl dieser schädlichen Verbindungen kommt, gerät der Server ins Stolpern und könnte gesättigt werden und nicht mehr reagieren.

      Um den Wert zu ändern, finden Sie die Timeout-Einträge in der Datei httpd-default.conf:

      • grep -n 'Timeout' /usr/local/etc/apache24/extra/httpd-default.conf

      Sie sehen eine ähnliche Ausgabe wie die folgende:

      Output

      8 # Timeout: The number of seconds before receives and sends time out. 10 Timeout 60 26 # KeepAliveTimeout: Number of seconds to wait for the next request from the 29 KeepAliveTimeout 5 89 RequestReadTimeout header=20-40,MinRate=500 body=20,MinRate=500

      In der Ausgabezeile legt 10 den Wert der Timeout-Anweisung fest. Um direkt auf diese Zeile zuzugreifen, führen Sie den folgenden Befehl aus:

      • sudo vi +10 /usr/local/etc/apache24/extra/httpd-default.conf

      Stellen Sie ihn zum Beispiel auf 30 Sekunden ein, wie nachfolgend gezeigt:

      /usr/local/etc/apache24/extra/httpd-default.conf

      #
      # Timeout: The number of seconds before receives and sends time out.
      #
      Timeout 30
      

      Speichern und schließen Sie die Datei mit :wq und der EINGABETASTE.

      Der Wert der Anweisung Timeout muss groß genug sein, damit eine legitime und erfolgreiche Verbindung hergestellt werden kann, und klein genug, um unerwünschte Verbindungsversuche zu verhindern.

      Anmerkung: Denial-of-Service-Angriffe können die Ressourcen des Servers ziemlich effektiv erschöpfen. Eine komplementäre und sehr fähige Gegenmaßnahme ist die Verwendung eines Threaded MPM, um für die Verbindungen und Prozesse von Apache HTTP die beste Leistung zu erzielen. Im Tutorial So konfigurieren Sie Apache HTTP mit MPM Event und PHP-FPM unter FreeBSD 12.0 finden Sie Schritte zur Aktivierung dieser Fähigkeit.

      Damit diese Änderung in Kraft tritt, starten Sie den Apache-HTTP-Server neu:

      Sie haben den Standardwert der Timeout-Anweisung geändert, um das Risiko von DoS-Angriffen teilweise zu reduzieren.

      Deaktivieren der TRACE-Methode

      Das Hypertext-Übertragungsprotokoll wurde nach einem Client-Server-Modell entwickelt und als solches hat das Protokoll Anforderungsmethoden, um Informationen vom Server abzurufen oder im Server abzulegen. Der Server muss diese Methodensätze und die Interaktion zwischen ihnen verstehen. In diesem Schritt konfigurieren Sie die mindestens erforderlichen Methoden.

      Die Methode TRACE, die als harmlos angesehen wurde, wurde für die Durchführung von Cross-Site-Tracing-Angriffen genutzt. Diese Art von Angriffen ermöglicht bösartigen Akteuren, Benutzersitzungen mithilfe dieser Methode zu stehlen. Die Methode wurde zum Zwecke des Debugging konzipiert, wobei der Server die gleiche Anfrage zurückgibt, die ursprünglich vom Client gesendet wurde. Da das Cookie aus der Sitzung des Browsers an den Server gesendet wird, wird es erneut zurückgesendet. Das könnte jedoch eventuell von einem bösartigen Akteur abgefangen werden, der dann die Verbindung eines Browsers zu einer Website umleiten kann, über die er die Kontrolle hat, anstatt zum ursprünglichen Server.

      Aufgrund des potenziellen Missbrauchs der TRACE-Methode wird empfohlen, sie nur für das Debugging und nicht in einer Produktivumgebung zu verwenden. In diesem Abschnitt deaktivieren Sie diese Methode.

      Bearbeiten Sie die Datei httpd.conf mit dem folgenden Befehl und drücken Sie dann G, um das Ende der Datei zu erreichen:

      • sudo vi /usr/local/etc/apache24/httpd.conf

      Fügen Sie am Ende der Datei folgenden Einstiegspfad hinzu:

      /usr/local/etc/apache24/httpd.conf

      . . .
      TraceEnable off
      

      Eine bewährte Vorgehensweise ist die Angabe der Methoden, die Sie auf Ihrem Apache-HTTP-Webserver verwenden. Dadurch werden potenzielle Einstiegspunkte für bösartige Akteure begrenzt.

      LimitExcept kann für diesen Zweck nützlich sein, da es keine anderen Methoden zulässt als die in ihm deklarierten. So kann beispielsweise eine Konfiguration wie diese erstellt werden:

      /usr/local/etc/apache24/httpd.conf

      DocumentRoot "/usr/local/www/apache24/data"
      <Directory "/usr/local/www/apache24/data">
          Options -Indexes +FollowSymLinks -Includes
          AllowOverride none
           <LimitExcept GET POST HEAD>
             deny from all
          </LimitExcept>
          Require all granted
      </Directory>
      

      Wie in der Anweisung LimitExcept deklariert, sind nur die Methoden GET, POST und HEAD in der Konfiguration erlaubt.

      • Die GET-Methode ist Teil des HTTP-Protokolls und dient zum Abrufen von Daten.
      • Die POST-Methode ist auch Teil des HTTP-Protokolls und dient dazu, Daten an den Server zu senden.
      • Die HEAD-Methode ist ähnlich wie GET, hat jedoch keinen Antworttext.

      Verwenden Sie den folgenden Befehl und legen Sie den LimitExcept-Block in der Datei ab:

      • sudo vi +272 /usr/local/etc/apache24/httpd.conf

      Um diese Konfiguration einzustellen, legen Sie den folgenden Block im Anweisungseintrag DocumentRoot ab, aus dem der Inhalt gelesen wird, genauer gesagt im Eintrag des Verzeichnisses:

      /usr/local/etc/apache24/httpd.conf

      . . .
      <LimitExcept GET POST HEAD>
         deny from all
      </LimitExcept>
      . . .
      

      Starten Sie Apache HTTP neu, damit die Änderungen übernommen werden:

      Die neuere Anweisung AllowedMethods​​​ hat eine ähnliche Funktionalität, ihr Status ist jedoch noch experimentell.

      Sie kennen nun HTTP-Methoden, ihre Verwendung und den Schutz, den sie vor bösartigen Aktivitäten mithilfe der TRACE-Methode bieten. Des Weiteren wissen Sie, wie man deklariert, welche Methoden verwendet werden sollen. Als Nächstes arbeiten Sie mit weiteren Schutzmaßnahmen für HTTP-Header und Cookies.

      In diesem Schritt richten Sie spezifische Anweisungen ein, um die Sitzungen zu schützen, die die Client-Rechner beim Besuch Ihres Apache-HTTP-Webservers öffnen. So lädt Ihr Server keinen unerwünschten Inhalt, die Verschlüsselung wird nicht heruntergeladen und Sie vermeiden Content Sniffing.

      Header sind Bestandteile der Anforderungsmethoden. Es gibt Header zum Anpassen der Authentifizierung, für die Kommunikation zwischen Server und Client, Zwischenspeicherung, Inhaltsaushandlung usw.

      Cookies sind Informationen, die vom Server an den Browser gesendet werden. Diese Informationen ermöglichen es dem Server, den Client-Browser von unterschiedlichen Computern zu unterscheiden. Außerdem ermöglichen sie Servern, Benutzersitzungen zu erkennen. Sie können beispielsweise den Einkaufswagen eines angemeldeten Benutzers, Zahlungsinformationen, den Verlauf etc. verfolgen. Cookies werden im Webbrowser des Clients verwendet und gespeichert, da HTTP ein zustandsloses Protokoll ist. Das bedeutet, sobald die Verbindung geschlossen wird, erinnert sich der Server nicht mehr an die Anfragen der einzelnen Clients.

      Es ist wichtig, sowohl Header als auch Cookies zu schützen, da sie eine Kommunikation zwischen Webbrowser-Client und Webserver bereitstellen.

      Das Modul Header ist standardmäßig aktiviert. Überprüfen Sie mit dem folgenden Befehl, ob es geladen wurde:

      • sudo apachectl -M | grep 'headers'

      Sie sehen die folgende Ausgabe:

      Output

      headers_module (shared)

      Wenn Sie keine Ausgabe sehen, überprüfen Sie, ob das Modul in der Apache-Datei httpd.conf aktiviert ist:

      • grep -n 'mod_headers' /usr/local/etc/apache24/httpd.conf

      Als Ausgabe sehen Sie eine unkommentierte Zeile, die auf das spezifische Modul für Header verweist:

      /usr/local/etc/apache24/httpd.conf

      . . .
      122  LoadModule headers_module libexec/apache24/mod_headers.so
      . . .
      

      Entfernen Sie den Hashtag am Anfang der Zeile mod_headers.so, falls vorhanden, um die Anweisung zu aktivieren.

      Durch die Verwendung der folgenden Apache-HTTP-Anweisungen schützen Sie Header und Cookies vor bösartigen Aktivitäten, um das Risiko für Clients und Server zu verringern.

      Jetzt richten Sie den Schutz des Headers ein. Legen Sie all diese Header-Werte in einen Block ab. Sie können diese Werte nach eigenem Ermessen anwenden, es werden jedoch alle empfohlen.

      Bearbeiten Sie die Datei httpd.conf mit dem folgenden Befehl und drücken Sie dann G, um das Ende der Datei zu erreichen:

      • sudo vi /usr/local/etc/apache24/httpd.conf

      Legen Sie den folgenden Block am Ende der Datei ab:

      /usr/local/etc/apache24/httpd.conf

      . . .
      <IfModule mod_headers.c>
        # Add security and privacy related headers
        Header set Content-Security-Policy "default-src 'self'; upgrade-insecure-requests;"
        Header set Strict-Transport-Security "max-age=31536000; includeSubDomains"
        Header always edit Set-Cookie (.*) "$1; HttpOnly; Secure"
        Header set X-Content-Type-Options "nosniff"
        Header set X-XSS-Protection "1; mode=block"
        Header set Referrer-Policy "strict-origin"
        Header set X-Frame-Options: "deny"
        SetEnv modHeadersAvailable true
      </IfModule>
      
      • Header Strict-Transport-Security "max-age​​, includeSubDomains": HTTP Strict Transport Security (HTSTS) ist ein Mechanismus für Webserver und Clients (hauptsächlich Browser) zur Einrichtung von Kommunikationen mit ausschließlich HTTPS. Durch die Implementierung vermeiden Sie Man-in-the-middle-Angriffe, bei denen ein Dritter in der Kommunikation potenziell auf Informationen zugreifen und diese manipulieren kann.

      • Header always edit Set-Cookie (. *) "$1; HttpOnly; Secure": Die Flags HttpOnly and Secure auf den Headern verringern das Risiko von Cross-Site-Scripting-Angriffen (XSS). Cookies können von Angreifern missbraucht werden, um sich als legitime Besucher bzw. als eine andere Person auszugeben (Identitätsdiebstahl), oder sie können manipuliert werden.

      • Header set Referrer-Policy "strict-origin​​": Der Header Referrer-Policy legt fest, welche Informationen im Header-Feld als Verweiser-Information enthalten sind.

      • Header set Content-Security-Policy "default-src 'self'; upgrade-insecure-requests;": Der Content-Security-Policy header (CSP) verhindert, dass Inhalt geladen wird, der in den Parametern nicht angegeben ist. Das ist hilfreich, um Cross-Site-Scripting-Angriffe (XSS) zu verhindern. Es gibt viele Parameter für die Konfiguration der Richtlinie dieses Headers. Entscheidend ist die Konfiguration zum Laden von Inhalt derselben Site und das Aktualisieren jedes Inhalts mit HTTP-Ursprung.

      • Header set X-XSS-Protection "1; mode=block": Dies unterstützt ältere Browser, die mit Content-Security-Policy nicht fertig werden. Der Header ‘X-XSS-Protection’ bietet Schutz vor Cross-Site-Scripting-Angriffen. Sie müssen diesen Header nicht einrichten, außer Sie müssen alte Browser-Versionen unterstützen, was selten ist.

      • Header set X-Frame-Options: "deny": Das verhindert clickjacking-Angriffe. Der Header ‘X-Frame-Options’ teilt einen Browser mit, wenn eine Seite in ein <frame>, <iframe>, <embed> oder <object> gerendert werden kann. So kann Inhalt von Sites nicht in andere eingebettet werden, wodurch Clickjacking-Angriffe verhindert werden. Hier verweigern Sie jegliches Frame-Rendering, damit die Webseite nicht irgendwo anders eingebettet werden kann, nicht einmal innerhalb derselben Website. Sie können dies Ihren Bedürfnissen anpassen, wenn Sie z. B. das Rendering bestimmter Seiten autorisieren müssen, da es sich um Anzeigen oder Kooperationen mit spezifischen Websites handelt.

      • Header set X-Content-Type-Options "nosniff": Der Header ‘X-Content-Type-Options’ steuert MIME types, damit sie nicht geändert und gefolgt werden können. MIME types sind Dateiformat-Standards: Sie funktionieren mit Text, Audio, Video, Image usw. Dieser Header hält bösartige Akteure von Content Sniffing der Dateien ab sowie vor dem Versuch, Dateitypen zu ändern.

      Starten Sie Apache neu, damit die Änderungen wirksam werden:

      Um die Sicherheitsebenen Ihrer Konfigurationseinstellungen zu überprüfen, besuchen Sie die Website Security Headers. Nach Ausführung der Schritte in diesem Tutorial wird Ihre Domäne die Note A erhalten.

      Anmerkung: Wenn Sie Ihre Header auf https://securityheaders.com/ überprüfen und ein F erhalten, könnte das daran liegen, dass in der DocumentRoot Ihrer Website kein index.html ist, wie am Ende von Schritt 2 beschrieben. Wenn Sie Ihre Header überprüfen und eine andere Note als A oder F erhalten, prüfen Sie jede Header set-Zeile auf Tippfehler, die zu der Herabstufung geführt haben könnten.

      In diesem Schritt haben Sie mit bis zu sieben Einstellungen gearbeitet, um die Sicherheit Ihrer Header und Cookies zu verbessern. Dadurch wird das Risiko von Cross-Site-Scripting, Clickjacking und anderen Arten von Angriffen verhindert.

      Zusammenfassung

      In diesem Tutorial haben Sie sich mit verschiedenen Sicherheitsaspekten befasst, wie der Preisgabe von Informationen, dem Schutz von Sitzungen sowie mit alternativen Konfigurationseinstellungen für wichtige Funktionen.

      Weitere Ressourcen zum Härten von Apache finden Sie hier:

      Weitere Tools zum Schutz von Apache HTTP:



      Source link

      Empfohlene Schritte zur Sicherung eines DigitalOcean Kubernetes Clusters


      Der Autor wählte die Kooperation Open Sourcing Mental Illness, um eine Spende im Rahmen des Programms Write for DOnations zu erhalten.

      Einführung

      Kubernetes, die Open-Source-Container-Orchestrierungsplattform, wird immer mehr zur bevorzugten Lösung für die Automatisierung, Skalierung und Verwaltung von Hochverfügbarkeits-Clustern. Aufgrund der zunehmenden Popularität wird die Sicherheit von Kubernetes immer wichtiger.

      In Anbetracht der beweglichen Teile, die in Kubernetes involviert sind, und der Vielfalt der Einsatzszenarien kann die Sicherung von Kubernetes manchmal komplex sein. Ziel dieses Artikels ist es daher, eine solide Sicherheitsbasis für einen DigitalOcean Kubernetes (DOKS) Cluster bereitzustellen. Beachten Sie, dass dieses Tutorial grundlegende Sicherheitsmaßnahmen für Kubernetes behandelt und eher als Startpunkt und nicht als erschöpfender Leitfaden gedacht ist. Zusätzliche Schritte finden Sie in der offiziellen Kubernetes-Dokumentation.

      In diesem Tutorial nehmen Sie grundlegende Schritte zur Sicherung Ihres DigitalOcean Kubernetes Clusters vor. Sie konfigurieren eine sichere lokale Authentifizierung mit TLS/SSL-Zertifikaten, vergeben Berechtigungen an lokale Benutzer mit rollenbasierten Zugriffskontrollen (RBAC) sowie an Kubernetes-Anwendungen und -Bereitstellungen mit Service Accounts, und richten Ressourcenbegrenzungen mit den Zugriffs-Controllern ResourceQuota und LimitRange ein.

      Voraussetzungen

      Um dieses Tutorial auszuführen, benötigen Sie Folgendes:

      • Einen von DigitalOcean Kubernetes (DOKS) verwalteten Cluster mit 3 Standardknoten, die jeweils mit mindestens 2 GB RAM und 1 vCPU konfiguriert sind. Eine detaillierte Anleitung für die Erstellung eines DOKS-Clusters finden Sie in unserem Leitfaden Kubernetes Quickstart. Dieses Tutorial verwendet die DOKS-Version 1.16.2-do.1.
      • Einen für die Verwaltung des DOKS-Clusters konfigurierten lokalen Client, mit einer vom DigitalOcean Control Panel heruntergeladenen Cluster-Konfigurationsdatei, gespeichert unter ~/.kube/config. Eine detaillierte Anleitung für die Konfiguration eines auf Remote-Ebene verwalteten DOKS finden Sie im Leitfaden Verbinden mit einem DigitalOcean Kubernetes Cluster. Im Einzelnen benötigen Sie Folgendes:
        • Die auf Ihrem lokalen Rechner installierte Befehlszeilenschnittstelle kubectl. Mehr über die Installation und Konfiguration von kubectl können Sie der offiziellen Dokumentation entnehmen. Dieses Tutorial verwendet die kubectl-Version 1.17.0-00.
        • Das offizielle DigitalOcean-Befehlszeilen-Tool doctl. Anweisungen für die Installation finden Sie auf der Seite doctl GitHub Page. Dieses Tutorial verwendet die Version doctl 1.36.0.

      Schritt 1 – Aktivieren der Remotebenutzer-Authentifizierung

      Nach der Erfüllung der Voraussetzungen erhalten Sie einen Kubernetes-Superuser, der sich über ein vordefiniertes DigitalOcean-Träger-Token authentifiziert. Die gemeinschaftliche Nutzung dieses Berechtigungsnachweises ist jedoch keine gute Sicherheitspraxis, da dieses Konto umfangreiche und möglicherweise destruktive Änderungen an Ihrem Cluster verursachen kann. Um diese Möglichkeit einzugrenzen, können Sie zusätzliche Benutzer einrichten, die von ihren jeweiligen lokalen Clients authentifiziert werden.

      In diesem Abschnitt authentifizieren Sie neue Benutzer beim DOKS-Remote-Cluster von lokalen Clients aus mit sicheren SSL/TLS-Zertifikaten. Dies ist ein dreistufiger Prozess: Zuerst generieren Sie für jeden Benutzer eine Zertifikatsignierungsanforderung, die Certificate Signing Requests (CSR)​​. Danach genehmigen Sie diese Zertifikate direkt im Cluster über kubectl. Abschließend erstellen Sie für jeden Benutzer eine kubeconfig-Datei mit den entsprechenden Zertifikaten. Weitere Informationen über zusätzliche von Kubernetes unterstützte Authentifizierungsverfahren finden Sie in der Kubernetes-Authentifizierungsdokumentation.

      Erstellen von Zertifikatsignierungsanforderungen für neue Benutzer

      Prüfen Sie vor dem Start die DOKS-Clusterverbindung von dem lokalen Rechner aus, der bei den Voraussetzungen konfiguriert wurde:

      Je nach Ihrer Konfiguration sehen Sie ein ähnliches Output:

      Output

      Kubernetes master is running at https://a6616782-5b7f-4381-9c0f-91d6004217c7.k8s.ondigitalocean.com CoreDNS is running at https://a6616782-5b7f-4381-9c0f-91d6004217c7.k8s.ondigitalocean.com/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

      Das bedeutet, dass Sie mit dem DOKS-Cluster verbunden sind.

      Erstellen Sie als Nächstes einen lokalen Ordner für die Client-Zertifikate. In diesem Tutorial nutzen Sie zur Speicherung aller Zertifikate ~/certs.

      Sie autorisieren in diesem Tutorial einen neuen Benutzer namens sammy, um auf den Cluster zuzugreifen. Sie können dies auch auf einen Benutzer Ihrer Wahl ändern. Generieren Sie mit der SSL- und TLS-Bibliothek OpenSSL einen neuen privaten Schlüssel für Ihren Benutzer mit dem folgenden Befehl:

      • openssl genrsa -out ~/certs/sammy.key 4096

      Das -out-Flag erzeugt die Output-Datei ~/certs/sammy.key, und 4096 setzt den Schlüssel als 4096-Bit. Weitere Informationen über OpenSSL finden Sie in unserem Leitfaden OpenSSL Essentials.

      Erstellen Sie nun eine Konfigurationsdatei zur Zertifikatsignierungsanforderung. Öffnen Sie die folgende Datei mit einem Texteditor (für dieses Tutorial verwenden wir nano):

      • nano ~/certs/sammy.csr.cnf

      Fügen Sie folgenden Inhalt in die Datei sammy.csr.cnf ein, um im Subjekt den gewünschten Benutzernamen als “common name” (CN) und die Gruppe als “organization”(O) festzulegen:

      ~/certs/sammy.csr.cnf

      [ req ]
      default_bits = 2048
      prompt = no
      default_md = sha256
      distinguished_name = dn
      [ dn ]
      CN = sammy
      O = developers
      [ v3_ext ]
      authorityKeyIdentifier=keyid,issuer:always
      basicConstraints=CA:FALSE
      keyUsage=keyEncipherment,dataEncipherment
      extendedKeyUsage=serverAuth,clientAuth
      

      Die Konfigurationsdatei für die Zertifikatsignierungsanforderung enthält alle erforderlichen Informationen, die Benutzeridentität und entsprechende Verwendungsparameter für den Benutzer. Das letzte Argument extendedKeyUsage=serverAuth,clientAuth ermöglicht Benutzern die Authentifizierung ihrer lokalen Clients mit dem DOKS-Cluster mittels des Zertifikats, sobald es unterzeichnet wurde.

      Erstellen Sie als Nächstes die Zertifikatsignierungsanforderung (CSR) für sammy:

      • openssl req -config ~/certs/sammy.csr.cnf -new -key ~/certs/sammy.key -nodes -out ~/certs/sammy.csr

      Mit -config können Sie die Konfigurationsdatei für die CSR festlegen, und -new signalisiert die Erstellung einer neuen CSR für den durch -key festgelegten Schlüssel.

      Sie können Ihre Zertifikatsignierungsanforderung überprüfen, indem Sie folgenden Befehl ausführen:

      • openssl req -in ~/certs/sammy.csr -noout -text

      Hier geben Sie die CSR mit -in an und verwenden -text, um die Zertifikatsanforderung in Text auszudrucken.

      Das Output zeigt die Zertifikatsanforderung, deren Anfang folgendermaßen aussieht:

      Output

      Certificate Request: Data: Version: 1 (0x0) Subject: CN = sammy, O = developers Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public-Key: (4096 bit) ...

      Wiederholen Sie den gleichen Vorgang, um CSRs für alle weiteren Benutzer zu erstellen. Wenn Sie alle Zertifikatsignierungsanforderungen in dem Ordner ~/certs des Administrators gespeichert haben, fahren Sie mit dem nächsten Schritt fort, um sie zu genehmigen.

      Verwalten von Zertifikatsignierungsanforderungen mit der Kubernetes-API

      Sie können die TLS-Zertifikate, die für die Kubernetes-API ausgegeben wurden, mit dem Befehlszeilen-Tool kubectl entweder genehmigen oder ablehnen. So können Sie sicherstellen, dass der angeforderte Zugang für den jeweiligen Benutzer geeignet ist. In diesem Abschnitt senden Sie die Zertifikatsanforderung für sammy und genehmigen sie.

      Zum Senden einer CSR an den DOKS-Cluster verwenden Sie den folgenden Befehl:

      cat <<EOF | kubectl apply -f -
      apiVersion: certificates.k8s.io/v1beta1
      kind: CertificateSigningRequest
      metadata:
        name: sammy-authentication
      spec:
        groups:
        - system:authenticated
        request: $(cat ~/certs/sammy.csr | base64 | tr -d 'n')
        usages:
        - digital signature
        - key encipherment
        - server auth
        - client auth
      EOF
      

      Dieser Befehl mit einem Bash-Heredoc nutzt cat, um die Zertifikatsanforderung an kubectl apply weiterzuleiten.

      Sehen Sie sich die Zertifikatsanforderung genauer an:

      • name: sammy-authentication erstellt einen Metadaten-Identifizierer, hier sammy-authentication genannt.
      • request: $(cat ~/certs/sammy.csr | Basis64 | tr -d 'n') sendet die Zertifikatsignierungsanforderung sammy.csr als Base64 kodiert an den Cluster.
      • server auth und client auth geben die beabsichtigte Verwendung des Zertifikats an. In diesem Fall ist der Zweck die Benutzerauthentifizierung.

      Das Output sieht ungefähr wie folgt aus:

      Output

      certificatesigningrequest.certificates.k8s.io/sammy-authentication created

      Sie können den Status der Zertifikatsignierungsanforderung mit diesem Befehl prüfen:

      Je nach Ihrer Cluster-Konfiguration sehen Sie ein ähnliches Output:

      Output

      NAME AGE REQUESTOR CONDITION sammy-authentication 37s your_DO_email Pending

      Als Nächstes genehmigen Sie die CSR durch Verwendung des Befehls:

      • kubectl certificate approve sammy-authentication

      Sie erhalten eine Nachricht, die die Operation bestätigt:

      Output

      certificatesigningrequest.certificates.k8s.io/sammy-authentication approved

      Anmerkung: Als Administrator können Sie eine CSR auch mit dem Befehl kubectl certificate deny sammy-authentication ablehnen. Weitere Informationen über die Verwaltung von TLS-Zertifikaten finden Sie in der offiziellen Dokumentation von Kubernetes.

      Nachdem die CSR nun genehmigt wurde, können Sie sie auf den lokalen Rechner herunterladen, indem Sie Folgendes ausführen:

      • kubectl get csr sammy-authentication -o jsonpath='{.status.certificate}' | base64 --decode > ~/certs/sammy.crt

      Dieser Befehl dekodiert das Base64-Zertifikat für eine richtige Anwendung durch kubectl und speichert es dann als ~/certs/sammy.crt.

      Mit dem signierten sammy-Zertifikat können Sie nun die kubeconfig-Datei des Benutzers erstellen.

      Erstellen der Remotebenutzer-Kubeconfig

      Als Nächstes erstellen Sie eine spezifische kubeconfig-Datei für den sammy-Benutzer. Dadurch erhalten Sie mehr Kontrolle über den Zugriff des Benutzers auf Ihren Cluster.

      Der erste Schritt beim Erstellen einer neuen kubeconfig ist die Erstellung einer Kopie der aktuellen kubeconfig-Datei. In diesem Tutorial benennen Sie die neue kubeconfig-Datei config-sammy:

      • cp ~/.kube/config ~/.kube/config-sammy

      Als Nächstes editieren Sie die neue Datei:

      • nano ~/.kube/config-sammy

      Behalten Sie die ersten acht Zeilen dieser Datei, da sie die erforderlichen Informationen für die SSL/TLS-Verbindung mit dem Cluster enthalten. Ersetzen Sie dann ausgehend vom Benutzerparameter den Text durch die folgenden hervorgehobenen Zeilen, damit die Datei ähnlich wie Folgendes aussieht:

      config-sammy

      apiVersion: v1
      clusters:
      - cluster:
          certificate-authority-data: certificate_data
        name: do-nyc1-do-cluster
      contexts:
      - context:
          cluster: do-nyc1-do-cluster
          user: sammy
        name: do-nyc1-do-cluster
      current-context: do-nyc1-do-cluster
      kind: Config
      preferences: {}
      users:
      - name: sammy
        user:
          client-certificate: /home/your_local_user/certs/sammy.crt
          client-key: /home/your_local_user/certs/sammy.key
      

      Anmerkung: Sowohl für client-certificate als auch für client-key verwenden Sie den absoluten Pfad zu deren entsprechenden Zertifikatsstandorten. Andernfalls erzeugt kubectl einen Fehler.

      Speichern und schließen Sie die Datei.

      Sie können die neue Benutzerverbindung mit kubectl cluster-info testen:

      • kubectl --kubeconfig=/home/your_local_user/.kube/config-sammy cluster-info

      Sie erhalten einen ähnlichen Fehler:

      Output

      To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'. Error from server (Forbidden): services is forbidden: User "sammy" cannot list resource "services" in API group "" in the namespace "kube-system"

      Dieser Fehler wird erwartet, weil der Benutzer sammy noch keine Berechtigung hat, eine Ressource auf dem Cluster zu listen. Die Erteilung von Berechtigungen an Benutzer wird im nächsten Schritt gezeigt. Das jetzige Output bestätigt, dass die SSL/TLS-Verbindung erfolgreich war und die Authentifizierungsangaben von sammy von der Kubernetes-API akzeptiert wurden.

      Schritt 2 – Autorisieren von Benutzern über die Rollenbasierte Zugriffskontrolle (RBAC)

      Nach der Authentifizierung eines Benutzers bestimmt die API seine Berechtigungen mit dem in Kubernetes integrierten Modell der Role Based Access Control (RBAC), der rollenbasierten Zugriffskontrolle. RBAC ist eine wirksame Methode zur Beschränkung von Benutzerrechten auf der Grundlage der jeweils zugewiesenen Rolle. Aus sicherheitstechnischer Sicht erlaubt RBAC das Festlegen genau definierter Berechtigungen und limitiert damit die Möglichkeiten von Benutzern, auf vertrauliche Daten zuzugreifen oder Befehle auf Superuser-Ebene auszuführen. Weitere detaillierte Informationen über Benutzerrollen finden Sie in der Kubernetes-RBAC-Dokumentation.

      In diesem Schritt verwenden Sie kubectl, um die vordefinierte Rolle edit dem Benutzer sammy im default-Namensraum zuzuweisen. In einer Produktivumgebung können Sie auch benutzerdefinierte Rollen und/oder benutzerdefinierte Rollenbindungen verwenden.

      Berechtigungen erteilen

      In Kubernetes bedeutet die Erteilung von Berechtigungen, einem Benutzer die gewünschte Rolle zuzuweisen. Erteilen Sie edit-Berechtigungen an den Benutzer sammy im default-Namensraum mit diesem Befehl:

      • kubectl create rolebinding sammy-edit-role --clusterrole=edit --user=sammy --namespace=default

      Sie erhalten ein Output, das dem Folgenden ähnelt:

      Output

      rolebinding.rbac.authorization.k8s.io/sammy-edit-role created

      Im Einzelnen setzt sich der Befehl wie folgt zusammen:

      • create rolebinding sammy-edit-role erstellt eine neue Rollenbindung, in diesem Fall namens sammy-edit-role.
      • --clusterrole=edit wendet die vordefinierte Rolle edit auf einen globalen Gültigkeitsbereich (Cluster-Rolle) an.
      • --user=sammy gibt an, an welchen Benutzer die Rolle gebunden wird.
      • --namespace=default erteilt die Rollenberechtigung des Benutzers im angegebenen Namensraum, in diesem Fall default.

      Als Nächstes verifizieren Sie die Benutzerberechtigung, indem Sie Pods in dem default-Namensraum auflisten. Sie können erkennen, ob die RBAC-Autorisierung wie erwartet funktioniert, wenn keine Fehler angezeigt werden.

      • kubectl --kubeconfig=/home/your_local_user/.kube/config-sammy auth can-i get pods

      Sie erhalten folgendes Output:

      Output

      yes

      Sie haben sammy nun Berechtigungen zugewiesen. Im nächsten Abschnitt sehen Sie, wie Sie diese Berechtigungen wieder entziehen.

      Berechtigungen entziehen

      In Kubernetes entziehen Sie Berechtigungen, indem Sie die Rollenbindung des Benutzers entfernen.

      In diesem Tutorial löschen Sie die edit-Rolle des Benutzers sammy, indem Sie folgenden Befehl ausführen:

      • kubectl delete rolebinding sammy-edit-role

      Sie erhalten folgendes Output:

      Output

      rolebinding.rbac.authorization.k8s.io "sammy-edit-role" deleted

      Überprüfen Sie, ob die Berechtigungen wie erwartet entzogen wurden, indem Sie Pods im default-Namensraum auflisten:

      • kubectl --kubeconfig=/home/localuser/.kube/config-sammy --namespace=default get pods

      Sie erhalten die folgende Fehlermeldung:

      Output

      Error from server (Forbidden): pods is forbidden: User "sammy" cannot list resource "pods" in API group "" in the namespace "default"

      Diese zeigt, dass die Autorisierung entzogen wurde.

      Aus sicherheitstechnischer Sicht gibt das Kubernetes-Autorisierungsmodell Cluster-Administratoren die Flexibilität, die Benutzerrechte bei Bedarf zu ändern. Außerdem ist die rollenbasierte Zugriffskontrolle nicht auf einen physischen Benutzer beschränkt; Sie können auch Cluster-Diensten Berechtigungen erteilen und entziehen. Mehr dazu erfahren Sie im nächsten Abschnitt.

      Weitere Informationen über die RBAC-Autorisierung und wie Sie benutzerdefinierte Rollen erstellen, finden Sie in der offiziellen Dokumentation.

      Schritt 3 – Verwalten von Anwendungsberechtigungen mit Service Accounts

      Wie im vorherigen Abschnitt erwähnt, erstrecken sich die RBAC-Autorisierungsmechanismen nicht nur auf menschliche Benutzer. Nicht-menschliche Cluster-Benutzer wie Anwendungen, Dienste und Prozesse, die in Pods ausgeführt werden, authentifizieren sich mit dem API-Server über Dienstkonten, die in Kubernetes Service Accounts (SAs) genannt werden. Wenn ein Pod in einem Namensraum erstellt wird, können Sie hierfür entweder das default-Service-Account verwenden oder ein Service Account Ihrer Wahl definieren. Die Möglichkeit, Anwendungen und Prozessen individuelle SAs zuzuordnen, gibt Administratoren die Freiheit, Berechtigungen nach Bedarf zu erteilen oder zu entziehen. Außerdem wird die Zuordnung bestimmter SAs zu produktionskritischen Anwendungen als beste Sicherheitspraxis angesehen. Da Service Accounts für die Authentifizierung und damit für die RBAC-Autorisierungsprüfungen verwendet werden, können Cluster-Administratoren Sicherheitsbedrohungen eindämmen, indem sie die Zugriffsrechte für Service Accounts ändern und den fehlerhaften Prozess isolieren.

      Zur Veranschaulichung von Service Accounts verwendet dieses Tutorial einen Nginx-Webserver als Beispielanwendung.

      Bevor Sie Ihrer Anwendung ein bestimmtes SA zuweisen, müssen Sie dieses SA erstellen. Erstellen Sie ein neues Service Account namens nginx-sa im default-Namensraum:

      • kubectl create sa nginx-sa

      Sie erhalten Folgendes:

      Output

      serviceaccount/nginx-sa created

      Überprüfen Sie, ob das Service Account erstellt wurde, indem Sie Folgendes ausführen:

      Dadurch erhalten Sie eine Liste Ihrer Service Accounts:

      Output

      NAME SECRETS AGE default 1 22h nginx-sa 1 80s

      Nun erteilen Sie dem Service Account nginx-sa eine Rolle. In diesem Beispiel erteilen Sie nginx-sa dieselben Berechtigungen wie dem Benutzer sammy:

      • kubectl create rolebinding nginx-sa-edit
      • --clusterrole=edit
      • --serviceaccount=default:nginx-sa
      • --namespace=default

      Nach der Ausführung erhalten Sie Folgendes:

      Output

      rolebinding.rbac.authorization.k8s.io/nginx-sa-edit created

      Dieser Befehl verwendet das gleiche Format wie für den Benutzer sammy. Ausgenommen hierbei ist das Flag --serviceaccount=default:nginx-sa, wo Sie das Service Account nginx-sa dem default-Namensraum zuweisen.

      Überprüfen Sie mit diesem Befehl, ob die Rollenbindung erfolgreich war:

      Dadurch erhalten Sie folgendes Output:

      Output

      NAME AGE nginx-sa-edit 23s

      Nachdem Sie bestätigt haben, dass die Rollenbindung für das Service Account erfolgreich konfiguriert wurde, können Sie das Service Account einer Anwendung zuweisen. Wenn Sie einer Anwendung ein bestimmtes Service Account zuweisen, können Sie dessen Zugriffsrechte in Echtzeit verwalten und somit die Sicherheit des Clusters erhöhen.

      In diesem Tutorial dient ein nginx-Pod als Beispielanwendung. Erstellen Sie den neuen Pod und bestimmen Sie das Service Account nginx-sa mit dem folgenden Befehl:

      • kubectl run nginx --image=nginx --port 80 --serviceaccount="nginx-sa"

      Der erste Teil des Befehls erstellt einen neuen Pod, der einen nginx-Webserver auf Port :80 ausführt. Der zweite Teil --serviceaccount="nginx-sa" zeigt an, dass dieser Pod das nginx-sa-Service-Account und nicht das default-Service-Account verwenden soll.

      Sie erhalten ein Output, das dem Folgenden ähnelt:

      Output

      deployment.apps/nginx created

      Überprüfen Sie mit kubectl describe, ob die neue Anwendung das Service Account verwendet:

      • kubectl describe deployment nginx

      Dadurch erhalten Sie eine längere Beschreibung der Bereitstellungsparameter. Unter dem Abschnitt Pod Template sehen Sie ein Output, das diesem ähnelt:

      Output

      ... Pod Template: Labels: run=nginx Service Account: nginx-sa ...

      In diesem Abschnitt haben Sie das Service Account nginx-sa im default-Namensraum erstellt und dem nginx-Webserver zugewiesen. Sie können nun die nginx-Berechtigungen in Echtzeit steuern, indem Sie seine Rolle nach Bedarf ändern. Sie können Anwendungen auch gruppieren, indem Sie jeder dasselbe Service Account zuweisen und dann Mehrfachänderungen (bulk changes) an Berechtigungen vornehmen. Sie können zudem kritische Anwendungen isolieren, indem Sie diesen ein individuelles SA zuweisen.

      Die Idee hinter der Zuweisung von Rollen an Ihre Anwendungen/Bereitstellungen besteht auch darin, eine Feinabstimmung der Berechtigungen vornehmen zu können. In realen Produktivumgebungen haben Sie möglicherweise mehrere Bereitstellungen, die unterschiedliche Berechtigungen erfordern, die von reinen Leseberechtigungen bis hin zu vollen Administratorrechten reichen. Mit RBAC können Sie den Zugriff auf den Cluster flexibel nach Bedarf einschränken.

      Als Nächstes richten Sie Zugangs-Controller ein, um Ressourcen zu kontrollieren und gegen übermäßigen Ressourcenverbrauch zu schützen.

      Schritt 4 – Einrichten von Zugriffs-Controllern

      Die Zugriffs-Controller von Kubernetes sind optionale Plugins, die in das kube-apiserver-Binärprogramm kompiliert werden, um die Sicherheitsoptionen zu erweitern. Zugriffs-Controller fangen Anfragen ab, nachdem diese die Authentifizierungs- und Autorisierungsphase durchlaufen haben. Nach dem Abfangen der Anfrage führen die Zugriffs-Controller den jeweils festgelegten Code aus, bevor die Anfrage ausgeführt wird.

      Während das Ergebnis einer Authentifizierungs- oder Autorisierungsprüfung ein boolescher Wahr-oder-Falsch-Wert ist, der die Anfrage entweder erlaubt oder ablehnt, können Zugriffs-Controller wesentlich vielfältiger agieren. Zugriffs-Controller können Anfragen in gleicher Weise wie eine Authentifizierung validieren. Sie können jedoch auch zusätzlich Anfragen mutieren und ändern sowie Objekte modifizieren, bevor diese zugelassen werden.

      In diesem Schritt verwenden Sie die Zugriffs-Controller ResourceQuota und LimitRange. Diese schützen Ihren Cluster, indem Sie Anfragen, die zu einem übermäßigen Ressourcenverbrauch oder einem Denial-of-Service-Angriff führen können, mutieren. Der Zugriffs-Controller ResourceQuota ermöglicht Administratoren, die Rechnerressourcen, die Speicherressourcen und die Quantität jedes Objekts in einem Namensraum zu beschränken. Der Zugriffs-Controller LimitRange beschränkt die Anzahl der von Containern verwendeten Ressourcen. Die gleichzeitige Verwendung dieser beiden Zugriffs-Controller schützt Ihren Cluster vor Angriffen, durch die Ihre Ressourcen nicht mehr verfügbar wären.

      Um zu zeigen, wie ResourceQuota funktioniert, implementieren Sie nun einige Beschränkungen im default-Namensraum. Beginnen Sie mit dem Erstellen einer neuen ResourceQuota-Objektdatei:

      • nano resource-quota-default.yaml

      Fügen Sie die folgende Objektdefinition hinzu, um Beschränkungen für den Ressourcenverbrauch im default-Namensraum festzulegen. Sie können die Werte entsprechend der physischen Ressourcen Ihrer Knoten nach Bedarf anpassen:

      resource-quota-default.yaml

      apiVersion: v1
      kind: ResourceQuota
      metadata:
        name: resource-quota-default
      spec:
        hard:
          pods: "2"
          requests.cpu: "500m"
          requests.memory: 1Gi
          limits.cpu: "1000m"
          limits.memory: 2Gi
          configmaps: "5"
          persistentvolumeclaims: "2"
          replicationcontrollers: "10"
          secrets: "3"
          services: "4"
          services.loadbalancers: "2"
      

      Diese Definition verwendet das Schlüsselwort hard, um harte Beschränkungen wie z. B. die maximale Anzahl von pods, configmaps, PersistentVolumeClaims, ReplicationControllers, secrets, services und loadbalancers festzulegen. Sie setzt auch Beschränkungen für Rechnerressourcen wie:

      • requests.cpu, das den maximalen CPU-Wert von Anfragen in milliCPU oder einem Tausendstel eines CPU-Kerns festlegt.
      • requests.memory, das den maximalen Speicherwert von Anfragen in Bytes festlegt.
      • limits.cpu, das den maximalen CPU-Wert von Limits in milliCPUs festlegt.
      • limits.memory, das den maximalen Speicherwert von Limits in Bytes festlegt.

      Speichern und schließen Sie die Datei.

      Erstellen Sie nun mit dem folgenden Befehl das Objekt im Namensraum:

      • kubectl create -f resource-quota-default.yaml --namespace=default

      Dadurch erhalten Sie:

      Output

      resourcequota/resource-quota-default created

      Beachten Sie, dass Sie das Flag -f verwenden, um Kubernetes den Speicherort der ResourceQuota-Datei anzuzeigen, sowie das Flag --namespace, um anzugeben, welcher Namensraum aktualisiert wird.

      Nach dem Erstellen des Objekts ist Ihr ResourceQuota aktiv. Sie können die default-Namensraumquoten mit describe quota prüfen:

      • kubectl describe quota --namespace=default

      Das Output sieht dem Folgenden ähnlich; mit den harten Limits, die Sie in der Datei resource-quota-default.yaml festgelegt haben:

      Output

      Name: resource-quota-default Namespace: default Resource Used Hard -------- ---- ---- configmaps 0 5 limits.cpu 0 1 limits.memory 0 2Gi persistentvolumeclaims 0 2 pods 1 2 replicationcontrollers 0 10 requests.cpu 0 500m requests.memory 0 1Gi secrets 2 3 services 1 4 services.loadbalancers 0 2

      ResourceQuotas werden in absoluten Einheiten ausgedrückt. Daher erhöht das Hinzufügen zusätzlicher Knoten nicht automatisch die hier definierten Werte. Wenn weitere Knoten hinzugefügt werden, müssen Sie die Werte hier manuell bearbeiten, um die Ressourcen zu proportionieren. ResourceQuotas können so oft wie nötig modifiziert werden. Sie können jedoch nicht entfernt werden, es sei denn, der gesamte Namensraum wird entfernt.

      Wenn Sie einen bestimmten ResourceQuota-Controller ändern möchten, aktualisieren Sie die entsprechende .yaml-Datei und wenden Sie die Änderungen mit dem folgenden Befehl an:

      • kubectl apply -f resource-quota-default.yaml --namespace=default

      Weitere Informationen über den Zugriffs-Controller ResourceQuota finden Sie in der offiziellen Dokumentation.

      Nachdem Ihr ResourceQuota nun eingerichtet ist, fahren Sie mit der Konfiguration des Zugriffs-Controllers LimitRange fort. Ähnlich wie der Controller ResourceQuota Limits für Namensräume umsetzt, setzt der Controller LimitRange die durch Validierung und Mutation von Containern deklarierten Beschränkungen durch.

      Wie zuvor beginnen Sie mit dem Erstellen der Objektdatei:

      • nano limit-range-default.yaml

      Nun können Sie mit dem LimitRange-Objekt den Ressourcenverbrauch nach Bedarf beschränken. Fügen Sie folgenden Inhalt als Beispiel eines typischen Anwendungsfalls hinzu:

      limit-ranges-default.yaml

      apiVersion: v1
      kind: LimitRange
      metadata:
        name: limit-range-default
      spec:
        limits:
        - max:
            cpu: "400m"
            memory: "1Gi"
          min:
            cpu: "100m"
            memory: "100Mi"
          default:
            cpu: "250m"
            memory: "800Mi"
          defaultRequest:
            cpu: "150m"
            memory: "256Mi"
          type: Container
      

      Die in limit-ranges-default.yaml verwendeten Beispielwerte beschränken den Containerspeicher auf ein Maximum von 1Gi und die CPU-Nutzung auf ein Maximum von 400 m, was einer Kubernetes-Metrik von 400 milliCPU entspricht und bedeutet, dass der Container auf nahezu die Hälfte seines Kerns beschränkt ist.

      Als Nächstes stellen Sie das Objekt mit dem folgenden Befehl für den API-Server bereit:

      • kubectl create -f limit-range-default.yaml --namespace=default

      Dadurch erhalten Sie folgendes Output:

      Output

      limitrange/limit-range-default created

      Nun können Sie die neuen Limits mit dem folgenden Befehl überprüfen:

      • kubectl describe limits --namespace=default

      Das Output sieht ungefähr wie folgt aus:

      Output

      Name: limit-range-default Namespace: default Type Resource Min Max Default Request Default Limit Max Limit/Request Ratio ---- -------- --- --- --------------- ------------- ----------------------- Container cpu 100m 400m 150m 250m - Container memory 100Mi 1Gi 256Mi 800Mi -

      Um den LimitRanger arbeiten zu sehen, stellen Sie einen Standard-nginx-Container mit dem folgenden Befehl bereit:

      • kubectl run nginx --image=nginx --port=80 --restart=Never

      Dadurch erhalten Sie folgendes Output:

      Output

      pod/nginx created

      Überprüfen Sie, wie der Zugriffs-Controller den Container mutiert hat, indem Sie folgenden Befehl ausführen:

      • kubectl get pod nginx -o yaml

      Dadurch erhalten Sie viele Zeilen an Output. Im Abschnitt der Container-Spezifizierung finden Sie die im LimitRange angegebenen Ressourcenlimits:

      Output

      ... spec: containers: - image: nginx imagePullPolicy: IfNotPresent name: nginx ports: - containerPort: 80 protocol: TCP resources: limits: cpu: 250m memory: 800Mi requests: cpu: 150m memory: 256Mi ...

      Dies wäre genauso, wenn Sie die Angaben für resources und requests manuell in der Container-Spezifikation festlegen würden.

      In diesem Schritt haben Sie die Zugriffs-Controller ResourceQuota und LimitRange verwendet, um die Ressourcen Ihres Clusters vor schädlichen Angriffen zu schützen. Weitere Informationen über den Zugriffs-Controller LimitRange finden Sie in der offiziellen Dokumentation.

      Zusammenfassung

      In diesem Tutorial haben Sie eine grundlegende Kubernetes-Sicherheitsvorlage konfiguriert. Dadurch wurden die Benutzerauthentifizierung und -autorisierung, die Anwendungsberechtigungen und der Schutz der Cluster-Ressourcen bestimmt. Wenn Sie alle in diesem Tutorial behandelten Vorschläge kombinieren, haben Sie eine solide Grundlage für den Einsatz eines Kubernetes-Clusters in einer produktiven Umgebung. Nun können Sie beginnen, individuelle Aspekte Ihres Clusters je nach Ihrer Vorstellung zu härten.

      Wenn Sie mehr über Kubernetes erfahren möchten, besuchen Sie unsere Kubernetes-Ressourcenseite oder folgen Sie dem selbstgeführten Kurs Kubernetes für umfassende Entwickler.



      Source link