Einheit 5.2: Sicherheitsautomatisierung

Einführung

Sie haben TaskBoard in Modul 3 zu Managed Kubernetes verschifft, und es spricht jetzt mit PostgreSQL, Redis, Object Storage und Kafka. Jede dieser Verbindungen wird durch eine Anmeldeinformation geschützt, und im Moment sind diese Anmeldeinformationen über Token-Dateien, Terraform-Zustand und CI-Geheimnis-Speicher verstreut. Im Moment, in dem ein Token ausfällt oder ein Ingenieur das Team verlässt, müssen Sie schnell rotieren und dies ohne manuelles Klicken in einer Konsole tun.

Diese Einheit behandelt Sicherheit als Code. Sie werden den gesamten Token-Lebenszyklus durch die Token Manager automatisieren, Benutzer und Zugriff mit dem IONOS-IAM-Modell in Terraform verwalten, Firewall-Regeln durch die gleiche Pipeline übertragen, die Ihre Server bereitstellt, und Datenbank-Anmeldeinformationen in Kubernetes-Geheimnisse direkt aus Terraform-Ausgaben einbinden. Das IONOS-Zugriffsmodell hat spezifische Kanten, gruppenbasierte Autorisierung anstelle von feingranularen Richtlinien, Netzwerksicherheitsgruppen, die nicht an gemanagte Lastenausgleich oder Kubernetes-Knoten gebunden sind, und Token, die genau einmal angezeigt werden, und das Richtigstellen dieser Kanten ist der Unterschied zwischen einer audit-sauberen Plattform und einem 2-Uhr-Vorfall.

1. API Token-Lebenszyklusautomatisierung

Bearer-Tokens sind die Methode, mit der jeder API-Aufruf, jeder SDK-Client und jede CI-Pipeline sich bei IONOS Cloud authentifiziert. Sie als langfristige Geheimnisse zu behandeln, die in die Konfiguration eingefügt werden, ist der häufigste Sicherheitsfehler auf der Plattform. Der Token Manager ermöglicht es Ihnen, pro Dienst-Tokens mit begrenzter Lebensdauer zu generieren und sie programmgesteuert zu rotieren.

Ein Token wird gegen Ihre Vertragsanmeldeinformationen angefordert und als JWT zurückgegeben. Die Basic-Authentifizierungsmethode (Benutzername und Passwort bei jedem Anfrage) wird eingestellt und sollte in der Automatisierung nicht verwendet werden, daher standardisieren Sie auf Bearer-Tokens überall.

1.1 Generieren und Scoping von Tokens

Fordern Sie ein Token mithilfe der Authentifizierung API. Der zurückgegebene token-Wert ist ein JWT, den Sie dann als Authorization: Bearer <token> bei nachfolgenden Cloud-API-Aufrufen übergeben.

# Request a bearer token using contract credentials (one-time, e.g. in a bootstrap step)
curl -s --request GET \
  --user "$IONOS_USERNAME:$IONOS_PASSWORD" \
  'https://api.ionos.com/auth/v1/tokens/generate' \
  | jq -r '.token' > taskboard-ci.token

Jedes Token trägt eine Time To Live (TTL), die festlegt, wie lange es gültig ist, bevor es abläuft und inaktiv wird. Die verfügbaren TTL-Werte sind fest: 1 Stunde, 4 Stunden, 1 Tag, 7 Tage, 30 Tage, 60 Tage, 90 Tage, 180 Tage und 365 Tage. Wählen Sie den kürzesten TTL, den ein bestimmter Verbraucher tolerieren kann. Eine CI-Pipeline, die bei jedem Merge läuft, kann mit einem 7-Tage-Token auskommen, der wöchentlich rotiert wird; ein lang laufender Controller kann 30 Tage benötigen.

Ein einzelner Benutzer kann bis zu 100 Token gleichzeitig halten. Diese Obergrenze ist großzügig genug, um jedem Dienst und jeder Umgebung sein eigenes Token zu geben, was genau das ist, was Sie wollen: ein Token pro Dienst, pro Umgebung, damit die Rücknahme eines geleakten Credentials nie etwas anderes beeinträchtigt.

1.2 Rotation ohne Ausfallzeit

Der Tokenwert wird genau einmal bei der Generierung angezeigt und ist danach nicht wiederherstellbar. Es gibt keinen "Token erneut anzeigen"-Aufruf, daher muss Ihre Rotationslogik den Wert bei der Erstellung erfassen und ihn direkt an sein Ziel (ein CI-Geheimnis, ein Kubernetes-Geheimnis) in demselben Schritt schreiben.

Die Rotation folgt einem generate-then-revoke-Muster, damit es nie eine Lücke gibt, in der kein gültiges Token existiert.

#!/usr/bin/env bash
set -euo pipefail

# 1. Generate the new token and capture it immediately (only chance to read it)
NEW_TOKEN=$(curl -s --request GET --user "$IONOS_USERNAME:$IONOS_PASSWORD" \
  'https://api.ionos.com/auth/v1/tokens/generate' | jq -r '.token')

# 2. Push it to consumers BEFORE revoking the old one (overlap window)
kubectl create secret generic ionos-api-token \
  --from-literal=token="$NEW_TOKEN" \
  --namespace taskboard --dry-run=client -o yaml | kubectl apply -f -

# 3. List existing tokens, identify the old one by its jti, then delete it
curl -s --request GET --header "Authorization: Bearer $NEW_TOKEN" \
  'https://api.ionos.com/auth/v1/tokens' | jq '.tokens[] | {id: .id, expirationDate}'

Das Löschen eines Tokens im Token Manager deaktiviert es sofort, auch wenn seine TTL noch nicht abgelaufen ist, sodass das alte Credential tot ist, sobald Sie den Aufruf DELETE ausführen. Führen Sie dieses Skript auf einem Zeitplan (ein CI-Cron-Job oder ein Kubernetes-CronJob) aus, und die Rotation wird zu einer Eigenschaft der Plattform anstelle einer Aufgabe, die jemand zu erledigen vergisst.

2. IAM als Code

Der Zugriff auf Benutzer und Gruppen in der IONOS Cloud folgt einem Modell für rollenbasierte Zugriffskontrolle, das auf Gruppen und nicht auf pro-Ressourcen-Richtliniendokumenten basiert. Sie weisen Privilegien einer Gruppe zu, fügen Benutzer der Gruppe hinzu und teilen bestimmte Ressourcen mit der Gruppe. Es gibt keine feingranulare, pro-Aktion-Richtliniensprache, daher sollten Sie Ihr Zugriffsdesign von Anfang an um Gruppen herum aufbauen.

Die Verwaltung in Terraform hält Ihre Zugriffsübersicht in Pull-Requests überprüfbar und reproduzierbar über Verträge hinweg.

2.1 Benutzer, Gruppen und Privilegien

Eine Gruppe trägt eine Menge von vertragsbezogenen Privilegien. Die verfügbaren Gruppenprivilegien sind ein festes Katalog: Erstellen von Rechenzentren, Erstellen von Snapshots, Reservieren von IP-Blöcken, Erstellen von Internetzugriff, Verwenden von Object Storage, Erstellen von Sicherungseinheiten, Erstellen von Kubernetes-Clustern und Zugriff auf Aktivitätsprotokolle. Sie aktivieren die Privilegien, die eine Gruppe benötigt, und nichts mehr.

resource "ionoscloud_group" "taskboard_deployers" {
  name                  = "taskboard-deployers"
  create_datacenter     = false
  create_snapshot       = false
  reserve_ip            = false
  access_activity_log   = true
  create_k8s_cluster    = true
  s3_privilege          = true # Use Object Storage
}

resource "ionoscloud_user" "ci_bot" {
  first_name     = "TaskBoard"
  last_name      = "CI"
  email          = "ci-bot@taskboard.example"
  password       = var.ci_bot_password # sensitive, from a secret store
  administrator  = false
  force_sec_auth = false
}

resource "ionoscloud_group_user" "ci_bot_membership" {
  group_id = ionoscloud_group.taskboard_deployers.id
  user_id  = ionoscloud_user.ci_bot.id
}

Behalten Sie administrator = false für jeden Automatisierungsbenutzer bei. Ein Administrator umgeht die Gruppenprivilegien vollständig, was das Prinzip der geringsten Privilegien untergräbt, das Sie aufbauen.

2.2 Ressourcen mit Gruppen teilen

Privilegien steuern, was eine Gruppe erstellen kann. Die Ressourcenfreigabe steuert, was eine Gruppe für bereits existierende Ressourcen sehen und ausführen kann. Die steuerbaren Ressourcentypen sind Virtuelle Rechenzentren, Snapshots, Bilder, IP-Blöcke, Sicherungseinheiten und Kubernetes-Cluster. Für jede geteilte Ressource erhält eine Gruppe ein Autorisierungsniveau: Lesen (implizit, sobald die Gruppe einer Ressource zugewiesen wird), Bearbeiten und Teilen.

resource "ionoscloud_share" "taskboard_vdc_share" {
  group_id      = ionoscloud_group.taskboard_deployers.id
  resource_id   = ionoscloud_datacenter.taskboard.id
  edit_privilege  = true
  share_privilege = false
}

Die folgende Tabelle ordnet die drei Autorisierungsniveaus dem zu, was ein Gruppenmitglied tun kann, was die Entscheidung ist, die Sie bei jeder Freigabe treffen:

Gewähren Sie Sharing sparsam. Eine Gruppe, die Ressourcen weiter teilen kann, kann den Zugriff über das hinaus erweitern, was Ihr Terraform beschreibt, und so eine Diskrepanz zwischen Ihrem Code und der Realität erzeugen.

3. NSG-Automatisierung in der Pipeline

Network Security Groups sind Zustands-firewalls, die auf der VM- oder NIC-Ebene angewendet werden. Die Verwaltung ihrer Regeln in Terraform, anstatt sie von Hand zu bearbeiten, bedeutet, dass Ihre Netzwerkpostur in der gleichen Pipeline wie die Server, die sie schützt, vorhanden ist und bei jeder Änderung überprüft wird.

Eine NSG standardmäßig auf "verweigern" eingestellt: Datenverkehr wird abgelehnt, es sei denn, eine Regel erlaubt ihn explizit. Regeln unterstützen sowohl INGRESS- als auch EGRESS-Richtungen und ein breites Protokollset, einschließlich TCP, UDP, ICMP, ICMPv6, GRE, VRRP, ESP und AH.

3.1 Regeln als Code

Binden Sie eine NSG an einen Server (der alle seine NICs abdeckt) oder an eine einzelne NIC für eine granulare Steuerung, und definieren Sie dann Regeln. Die Plattform beschränkt Sie auf 100 Regeln pro NSG, 10 NSGs pro NIC und 200 NSGs pro VDC, was großzügig genug ist, dass Sie vor einem Kontingent ein Designproblem erreichen.

resource "ionoscloud_nsg" "taskboard_app" {
  name          = "taskboard-app-tier"
  description   = "App tier: allow HTTPS in, Postgres out"
  datacenter_id = ionoscloud_datacenter.taskboard.id
}

resource "ionoscloud_nsg_firewallrule" "allow_https_in" {
  nsg_id          = ionoscloud_nsg.taskboard_app.id
  protocol        = "TCP"
  name            = "https-ingress"
  type            = "INGRESS"
  port_range_start = 443
  port_range_end   = 443
}

resource "ionoscloud_nsg_firewallrule" "allow_pg_out" {
  nsg_id          = ionoscloud_nsg.taskboard_app.id
  protocol        = "TCP"
  name            = "postgres-egress"
  type            = "EGRESS"
  port_range_start = 5432
  port_range_end   = 5432
}

# Bind the NSG to the app server's NIC
resource "ionoscloud_nic" "app_nic" {
  datacenter_id     = ionoscloud_datacenter.taskboard.id
  server_id         = ionoscloud_server.app.id
  lan               = ionoscloud_lan.app_lan.id
  security_groups_ids = [ionoscloud_nsg.taskboard_app.id]
}

Die zugrunde liegende API-Ressource ist security-group, und jede Regel gibt Eigenschaften wie name, protocol, sourceIp, targetIp, portRangeStart, portRangeEnd, icmpType und icmpCode frei. Die ICMP-Felder gelten nur, wenn das Protokoll ICMP oder ICMPv6 ist.

3.2 Was NSGs nicht abdecken

Dies ist die Einschränkung, die Entwicklern Stunden der Fehlersuche kostet. NSGs gelten nur auf der VDC-Server-NIC-Ebene. Sie binden NICHT an Managed Application Load Balancer, Managed Network Load Balancer oder Managed Kubernetes. Insbesondere sind Managed Kubernetes-Node-Poolknoten und suspendierte Cubes von der NSG-Durchsetzung ausgeschlossen.

# WRONG: there is no security_groups argument on a managed load balancer.
# resource "ionoscloud_application_loadbalancer" "alb" {
#   security_groups_ids = [ionoscloud_nsg.x.id]  # not a valid argument
# }

Für einen ALB-gestützten Dienst wie TaskBoards API können Sie den ALB selbst nicht mit einer NSG Firewall-schützen. Schützen Sie die Ebene, indem Sie die Anwendungsserver auf einem privaten LAN platzieren und NSG-Regeln auf ihre NICs anwenden, sodass nur das Subnetz des ALB sie erreichen kann. Für Kubernetes setzen Sie die Verkehrspolitik mit Kubernetes-NetworkPolicy-Objekten innerhalb des Cluster um, da die Node-NICs außerhalb des NSG-Umfangs liegen. NSGs sind auch unabhängig von der Legacy-per-NIC-Firewall, also erwarten Sie nicht, dass eine die Regeln der anderen erbt.

4. Kubernetes Geheimnisse von Terraform

TaskBoards Pods benötigen die PostgreSQL-Verbindungszeichenfolge, das Redis-Passwort und den Object Storage-Zugriffsschlüssel. Keiner dieser Werte sollte jemals in einem committeten Manifest erscheinen. Das saubere Muster besteht darin, sie aus Terraform-Ausgaben (markiert als sensitiv) zu beziehen und bei der Bereitstellung aus diesen Ausgaben Kubernetes-Geheimnisse zu erstellen.

4.1 Sensitive Ausgaben, die Geheimnisse speisen

Markieren Sie jede Anmeldeinformationenausgabe mit sensitive = true, damit Terraform sie nie in Protokolle oder in terraform output ohne die explizite Flagge ausgibt.

output "pg_connection_uri" {
  value     = "postgresql://${ionoscloud_pg_cluster.taskboard.credentials[0].username}:${var.pg_password}@${ionoscloud_pg_cluster.taskboard.dns_name}:5432/taskboard?sslmode=require"
  sensitive = true
}

output "s3_access_key" {
  value     = ionoscloud_s3_key.taskboard.id
  sensitive = true
}

output "s3_secret_key" {
  value     = ionoscloud_s3_key.taskboard.secret_key
  sensitive = true
}

Bei der Bereitstellung lesen Sie diese Ausgaben und erstellen das Kubernetes-Geheimnis in einem Schritt, sodass der Klartextwert niemals auf der Festplatte in einem Manifest landet:

kubectl create secret generic taskboard-db \
  --namespace taskboard \
  --from-literal=DATABASE_URL="$(terraform output -raw pg_connection_uri)" \
  --from-literal=S3_ACCESS_KEY="$(terraform output -raw s3_access_key)" \
  --from-literal=S3_SECRET_KEY="$(terraform output -raw s3_secret_key)" \
  --dry-run=client -o yaml | kubectl apply -f -

Das --dry-run=client -o yaml | kubectl apply -f --Idiom macht den Vorgang idempotent: Wenn es erneut ausgeführt wird, aktualisiert es das Geheimnis anstelle dessen, zu fehlschlagen, weil es bereits existiert.

4.2 Verwenden und Rotieren von Geheimnissen

Die Bereitstellung verweist auf das Geheimnis nach Namen, sodass das Rotieren einer Anmeldeinformation das Neuerstellen des Geheimnisses und das Neustarten des Pods bedeutet, anstatt ein Manifest zu bearbeiten.

spec:
  containers:
    - name: taskboard-api
      image: taskboard-prod.cr.de-fra.ionos.com/taskboard/api:abc123
      envFrom:
        - secretRef:
            name: taskboard-db

Nach der Rotation der zugrunde liegenden Anmeldeinformationen und erneuter Anwendung des Geheimnisses muss der Pods dazu gezwungen werden, es aufzunehmen:

kubectl rollout restart deployment/taskboard-api -n taskboard

Für größere Flotten kann ein externer Secrets-Operator von einem zentralen Speicher nach einem Zeitplan synchronisieren, aber das Terraform-Ausgabe-zu-Geheimnis-Muster ist die richtige Grundlage und hält die Quelle der Wahrheit für die Anmeldeinformationen in Ihrem Infrastruktur-Code.

5. SSH-Schlüsselautomatisierung

Server, die von Terraform bereitgestellt werden, erhalten ihren SSH-Zugriff durch Schlüssel, die beim Bootvorgang injiziert werden. Der SSH Key Manager speichert Schlüssel pro Benutzer (bis zu 100 gespeicherte Schlüssel pro Benutzer), sodass ein Team auf denselben Schlüsselsatz über verschiedene Bereitstellungen hinweg verweisen kann, und cloud-init injiziert sie in neue Instanzen.

5.1 Injizieren und Rotieren von Schlüsseln

Speichern Sie die öffentlichen Schlüssel des Teams und injizieren Sie sie durch die cloud-init user_data des Servers. Eine ad-hoc-Schlüsselinjektion während der Bereitstellungszeit wird durch die Cloud API unterstützt, die genau das ist, was Terraform verwendet.

locals {
  team_keys = [
    file("${path.module}/keys/alice.pub"),
    file("${path.module}/keys/bob.pub"),
  ]
}

resource "ionoscloud_server" "app" {
  name              = "taskboard-app"
  datacenter_id     = ionoscloud_datacenter.taskboard.id
  cores             = 4
  ram               = 8192
  ssh_key_path      = local.team_keys

  volume {
    name      = "app-boot"
    size      = 20
    disk_type = "SSD"
    image_name = "ubuntu:latest"
  }
}

Das Rotieren eines Team-Schlüssels ist eine Code-Änderung: Entfernen Sie den alten .pub, fügen Sie den neuen hinzu und terraform apply. Neue und neu bereitgestellte Server übernehmen die Änderung sofort. Kombinieren Sie dies mit einem cloud-init-Schritt, der veraltete Schlüssel aus ~/.ssh/authorized_keys auf vorhandenen Hosts entfernt, sodass die Rotation auch auf ausgeführte Server ausgedehnt wird.

#cloud-config
ssh_authorized_keys:
  - ssh-ed25519 AAAA... alice@taskboard
  - ssh-ed25519 AAAA... bob@taskboard

Halten Sie private Schlüssel aus dem Terraform-Zustand und aus Git heraus. Nur öffentliche Schlüssel gehören in Ihr Repository; die entsprechenden privaten Schlüssel bleiben bei jedem Ingenieur oder in einem dedizierten Geheimnis-Speicher.

API Referenz-Quick-Card

Wichtige Endpunkte für Token- und Zugriffsautomatisierung:

Basis-URL: https://api.ionos.com (Cloud-API-Ressourcen unter /cloudapi/v6) Authentifizierung: Authorization: Bearer <token>

Code-Labor

Ziel: Rotieren Sie das API-Token von TaskBoard durch das Token Manager, fügen Sie eine NSG-Regel über Terraform hinzu und verbinden Sie eine Datenbank-Anmeldeinformation mit einem Kubernetes-Geheimnis aus einer Terraform-Ausgabe.

Voraussetzungen:

• IONOS Cloud-Konto mit Vertragsanmeldeinformationen und einem vorhandenen TaskBoard-VDC
• Terraform mit dem ionoscloud-Anbieter konfiguriert
• kubectl mit Ihrem TaskBoard-MKS-Cluster verbunden, jq installiert

Schritt 1: Erstellen Sie ein neues Token

NEW_TOKEN=$(curl -s --request GET --user "$IONOS_USERNAME:$IONOS_PASSWORD" \
  'https://api.ionos.com/auth/v1/tokens/generate' | jq -r '.token')
echo "${NEW_TOKEN:0:12}..."

Erwartete Ausgabe:

eyJ0eXAiOiJK...

Schritt 2: Listen Sie Ihre aktiven Token auf

curl -s --request GET --header "Authorization: Bearer $NEW_TOKEN" \
  'https://api.ionos.com/auth/v1/tokens' | jq '.tokens | length'

Erwartete Ausgabe:

3

Schritt 3: Fügen Sie eine NSG-Eingangsregel in Terraform hinzu

resource "ionoscloud_nsg_firewallrule" "lab_https" {
  nsg_id           = ionoscloud_nsg.taskboard_app.id
  protocol         = "TCP"
  name             = "lab-https"
  type             = "INGRESS"
  port_range_start = 443
  port_range_end   = 443
}

terraform apply -target=ionoscloud_nsg_firewallrule.lab_https

Erwartete Ausgabe:

ionoscloud_nsg_firewallrule.lab_https: Creation complete
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

Schritt 4: Erstellen Sie das K8s-Geheimnis aus einer sensiblen Ausgabe

kubectl create secret generic taskboard-db -n taskboard \
  --from-literal=DATABASE_URL="$(terraform output -raw pg_connection_uri)" \
  --dry-run=client -o yaml | kubectl apply -f -

Erwartete Ausgabe:

secret/taskboard-db configured

Schritt 5: Überprüfen Sie das Geheimnis, ohne es preiszugeben

kubectl get secret taskboard-db -n taskboard -o jsonpath='{.data.DATABASE_URL}' | base64 -d | sed 's/:[^@]*@/:****@/'

Erwartete Ausgabe:

postgresql://taskboard:****@pg-xxxx.de-fra.ionos.com:5432/taskboard?sslmode=require

Schritt 6: Starten Sie Pods neu, um das rotierte Geheimnis aufzunehmen

kubectl rollout restart deployment/taskboard-api -n taskboard
kubectl rollout status deployment/taskboard-api -n taskboard

Erwartete Ausgabe:

deployment "taskboard-api" successfully rolled out

Schritt 7: Widerrufen Sie das alte Token

curl -s --request DELETE --header "Authorization: Bearer $NEW_TOKEN" \
  "https://api.ionos.com/auth/v1/tokens/$OLD_TOKEN_ID" -o /dev/null -w "%{http_code}\n"

Erwartete Ausgabe:

200

Validierungs-Checkliste:

• [ ] Neues Token erstellt und altes Token gibt nach der Löschung 401 zurück
• [ ] NSG-Regel über terraform state show ionoscloud_nsg_firewallrule.lab_https sichtbar
• [ ] Pods läuft mit dem rotierten Geheimnis, keine Anmeldeinformationen in einem Manifest

Aufräumen:

terraform destroy -target=ionoscloud_nsg_firewallrule.lab_https
kubectl delete secret taskboard-db -n taskboard

Häufige Fallstricke

1. Versuch, einen Token-Wert ein zweites Mal zu lesen

   • Problem: Ihr Rotations-Skript generiert einen Token, protokolliert "rotiert" und versucht später, den Token-Wert abzurufen, um ihn irgendwo zu übertragen, und erhält nur Metadaten.
   • Warum es passiert: Der Token-Wert wird genau einmal bei der Generierung angezeigt und ist nicht wiederherstellbar. Die Auflistung von Token gibt IDs und Ablaufdatum zurück, nie das Geheimnis.
   • Lösung: Erfassen Sie den Wert bei der Erstellung und schreiben Sie ihn in seinem Ziel im gleichen Schritt:

   NEW_TOKEN=$(curl -s --request GET --user "$U:$P" \
     'https://api.ionos.com/auth/v1/tokens/generate' | jq -r '.token')
   kubectl create secret generic ionos-api-token --from-literal=token="$NEW_TOKEN" \
     --dry-run=client -o yaml | kubectl apply -f -
   

2. Anfügen einer NSG an einen gemanagten Load Balancer oder MKS Node-Pool

   • Problem: Sie fügen security_groups_ids zu einem ALB hinzu oder erwarten, dass NSG-Regeln den Kubernetes Node-Datenverkehr filtern, und nichts wird durchgesetzt.
   • Warum es passiert: NSGs werden nur auf der VDC-Server-NIC-Ebene angewendet. Gemanagte ALB/NLB sind aus dem Umfang und Managed Kubernetes Node-Pool-Knoten sind explizit von der NSG-Durchsetzung ausgeschlossen.
   • Lösung: Wenden Sie NSG-Regeln auf die NICs der Anwendungsserver hinter dem Load Balancer an und verwenden Sie Kubernetes NetworkPolicy-Objekte innerhalb des Cluster für die Steuerung des Datenverkehrs auf Pod-Ebene.

3. Commit von Anmeldeinformationen, da die Ausgabe nicht als sensitiv markiert war

   • Problem: Ein Teammitglied führt terraform output in CI-Logs aus und das Datenbankpasswort wird im Klartext in der Build-Ausgabe gedruckt.
   • Warum es passiert: Eine Ausgabe ohne sensitive = true wird im Konsoleausgabe und in den Protokollen gerendert.
   • Lösung: Markieren Sie jede Ausgabe von Anmeldeinformationen als sensitiv und lesen Sie sie explizit mit -raw nur am Punkt der Verwendung:

   output "pg_connection_uri" {
     value     = local.pg_uri
     sensitive = true
   }
   

Zusammenfassung

Sie können nun die Sicherheit als Teil Ihrer Infrastruktur-Pipeline behandeln, anstatt sie als manuelle Konsole-Aufgabe. Token werden mit begrenzten TTLs generiert, pro Service und pro Umgebung skaliert und mit einer Generierungs-Push-Widerrufs-Sequenz rotiert, die nie eine Lücke hinterlässt. Der Zugriff wird durch Gruppen, Benutzer und Freigaben als Code beschrieben, was dem IONOS-Gruppen-basierten RBAC-Modell entspricht. Firewall-Regeln werden zusammen mit den Servern, die sie schützen, ausgeliefert, und Anmeldeinformationen fließen von sensitiven Terraform-Ausgaben direkt in Kubernetes-Geheimnisse, ohne jemals eine committete Datei zu berühren.

Die IONOS-spezifischen Kanten sind es, die dies sauber halten: Token werden genau einmal angezeigt, ein festes Katalog von Gruppenprivilegien anstelle von freiformigen Richtlinien und NSGs, die am Server-NIC-Level stoppen und nie Managed-Load-Balancer oder Kubernetes-Knoten erreichen. Bauen Sie um diese Kanten herum und Ihre Plattform bleibt überprüfbar und wiederherstellbar.

Wichtige Punkte:

• Erstellen Sie ein Bearer-Token pro Service pro Umgebung (bis zu 100 pro Benutzer) mit der kürzesten möglichen TTL aus dem festen Satz (1 Stunde bis 365 Tage)
• Token-Werte werden genau einmal angezeigt und das Löschen eines Tokens deaktiviert es sofort, sodass capture-then-push-then-revoke die sichere Rotationsreihenfolge ist
• IONOS-Zugriff ist gruppenbasiert RBAC: Weisen Sie Privilegien Gruppen zu, teilen Sie Ressourcen auf Lesen/Bearbeiten/Teilen-Ebenen, halten Sie Automatisierungsbenutzer nicht-administrator
• NSGs sind zustandsbehaftet, standardmäßig alles ablehnen, werden nur auf dem Server-NIC-Level angewendet und decken keine Managed-ALB/NLB oder Managed Kubernetes-Knoten ab
• Quellen Kubernetes-Geheimnisse aus sensitive Terraform-Ausgaben, sodass Anmeldeinformationen nie in einem Manifest oder Git leben

Wichtige Begriffe:

• Token Manager: Das IONOS-Feature, das Bearer-Token (JWTs) generiert, auflistet und widerruft, die für API- und SDK-Authentifizierung verwendet werden.
• TTL (Time To Live): Die feste Gültigkeitsdauer, die einem Token bei der Erstellung zugewiesen wird, nach der es abläuft und inaktiv wird.
• Gruppenbasiertes RBAC: Das IONOS-Zugriffsmodell, bei dem Privilegien und Ressourcenfreigaben Gruppen anstelle von einzelnen Benutzern oder pro-Aktion-Richtlinien gewährt werden.
• Netzwerksicherheitsgruppe (NSG): Eine zustandsbehaftete, standardmäßig alles ablehnende Firewall, die auf dem VM- oder NIC-Level angebracht und über die security-group API-Ressource gemanagt wird.
• Sensibler Ausgang: Ein Terraform-Ausgang, der als sensitive = true markiert ist, sodass sein Wert von der Konsole-Ausgabe und den Protokollen ausgeschlossen wird.

Nächste Schritte

Weiter lernen: Einheit 5.3: GitOps und Deployment-Operationen

Verwandte Themen:

• Einheit 2.3: Lastverteilung und Sicherheit als Code
• Einheit 5.1: Beobachtbarkeit und Fehlersuche