asanger.dev

In /etc/rc.local

echo 0 > /sys/class/leds/green:power/brightnessecho 0 > /sys/class/leds/green:wan/brightness
echo 0 > /sys/class/leds/red:wlan/brightness

git fetch --all

Install GitLens extension in vscode

git rebase -i origin/main

git push –force-with-lease

Nur ein commit:

Visual Studio
git rebase -i origin/main
Alterster Commit: pick
Alle anderen: fixup

Dann: git push –force-with-lease

  • VNets
    • Virtual Networks sind separiert von anderen virtual Networks und können als physical Networks gesehen werden.
    • Ressources (VMs, DBs,…) können per default im eigenen VNet communizieren aber nicht in anderen VNets
    • VNets sind kostenfrei, aber limitiert bis 50 über alle Regions
    • VNets sind nicht Region übergreifend.
    • VNets können via „Peering“ verbunden werden
    • VNets sind in Subnetze unterteilt (CIDR Notation) max. 65.536 IP Adressen
    • VNets sind mit NSG geschützt, die aber den Subnets zugeordnet sind.
    • z.B.: 10.0.0.0/16 = 10.0.0.0 – 10.0.255.255 (65.536 addresses)
    • Die Azure Firewall kann einem VNet zugewiesen werden (https://learn.microsoft.com/de-de/azure/firewall/overview).
    • Always minimize the Access to the Ressources in a VNet
  • SubNets
    • logisches Segment in einem VNet
    • bekommt einen IP Bereich aus dem VNet
    • Ressourcen werden in einem Subnet deplyed und nicht direkt im VNet
    • Subnetze im selben VNet können untereinander kommunizieren
    • Subnetze sind kostenfrei, es gibt ein Limit von 3000
    • z.B. : 10.0.0.0 – 10.0.0.255 (/24) (256 addresses)
    • Front und Backend Services können in verschiedene Subnetze deployed werden
  • Load Balancer
  • Application Gateway
  • Network Security Group (NSG)
    • Filter Regeln (Security Rule) nach SourceIP, SourcePort, DestinationIP, DestinationPort, Protokoll
  • Network Peering
    • Verbindet zwei VNets
    • NSG können angewand werden
    • Traffic wird berechnet mit 1ct pro GB (jeweils inbound und outbound)

1. Verschiedene Subnetze im selben VNET

Dies ist die häufigste und empfohlene Praxis in vielen Umgebungen. Die Idee ist, Frontend und Backend in getrennten Subnetzen innerhalb desselben Virtual Network zu platzieren.

Vorteile:

  • Segmentierung und Sicherheit: Frontend- und Backend-Services können getrennt werden, und Firewall-Regeln oder NSGs (Network Security Groups) können implementiert werden, um den Zugriff nur auf das Nötigste zu beschränken. Beispielsweise könnte das Backend-Subnetz nur Anfragen vom Frontend akzeptieren und keine direkte Verbindung zum Internet haben.
  • Leichtes Routing: Da sich beide Subnetze im selben VNET befinden, ist das Routing zwischen ihnen einfach und performant. Es ist keine zusätzliche Konfiguration für die Kommunikation zwischen den Services nötig.
  • Sicherheit auf Layer-3 (Netzwerk): Durch die Trennung in Subnetze können Zugriffskontrollen feiner granuliert werden. Regeln können beispielsweise sicherstellen, dass das Frontend auf das Backend zugreifen kann, aber nicht umgekehrt.
  • Kosteneffizienz: Da alles im selben VNET bleibt, gibt es keine zusätzlichen Kosten oder Komplexität für die Verbindung von verschiedenen VNETs (z.B. Peering oder Gateways).

Wann sinnvoll?:

  • Wenn beide Services regelmäßig miteinander kommunizieren müssen (z.B. API-Aufrufe des Frontends an das Backend).
  • Wenn Sicherheit durch Netzwerksicherheit (Subnetz, Firewalls, NSGs) erreicht werden soll.
  • Wenn die Verwaltung einfach bleiben soll und der Overhead einer separaten Netzwerkverwaltung vermieden werden soll.

2. Verschiedene VNETs für Frontend und Backend

In einigen Szenarien kann es sinnvoll sein, Frontend und Backend in verschiedenen Virtual Networks zu deployen. Dies bietet zusätzliche Isolation, kommt aber auch mit mehr Komplexität.

Vorteile:

  • Stärkere Isolation: Durch die Verwendung von separaten VNETs können Sie eine noch stärkere Trennung zwischen Frontend und Backend erreichen. Dies ist besonders nützlich, wenn es notwendig ist, die Umgebung stark voneinander zu isolieren (z.B. aus regulatorischen oder Compliance-Gründen).
  • Erweiterte Sicherheitskontrollen: Separate VNETs ermöglichen eine noch granularere Kontrolle über die Netzwerkkommunikation. Sie können striktere VNET-Peering-Regeln festlegen oder Gateways zur Kommunikation zwischen VNETs verwenden.
  • Multi-Cloud oder Multi-Regionen: Wenn Ihr Frontend in einer anderen Cloud oder einer anderen Region läuft, ist ein separates VNET möglicherweise erforderlich. Das Backend könnte in einer anderen Cloud-Umgebung liegen, um Daten geografisch oder aus Compliance-Gründen zu trennen.

Nachteile:

  • Komplexität: Die Verwaltung mehrerer VNETs bringt zusätzliche Komplexität. Sie müssen VNET-Peering oder andere Netzwerktechnologien konfigurieren, um sicherzustellen, dass die beiden Netzwerke miteinander kommunizieren können.
  • Kosten: VNET-Peering oder die Verwendung von Gateways (z.B. VPN oder ExpressRoute) zwischen VNETs kann zusätzliche Kosten verursachen.
  • Leistungsüberlegungen: Die Latenz kann zunehmen, wenn die Kommunikation zwischen zwei verschiedenen VNETs über ein Gateway oder andere Netzwerkmechanismen erfolgt.

Wann sinnvoll?:

  • Wenn Sie eine besonders starke Trennung zwischen Frontend und Backend benötigen (z.B. um strenge Sicherheitsvorgaben zu erfüllen).
  • Wenn Ihre Frontend- und Backend-Services in unterschiedlichen Regionen oder Cloud-Providern betrieben werden.
  • Wenn Sie eine hoch skalierbare Multi-Tenant-Architektur haben, bei der jeder Teil einer Anwendung in einer eigenen isolierten Umgebung liegt.

Zusammenfassung:

  • Verschiedene Subnetze innerhalb desselben VNET:
    • Die bevorzugte Lösung für die meisten Anwendungsfälle.
    • Einfaches Routing, hohe Effizienz und ausreichende Sicherheit.
    • Ideal, wenn Frontend und Backend regelmäßig miteinander kommunizieren müssen.
  • Verschiedene VNETs:
    • Mehr Isolation und Sicherheit, aber komplexer und kostspieliger.
    • Sinnvoll, wenn besonders hohe Sicherheitsanforderungen bestehen oder wenn die Systeme stark voneinander getrennt sein müssen (z.B. aus Compliance-Gründen oder in Multi-Region-Szenarien).

In den meisten Fällen ist es effizienter und einfacher, Frontend- und Backend-Services in getrennte Subnetze innerhalb desselben VNET zu deployen. Separate VNETs sind eher in speziellen Szenarien mit besonderen Anforderungen erforderlich.

Journalbeat installieren

sudo apt install journalbeat

Journalbeat konfigurieren (vi /etc/journalbeat/journalbeat.yml)

logging.level: info
logging.to_files: true
logging.files:
        path: /var/log/journalbeat
        name: journalbeat
        keepfiles: 7
        permissions: 0644
journalbeat.inputs:
- paths: []
  seek: head
output.logstash:
  # Boolean flag to enable or disable the output module.
  enabled: true
  ssl.enabled: false  
  # Graylog host and the beats input
  hosts: ["127.0.0.1:5044"]

Beat input in Graylog konfigurieren

Journalbeat starten

systemctl start journalbeat
systemctl enable journalbeat
systemctl status journalbeat

Schritt 1: Inputs einrichten (Logquellen definieren)

Zunächst musst du einen Input einrichten, der die Logs verarbeitet. Für Demo-Zwecke könntest du z.B. Syslog verwenden, um Logs von deinem eigenen Server oder einem anderen Gerät zu sammeln.

  1. Gehe in der Graylog-Oberfläche auf SystemInputs.
  2. Wähle unter Select input den Syslog UDP-Input (oder einen anderen Input) aus und klicke auf Launch new input.
  3. Gib deinem Input einen Namen (z.B. „Syslog UDP“) und wähle den Node (normalerweise deinen lokalen Graylog-Server).
  4. Stelle sicher, dass der Port korrekt ist (normalerweise 514 für Syslog).
  5. Klicke auf Save.

Jetzt ist dein Graylog-System bereit, Logs über den konfigurierten Input zu empfangen.

Schritt 2: Testdaten generieren

Um Testdaten zu simulieren, kannst du einige Syslog-Nachrichten direkt auf deinem Server erzeugen, wo Graylog läuft, oder Daten von anderen Servern an den Syslog-Input senden.

Beispiel: Syslog-Daten lokal senden

Auf deinem Linux-Server kannst du Syslog-Nachrichten über logger generieren. Öffne ein Terminal und sende einige Nachrichten:

logger -n 127.0.0.1 -P 514 "Test log message from local system"

Dies sendet eine Test-Syslog-Nachricht an deinen Graylog-Server, der auf localhost (127.0.0.1) auf Port 514 lauscht.

Beispiel: Weitere Testdaten erzeugen

Du kannst ein Skript verwenden, um kontinuierlich Log-Nachrichten zu senden und zu testen, wie Graylog mit größeren Datenmengen umgeht. Hier ein Beispiel für ein Bash-Skript:

#!/bin/bash
for i in {1..100}
do
  logger -n 127.0.0.1 -P 514 "Test log message number $i"
  sleep 1
done

Das Skript sendet 100 Nachrichten mit einer Sekunde Verzögerung. Dies hilft dir, zu sehen, wie Graylog die Logs in Echtzeit verarbeitet.

Schritt 3: Logs in Graylog durchsuchen

Nachdem du einige Logs erzeugt hast, kannst du sie in Graylog durchsuchen:

  1. Gehe in der Graylog-Oberfläche auf Search.
  2. Wähle den gewünschten Zeitraum (z.B. „Last 5 minutes“) und klicke auf Search.
  3. Du solltest die gesendeten Logs in der Liste sehen. Du kannst die Logs durch Filter und Suchabfragen weiter eingrenzen.

Schritt 4: Dashboards erstellen

Um die Logs besser zu visualisieren, kannst du ein Dashboard in Graylog erstellen.

  1. Gehe auf DashboardsCreate new dashboard.
  2. Gib dem Dashboard einen Namen und klicke auf Create.
  3. Füge Widgets hinzu, um verschiedene Aspekte deiner Logs zu visualisieren (z.B. Log-Level, Häufigkeit bestimmter Ereignisse usw.).

Mit diesen Schritten hast du eine grundlegende Testumgebung mit Demo-Daten in Graylog eingerichtet. Du kannst jetzt die Logs analysieren, Dashboards erstellen und die Funktionen der Plattform erkunden.

Schritt 1: System aktualisieren

Zuerst sollten wir sicherstellen, dass das System auf dem neuesten Stand ist.

sudo apt update && sudo apt upgrade -y

Schritt 2: Installiere Java (OpenJDK 11)

Graylog erfordert Java, das du mit folgendem Befehl installieren kannst:

sudo apt install openjdk-11-jre-headless -y

Stelle sicher, dass Java korrekt installiert wurde:

java -version

Schritt 3: Installiere MongoDB

Graylog benötigt MongoDB als Datenbank.

  1. MongoDB-Repository hinzufügen:
wget -qO - https://www.mongodb.org/static/pgp/server-4.4.asc | sudo apt-key add -
echo "deb [ arch=amd64 ] https://repo.mongodb.org/apt/ubuntu focal/mongodb-org/4.4 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-4.4.list
sudo apt update
  1. MongoDB installieren:
sudo apt install -y mongodb-org
  1. MongoDB starten und beim Boot aktivieren:
sudo systemctl start mongod
sudo systemctl enable mongod

Schritt 4: Installiere Elasticsearch

Graylog verwendet Elasticsearch zur Indizierung und Speicherung von Log-Daten.

  1. Elasticsearch-Repository hinzufügen:
wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add -
echo "deb https://artifacts.elastic.co/packages/7.x/apt stable main" | sudo tee /etc/apt/sources.list.d/elastic-7.x.list
sudo apt update
  1. Elasticsearch installieren:
sudo apt install elasticsearch -y
  1. Elasticsearch konfigurieren: Öffne die Konfigurationsdatei und aktiviere die Netzwerkschnittstelle, falls du Elasticsearch nicht nur lokal verwenden möchtest:
sudo vi /etc/elasticsearch/elasticsearch.yml

Entferne die Kommentare vor network.host und cluster.name, und passe sie an:

cluster.name: graylog
network.host: 127.0.0.1
  1. Elasticsearch starten und beim Boot aktivieren:
sudo systemctl start elasticsearch
sudo systemctl enable elasticsearch

Schritt 5: Installiere Graylog

Jetzt kannst du Graylog installieren.

  1. Graylog-Repository hinzufügen:
wget https://packages.graylog2.org/repo/packages/graylog-4.3-repository_latest.deb
sudo dpkg -i graylog-4.3-repository_latest.deb
sudo apt update
  1. Graylog installieren:
sudo apt install graylog-server -y

Schritt 6: Graylog konfigurieren

  1. Öffne die Konfigurationsdatei von Graylog:
sudo vi /etc/graylog/server/server.conf
  1. Setze das password_secret (generiere ein sicheres Passwort):
pwgen -N 1 -s 96




Füge den generierten Wert in die Datei server.conf unter password_secret ein.

  1. Setze das root_password_sha2 (Admin-Passwort für das Graylog-Interface):
echo -n 'deinPasswort' | sha256sum

Füge den generierten SHA256-Hash in die Datei unter root_password_sha2 ein.

  1. Stelle sicher, dass http_bind_address auf 0.0.0.0:9000 gesetzt ist, damit du auf die Web-Oberfläche zugreifen kannst:
http_bind_address = 0.0.0.0:9000

Schritt 7: Graylog starten

Jetzt kannst du Graylog starten und den Dienst aktivieren:

sudo systemctl start graylog-server
sudo systemctl enable graylog-server

Schritt 8: Zugriff auf die Graylog-Weboberfläche

Öffne deinen Webbrowser und navigiere zu:

http://<Deine-IP-Adresse>:9000

Melde dich mit dem Benutzernamen admin und dem Passwort an, das du zuvor unter root_password_sha2 gesetzt hast.

kubectl create secret generic azure-secrets --from-env-file <(jq -r "to_entries|map(\"\(.key)=\(.value|tostring)\")|.[]" azure-credentials.json)

Operator mit Helm installieren

helm repo add external-secrets https://charts.external-secrets.io
helm install external-secrets external-secrets/external-secrets

Erstellung eines Azure Service Principals

provider "azurerm" {
  features {}
}

provider "kubernetes" {
  config_path = "~/.kube/config"
}

provider "azuread" {
  tenant_id = data.azurerm_client_config.current.tenant_id
}

data "azurerm_client_config" "current" {}

resource "azuread_application" "eso_app" {
  display_name = "external-secrets-operator"
}

resource "azuread_service_principal" "eso_sp" {
  application_id = azuread_application.eso_app.application_id
}

resource "azuread_service_principal_password" "eso_sp_password" {
  service_principal_id = azuread_service_principal.eso_sp.id
  value                = random_password.sp_password.result
  end_date             = "2099-01-01T00:00:00Z"
}

resource "random_password" "sp_password" {
  length  = 32
  special = true
}

resource "azurerm_role_assignment" "kv_role_assignment" {
  principal_id   = azuread_service_principal.eso_sp.id
  role_definition_name = "Key Vault Secrets User"
  scope          = azurerm_key_vault.example.id
}

# Optional: Erstelle ein JSON-Dokument im Azure SDK-Format (wie azure-credentials.json)
locals {
  azure_credentials = jsonencode({
    clientId     = azuread_service_principal.eso_sp.application_id
    clientSecret = azuread_service_principal_password.eso_sp_password.value
    tenantId     = data.azurerm_client_config.current.tenant_id
    subscriptionId = data.azurerm_client_config.current.subscription_id
    activeDirectoryEndpointUrl = "https://login.microsoftonline.com"
    resourceManagerEndpointUrl = "https://management.azure.com/"
    activeDirectoryGraphResourceId = "https://graph.windows.net/"
    sqlManagementEndpointUrl = "https://management.core.windows.net:8443/"
    galleryEndpointUrl = "https://gallery.azure.com/"
    managementEndpointUrl = "https://management.core.windows.net/"
  })
}

# Kubernetes Secret für Service Principal erstellen
resource "kubernetes_secret" "azure_secrets" {
  metadata {
    name      = "azure-secrets"
    namespace = "default"
  }

  data = {
    "azure-credentials.json" = base64encode(local.azure_credentials)
  }
}

Erklärung der Ressourcen:

  • azuread_application: Erstellt die Azure AD Anwendung, die den Service Principal repräsentiert.
  • azuread_service_principal: Erstellt den Service Principal für die Anwendung.
  • azuread_service_principal_password: Erstellt ein Kennwort (Client Secret) für den Service Principal.
  • azurerm_role_assignment: Weist dem Service Principal die Rolle Key Vault Secrets User für den Zugriff auf den Key Vault zu.
  • kubernetes_secret: Erstellt ein Kubernetes Secret, das die Azure-Anmeldeinformationen im azure-credentials.json-Format speichert. Das JSON wird mithilfe der local-Variable generiert.

Oder per CLI:

$ az ad sp create-for-rbac --name "external-secrets-operator" --sdk-auth > azure-credentials.json

$ kubectl create secret generic azure-secrets --from-env-file <(jq -r "to_entries|map(\"\(.key)=\(.value|tostring)\")|.[]" azure-credentials.json)

Secretstore anlegen

apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
  name: example-secret-store
spec:
  provider:
    azurekv:
      tenantId: "xxxxx-xxx-xxxx-xxxx-xxxxxxx"
      vaultUrl: "https://xxxxx.vault.azure.net"
      authSecretRef:
        clientId:
          name: azure-secrets
          key: clientId
        clientSecret:
          name: azure-secrets
          key: clientSecret

Externalsecret anlegen

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: example-external-secret
spec:
  refreshInterval: 1h
  secretStoreRef:
    kind: SecretStore
    name: example-secret-store

  target:
    name: secret-to-be-created
    creationPolicy: Owner

  data:
  - secretKey: secret-key
    remoteRef:
      key: secret-key

Optional: Repo hinzufügen

helm repo add argo https://argoproj.github.io/argo-helm
helm repo update

Repo nach vorhandenen Charts durchsuchen:

helm search repo argo
NAME                            CHART VERSION   APP VERSION     DESCRIPTION                                       
argo/argo                       1.0.0           v2.12.5         A Helm chart for Argo Workflows                   
argo/argo-cd                    7.6.6           v2.12.4         A Helm chart for Argo CD, a declarative, GitOps...
argo/argo-ci                    1.0.0           v1.0.0-alpha2   A Helm chart for Argo-CI                          
argo/argo-events                2.4.8           v1.9.2          A Helm chart for Argo Events, the event-driven ...
argo/argo-lite                  0.1.0                           Lighweight workflow engine for Kubernetes         
argo/argo-rollouts              2.37.7          v1.7.2          A Helm chart for Argo Rollouts                    
argo/argo-workflows             0.42.4          v3.5.11         A Helm chart for Argo Workflows                   
argo/argocd-applicationset      1.12.1          v0.4.1          A Helm chart for installing ArgoCD ApplicationSet 
argo/argocd-apps                2.0.1                           A Helm chart for managing additional Argo CD Ap...
argo/argocd-image-updater       0.11.0          v0.14.0         A Helm chart for Argo CD Image Updater, a tool ...
argo/argocd-notifications       1.8.1           v1.2.1          A Helm chart for ArgoCD notifications, an add-o...

gewünschtes Helm Chart pullen

helm pull argo/argo-cd

Helm Chart entpacken

tar -xvf argo-cd-7.6.6.tgz

Helm Repo hinzufügen

helm repo add jetstack https://charts.jetstack.io --force-update
helm install \
  cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --create-namespace \
  --version v1.15.3 \
  --set crds.enabled=true

ClusterIssuer konfigurieren

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: ta@example.com
    privateKeySecretRef:
      name: example-issuer-account-key
    solvers:
    - http01:
        ingress:
          ingressClassName: nginx