Einheit 5.2: Sicherheitsautomatisierung

Einführung

Sie haben TaskBoard in Modul 3 in Managed Kubernetes bereitgestellt, und es kommuniziert nun mit PostgreSQL, Redis, Object Storage und Kafka. Jede dieser Verbindungen wird durch ein Zugangsdatum geschützt, und derzeit sind diese Zugangsdaten über Token-Dateien, Terraform-Zustandsdateien und CI-Geheimnisspeicher verstreut. Sobald ein Token geleckt wird oder ein Ingenieur das Team verlässt, müssen Sie schnell rotieren, und zwar ohne manuelle Klicks in einer Konsole.

Diese Einheit behandelt Sicherheit als Code. Sie automatisieren den gesamten Token-Lebenszyklus über den Token Manager, verwalten Benutzer und Zugriff mit dem IONOS CLOUD IAM-Modell in Terraform, schieben Firewall-Regeln durch dieselbe Pipeline, die Ihre Server bereitstellt, und verdrahten Datenbank-Zugangsdaten direkt aus Terraform-Ausgaben in Kubernetes-Secrets. Das IONOS CLOUD-Zugriffsmodell hat spezifische Kanten: gruppengestützte Autorisierung statt feingranularer Richtlinien, NSGs, die nicht an verwaltete Load Balancer oder Kubernetes-Knoten gebunden sind, und Tokens, die genau einmal angezeigt werden. Das korrekte Beherrschen dieser Kanten ist der Unterschied zwischen einer audit-freien Plattform und einem Vorfall um 2 Uhr nachts.

1. Automatisierung des API-Token-Lebenszyklus

Bearer-Tokens sind der Mechanismus, mit dem jeder API-Aufruf, jeder SDK-Client und jede CI-Pipeline die Authentifizierung gegenüber IONOS CLOUD durchführt. Die Behandlung dieser Tokens als langlebige Secrets, die in Konfigurationsdateien eingefügt werden, ist der häufigste Sicherheitsfehler auf der Plattform. Der Token Manager ermöglicht die Erzeugung von Tokens pro Dienst mit begrenzter Lebensdauer und deren programmgesteuerte Rotation.

Ein Token wird anhand Ihrer Vertragszudaten angefordert und als JWT zurückgegeben. Die Methode Basic Authentication (Benutzername und Passwort bei jedem Aufruf) wird eingestellt und sollte in der Automatisierung nicht verwendet werden. Standardisieren Sie daher überall auf Bearer-Tokens.

1.1 Erzeugen und Berechtigungen von Tokens

Fordern Sie ein Token über die Auth-API an. Der zurückgegebene Wert token ist ein JWT, das Sie bei nachfolgenden Cloud-API-Aufrufen als Authorization: Bearer <token> ü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

Jeder Token enthält eine Time To Live (TTL), die festlegt, wie lange er gültig ist, bevor er abläuft und inaktiv wird. Die verfügbaren TTL-Werte sind festgelegt: 1 Stunde, 4 Stunden, 1 Tag, 7 Tage, 30 Tage, 60 Tage, 90 Tage, 180 Tage und 365 Tage. Wählen Sie die kürzeste TTL, die ein bestimmter Verbraucher tolerieren kann. Eine CI-Pipeline, die bei jedem Merge ausgeführt wird, kann mit einem 7-Tage-Token auskommen, das wöchentlich rotiert wird; ein langlaufender Controller benötigt möglicherweise 30 Tage.

Ein einzelner Benutzer kann gleichzeitig bis zu 100 Tokens halten. Diese Obergrenze ist großzügig genug, um jedem Dienst und jeder Umgebung einen eigenen Token zuzuweisen, was genau das ist, was Sie möchten: ein Token pro Dienst und pro Umgebung, damit das Widerrufen eines geleakten Credentials niemals etwas anderes beeinträchtigt.

1.2 Rotation ohne Ausfallzeit

Der Token-Wert wird genau einmal bei der Generierung angezeigt und ist danach nicht wiederherstellbar. Es gibt keinen Aufruf „Token erneut anzeigen“, daher muss Ihre Rotationslogik den Wert zum Zeitpunkt der Erstellung erfassen und ihn direkt an sein Ziel (ein CI-Secret, ein Kubernetes-Secret) im selben Schritt schreiben.

Die Rotation folgt einem Muster aus Generieren und dann Widerrufen, sodass es nie eine Lücke gibt, in der kein gültiger 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 dessen TTL noch nicht abgelaufen ist, sodass die alte Zugangsdatenkombination im Moment, in dem Sie DELETE aufrufen, ungültig ist. Führen Sie dieses Skript nach Zeitplan aus (ein CI-Cron-Job oder ein Kubernetes CronJob), und die Rotation wird zu einer Eigenschaft der Plattform, statt eine Aufgabe zu sein, die sich jemand merken muss.

2. IAM as Code

Der Benutzer- und Gruppenzugriff auf IONOS CLOUD folgt einem Role-Based Access Control-Modell, das auf Gruppen basiert und nicht auf Policy-Dokumenten pro Ressource. Sie weisen einer Gruppe Berechtigungen zu, fügen Benutzer der Gruppe hinzu und teilen bestimmte Ressourcen mit der Gruppe. Es gibt keine feingranulare, aktionsbezogene Policy-Sprache. Gestalten Sie Ihr Zugriffskonzept daher von Anfang an um Gruppen herum.

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

2.1 Benutzer, Gruppen und Berechtigungen

Eine Gruppe trägt einen Satz an vertragsbezogenen Berechtigungen. Die verfügbaren Gruppenberechtigungen sind ein fester Katalog: Create Data Center, Create Snapshots, Reserve IP Blocks, Create Internet Access, Use Object Storage, Create Backup Units, Create Kubernetes Clusters und Access Activity Log. Sie aktivieren die Berechtigungen, die eine Gruppe benötigt, und nichts darüber hinaus.

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
  user_ids              = [ionoscloud_user.ci_bot.id]
}

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
}

Bewahren Sie administrator = false für jeden Automatisierungsnutzer auf. Ein Administrator umgeht die Gruppenberechtigungen vollständig, was das Modell der geringstmöglichen Berechtigungen, das Sie aufbauen, zunichtemacht.

2.2 Ressourcen mit Gruppen teilen

Berechtigungen steuern, was eine Gruppe erstellen kann. Das Teilen von Ressourcen steuert, was eine Gruppe für bereits vorhandene Ressourcen sehen und damit tun kann. Die steuerbaren Ressourcentypen sind: Virtuelle Rechenzentren, Snapshots, Images, IP-Blöcke, Sicherungseinheiten und Kubernetes-Cluster. Für jede geteilte Ressource erhält eine Gruppe eine Autorisierungsstufe: Lesen (implizit, sobald der Gruppe eine 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 Autorisierungsebenen den Handlungen zu, die ein Gruppenmitglied ausführen kann. Diese Entscheidung treffen Sie bei jedem Freigabevorgang:

Verleihen Sie Sharing sparsam. Eine Gruppe, die Ressourcen neu freigeben kann, kann den Zugriff über das hinaus erweitern, was Ihr Terraform beschreibt, was zu einer Abweichung zwischen Ihrem Code und der Realität führt.

3. NSG-Automatisierung in der Pipeline

Network Security Groups sind zustandsbehaftete Firewalls, die auf VM- oder NIC-Ebene angewendet werden. Die Verwaltung ihrer Regeln in Terraform, anstatt sie manuell zu bearbeiten, bedeutet, dass Ihre Netzwerksicherheit in derselben Pipeline wie die Server, die sie schützen, verwaltet wird und bei jeder Änderung überprüft wird.

Eine NSG verweigert standardmäßig alles: Der Datenverkehr wird verworfen, es sei denn, eine Regel erlaubt ihn ausdrücklich. Regeln unterstützen sowohl die Richtungen INGRESS und EGRESS als auch einen breiten Satz von Protokollen, darunter TCP, UDP, ICMP, ICMPv6, GRE, VRRP, ESP und AH.

3.1 Regeln als Code

Binden Sie eine NSG an einen Server (um alle seine NICs abzudecken) oder an eine einzelne NIC für eine granulare Steuerung, und definieren Sie dann Regeln. Die Plattform begrenzt Sie auf 100 Regeln pro NSG, 10 NSGs pro NIC und 200 NSGs pro VDC, was großzügig genug ist, sodass Sie ein Designproblem erreichen, bevor Sie eine Quota überschreiten.

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 stellt Eigenschaften wie name, protocol, sourceIp, targetIp, portRangeStart, portRangeEnd, icmpType und icmpCode bereit. 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 des Debuggens kostet. NSGs gelten nur auf der Ebene der VDC-Server-NIC. Sie werden NICHT an Managed Application Load Balancer, Managed Network Load Balancer oder Managed Kubernetes gebunden. Konkret sind Knoten in Knotenpools von Managed Kubernetes und ausgesetzte Cubes von der NSG-Durchsetzung ausgenommen.

# 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 durch einen ALB gesicherten Dienst wie die API von TaskBoard können Sie den ALB selbst nicht mit einer NSG absichern. Schützen Sie die Ebene, indem Sie die Anwendungsserver in einem privaten LAN platzieren und NSG-Regeln auf deren NICs anwenden, sodass nur das Subnetz des ALB auf sie zugreifen kann. Für Kubernetes setzen Sie die Traffic-Richtlinie innerhalb des Clusters mit Kubernetes NetworkPolicy-Objekten durch, da die NICs der Nodes außerhalb des NSG-Wirkungsbereichs liegen. NSGs sind zudem unabhängig von der veralteten Firewall pro NIC, daher ist nicht davon auszugehen, dass die eine die Regeln der anderen übernimmt.

4. Kubernetes Secrets aus Terraform

Die Pods von TaskBoard benötigen die PostgreSQL-Verbindungszeichenfolge, das Redis-Passwort und den Object Storage-Zugriffsschlüssel. Keiner dieser Werte darf in einem commitierten Manifest erscheinen. Das saubere Muster besteht darin, diese Werte aus Terraform-Outputs (als sensibel markiert) zu beziehen und bei der Bereitstellung Kubernetes Secrets aus diesen Outputs zu erstellen.

4.1 Sensible Outputs, die Secrets speisen

Markieren Sie jeden Credential-Output sensitive = true, damit Terraform ihn niemals ohne den expliziten Flag in Logs oder in terraform output 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
}

Zum Bereitstellungszeitpunkt werden diese Ausgaben gelesen und das Kubernetes-Secret in einem einzigen Schritt erstellt, sodass der Klartextwert nie in einem Manifest auf der Festplatte 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 Idiom --dry-run=client -o yaml | kubectl apply -f - macht die Operation idempotent: Bei einer erneuten Ausführung wird das Secret an Ort und Stelle aktualisiert, anstatt dass ein Fehler auftritt, weil es bereits existiert.

4.2 Verwenden und Rotieren von Secrets

Die Deployment referenziert das Secret nach dem Namen. Das Rotieren einer Berechtigung bedeutet daher, das Secret neu zu erstellen und die Pods neu zu starten, niemals 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

Nachdem das zugrunde liegende Anmeldezeichen (Credential) rotiert und das Secret erneut angewendet wurde, zwingen Sie die Pods, es zu übernehmen:

kubectl rollout restart deployment/taskboard-api -n taskboard

Für größere Flotten kann ein externer Secrets-Operator nach Zeitplan aus einem zentralen Store synchronisieren, aber das Muster Terraform-Ausgabe-zu-Secret ist die richtige Grundlage und hält die Quelle der Wahrheit für die Zugangsdaten in Ihrem Infrastrukturcode.

5. SSH-Schlüssel-Automatisierung

Server, die von Terraform provisioniert werden, erhalten ihren SSH-Zugriff über Schlüssel, die beim Start injiziert werden. Der SSH Key Manager speichert Schlüssel pro Benutzer (bis zu 100 gespeicherte Schlüssel pro Benutzer), sodass ein Team denselben Schlüsselbestand über verschiedene Bereitstellungen hinweg referenzieren kann. cloud-init injiziert diese Schlüssel in neue Instanzen.

5.1 Injizieren und Rotieren von Schlüsseln

Speichern Sie die öffentlichen Schlüssel des Teams und injizieren Sie sie über cloud-init user_data des Servers. Die Ad-hoc-Injektion von Schlüsseln zum Zeitpunkt der Provisionierung wird über die Cloud API unterstützt, was 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 provisionierte Server übernehmen die Änderung sofort. Kombinieren Sie dies mit einem cloud-init-Schritt, der veraltete Schlüssel von ~/.ssh/authorized_keys auf vorhandenen Hosts entfernt, damit die Rotation auch laufende Server erreicht.

#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 vollständig aus Git heraus. Nur öffentliche Schlüssel gehören in Ihr Repository; die zugehörigen privaten Schlüssel verbleiben bei jedem Ingenieur oder in einem dedizierten Secret Store.

API-Referenz Schnellkarte

Wichtige Endpunkte für die Automatisierung von Tokens und Zugriffen:

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

Code Lab

Ziel: Den API-Token von TaskBoard über den Token Manager rotieren, eine NSG-Regel über Terraform hinzufügen und eine Datenbankanmeldeinformation aus einem Terraform-Output in ein Kubernetes-Secret einbinden.

Voraussetzungen:

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

Schritt 1: Einen neuen Token generieren

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: Ihre aktiven Token auflisten

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

Erwartete Ausgabe:

3

Schritt 3: Eine NSG-Eingangsregel in Terraform hinzufügen

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 des K8s-Secrets 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: Das Secret ohne Preisgabe überprüfen

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: Pods neu starten, um das rotierte Secret zu übernehmen

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: Den alten Token widerrufen

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

Prüfliste:

• [ ] Neues Token generiert und altes Token liefert nach der Löschung 401 zurück
• [ ] NSG-Regel über terraform state show ionoscloud_nsg_firewallrule.lab_https sichtbar
• [ ] Pods laufen mit dem rotierten Secret, keine Anmeldedaten in einem Manifest

Aufräumarbeiten:

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

Häufige Fehler

1. Versuch, einen Tokenwert ein zweites Mal auszulesen

   • Problem: Ihr Rotationsskript erzeugt einen Token, protokolliert „rotated" und versucht später, den Tokenwert abzurufen, um ihn an einen anderen Ort zu senden, erhält dabei jedoch nur Metadaten.
   • Ursache: Der Tokenwert wird genau einmal bei der Erzeugung angezeigt und ist nicht wiederherstellbar. Die Auflistung von Tokens liefert IDs und Ablaufdaten, niemals den geheimen Wert.
   • Lösung: Erfassen Sie den Wert bei der Erstellung und schreiben Sie ihn im selben Schritt an das Ziel:

   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. Anhängen einer NSG an einen verwalteten Load Balancer oder an einen MKS-Knotenpool

   • Problem: Sie fügen security_groups_ids einem ALB hinzu oder erwarten, dass NSG-Regeln den Kubernetes-Knotenverkehr filtern, und es wird nichts durchgesetzt.
   • Ursache: NSGs werden nur auf der Ebene der Server-NIC im VDC angewendet. Verwaltete ALB/NLB fallen nicht in den Geltungsbereich, und Knoten in Managed Kubernetes-Knotenpools sind ausdrücklich von der NSG-Durchsetzung ausgenommen.
   • Lösung: Wenden Sie NSG-Regeln auf die NICs der hinter dem Load Balancer befindlichen Anwendungsserver an und verwenden Sie Kubernetes NetworkPolicy-Objekte innerhalb des Clusters für die Verkehrskontrolle auf Pod-Ebene.

3. Einreichen von Zugangsdaten, weil die Ausgabe nicht als sensibel markiert war

   • Problem: Ein Teammitglied führt terraform output in CI-Protokollen aus, und das Datenbankpasswort wird in Klartext in der Build-Ausgabe ausgegeben.
   • Ursache: Eine Ausgabe ohne sensitive = true wird in der Konsolenausgabe und in Protokollen dargestellt.
   • Lösung: Markieren Sie jede Ausgabe mit Zugangsdaten als sensibel und lesen Sie sie nur an der Verwendungsstelle explizit mit -raw ein:

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

Zusammenfassung

Sie können Sicherheit nun als Teil Ihrer Infrastruktur-Pipeline behandeln, anstatt sie als manuelle Konsolenarbeit zu betrachten. Token werden mit begrenzten TTLs erstellt, pro Dienst und pro Umgebung eingeschränkt und über eine Erstellen-Schicken-Widerrufen-Sequenz rotiert, die niemals eine Lücke hinterlässt. Der Zugriff wird als Code über Gruppen, Benutzer und Freigaben beschrieben, was dem gruppenbasierten RBAC-Modell von IONOS CLOUD entspricht. Firewall-Regeln werden zusammen mit den Servern ausgeliefert, die sie schützen, und Zugangsdaten fließen von sensiblen Terraform-Ausgaben direkt in Kubernetes-Secrets, ohne jemals eine commitete Datei zu berühren.

Die IONOS CLOUD-spezifischen Grenzen sorgen dafür, dass dies sauber bleibt: Token werden genau einmal angezeigt, ein fester Katalog von Gruppenrechten anstelle von frei formulierten Richtlinien, und NSGs, die an der Server-NIC enden und verwaltete Load Balancer oder Kubernetes-Knoten niemals erreichen. Bauen Sie um diese Grenzen herum, und Ihre Plattform bleibt überprüfbar und wiederherstellbar.

Wichtige Punkte:

• Erstellen Sie ein Bearer-Token pro Dienst und pro Umgebung (bis zu 100 pro Benutzer) mit der kürzesten praktikablen TTL aus dem festen Satz (1 Stunde bis 365 Tage)
• Token-Werte werden genau einmal angezeigt und das Löschen eines Token deaktiviert es sofort, daher ist die sichere Rotationsreihenfolge: erfassen, dann senden, dann widerrufen
• Der Zugriff in IONOS CLOUD basiert auf gruppenbasiertem RBAC: weisen Sie Gruppen Rechte zu, teilen Sie Ressourcen auf den Ebenen Lesen/Bearbeiten/Freigabe, und halten Sie Automatisierungskonten auf Nicht-Administrator-Ebene
• NSGs sind zustandsbehaftet, verweigern standardmäßig alles, gelten nur auf Server-NIC-Ebene und decken verwaltete ALB/NLB oder Managed Kubernetes-Knoten NICHT ab
• Erstellen Sie Kubernetes-Secrets aus sensitive Terraform-Ausgaben, damit Zugangsdaten niemals in einem Manifest oder in Git gespeichert werden

Wichtige Begriffe:

• Token Manager: Die IONOS CLOUD-Funktion, die Bearer-Token (JWTs) für die Authentifizierung von API und SDK erstellt, auflistet und widerruft.
• 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 CLOUD-Zugriffsmodell, bei dem Rechte und Ressourcenfreigaben Gruppen statt einzelnen Benutzern oder pro Aktion definierten Richtlinien zugewiesen werden.
• Network Security Group (NSG): Eine zustandsbehaftete, standardmäßig alles verweigernde Firewall, die auf VM- oder NIC-Ebene angebracht wird und über die security-group API-Ressource verwaltet wird.
• Sensible Ausgabe: Eine Terraform-Ausgabe, die als sensitive = true markiert ist, sodass ihr Wert aus Konsolenausgaben und Logs ausgeschlossen wird.

Nächste Schritte

Weiter lernen: Einheit 5.3: GitOps und Deployment-Operationen

Verwandte Themen:

• Einheit 2.3: Lastverteilung und Security as Code
• Einheit 5.1: Observability und Debugging