Executive Summary
Okta Privileged Access (OPA) Workload Identity for Automation wird in die Google Cloud Platform (GCP) integriert, indem plattformsignierte OIDC JSON Web Token (JWTs) gegen kurzlebige, flüchtige SSH-Zertifikate ausgetauscht werden. Eine automatisierte Runner-VM fragt bei ihrem lokalen GCP-Metadatenserver ein von Google signiertes JWT ab, übermittelt es zur Authentifizierung über die sft-CLI an OPA und erhält ein zeitbasiertes SSH-Zertifikat für den Zugriff auf Zielserver. Damit werden statische SSH-Keys, API-Token und Service-Account-JSON-Dateien überflüssig.
Alle Automatisierungsentwickler:innen hat schon einmal denselben unangenehmen Moment erlebt: Ihr Skript muss sich mit einem Server verbinden, also generieren Sie Zugangsdaten, fügen diese in eine Konfigurationsdatei ein und machen weiter. Wochen später befinden sich diese Anmeldedaten in drei Konfigurationsdateien, zwei CI/CD-Pipelines und einer Slack-Nachricht, die jemand gesendet hat, um „nur mal schnell etwas zu testen“. Niemand weiß, welche noch aktiv sind. Niemand möchte die Person sein, die die Produktionsumgebung durch deren Rotation lahmlegt.
In diesem Blog-Beitrag stellen wir eine vollständige, funktionierende Lösung vor: die Nutzung von Okta Privileged Access (OPA) Workload Identity for Automation mit der Google Cloud Platform (GCP), um einem Automatisierungsskript den Zugriff auf einen Zielserver über Secure Shell (SSH) zu ermöglichen, ohne dass Anmeldedaten auf der Festplatte gespeichert werden.
Wie OPA- und GCP-Workload-Identitäten statische Anmeldedaten eliminieren
Primäres Ziel: Statische Anmeldedaten (API-Keys, statische SSH-Keys und Service-Account-JSON-Dateien) beim automatisierten Serverzugriff durch die Nutzung plattformsignierter Identity-Nachweise eliminieren.
Keine gespeicherten Anmeldedaten: Keine Secrets auf der Festplatte, in Konfigurationen oder in CI/CD-Variablen.
Kurzlebige flüchtige Zertifikate: Ausstellung von SSH-Zertifikaten mit einer Gültigkeit von 15 Minuten, wodurch das operative Risiko der Rotation entfällt.
Kryptografische End-to-End-Validierung: Okta Privileged Access, das als Trust Broker fungiert und von GCP ausgestellte JSON Web Token (JWTs) validiert.
Automatisierte Audit-Protokollierung: Vollständige Identitätsnachverfolgbarkeit bei Token-Austausch und SSH-Session-Aktivitäten im Okta System Log.
Das Problem: Statische Anmeldedaten sind Sicherheitsschulden, keine Infrastruktur-Features
Wenn ein automatisierter Job (z. B. Ansible-Playbook, ein Bereitstellungsskript oder ein CI/CD-Runner) auf eine privilegierte Ressource zugreifen muss, muss er seine Identität nachweisen können. Beim herkömmlichen Ansatz erhält er statische Anmeldedaten: einen API-Key, einen privaten SSH-Key oder eine Service-Account-JSON-Datei. Diese Anmeldedaten werden irgendwo gespeichert. Damit wird dieser Ort zu einem potenziellen Angriffsziel.
Die Folgen zeigen sich auf vorhersehbare Weise:
Anmeldedaten überdauern ihren Zweck: Ein Service-Account-Key, der für eine einmalige Bereitstellungsaufgabe erstellt wurde, bleibt jahrelang gültig. Die Person, die es erstellt hat, verlässt das Unternehmen. Der Key bleibt. Niemand führt dafür Audits durch. Im Laufe der Zeit häufen sich Berechtigungen an, da es einfacher ist, Zugriff hinzuzufügen, als zu untersuchen, was sicher entfernt werden kann. Dies sind die „Zombie-Anmeldedaten“, die in Ihrer Umgebung weiterleben – lange nachdem der Workload, der sie benötigte, verschwunden ist.
Rotation wird zur Krisenübung: Wenn Anmeldedaten in Dutzenden Pipelines und Konfigurationsdateien eingebettet sind, bedeutet ihre Rotation, dass zunächst jeder Verweis gefunden werden muss. Teams entdecken Referenzen, indem sie beobachten, was nach der Rotation nicht mehr funktioniert. Dies ist keine Rotationsstrategie, sondern ein kontrollierter Ausfall.
Das zugrunde liegende Problem ist architektonischer Natur: Statische Anmeldedaten sind ein Identity-Modell, das für Menschen konzipiert wurde, nicht für Maschinen. Ein Mensch kann sein Passwort ändern und sich das neue merken. Eine Maschine muss nur wissen: „Bin ich, wer ich vorgebe zu sein?“. Eine Cloud-Plattform kann diese Frage kryptografisch beantworten. Sie benötigt dafür kein gespeichertes Secret.
Die Lösung: kurzlebige Token, dauerhafte Sicherheit
Okta Privileged Access Workload Identity for Automation löst das „Secret Zero“-Problem, bei dem ein anfänglicher Key zum Abrufen weiterer sicherer Anmeldedaten benötigt wird, indem die statischen Anmeldedaten durch plattformsignierte Identity-Nachweise ersetzt werden.
Die Erkenntnis ist einfach: eine virtuelle GCP-Maschine (VM) verfügt bereits über eine kryptografische Identität. Wenn Sie einer VM einen Service-Account zuweisen, kann GCP ein mit dem privaten Schlüssel von Google signiertes JWT ausstellen, das im Grunde besagt: „Ich bin diese VM, die als dieser Service-Account ausgeführt wird, und mir wurde dieses Token in genau diesem Moment ausgestellt.“ Niemand kann dieses Token ohne den privaten Schlüssel von Google fälschen. Es läuft automatisch ab und kann nicht auf einem anderen System wiederverwendet werden.
OPA fungiert als Trust Broker. Sie konfigurieren es einmalig mit der Vorgabe: „Ich vertraue von Google signierten JWTs für den Service-Account X.“ Von diesem Zeitpunkt an kann jede Workload, die als dieser Service-Account ausgeführt wird, ihre Identität gegenüber OPA nachweisen, indem sie ihr von GCP ausgestelltes JWT vorlegt, und OPA tauscht dieses gegen ein kurzlebiges Access-Token ein. Dieses Token wird dann verwendet, um ein kurzlebiges SSH-Zertifikat zu erhalten, das nur Minuten statt Jahre gültig ist, um eine Verbindung zu einem Zielserver herzustellen.
Dies ist keine Änderung an der Funktionsweise von SSH. Es ist eine Änderung daran, wie die Identität festgestellt wird, bevor SSH beginnt.
Systemarchitektur und Komponentenzuordnung
Der Authentifizierungsworkflow basiert auf einem Trust-Broker-Designmuster, bei dem OPA von GCP kryptografisch generierte Identity-Claims validiert.
| Komponente | Sicherheitsrolle | Standort |
|---|---|---|
GCP-Metadatenserver | Interner GCP-Endpoint, der auf Anfrage signierte JWTs an jede VM ausstellt | GCP-Infrastruktur (nicht Ihre VM) |
Workload-Verbindung | OPA-Konfigurationsobjekt, das die Vertrauensstellung mit GCP definiert und festlegt, welche JWTs akzeptiert und welche Claims verifiziert werden sollen | OPA-Dashboard |
Workload-Rolle | OPA-Autorisierungsentität, die eine verifizierte Workload-Identität mit einem Linux-Benutzernamen auf Zielservern abgleicht | OPA-Dashboard |
Richtlinie und Regel | Definiert, welche Workload-Rollen über welche Methode auf welche Server zugreifen können | OPA-Dashboard |
sft (OPA-Client) | Binärdatei der Befehlszeilenschnittstelle (CLI), die die Workload-Authentifizierung und die Ausstellung von SSH-Zertifikaten übernimmt | Runner-VM |
sftd (OPA-Agent) | Daemon, der den Zielserver bei OPA registriert und SSH so konfiguriert, dass es der Zertifizierungsstelle von OPA vertraut | Ziel-VM |
Architektur und Authentifizierungsablauf
Grundlagen des Sicherheitsdesigns
OPA-Zielgruppenbindung: Das GCP-JWT wird mit der OPA-URL als Zielgruppe angefordert. Selbst wenn es abgefangen wird, kann es auf keinem anderen System wiederverwendet werden.
Kryptografische Verifizierung: OPA ruft die öffentlichen Schlüssel von Google ab und verifiziert die JWT-Signatur, bevor ein Token ausgestellt wird. Ein gefälschtes oder manipuliertes JWT schlägt fehl.
Strikte Time-to-Live-Ablaufzeiten (TTL): Das GCP-JWT läuft nach einer Stunde ab. Das OPA-Token ist für die Dauer der Session gültig. Das SSH-Zertifikat ist für den definierten Zeitraum gültig. Nichts bleibt erhalten.
Konfiguration einer Okta Privileged Access-Workload-Verbindung für GCP
Anforderungen und Voraussetzungen
GCP-Account: Die Abrechnung muss aktiviert sein und Sie müssen über Inhaber- oder Bearbeiterrechte für das Projekt verfügen.
gcloud CLI: Auf dem lokalen Rechner installiert und authentifiziert.
OPA-Tenant: Okta Privileged Access, lizenziert und über Ihre Tenant-URL (z. B. [https://YOUR-TEAM.pam.okta.com]) zugänglich.
DevOps-Admin-Rolle: In OPA erforderlich, um die Workload-Verbindung zu erstellen.
Sicherheitsadmin-Rolle: Erforderlich in OPA, um die Verbindung zu aktivieren, die Workload-Rolle zu erstellen und die Richtlinie zu erstellen.
Schritt 1: GCP-Infrastruktur erstellen
Führen Sie die folgenden Befehle auf Ihrem lokalen Rechner aus.
1.1 Projekt erstellen und APIs aktivieren (GCP)
PROJECT_ID="IHRE_PROJEKT_ID"
ZONE="VM_STANDORT"
gcloud projects create "$PROJECT_ID" --name="YOUR_PROJECT_ID"
gcloud config set project "$PROJECT_ID"
gcloud services enable compute.googleapis.com iam.googleapis.com
11.2 Service-Account für Runner-VM erstellen (GCP)
Dieser Service-Account ist die Maschinenidentität des Runners. Es wird keine Schlüsseldatei generiert. Die Verknüpfung der VM mit diesem Account bei der Erstellung ist der Identitätsnachweis.
gcloud iam service-accounts create opa-runner-sa \
--display-name="OPA Runner Service Account" \
--project="$PROJECT_ID"
Generierte Service-Account-E-Mail: opa-runner-sa@<IHRE_PROJEKT_ID>.iam.gserviceaccount.com
1.3 Runner- und Ziel-Compute-Instanzen erstellen (GCP)
# Runner-VM
gcloud compute instances create runner-vm \
--zone="$ZONE" \
--machine-type=e2-medium \
--image-family=ubuntu-2204-lts \
--image-project=ubuntu-os-cloud \
--service-account=opa-runner-sa@${PROJECT_ID}.iam.gserviceaccount.com \
--scopes=https://www.googleapis.com/auth/cloud-platform \
--tags=opa-runner
# Ziel-VM
gcloud compute instances create target-vm \
--zone="$ZONE" \
--machine-type=e2-medium \
--image-family=ubuntu-2204-lts \
--image-project=ubuntu-os-cloud \
--tags=opa-target
Hinweis: Die oben angegebenen Server werden mit „machine-type“ : „e2-medium “ und „image-family“ : „ubuntu-2204-lts“ eingerichtet. Sie können Ihren eigenen Maschinentyp und Ihre eigene Image-Familie auswählen.
1.4 Firewall-Regeln konfigurieren (GCP)
# Internen SSH-Zugriff vom Runner auf das Ziel zulassen
gcloud compute firewall-rules create allow-runner-to-target \
--allow=tcp:22 \
--source-tags=opa-runner \
--target-tags=opa-target \
--project="$PROJECT_ID"
# Ausgehenden HTTPS-Datenverkehr vom Ziel für die Kommunikation des OPA-Agenten zulassen
gcloud compute firewall-rules create allow-egress-opa \
--direction=EGRESS \
--allow=tcp:443 \
--target-tags=opa-target \
--project="$PROJECT_ID"
Schritt 2: Runner-VM einrichten (GCP)
Die Runner-VM benötigt nur die sft-Binärdatei. Sie wird nicht für Benutzer:innen in OPA registriert.
# SSH-Verbindung zu Runner-VM herstellen
gcloud compute ssh runner-vm --zone="$ZONE"
# Abhängigkeiten und sft-Client-Binärdatei installieren
# Repository-Schlüssel installieren und Okta PAM-Repository hinzufügen
curl -fsSL https://dist.scaleft.com/GPG-KEY-OktaPAM-2023 | gpg --dearmor | sudo tee /usr/share/keyrings/oktapam-2023-archive-keyring.gpg > /dev/null
echo "deb [signed-by=/usr/share/keyrings/oktapam-2023-archive-keyring.gpg] https://dist.scaleft.com/repos/deb $(lsb_release -cs) okta" | sudo tee /etc/apt/sources.list.d/oktapam-stable.list
# Repository aktualisieren und SFT-Client-Tools installieren
sudo apt-get update && sudo apt-get install -y scaleft-client-tools
# Angehängten Identitätsnachweis bestätigen
curl -sf -H "Metadata-Flavor: Google" "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/email"
# Erwartete Ausgabe: opa-runner-sa@opa-workload-demo.iam.gserviceaccount.com
exit
Schritt 3: Ziel-VM einrichten
3.1 OPA-Dashboard einrichten und Server-Registrierungstoken generieren (Okta)
- Gehen Sie zu OPA Dashboard (OPA-Dashboard) → Resource Administration (Ressourcenverwaltung) → Resource Management (Ressourcenmanagement) → Create Resource Group (Ressourcengruppe erstellen) → Create Project (Projekt erstellen) oder Existing Resource Group (Vorhandene Ressourcengruppe) → Save (Speichern).
- Name: GCP_Servers_Proj
- Beschreibung: GCP-Zielserver für Workload-Demo
- Navigieren Sie zu GCP_Servers_Proj → Project (Projekt) → Resource Type - Servers (Ressourcentyp – Server) → Settings (Einstellungen) → Enrollment Token (Registrierungstoken) → View (Anzeigen) → Create Enrollment Token (Registrierungstoken erstellen)
- Select OS (Betriebssystem auswählen): Linux
- Generiertes Registrierungstoken kopieren
3.2 sftd-Agent auf Ziel-VM installieren und starten (GCP-basiert)
# SSH-Verbindung zur Ziel-VM herstellen
gcloud compute ssh target-vm --zone="$ZONE"
# Abhängigkeiten und sftd-Daemon installieren
# Repository-Schlüssel installieren und Okta PAM-Repository hinzufügen
curl -fsSL https://dist.scaleft.com/GPG-KEY-OktaPAM-2023 | gpg --dearmor | sudo tee /usr/share/keyrings/oktapam-2023-archive-keyring.gpg > /dev/null
echo "deb [signed-by=/usr/share/keyrings/oktapam-2023-archive-keyring.gpg] https://dist.scaleft.com/repos/deb $(lsb_release -cs) okta" | sudo tee /etc/apt/sources.list.d/oktapam-stable.list
# Repository aktualisieren und SFT-Server-Tools installieren
sudo apt-get update && sudo apt-get install -y scaleft-server-tools
# Konfigurationstoken für Registrierung speichern
sudo mkdir -p /var/lib/sftd
echo "IHR_REGISTRIERUNGSTOKEN" | sudo tee /var/lib/sftd/enrollment.token > /dev/null
# Dateiberechtigung aus Sicherheitsgründen einschränken
sudo chmod 600 /var/lib/sftd/enrollment.token
# Daemon-Status aktivieren und überprüfen
sudo systemctl enable sftd && sudo systemctl start sftd
sleep 5
sudo systemctl status sftd --no-pager
exit
3.3 Registrierung überprüfen
Überprüfen Sie auf dem OPA-Dashboard, ob der Status „Enrolled“ (Registriert) angezeigt wird: OPA Dashboard → GCP_Servers_Proj → Servers → target-vm (Status: Enrolled) ✓ („OPA Dashboard“ → „GCP_Servers_Proj“ → „Server“ → „target-vm“ (Status: Registriert))
Schritt 4: OPA-Workload-Verbindung und -Rollen konfigurieren (Okta)
4.1 Workload-Verbindung erstellen und aktivieren (DevOps-Admin und Sicherheitsadmin)
Navigieren Sie im OPA-Dashboard zu DevOps - Administration (DevOps – Verwaltung) → Workload - connections (Verbindungen – Verbindungen) → Create Workload Conection (Workload-Verbindung erstellen).
Wählen Sie Google Cloud Provider.
Geben Sie die Details der App-Client-ID ein:
App-Client-ID: Geben Sie Ihre App-Client-ID ein (den Service-Account, der im vorherigen Schritt innerhalb des GCP-Projekts erstellt wurde)
Scope to Email (E-Mail-Bereich) aktivieren (E-Mail wird automatisch generiert)
Parameter definieren:
Verbindungsname: OKTA-OPA-Demo
Token TTL: 3.600 Sekunden
Erforderliche Claims: aud = [https://YOUR-TEAM.pam.okta.com] und iss = [https://accounts.google.com]
Klicken Sie auf Create Workload Connection (Workload-Verbindung erstellen).
- Wechseln Sie zu DevOps-Admin: Öffnen Sie OKTA-OPA-Demo → Actions → Activate (Aktionen → Aktivieren).
4.2 Workload-Rolle erstellen (Sicherheitsadmin)
Gehen Sie zu Security Administration (Sicherheitsverwaltung) → Workload roles (Workload-Rollen) → Create Workload Role (Workload-Rolle erstellen).
Attribute konfigurieren:
Name: OKTA-OPA-WR
Workload-Verbindung: OKTA-OPA-Demo
Klicken Sie auf Save Workload Role (Workload-Rolle speichern). OPA weist einen automatischen Linux-Benutzernamen zu (wl_okta_opa_wr).
4.3 Richtlinie und Regeln konfigurieren (Sicherheitsadmin)
Gehen Sie zu Security Administration (Sicherheitsverwaltung) → Policies (Richtlinien) → Create Policy (Richtlinie erstellen) → Default (Standard).
Name: NHI-Serverzugriff
Select resource groups (Ressourcengruppen auswählen): Alle Ressourcengruppen
Fügen Sie unter Add principals (Principals hinzufügen) die Workload-Rolle „OKTA-OPA-WR“ hinzu.
Wählen Sie unter „Add rule to policy“ (Regel zur Richtlinie hinzufügen) die Option „Server Rule“ (Serverregel) aus:
Regelname: SSH für Workload-Rolle zulassen
Session-Typ: Server-SSH-Session
Accounts: „Select accounts by name“ (Accounts nach Namen auswählen) aktivieren → Ziel: target-vm/root
Wichtig: Aktivieren Sie MFA oder Access Requests NICHT (Headless-Jobs können keine interaktiven Eingabeaufforderungen beantworten).
Klicken Sie auf „Save Policy“ (Richtlinie speichern) und gehen Sie dann zu „Actions → Publish“ (Aktionen → Veröffentlichen).
Schritt 5: Ausführung überprüfen und testen (GCP-basiert)
5.1 Automatisierungsskript für die Verifizierung vorbereiten
Stellen Sie erneut eine SSH-Verbindung zu runner-vm her und bereiten Sie das Automatisierungsskript vor:
gcloud compute ssh runner-vm --zone="$ZONE"
#!/bin/bash
#
# OPA Workload Identity Demo-Skript
# Basierend auf: Okta Privileged Access – Einführung in Workload-Identitäten
#
# ─── UMGEBUNGSVARIABLEN FESTLEGEN ───────────────────────────────────────────────
# Zielgruppe = Ihre OPA-Adresse (muss dem aud-Claim entsprechen, den OPA erwartet)
AUDIENCE="https://opa-gcp.pam.okta.com"
# GCP-Metadaten-URL zum Abrufen des JWT
METADATA_URL="http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity?audience=${AUDIENCE}&format=full"
# OPA-Team und Adresse (sft liest diese aus der Umgebung)
export SFT_TEAM="opa-gcp"
export OPA_ADDR="https://demo-opa-gcp-demo.pam.okta.com"
# Namen müssen exakt mit dem übereinstimmen, was Sie im OPA-Dashboard erstellt haben
CONNECTION_NAME="okta-opa-demo"
ROLE_NAME="okta_opa_wr"
# Zielservername (wie in OPA registriert – der Hostname)
TARGET_SERVER="target-vm"
# ─── SCHRITT 1: GCP IDENTITY JWT ABRUFEN ────────────────────────────────────────────
echo "------------------------------------------------------------"
echo „SCHRITT 1: Abrufen des JWT vom GCP-Metadatenserver“
echo "------------------------------------------------------------"
ID_TOKEN=$(curl -s -H "Metadata-Flavor: Google" "$METADATA_URL" | tr -d '\n\r')
if [[ "$ID_TOKEN" == eyJ* ]]; then
GCP_JWT="$ID_TOKEN"
# Dekodieren und Gültigkeitszeitraum anzeigen
PAYLOAD=$(echo "$GCP_JWT“ | cut -d. -f2 | base64 --decode 2>/dev/null)
EXP=$(echo "$PAYLOAD" | jq -r '.exp')
ISS=$(echo "$PAYLOAD" | jq -r '.iss')
EMAIL=$(echo "$PAYLOAD" | jq -r '.email')
NOW=$(date +%s)
DIFF=$((EXP - NOW))
echo "Aussteller : $ISS"
echo "E-Mail : $EMAIL"
echo "Zielgruppe: $AUDIENCE"
echo ""
echo "WERT VON GCP_JWT:"
echo "${GCP_JWT:0:80}... (gekürzt)"
echo ""
echo "Erfolg: JWT erhalten."
echo "Token ist noch für weitere $DIFF Sekunden gültig (ca. $((DIFF / 60)) Minuten)."
alternativ
echo "FEHLER: Abrufen des JWT vom Metadatenserver fehlgeschlagen."
echo "Stellen Sie sicher, dass dieses Skript auf einer GCP-VM ausgeführt wird, der ein Service-Account zugewiesen ist."
exit 1
fi
# Export zur Verwendung durch sft
export GCP_TOKEN="$GCP_JWT"
echo ""
# ─── SCHRITT 2: GCP-JWT GEGEN OPA-TOKEN EINTAUSCHEN ──────────────────────────────────
echo "------------------------------------------------------------"
echo "SCHRITT 2: Workload mit OPA authentifizieren, um OPA_TOKEN zu erhalten"
echo "------------------------------------------------------------"
echo "Wird ausgeführt:"
echo "sft wl authenticate --team $SFT_TEAM \\"
echo " --connection $CONNECTION_NAME \\"
echo " --role-hint $ROLE_NAME \\"
echo " --jwt-env GCP_TOKEN"
echo ""
OPA_TOKEN=$(sft wl authenticate \
--team "$SFT_TEAM" \
--connection "$CONNECTION_NAME“ \
--role-hint "$ROLE_NAME" \
--jwt-env GCP_TOKEN 2>&1 | tr -d '\n\r')
export OPA_TOKEN
if [[ "$OPA_TOKEN“ == *„error“* ]] || [[ -z "$OPA_TOKEN“ ]]; then
echo "FEHLER: OPA_TOKEN konnte nicht abgerufen werden."
echo "Detail: $OPA_TOKEN"
echo ""
echo "Checkliste:"
echo " 1. Ist der Status der Workload-Verbindung AKTIV (nicht Entwurf)?"
echo " 2. Stimmt der Verbindungsname '$CONNECTION_NAME' genau überein?"
echo " 3. Entspricht dem aud-Claim '$AUDIENCE'?"
echo " 4. Stimmt der E-Mail-Claim mit dem SA in der Workload Connection überein?"
exit 1
alternativ
echo "ERFOLG: OPA_TOKEN erhalten."
echo ""
echo "WERT VON OPA_TOKEN:"
echo "${OPA_TOKEN:0:80}... (gekürzt)"
fi
echo ""
# ─── SCHRITT 3: OPA-TOKEN FÜR DEN ZUGRIFF AUF DEN ZIELSERVER VERWENDEN ───────────────────────
echo "------------------------------------------------------------"
echo "SCHRITT 3: OPA_TOKEN mit sft-Befehlen testen"
echo "------------------------------------------------------------"
echo ""
echo "3a. Auflistung der Server, auf die dieser Workload zugreifen kann:"
sft list-servers
echo ""
echo "3b. Verbindung zu $TARGET_SERVER als root herstellen und einen Befehl ausführen:"
sft ssh --command "hostname && whoami && date && echo 'Workload access SUCCESS'" \
"$TARGET_SERVER"
echo ""
echo "------------------------------------------------------------"
echo "FERTIG: Workload-Identity-Demo abgeschlossen."
echo "Überprüfen Sie das Okta System Log auf zwei Ereignisse:"
echo " 1. Token-Austausch (Authentifizierung)"
echo " 2. SSH-Login beim Server"
echo "------------------------------------------------------------"
5.2 Automatisierungsskript ausführen
Führen Sie das Automatisierungsskript aus:
$ bash ~/opa-workload-test.sh
5.3 Erwartete Ausgabe und Audit-Logs
Bei der Ausführung gibt das Terminal Folgendes zurück:
Die Ausgabe zeigt einen vollständigen Zero-Credential-SSH-Authentifizierungsablauf in drei Schritten:
GCP-Identity-Abruf: Die Runner-VM fordert ein plattformsigniertes JWT direkt von den Google-Cloud-Metadaten (accounts.google.com) für den Service-Account opa-runner-sa an, um dessen Identität ohne gespeicherte Secrets festzustellen.
SToken-Austausch: Das Skript übergibt das GCP-JWT über sft wl authenticate an Okta Privileged Access. OPA verifiziert die kryptografische Signatur von Google und stellt ein OPA_TOKEN aus, das der Rolle okta_opa_wr zugeordnet ist.
Passwortlose Ausführung: OPA erkennt target-vm und verwendet ein zeitbasiertes, kurzlebiges SSH-Zertifikat, um Befehle auf dem Remote-Server auszuführen.
Die Antwort des Zielservers zeigt seinen Hostnamen (target-vm), den vom System zugewiesenen Workload-Benutzer (wl_okta_opa_wr) und den Ausführungszeitstempel an. Dies bestätigt einen vollständigen, auditierbaren SSH-Zugriff, der ausschließlich durch Laufzeit-Plattformnachweise anstelle von statischen Keys gesteuert wird.
Auditierbarkeit und Systemprotokolle
Jeder Authentifizierungszyklus generiert strukturierte Ereignisse im Okta System Log (Okta Admin-Konsole → „Reports “(Berichte) → „System Log“ (Systemprotokoll)).
Sie können den folgenden Filter anwenden, um die erforderlichen Systemprotokolle anzuzeigen:
eventType eq "pam.user_creds.issue" and actor.type eq "WorkloadPrincipal"
Statische Secrets in der Automatisierungsinfrastruktur eliminieren
Indem permanenter SSH-Keys und Service-Account-Dateien durch kryptografische, plattformsignierte Identity-Nachweise ersetzt werden, können Ihre Entwicklungs- und Security-Teams einen echten Zero-Trust-Serverzugriff implementieren, ohne Automatisierungspipelines zu unterbrechen. Okta Privileged Access vereinfacht das Identity and Access Management (IAM) für nicht-menschliche Identitäten, indem es die dynamische Workload-Föderation und die Ausstellung kurzlebiger Zertifikate mit umfassender Auditierbarkeit auf einer einzigen Kontrollebene kombiniert.
Erfahren Sie, wie Okta Privileged Access die Identitäten von Maschinen und Menschen in all Ihren Cloud-Ressourcen schützt.
