TOC

So sichern Sie Ihren CoreOS-Cluster mit TLS / SSL- und Firewall-Regeln

Einführung

Wenn Sie vorhaben, einen CoreOS-Cluster in einer Netzwerkumgebung außerhalb Ihrer Kontrolle auszuführen, z. B. in einem gemeinsam genutzten Datencenter oder über das öffentliche Internet, haben Sie möglicherweise festgestellt, dass die Kommunikation mit "+ etcd +" unverschlüsselt über HTTP-Anforderungen erfolgt. Es ist möglich, die Risiken dieses Verhaltens zu verringern, indem auf jedem Knoten im Cluster eine IPTables-Firewall konfiguriert wird. Eine vollständige Lösung würde jedoch idealerweise eine verschlüsselte Transportschicht verwenden.

Glücklicherweise unterstützt "+ etcd +" Peer-to-Peer-TLS / SSL-Verbindungen, sodass jedes Mitglied eines Clusters authentifiziert und die gesamte Kommunikation verschlüsselt wird. In diesem Handbuch stellen wir zunächst einen einfachen Cluster mit drei Mitgliedern bereit und konfigurieren dann HTTPS-Endpunkte und eine grundlegende Firewall auf jedem Computer.

Voraussetzungen

Dieses Handbuch baut in hohem Maße auf Konzepten auf, die unter https://www.digitalocean.com/community/tutorials/an-introduction-to-coreos-system-components (Einführung in CoreOS-Systemkomponenten) und https://www.digitalocean beschrieben werden. de / community / tutorials / wie-ein-coreos-cluster-on-digitalocean-eingerichtet wird [dieser Leitfaden zum Einrichten eines CoreOS-Clusters auf DigitalOcean].

Sie sollten mit den Grundlagen von "+ etcd" -, "+ fleetctl" - und "+ cloud-config" -Dateien vertraut sein und eine Erkennungs-URL generieren.

Zum Erstellen und Zugreifen auf die Computer in Ihrem Cluster benötigen Sie einen öffentlichen SSH-Schlüssel, der Ihrem DigitalOcean-Konto zugeordnet ist. Ausführliche Informationen zur Verwendung von SSH-Schlüsseln mit DigitalOcean finden Sie unter siehe hier.

Wenn Sie die DigitalOcean-API zum Erstellen Ihrer CoreOS-Maschinen verwenden möchten, lesen Sie https://www.digitalocean.com/community/tutorials/how-to-use-the-digitalocean-api-v2#how-to-generate- a-personal-access-token [dieses Tutorial] enthält Informationen zum Generieren und Verwenden eines persönlichen Zugriffstokens mit Schreibberechtigungen. Die Verwendung der API ist optional, kann jedoch auf lange Sicht Zeit sparen, insbesondere wenn Sie damit rechnen, größere Cluster zu erstellen.

Generieren Sie eine neue Erkennungs-URL

Rufen Sie eine neue Erkennungs-URL von discovery.etcd.io ab, indem Sie in Ihrem Browser https://discovery.etcd.io/new?size=3 aufrufen und die angezeigte URL kopieren, oder indem Sie "+ curl +" vom Terminal aus verwenden Ihre lokale Maschine:

curl -w "\n" "https://discovery.etcd.io/new?size=3"

Speichern Sie die zurückgegebene URL. Wir werden es in Kürze in unserer Cloud-Konfiguration verwenden.

Schreiben Sie eine Cloud-Config-Datei mit HTTPS-Konfiguration

Wir beginnen mit dem Schreiben einer "+ cloud-config". Das + cloud-config + wird bei der Initialisierung jedes Servers als * Benutzerdaten * bereitgestellt und definiert wichtige Konfigurationsdetails für den Cluster. Diese Datei wird lang sein, sollte aber nicht viel komplizierter sein als die Version in der https://www.digitalocean.com/community/tutorials/how-to-set-up-a-coreos-cluster-on- digitalocean [Cluster-Leitfaden]. Wir werden "+ fleet " ausdrücklich anweisen, HTTPS-Endpunkte zu verwenden, einen Dienst mit dem Namen " iptables-restore " für unsere Firewall zu aktivieren und Konfigurationsdateien zu schreiben, in denen angegeben ist, wo " etcd " und " fleet +" SSL-Zertifikate zu finden sind.

Öffnen Sie ein Terminal auf Ihrem lokalen Computer, vergewissern Sie sich, dass Sie sich in Ihrem Ausgangsverzeichnis befinden, und verwenden Sie "+ nano " (oder Ihren bevorzugten Texteditor), um " ~ / cloud-config.yml +" zu erstellen und zu öffnen:

cd ~
nano cloud-config.yml

Fügen Sie Folgendes ein und ändern Sie dann "+" im Abschnitt " etcd2 +" in die Erkennungs-URL, die Sie im letzten Abschnitt angegeben haben.

Sie können auch den Abschnitt "+ iptables-restore +" entfernen, wenn Sie keine Firewall aktivieren möchten.

Gehen Sie beim Einfügen vorsichtig mit Einrückungen um. Die + cloud-config + ist in YAML geschrieben, das für Leerzeichen empfindlich ist. Informationen zu bestimmten Zeilen finden Sie in den Kommentaren in der Datei. Anschließend werden einige wichtige Abschnitte ausführlicher behandelt.

~ / cloud-config.yml

#cloud-config

coreos:
 etcd2:
   # generate a new token for each unique cluster from https://discovery.etcd.io/new:
   discovery:
   # multi-region deployments, multi-cloud deployments, and Droplets without
   # private networking need to use $public_ipv4:
   advertise-client-urls: https://$private_ipv4:2379,https://$private_ipv4:4001
   initial-advertise-peer-urls: https://$private_ipv4:2380
   # listen on the official ports 2379, 2380 and one legacy port 4001:
   listen-client-urls: https://0.0.0.0:2379,https://0.0.0.0:4001
   listen-peer-urls: https://$private_ipv4:2380
 fleet:
   # fleet defaults to plain HTTP - explicitly tell it to use HTTPS on port 4001:
   etcd_servers: https://$private_ipv4:4001
   public-ip: $private_ipv4   # used for fleetctl ssh command
 units:
   - name: etcd2.service
     command: start
   - name: fleet.service
     command: start




write_files:
 # tell etcd2 and fleet where our certificates are going to live:
 - path: /run/systemd/system/etcd2.service.d/30-certificates.conf
   permissions: 0644
   content: |
     [Service]
     # client environment variables
     Environment=ETCD_CA_FILE=/home/core/ca.pem
     Environment=ETCD_CERT_FILE=/home/core/coreos.pem
     Environment=ETCD_KEY_FILE=/home/core/coreos-key.pem
     # peer environment variables
     Environment=ETCD_PEER_CA_FILE=/home/core/ca.pem
     Environment=ETCD_PEER_CERT_FILE=/home/core/coreos.pem
     Environment=ETCD_PEER_KEY_FILE=/home/core/coreos-key.pem
 - path: /run/systemd/system/fleet.service.d/30-certificates.conf
   permissions: 0644
   content: |
     [Service]
     # client auth certs
     Environment=FLEET_ETCD_CAFILE=/home/core/ca.pem
     Environment=FLEET_ETCD_CERTFILE=/home/core/coreos.pem
     Environment=FLEET_ETCD_KEYFILE=/home/core/coreos-key.pem

Optional können Sie Ihre Cloud-Konfiguration in the official CoreOS Cloud Config Validator einfügen und auf * Validate Cloud-Config * klicken.

Speichern Sie die Datei und beenden Sie sie. In + nano + können Sie dies mit * Ctrl-X * zum Beenden, * y * zum Bestätigen des Schreibens der Datei und * Enter * zum Bestätigen des zu speichernden Dateinamens bewerkstelligen.

Schauen wir uns eine Handvoll spezifischer Blöcke aus "+ cloud-init.yml " an. Erstens, die " Flotte +" Werte:

 fleet:
   # fleet defaults to plain HTTP - explicitly tell it to use HTTPS:
   etcd_servers: https://$private_ipv4:4001
   public-ip: $private_ipv4   # used for fleetctl ssh command

Beachten Sie, dass "+ etcd_servers " auf eine " https " - URL gesetzt ist. Für den normalen HTTP-Betrieb muss dieser Wert nicht festgelegt werden. Ohne explizite Konfiguration schlägt HTTPS jedoch fehl. (` $ private_ipv4 +` ist eine Variable, die vom CoreOS-Initialisierungsprozess verstanden wird und nicht geändert werden muss.)

Als nächstes kommen wir zum + write_files + Block. Die Werte werden in einen Dateisystempfad, eine Berechtigungsmaske und einen Inhalt unterteilt, der den gewünschten Inhalt einer Datei enthält. Hier geben wir an, dass "+ systemd " - Einheitendateien für die Dienste " etcd2 " und " fleet +" Umgebungsvariablen einrichten sollen, die auf die TLS / SSL-Zertifikate verweisen, die wir generieren:

write_files:
 # tell etcd2 and fleet where our certificates are going to live:
 - path: /run/systemd/system/etcd2.service.d/30-certificates.conf
   permissions: 0644
   content: |
     [Service]
     # client environment variables
     Environment=ETCD_CA_FILE=/home/core/ca.pem
     ...
 - path: /run/systemd/system/fleet.service.d/30-certificates.conf
   permissions: 0644
   content: |
     [Service]
     # client auth certs
     Environment=FLEET_ETCD_CAFILE=/home/core/ca.pem
     ...

Wir teilen den Diensten zwar mit, wo Zertifikatsdateien zu finden sind, können die Dateien jedoch noch nicht selbst bereitstellen. Dazu müssen wir die private IP-Adresse jedes CoreOS-Computers kennen, die erst verfügbar ist, nachdem die Computer erstellt wurden.

Bereitstellung von Tröpfchen

Nachdem wir eine "+ cloud-config.yml +" definiert haben, werden wir sie verwenden, um jedes Mitglied des Clusters bereitzustellen. Bei DigitalOcean gibt es zwei grundlegende Ansätze: Über das webbasierte Control Panel oder durch Aufrufen der DigitalOcean-API mithilfe von cURL über die Befehlszeile.

Verwenden der DigitalOcean-Systemsteuerung

Erstellen Sie drei neue CoreOS-Droplets in derselben Datencenter-Region. Stellen Sie sicher, dass Sie jedes Mal * Privates Netzwerk * ​​und * Benutzerdaten aktivieren * markieren.

  • * Coreos-1 *

  • * Coreos-2 *

  • * Coreos-3 *

Fügen Sie im Feld * Benutzerdaten * den Inhalt von "+ cloud-config.yml " von oben ein und vergewissern Sie sich, dass Sie Ihre Erkennungs-URL in das Feld " discovery +" oben in der Datei eingegeben haben.

Verwenden der DigitalOcean-API

Als alternative Methode, die das wiederholte Einfügen in Felder erspart, können wir ein kurzes Bash-Skript schreiben, das "+ curl " verwendet, um mit unserer " cloud-config " ein neues Droplet von der DigitalOcean-API anzufordern und es für jedes Droplet einmal aufzurufen . Öffne eine neue Datei mit dem Namen " makecoreos.sh " mit " nano +" (oder einem Texteditor deiner Wahl):

cd ~
nano makecoreos.sh

Fügen Sie das folgende Skript ein und speichern Sie es. Passen Sie dabei die Felder "+ region " und " size +" wie gewünscht für Ihren Cluster an Region oder größere Tröpfchen für reale Projekte):

~ / makecoreos.sh

#!/usr/bin/env bash

# A basic Droplet create request.
curl -X POST "https://api.digitalocean.com/v2/droplets" \
    -d'{"name":"'"$1"'","region":"","size":"","private_networking":true,"image":"coreos-stable","user_data":
"'"$(cat ~/cloud-config.yml)"'",
        "ssh_keys":[ "'$DO_SSH_KEY_FINGERPRINT'" ]}' \
    -H "Authorization: Bearer $TOKEN" \
    -H "Content-Type: application/json"

Stellen Sie nun die Umgebungsvariablen "+ $ DO_SSH_KEY_FINGERPRINT " und " $ TOKEN +" auf den Fingerabdruck eines SSH-Schlüssels ein, der Ihrem DigitalOcean-Konto bzw. Ihrem API Personal Access Token zugeordnet ist.

Informationen zum Abrufen eines persönlichen Zugriffstokens und zur Verwendung der API finden Sie unter https://www.digitalocean.com/community/tutorials/how-to- use-the-digitalocean-api-v2[this tutorial].

Um den Fingerabdruck eines Schlüssels zu finden, der Ihrem Konto zugeordnet ist, überprüfen Sie den Abschnitt * Security * Ihrer Kontoeinstellungen unter * SSH Keys *. Es wird die Form eines public key fingerprint haben, etwa `+43: 51: 43: a1: b5: fc: 8b: b7: 0a: 3a : a9: b1: 0f: 66: 73: a8 + `.

Wir verwenden hier "+ export ", damit untergeordnete Prozesse der Shell, wie " makecoreos.sh +", auf die Variablen zugreifen können. Beide müssen bei jeder Verwendung des Skripts in der aktuellen Shell festgelegt werden. Andernfalls schlägt der API-Aufruf fehl:

export DO_SSH_KEY_FINGERPRINT=""
export TOKEN=""

Sobald wir Umgebungsvariablen für die erforderlichen Anmeldeinformationen festgelegt haben, können wir das Skript ausführen, um jedes gewünschte Droplet zu erstellen. + makecoreos.sh + verwendet seinen ersten Parameter, um das Feld + name + in seinem API-Aufruf auszufüllen:

bash makecoreos.sh coreos-1
bash makecoreos.sh coreos-2
bash makecoreos.sh coreos-3

Sie sollten sehen, dass die JSON-Ausgabe jedes neue Droplet beschreibt, und alle drei sollten in der Liste der Droplets in der Systemsteuerung angezeigt werden. Es kann einige Sekunden dauern, bis der Startvorgang abgeschlossen ist.

Melden Sie sich bei coreos-1 an

Unabhängig davon, ob Sie die Systemsteuerung oder die API verwendet haben, sollten jetzt drei Droplets ausgeführt werden. Jetzt ist ein guter Zeitpunkt, um die öffentlichen und privaten IP-Adressen zu notieren, die verfügbar sind, indem Sie in der Systemsteuerung auf ein einzelnes Droplet und dann auf den Link * Einstellungen * klicken. Die private IP-Adresse jedes Droplets wird benötigt, um Zertifikate zu erstellen und eine Firewall zu konfigurieren.

Lassen Sie uns ein Tröpfchen testen. Stellen Sie sicher, dass Ihr SSH-Schlüssel Ihrem lokalen SSH-Agenten hinzugefügt wurde:

eval $(ssh-agent)
ssh-add

Suchen Sie die öffentliche IP-Adresse von * coreos-1 * in der DigitalOcean-Systemsteuerung und stellen Sie eine Verbindung mit aktivierter SSH-Agentenweiterleitung her:

ssh -A core@

Bei der ersten Anmeldung bei einem Mitglied des Clusters erhalten wir wahrscheinlich eine Fehlermeldung von + systemd +:

OutputCoreOS stable (766.5.0)
Failed Units: 1
 iptables-restore.service

Dies zeigt an, dass die Firewall noch nicht konfiguriert wurde. Im Moment ist es sicher, diese Nachricht zu ignorieren. (Wenn Sie die Firewall in Ihrer "+ cloud-config " nicht aktivieren, wird keine Fehlermeldung angezeigt. Sie können den " iptables-restore +" - Dienst später jederzeit aktivieren.)

Bevor wir uns um die Firewall kümmern, lassen Sie uns die "+ etcd2 +" - Instanzen auf jedem Mitglied des Clusters miteinander sprechen.

Verwenden Sie CFSSL, um selbstsignierte Zertifikate zu generieren

CFSSL ist ein von CloudFlare veröffentlichtes Toolkit für die Arbeit mit TLS / SSL-Zertifikaten. Zum Zeitpunkt des Schreibens ist es das von CoreOS-Betreuern gewählte Tool zum Generieren von selbstsignierten Zertifikaten, anstelle von OpenSSL und dem jetzt veralteten "+ etcd-ca +".

Installieren Sie CFSSL auf Ihrem lokalen Computer

Für die Installation von CFSSL ist eine funktionsfähige Go-Installation erforderlich. Siehe diese Anleitung zur Installation von Go.

Stellen Sie sicher, dass Ihr + $ GOPATH + richtig eingestellt und zu Ihrem + $ PATH + hinzugefügt ist, und installieren Sie dann mit + go get + die + cfssl + Befehle:

export GOPATH=~/gocode
export PATH=$PATH:$GOPATH/bin
go get -u github.com/cloudflare/cfssl/cmd/cfssl
go get -u github.com/cloudflare/cfssl/...

Alternativ können vorgefertigte Binärdateien von pkg.cfssl.org abgerufen werden. Stellen Sie zunächst sicher, dass "+ ~ / bin +" existiert und sich in Ihrem Pfad befindet:

mkdir -p ~/bin
export PATH=$PATH:~/bin

Verwenden Sie dann "+ curl ", um die neuesten Versionen von " cfssl " und " cfssljson +" für Ihre Plattform abzurufen:

curl -s -L -o ~/bin/cfssl https://pkg.cfssl.org/
curl -s -L -o ~/bin/cfssljson https://pkg.cfssl.org/

Stellen Sie sicher, dass die + cfssl + Binärdateien ausführbar sind:

chmod +x ~/bin/cfssl
chmod +x ~/bin/cfssljson

Generieren Sie eine Zertifizierungsstelle

Nachdem die Befehle "+ cfssl +" installiert wurden, können wir sie zum Generieren einer benutzerdefinierten Zertifizierungsstelle verwenden, mit der wir Zertifikate für jeden unserer CoreOS-Computer signieren. Beginnen wir damit, ein neues Verzeichnis zu erstellen und einzugeben, in dem diese Dateien gespeichert werden:

mkdir ~/coreos_certs
cd ~/coreos_certs

Erstellen und öffnen Sie nun "+ ca-config.json" in "+ nano +" (oder Ihrem bevorzugten Texteditor):

nano ca-config.json

Fügen Sie Folgendes ein und speichern Sie es. Dadurch wird festgelegt, wie "+ cfssl +" signiert:

~ / coreos_certs / ca-config.json

{
   "signing": {
       "default": {
           "expiry": "43800h"
       },
       "profiles": {
           "client-server": {
               "expiry": "43800h",
               "usages": [
                   "signing",
                   "key encipherment",
                   "server auth",
                   "client auth"
               ]
           }
       }
   }
}

Zu erwähnen sind hier das auf 43800 Stunden (oder 5 Jahre) festgelegte Ablaufdatum und das Client-Server-Profil, das sowohl die Verwendung von Serverauthentifizierung als auch Clientauthentifizierung umfasst. Beides benötigen wir für Peer-to-Peer-TLS.

Als nächstes erstellen und öffnen Sie + ca-csr.json.

nano ca-csr.json

Fügen Sie Folgendes ein, indem Sie "+ CN " und " names " wie gewünscht für Ihren Standort und Ihre Organisation anpassen. Es ist sicher, fiktive Werte für den Eintrag " hosts +" sowie Orts- und Organisationsnamen zu verwenden:

~ / coreos_certs / ca-csr.json

{
   "CN": "My Fake CA",
   "hosts": [
       "example.net",
       "www.example.net"
   ],
   "key": {
       "algo": "rsa",
       "size": 2048
   },
   "names": [
       {
           "C": "US",
           "L": "CO",
           "O": "My Company",
           "ST": "Lyons",
           "OU": "Some Org Unit"
       }
   ]
}

Generieren Sie mit "+ ca-csr.json" und "+ ca-config.json" die Zertifizierungsstelle:

cfssl gencert -initca ca-csr.json | cfssljson -bare ca -

Generieren und Signieren von Zertifikaten für CoreOS-Maschinen

Jetzt, da wir eine Zertifizierungsstelle haben, können wir Standardeinstellungen für einen CoreOS-Computer schreiben:

Erstelle und öffne + coreos-1.json:

nano coreos-1.json

Fügen Sie Folgendes ein und speichern Sie es, indem Sie es an die private IP-Adresse von * coreos-1 * anpassen (sichtbar in der DigitalOcean-Systemsteuerung, indem Sie auf ein einzelnes Droplet klicken):

~ / coreos_certs / coreos-1.json

{
   "CN": "",
   "hosts": [
       "",
       ".local",
       "127.0.0.1",
       ""
   ],
   "key": {
       "algo": "rsa",
       "size": 2048
   },
   "names": [
       {
           "C": "",
           "L": "",
           "ST": ""
       }
   ]
}

Die wichtigsten Teile sind "+ CN ", das Ihr Hostname sein sollte, und das " hosts +" - Array, das Folgendes enthalten muss:

  • Ihre lokalen Hostnamen

  • + 127.0.0.1 +

  • Die private IP-Adresse des CoreOS-Computers (nicht die öffentlich zugängliche IP-Adresse)

Diese werden dem resultierenden Zertifikat als * https: //en.wikipedia.org/wiki/SubjectAltName [subjectAltNames] * hinzugefügt. Für + etcd + Verbindungen (einschließlich zum lokalen Loopback-Gerät unter + 127.0.0.1 +) muss das Zertifikat über ein SAN verfügen, das mit dem Hostnamen der Verbindung übereinstimmt.

Bei Bedarf können Sie auch das Array "+ names +" ändern, um Ihren Standort wiederzugeben. Wieder ist es sicher, fiktive Werte für Ortsnamen zu verwenden.

Wiederholen Sie diesen Vorgang für jede verbleibende Maschine und erstellen Sie ein übereinstimmendes "+ coreos-2.json " und " coreos-3.json " mit den entsprechenden " hosts +" - Einträgen.

Generieren Sie nun für jede CoreOS-Maschine ein signiertes Zertifikat und laden Sie es auf die richtige Maschine hoch:

cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=client-server  | cfssljson -bare coreos
chmod 0644 coreos-key.pem
scp ca.pem coreos-key.pem coreos.pem core@:

Dadurch werden drei Dateien erstellt ("+ ca.pem ", " coreos-key.pem " und " coreos.pem "). Stellen Sie sicher, dass die Berechtigungen für die Schlüsseldatei korrekt sind, und kopieren Sie sie über " scp +" nach "*". Das Basisverzeichnis von core * auf * coreos-1 *.

Wiederholen Sie diesen Vorgang für alle verbleibenden Computer. Beachten Sie dabei, dass bei jedem Aufruf des Befehls die vorherigen Zertifikatsdateien überschrieben werden:

cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=client-server  | cfssljson -bare coreos
chmod 0644 coreos-key.pem
scp ca.pem coreos-key.pem coreos.pem core@:
cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=client-server coreos-3.json | cfssljson -bare coreos
chmod 0644 coreos-key.pem
scp ca.pem coreos-key.pem coreos.pem core@:

Überprüfen Sie die etcd2-Funktionalität auf Coreos-1

Wenn Zertifikate vorhanden sind, sollten wir in der Lage sein, + fleetctl + auf * coreos-1 * auszuführen. Melden Sie sich zunächst über SSH an:

ssh -A core@

Versuchen Sie als Nächstes, alle Maschinen im Cluster aufzulisten:

fleetctl list-machines

Sie sollten eine Kennung für jeden Computer sehen, die zusammen mit seiner privaten IP-Adresse aufgeführt ist:

OutputMACHINE     IP      METADATA
7cb57440... 10.132.130.187  -
d91381d4... 10.132.87.87    -
eeb8726f... 10.132.32.222   -

Wenn + fleetctl + auf unbestimmte Zeit hängt, muss der Cluster möglicherweise neu gestartet werden. Beenden Sie zu Ihrem lokalen Computer:

exit

Verwenden Sie SSH, um "+ reboot +" - Befehle an jeden CoreOS-Rechner zu senden:

ssh core@coreos-1_public_ip 'sudo reboot'
ssh core@coreos-2_public_ip 'sudo reboot'
ssh core@coreos-3_public_ip 'sudo reboot'

Warten Sie einen Moment, stellen Sie die Verbindung zu * coreos-1 * wieder her und versuchen Sie + fleetctl + erneut.

Konfigurieren Sie eine IPTables-Firewall für Cluster-Mitglieder

Wenn Zertifikate vorhanden sind, sollten andere Computer im lokalen Netzwerk nicht in der Lage sein, Ihren Cluster zu steuern oder Werte aus "+ etcd2 +" zu extrahieren. Trotzdem ist es eine gute Idee, die verfügbare Angriffsfläche nach Möglichkeit zu reduzieren. Um die Netzwerkbelastung zu begrenzen, können wir jedem Computer einige einfache Firewall-Regeln hinzufügen, die den meisten lokalen Netzwerkverkehr von anderen Quellen als Peers im Cluster blockieren.

Denken Sie daran, dass bei Aktivierung des Dienstes "+ iptables-restore " in " cloud-config " eine " systemd +" -Fehlermeldung angezeigt wird, wenn Sie sich zum ersten Mal bei einem CoreOS-Computer anmelden:

OutputCoreOS stable (766.5.0)
Failed Units: 1
 iptables-restore.service

Dies lässt uns wissen, dass, obwohl der Dienst aktiviert ist, "+ iptables-restore " nicht korrekt geladen werden konnte. Wir können dies mit ` systemctl +` diagnostizieren:

systemctl status -l iptables-restore
Output● iptables-restore.service - Restore iptables firewall rules
  Loaded: loaded (/usr/lib64/systemd/system/iptables-restore.service; enabled; vendor preset: disabled)
  Active: failed (Result: exit-code) since Wed 2015-11-25 00:01:24 UTC; 27min ago
 Process: 689 ExecStart=/sbin/iptables-restore /var/lib/iptables/rules-save (code=exited, status=1/FAILURE)
Main PID: 689 (code=exited, status=1/FAILURE)

Nov 25 00:01:24 coreos-2 systemd[1]: Starting Restore iptables firewall rules...
Nov 25 00:01:24 coreos-2 systemd[1]: iptables-restore.service: Main process exited, code=exited, status=1/FAILURE
Nov 25 00:01:24 coreos-2 systemd[1]: Failed to start Restore iptables firewall rules.

Nov 25 00:01:24 coreos-2 systemd[1]: iptables-restore.service: Unit entered failed state.
Nov 25 00:01:24 coreos-2 systemd[1]: iptables-restore.service: Failed with result 'exit-code'.

Hier gibt es viele Informationen, aber die nützlichste Zeile ist die, die "+ iptables-restore [689] " enthält. Dies ist der Name des Prozesses " systemd +", der versucht hat, zusammen mit seiner Prozess-ID ausgeführt zu werden. Hier finden wir häufig die tatsächliche Fehlerausgabe von fehlgeschlagenen Diensten.

Die Firewall konnte nicht wiederhergestellt werden, da wir "+ iptables-restore " in " cloud-config +" aktiviert haben, aber noch keine Datei mit den gewünschten Regeln bereitgestellt haben. Wir hätten dies tun können, bevor wir die Droplets erstellt haben, außer dass nicht bekannt ist, welche IP-Adressen einem Droplet vor seiner Erstellung zugewiesen werden. Jetzt, da wir jede private IP kennen, können wir einen Regelsatz schreiben.

Öffnen Sie eine neue Datei in Ihrem Editor, fügen Sie Folgendes ein und ersetzen Sie "", "" und "+" durch die private IP-Adresse jedes CoreOS-Computers. Möglicherweise müssen Sie auch den Abschnitt unter " Allen TCP / IP-Verkehr akzeptieren …​ +" anpassen, um die öffentlichen Dienste widerzuspiegeln, die Sie vom Cluster anbieten möchten, obwohl diese Version zu Demonstrationszwecken gut funktionieren sollte.

/ var / lib / iptables / rules-save

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]

# Accept all loopback (local) traffic:
-A INPUT -i lo -j ACCEPT

# Accept all traffic on the local network from other members of
# our CoreOS cluster:
-A INPUT -i eth1 -p tcp -s  -j ACCEPT
-A INPUT -i eth1 -p tcp -s  -j ACCEPT
-A INPUT -i eth1 -p tcp -s  -j ACCEPT

# Keep existing connections (like our SSH session) alive:
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

# Accept all TCP/IP traffic to SSH, HTTP, and HTTPS ports - this should
# be customized  for your application:




# Accept pings:
-A INPUT -p icmp -m icmp --icmp-type 0 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT
COMMIT

Kopieren Sie das Obige in Ihre Zwischenablage, melden Sie sich bei * coreos-1 * an und öffnen Sie + rules-save + unter https://www.digitalocean.com/community/tutorials/installing-and-using-the-vim-text -editor-on-a-Cloud-Server [Vim], der Standard-Texteditor unter CoreOS:

ssh -A core@
sudo vim /var/lib/iptables/rules-save

Geben Sie im Editor "+: Einfügen +" ein und drücken Sie die Eingabetaste, um sicherzustellen, dass die automatische Einrückung deaktiviert ist. Drücken Sie anschließend die Taste "i", um den Einfügemodus zu aktivieren und die Firewall-Regeln einzufügen. Drücken Sie * Esc *, um den Einfügemodus zu verlassen, und *: wq *, um die Datei zu schreiben und zu beenden.

Vergewissern Sie sich abschließend, dass die Datei über die entsprechenden Berechtigungen verfügt (Lesen und Schreiben für Benutzer, Nur-Lesen für Gruppe und Welt):

sudo chmod 0644 /var/lib/iptables/rules-save

Jetzt sollten wir bereit sein, den Dienst erneut zu versuchen:

sudo systemctl start iptables-restore

Bei Erfolg wird + systemctl + lautlos beendet. Der Status der Firewall kann auf zwei Arten überprüft werden. Erstens mit + systemctl status:

sudo systemctl status -l iptables-restore

Und zweitens, indem Sie die aktuellen "+ iptables +" - Regeln selbst auflisten:

sudo iptables -v -L

Wir verwenden die Option "+ -v +", um eine ausführliche Ausgabe zu erhalten, mit der wir wissen, für welche Schnittstelle eine bestimmte Regel gilt.

Wenn Sie sicher sind, dass die Firewall auf * coreos-1 * konfiguriert ist, melden Sie sich ab:

exit

Wiederholen Sie diesen Vorgang als nächstes, um "+ / var / lib / iptables / rules-save +" auf * coreos-2 * und * coreos-3 * zu installieren.

Fazit

In diesem Handbuch haben wir einen CoreOS-Basiscluster mit drei Mitgliedern definiert, die jeweils ein TLS / SSL-Zertifikat für die Authentifizierung und die Transportsicherheit erhalten. Außerdem haben wir eine Firewall verwendet, um Verbindungen von anderen Droplets im lokalen Rechenzentrumsnetzwerk zu blockieren. Dies trägt dazu bei, viele der grundlegenden Sicherheitsbedenken bei der Verwendung von CoreOS in einem gemeinsam genutzten Netzwerk abzumildern.

Von hier aus können Sie die Techniken in den übrigen Abschnitten von diese Serie zum Einstieg in CoreOS anwenden, um Dienste zu definieren und zu verwalten.

Related