Sichere Azure DevOps Automatisierung: Service Principals anstelle von PATs

Nachteile der Verwendung eines Personal Access Token (PAT)

Die Verwendung von Personal Access Tokens (PATs) für automatisierte Prozesse bringt diverse Herausforderungen in Bezug auf Sicherheit, Verwaltung und Compliance mit sich.

1. Sicherheitsrisiken

Ein PAT ist an ein bestimmtes Benutzerkonto gebunden. Kompromittiert jemand diesen Token, erhält er Zugriff auf alle Ressourcen, für die der Benutzer berechtigt ist. Diese Kontobindung macht PATs anfällig für Missbrauch, insbesondere in automatisierten Umgebungen, wo eine bessere Kontrolle und Trennung von Benutzer- und Systemrechten erforderlich sind.

2. Verwaltungskomplexität

PATs haben eine begrenzte Gültigkeitsdauer und müssen regelmässig manuell erneuert werden. Läuft ein Token ab, kann dies zu unerwarteten Unterbrechungen automatisierter Prozesse führen. In Teams mit mehreren Tokens wird das Nachverfolgen und rechtzeitige Erneuern schnell zur komplexen Aufgabe, die zusätzliche Ressourcen beansprucht. Hier könnte eine effiziente IT-Strategie helfen, um die Verwaltung zu optimieren.

3. Sicherheitsrisiko durch Personalwechsel

Bei Personalwechsel bleiben persönliche PATs bestehen, bis sie manuell widerrufen werden. Wenn die Verwaltung unzureichend ist, könnten ehemalige Mitarbeiter oder Partner weiterhin Zugriff auf geschützte Ressourcen haben. Diese zentrale Verwaltung der Zugriffsrechte ist bei PATs problematisch und birgt Sicherheitslücken.

Vorteile von Service Principals für die Automatisierung

Die Implementierung von Service Principals in Azure DevOps eröffnet eine Vielzahl von Vorteilen, die über die reine Automatisierung hinausgehen.

1. Erhöhte Sicherheit

Service Principals sind speziell für Automatisierungen und Anwendungen konzipiert, wodurch sie weniger anfällig für Missbrauch sind. Da sie unabhängig von Benutzerkonten operieren und keine persönlichen Anmeldeinformationen benötigen, wird das Risiko von Sicherheitsvorfällen erheblich reduziert. Zudem ermöglichen sie eine granularere Steuerung der Zugriffsrechte, sodass nur die erforderlichen Berechtigungen für spezifische Aufgaben vergeben werden.

2. Effizientes Berechtigungsmanagement

Die Verwaltung von Zugriffsrechten in DevOps-Pipelines kann eine Herausforderung sein. Mit Service Principals wird der Zugriff auf die absolut notwendigen Ressourcen beschränkt, was überflüssige Berechtigungen minimiert und die Übersichtlichkeit erhöht. Das Prinzip des minimalen Zugriffs (Principle of Least Privilege) ermöglicht es, spezifische Rollen und Berechtigungen für jede Pipeline festzulegen und Sicherheitslücken zu vermeiden. Dies ist besonders wichtig für die digitale Transformation, wo klare Zugriffsstrukturen gefordert sind.

3. Compliance-gerechte Lösungen

Für Unternehmen mit strengen Compliance-Vorgaben bieten Service Principals die erforderlichen Kontrollmechanismen und Transparenz. Diese Lösung entspricht den Best Practices zur Einhaltung von Datenschutz- und Sicherheitsanforderungen und erleichtert die Nachverfolgbarkeit von Zugriffen – ein zentraler Aspekt bei Audits. In Kombination mit modernen Cloud-Lösungen können Unternehmen ihre Sicherheitsstandards weiter erhöhen.

Insgesamt bieten Service Principals eine robuste Lösung für die Automatisierung in Azure DevOps und adressieren die häufigsten Herausforderungen, die mit der Verwendung von Personal Access Tokens verbunden sind. Die Implementierung dieser Lösung ist nicht nur ein Schritt in Richtung einer sicheren Infrastruktur, sondern auch ein Beitrag zu einer effizienten und skalierbaren DevOps-Praxis.

Azure DevOps Pipeline Template für Service Principals

Um den Prozess der Verwendung von Service Principals zu erleichtern, haben wir eine Azure DevOps Pipeline Template entwickelt, welches Service Principals nutzt, um zeitlich begrenzte PATs zu generieren. So können Entwickler sicherstellen, dass sie Compliance-Vorgaben erfüllen, ohne sich um die Details kümmern zu müssen.

1. Azure DevOps Pipeline-Template hinzufügen

Fügen Sie die Vorlage und das Skript zu Ihrem bestehenden CI/CD-Repo hinzu oder erstellen Sie ein neues. Dies stellt sicher, dass alle erforderlichen Komponenten bei der Ausführung der Pipeline verfügbar sind.

2. Service Principal erstellen

Erstellen Sie den Service Principal und speichern Sie die Anmeldedaten. Nutzen Sie dafür entweder den Azure Key Vault oder die Azure DevOps Pipeline Library. Berechtigen Sie den Service Principal in Azure DevOps genauso wie einen Benutzer, der die Aufgaben ausführen soll.

3. CI/CD-Repo in der Pipeline verknüpfen

Verwenden Sie die vordefinierte Aufgabe aus der Vorlage, um das CI/CD-Repository mit der Pipeline zu verknüpfen. Dies gewährleistet, dass die richtigen Ressourcen während der Ausführung der Pipeline zur Verfügung stehen.

4. Testen Sie den Ablauf

Das Script im Template fragt automatisch einen temporären PAT ab und stellt diesen per Environment variable den folgenden Schritten in der Pipeline zur Verfügung.

Diese Lösung reduziert die Komplexität und sorgt gleichzeitig für die Einhaltung der Compliance-Richtlinien in Azure DevOps. Durch den Einsatz von Service Principals wird die Automatisierung nicht nur sicherer, sondern auch effizienter, da die Abhängigkeit von manuell verwalteten PATs entfällt.

Anhang 1: Bash Script

#!/bin/bash

# Parse command-line arguments
while [[ "$#" -gt 0 ]]; do
    case $1 in
        --tenantId) tenant_id="$2"; shift ;;
        --clientId) client_id="$2"; shift ;;
        --clientSecret) client_secret="$2"; shift ;;
        *) echo "Unknown parameter passed: $1"; exit 1 ;;
    esac
    shift
done

# Check if required parameters are provided
if [[ -z "$tenant_id" || -z "$client_id" || -z "$client_secret" ]]; then
    echo "Error: Missing required parameters."
    echo "Usage: $0 --tenantId  --clientId  --clientSecret "
    exit 1
fi

# Get access token
response=$(curl -s -X POST -d "grant_type=client_credentials&client_id=$client_id&client_secret=$client_secret&resource=499b84ac-1321-427f-aa17-267ca6975798/.default" \
https://login.microsoftonline.com/"$tenant_id"/oauth2/token)

access_token=$(echo "$response" | jq -r '.access_token')

if [ "$access_token" == "null" ]; then
    echo "Error: Unable to get access token."
    echo "Response: $response"
    exit 1
fi

export ADO_AT="$access_token"
echo "##vso[task.setvariable variable=ADO_AT]$access_token"

Anhang 2: Azure DevOps Pipeline Template

parameters:
  - name: tenantId
    type: string
  - name: clientId
    type: string
  - name: clientSecret
    type: string

steps:
  - checkout: self # Check out the repository where the pipeline runs
  - checkout: cicd-pipeline-library # Check out the pipeline library repository, to have the shell script available
  - task: Bash@3
    inputs:
      filePath: './cicd-pipeline-library/ci-templates/utils/set-azdev-sp-at-env.sh'
      arguments: '--tenantId ${{ parameters.tenantId }} --clientId ${{ parameters.clientId }} --clientSecret ${{ parameters.clientSecret }}'
    displayName: "Get and set Azure DevOps Service Principal Access Token"

Anhang 3: Beispielverwendung in einer Pipeline

trigger:
- main

resources:
  repositories:
    - repository: cicd-pipeline-library
      name: cicd-pipeline-library
      type: git
      ref: refs/tags/2024-10-final-2

pool:
  vmImage: 'ubuntu-latest'

variables:
- group: 'app-python-azdogantt'

steps:
- checkout: self

# Use service principal to get a short time PAT 
- template: ci-templates/utils/set-azdev-sp-at-env.yml@cicd-pipeline-library
  parameters:
    tenantId: $(TenantId)
    clientId: $(ClientId)
    clientSecret: $(ClientSecret)

# Run a Python script that requires the access token (AT)
- script: |
    cd app-python-azdogantt
    python src/generate_gantt.py
  env:
    ADO_ORG: $(ADO_ORG)
    ADO_PROJECT: $(ADO_PROJECT)
    ADO_TEAM: $(ADO_TEAM)
    ADO_AT: $(ADO_AT)
  displayName: 'Generate Gantt chart HTML file'