Netzwerk

Themen

• Einleitung
• Technische Konzepte
• Relevante AWS Services
• Anwendung
  • Erstellen einer neuen VPC
  • Subnetze definieren
  • Internet Gateway erstellen
  • Routing-Tabelle konfigurieren
  • Security Groups einrichten
• Zusammenfassung und nächste Schritte

Einleitung

Seit Jahrzehnten kommunizieren IT-Systeme durch Netzwerke miteinander. Waren es zu Beginn ausschliesslich physikalische Geräte wie Switches oder Router, welche über physische Kabel miteinander verbunden wurden, so hat es im letzten Jahrzehnt einen klaren Trend zu Software-basierten Netzwerken gegeben. Heute gelten noch immer viele der damaligen Konzepte und Ideen, jedoch sind physische Netzwerk-Komponenten virtuellen Software-Lösungen gewichen. Software-basierte Komponenten lassen sich deutlich kostengünstiger “erzeugen” und betreiben und stellen somit für moderne Cloud-Architekturen ein wichtiges Grundelement dar.

Technische Konzepte

Ein zentraler Einstiegspunkt um IT-Netzwerke zu verstehen ist das OSI-Referenzmodell. Die verschiedenen Ebenen (Layers) des Modells beschreiben Netzwerke von den physischen Verbindungen über das tcp Protokoll bis hin zu https.

Ein bekanntes Verfahren ist es, Netzwerke in unterschiedliche Bereiche (Netzwerke) zu organisieren, um zusammengehörige IT-Komponenten in gleiche Netzwerke zu platzieren und unterschiedliche IT-Komponenten über verschiedene Netzwerk-Zonen voneinander zu trennen. Unternehmen verwenden diesen Ansatz, um zum Beispiel Proxy-Server oder Loadbalancer von Applikationsservern oder Datenbanken zu trennen. Jeder dieser Netzwerk-Bereiche verfügt über eine eigene Netzmaske oder CIDR-Range welcher definiert, wie viele Netzwerk-Komponenten innerhalb eines Netzwerk-Bereiches erzeugt werden können und anschliessend eine IP-Adresse erhalten. Zwischen den Netzwerken lässt sich anschliessend mittels Router definieren, wohin Netzwerk-Pakete zugestellt werden sollen. Möchten Unternehmen zusätzlichen noch den Netzwerkverkehr einschränken, so werden hierfür Netzwerk-Regeln (oder Firewall-Rules) definiert.

Ein Netzwerk-Bereich, oder auch Subnetz genannt, lässt sich als öffentliches (public) oder privates (private) Subnetz erstellen. Der grösste Unterschied zwischen diesen beiden Varianten ist, dass IT-Komponenten innerhalb eines öffentlichen Subnetzes mit Maschinen ausserhalb dem Unternehmensnetzwerk, also dem Internet kommunizieren können, wogegen Elemente in einem privaten Subnetz dies generell nicht können. Im oben erwähnten Fall des Load Balancers ist genau gewollt, dass dieser z.B. Anfragen von beliebigen Clients aus dem Internet entgegennehmen kann, wogegen direkter Zugriff aus dem Internet auf eine Datenbank mit sensitiven Informationen typischerweise vermieden werden soll.

Relevante AWS Services

Innerhalb eines AWS Accounts können mehrere Amazon Virtual Private Clouds (Amazon VPCs) erstellt werden. Private oder öffentliche Subnetze werden in einem AWS Account immer einem VPC zugeordnet und nutzen Teile der CIDR-Range der VPC, wodurch es möglich ist unterschiedlichste Netzwerk-Architekturen zu realisieren. Während ein AWS Account AWS Services in unterschiedlichen AWS Regionen nutzen kann, befindet sich eine VPC immer exakt in einer AWS Region. Die folgende Grafik zeigt die wichtigsten Services innerhalb einer VPC:

• Subnetze: AWS erlaubt die Erstellung von öffentlichen und privaten Subnetzen innerhalb einer VPC. Öffentliche Subnetze können mit dem Internet kommunizieren, da sie eine öffentliche IP oder eine elastische IP haben können. Private Subnetze hingegen können nicht direkt mit dem Internet kommunizieren. Jedoch können die Subnetze untereinander Informationen austauschen, wenn sie in der gleichen VPC sind.

• Network Access Control List (NACL): Hierbei handelt es sich um Regeln, welche den Zugriff auf Subnetze definieren. Eine Regel besteht primär aus einer Quelle, dem genutzten Protokoll und dem Port. Hierdurch wird beschrieben, welcher Netzwerkverkehr akzeptiert und welcher verboten ist. Ein NACL regelt nicht den Netzwerkverkehr innerhalb eines Subnetzes, sondern nur, ob der Netzwerkverkehr in und aus dem Subnetz erlaubt ist. Beide Richtungen, der Netzwerkverkehr zu und von dem Subnetz, müssen jeweils separat beschrieben werden. Standardmässig wird erstmal jeder Netzwerkverkehr erlaubt, der dann mit den Regeln genauer reguliert werden kann.

• Security Group: Neben NACLs sind Security Groups eine weitere Möglichkeit, um den Netzwerkverkehr zu steuern. Während NACLS den Zugriff auf Subnetz-Ebene regeln, erlauben Security Groups eine feinere Zugriffskontrolle. Der Zugriff auf einzelne Instanzen oder Gruppen von Instanzen innerhalb eines Subnetzes, wie eine EC2-Instanz oder eine RDS-Datenbank, lässt sich mit Security Groups kontrollieren. Neben der Möglichkeit den Zugriff auf bestimmte IP-Ranges inklusive Ports und Protokollen zu limitieren, ist es mit Security Groups ebenfalls möglich als Quelle eine andere Security Group zu hinterlegen. Dabei kann nur definiert werden, dass Ressourcen erlaubt wird Zugriff zu erhalten. Es können keine Regeln definiert werden, die den Zugriff verbieten. Wenn es keine Regel gibt, um den Zugriff zu gestattet, wird implizit angenommen, dass der Zugriff verboten ist. Über Security Groups kann z.B. festgelegt werden, dass Datenbank-Instanzen nur über interne Webserver aufgerufen werden, wie es in der Grafik oben zu sehen ist.

• Internet Gateway: Die Verbindung zum Internet in einer Amazon VPC kann mithilfe eines Internet Gateways realisiert werden. Ein oder mehrere öffentliche Subnetze der VPCs können per Internet Gateway Verbindungen mit dem Internet herstellen.

Damit festgelegt werden kann, welche Pfade Netzwerkpakete nutzen sollen, werden Route Tables definiert. Innerhalb jeder VPC gibt es eine Default Route Table, welche immer dann verwendet wird, wenn keine andere Route Table erstellt und dem VPC oder einem der Subnetze zugeordnet wird. Die Einträge in einer Route Table bestehen aus den Spalten Destination und Target. Mittels der Destination wird der gewünschte CIDR-Bereich beschrieben, welcher wiederum zur Target-IP des Netzwerkpakets passen muss. Das Target legt fest, zu welchem Endpunkt / Netzwerk das Paket geroutet werden soll. Typische Werte können hier local oder die ID des Internet Gateways sein, falls das Netzwerkpaket ins Internet geroutet werden soll.

Um Instanzen in einem privaten Subnetz die Kommunikation zum Internet zu ermöglichen, kann man ein NAT Gateway dafür nutzen. Ein NAT-Gateway ist ein Network Address Translation Service. Der Vorteil dabei ist, dass externe Services jedoch keine Verbindung mit den Instanzen im privaten Subnetz herstellen können. Das NAT-Gateway wird im öffentlichen Subnetz erstellt. Wenn es genutzt wird, dann ersetzt es die Quellen-IP der Instanzen im privaten Subnetz durch seine eigene IP-Adresse, sodass die Quellen-IP der Instanzen privat bleibt. Damit vom privaten Netz zum NAT-Gateway geroutet werden kann, braucht es eine entsprechende Route in der Route Table.

Anwendung

Der gesamte praktische Teil dieses Moduls wird in der Region us-east-1 durchgeführt und sollte auch nicht während der Durchführung geändert werden.

Erstellen einer neuen VPC

Aufgabe: Erstelle eine eigene VPC ohne Subnetze mit dem Adressbereich 172.100.0.0/16 und nutze als Tag Name:Workshop-VPC. Eine VPC ist immer an eine AWS Region gebunden.

Subnetze definieren

Nach dem VPC selbst können individuelle Subnetze angelegt werden. Wie besprochen benötigst du öffentlichen Subnetze, in denen später die Frontend- und Backend-Container platziert werden, da diese vom Internet zugänglich sein sollen. Die Datenbank soll nicht direkt vom Internet zugänglich sein, deshalb wirst du zusätzlich private Subnetze erstellen.

Aufgabe: Lege ein neues Subnetz Workshop-PublicA in deiner gerade erstellten VPC in der Availability Zone US East (N. Virginia / us-east-1a) an. Das Subnetz sollte den CIDR-Block 172.100.1.0/24 nutzen.

Aufgabe: Lege ein weiteres Subnetz Workshop-PublicB in deiner gerade erstellten VPC in der Availability Zone US East (N. Virginia / us-east-1b) an. Das Subnetz sollte den CIDR-Block 172.100.2.0/24 nutzen.

Aufgabe: Lege ein weiteres Subnetz Workshop-PrivateA in deiner gerade erstellten VPC in der Availability Zone US East (N. Virginia / us-east-1a) an. Das Subnetz sollte den CIDR-Block 172.100.3.0/24 nutzen.

Aufgabe: Lege ein weiteres Subnetz Workshop-PrivateB in deiner gerade erstellten VPC in der Availability Zone US East (N. Virginia / us-east-1b) an. Das Subnetz sollte den CIDR-Block 172.100.4.0/24 nutzen.

Wenn in der Übersicht unter Subnets ein gerade erstelltes Subnetz per Checkbox ausgewählt wird, können die Details angezeigt werden (z.B. Subnetz ID, VPC, AZ, Route tables etc.)

Internet Gateway erstellen

Um eine Kommunikation zum Internet zu ermöglichen und um Ressourcen aus dem Internet zugänglich zu machen, muss ein Internet Gateway (IGW) erstellt werden:

Aufgabe: Erstelle nun ein Internet Gateway mit dem Namen Workshop-IGW. Das neue Internet Gateway ist im Zustand detached. Um das zu ändern, musst du es mit deiner VPC Workshop-VPC verbinden.

Routing-Tabelle konfigurieren

Eine Routing-Tabelle enthält eine Reihe von Regeln (Routes), die festlegen, wohin der Netzwerkverkehr aus einem VPC weitergeleitet wird. Pro Route wird der Ziel-IP Adressbereich sowie das Gateway oder die Netzwerkschnittstelle angegeben, an die der Netzwerkverkehr geschickt wird. Dabei kann eine Routing-Tabelle einem Subnetz explizit zugeordnet werden. Andernfalls wird das Subnetz implizit der Default Routing-Tabelle des VPCs zugeordnet, die bei der Erstellung des VPCs automatisch erzeugt wird.

Es ist eine Good Practice, eine neue Routing-Tabelle mit den entsprechenden Regeln zu erstellen.

1. Unter Services den Dienst VPC auswählen.
2. Links unter Virtual private cloud auf Route tables klicken. Bereits bestehende Routing-Tabellen werden in der Übersicht angezeigt.
3. Klick auf Create route table um eine neue Routing-Tabelle zu erstellen.
4. Unter Name - optional Workshop-Public eingeben.
5. Unter VPC im Dropdown das Workshop-VPC auswählen.
6. Klick auf Create route table.

Zuweisung der Subnetze

Aufgabe: Weise nun die beiden Subnetze Workshop-PublicA und Workshop-PublicB der gerade erstellten Routing-Tabelle zu.

Definition der Route Einträge

Nun muss die Regel (Route) angelegt werden, damit der ein- und ausgehende Netzwerkverkehr über das Internet Gateway geschickt wird.

Aufgabe: Lege nun eine Regel (Route) an mit der Destination 0.0.0.0/0 (das Internet) und mit dem Ziel (target) Internet Gateway Workshop-IGW.

Die Routing-Tabelle enthält nun zwei Regeln. Damit ist die Konfiguration des Routings abgeschlossen.

Security Groups einrichten

Eine Sicherheitsgruppe dient als virtuelle Firewall für Ressourcen und somit der Steuerung von ein- und ausgehendem Datenverkehr. Sicherheitsgruppen wirken auf der Instanz-Ebene und nicht auf der Subnetzebene. Daher kann jede Instanz in einem Subnetz eines VPCs einer anderen Reihe von Sicherheitsgruppen zugeordnet werden. Im letzten Schritt müssen also die Firewall Regeln (Security Groups) konfiguriert werden, damit Ressourcen später auch tatsächlich erreicht werden können. Für die Beispielanwendung werden drei Security Groups benötigt. Eine Security Group regelt den Zugriff aus dem Internet auf den Load Balancer. Die zweite Security Group regelt den Zugriff vom Load Balancer auf die Container Instanzen und die Dritte den Zugriff von Container Instanzen auf die Datenbank.

Zugriff aus dem Internet

Anbei die Konfiguration für die erste Security Group für den Zugriff aus dem Internet:

1. Unter Services den Dienst VPC auswählen.
2. Links unter Security auf Security groups klicken. Bereits bestehende Security Groups werden in der Übersicht angezeigt.
3. Auf den Button Create security group klicken.
4. Unter Security group name und Description Workshop-ALB-SG eingeben. ALB steht hier für Application Load Balancer.
5. Im Dropdown unter VPC das Workshop-VPC auswählen.
6. Im Abschnitt Inbound rules auf Add rule klicken.
7. Als Type das Protokoll HTTP auswählen.
8. Unter Source den Eintrag Anywhere-IPv4 auswählen.
9. Im Feld Description Allow HTTP from anywhere eintragen. Eure Eingabemaske sollte anschliessend wie folgt aussehen.
10. Mit dem Klick auf Create security group die Erstellung abschliessen.
11. In der Übersicht können die Einstellungen nochmals überprüft werden.

Zugriff auf den Backend Container

Der Zugriff auf den Backend Container vom Load Balancer kann durch eine zweite Security Group erteilt werden.

Aufgabe: Erstelle eine neue Security Group Workshop-ECS-Backend-SG für deine VPC Workshop-VPC. Füge eine Inboud rule hinzu, die Zugriff durch das Protokoll Custom TCP auf den Port 5000 erlaubt. Als Quelle soll die Security Group des Load Balancers Workshop-ALB-SG genutzt werden.

Zugriff auf die Datenbank

Der Zugriff der Backend Container Instanzen auf die Datenbank kann durch eine dritte Security Group erteilt werden.

Aufgabe: Erstelle eine neue Security Group Workshop-RDS-SG für deine VPC Workshop-VPC. Füge eine Inboud rule hinzu, die Zugriff durch das Protokoll MYSQL/Aurora erlaubt. Als Quelle soll die Security Group des Backend Containers Workshop-ECS-Backend-SG genutzt werden.

Zugriff auf den Frontend Container

Aufgabe: Um Zugriff auf den Frontend Container zu erhalten, wird eine weitere Security Group für den Zugriff vom Load Balancer auf die Container Instanzen benötigt. Erstelle eine Security Group mit dem Namen Workshop-ECS-Frontend-SG. Nutze den Port 8080 und als Source dient die Security Group Workshop-ALB-SG, um die Sicherheit zu erhöhen.

Zugriff auf einen einzelnen Container

Im Kapitel zu 5.Container Plattform wirst du einen einzelnen Container ausführen, um zusehen wie das funktioniert. Da dieser seperat ausgeführt wird und auch nicht mit dem Load Balancer verbunden sein wird, braucht es noch eine andere Security Gruppe.

1. Links unter Security auf Security Groups klicken. Bereits bestehende Security Groups werden in der Übersicht angezeigt.
2. Klick auf Create security group.
3. Unter Security group name und Description Workshop-ECS-Task-SG eingeben.
4. Im Dropdown unter VPC das Workshop-VPC auswählen.
5. Im Abschnitt Inbound rules auf Add rule klicken.
6. Als Type das Custom TCP auswählen und Port Range 8080 eingeben.
7. Unter Source im Suchfenster nun 0.0.0.0/0 auswählen. Damit ist der Container aus dem Internet erreichbar, sodass du ihn direkt ansprechen kann.
8. Im Feld Description Allow HTTP for ECS task eintragen.
9. Mit dem Klick auf Create security group die Erstellung abschliessen.
10. In der Übersicht können die Einstellungen nochmals überprüft werden.

Zusammenfassung und nächste Schritte

Herzlichen Glückwunsch! Du hast alle Netzwerkressourcen so konfiguriert, damit die Komponenten der ToDo-Applikation sicher kommunizieren können. Dafür hast du die Security Groups und die benötigte Routing-Tabelle konfiguriert. Im nächsten Schritt wird die Datenbank erstellt, die später die ToDos zentral speichern wird.