Senden von Prometheus-Daten an Azure Monitor unter Verwendung der Microsoft Entra-Authentifizierung

Artikel
04/24/2024

In diesem Artikel erfahren Sie, wie Sie Remoteschreibzugriff einrichten, um Daten von einem selbstverwalteten, in Ihrem AKS-Cluster (Azure Kubernetes Service) oder in einem Kubernetes-Cluster mit Azure Arc-Unterstützung ausgeführten Prometheus-Server unter Verwendung der Microsoft Entra-Authentifizierung zu senden.

Clusterkonfigurationen

Dieser Artikel gilt für die folgenden Clusterkonfigurationen:

Azure Kubernetes Service-Cluster
Kubernetes-Cluster mit Azure Arc-Unterstützung
Kubernetes-Cluster, der in einer anderen Cloud oder lokal ausgeführt wird

Hinweis

Für einen AKS-Cluster oder einen Kubernetes-Cluster mit Azure Arc-Unterstützung empfehlen wir, die Authentifizierung mit verwalteten Identitäten zu verwenden. Weitere Informationen finden Sie unter Senden von Prometheus-Daten an Azure Monitor unter Verwendung der Authentifizierung mit verwalteten Identitäten.

Voraussetzungen

Unterstützte Versionen

Für die Microsoft Entra ID-Anwendungsauthentifizierung sind Prometheus-Versionen größer als v2.48 erforderlich.

Azure Monitor-Arbeitsbereich

Dieser Artikel behandelt das Senden von Prometheus-Metriken an einen Azure Monitor-Arbeitsbereich. Informationen zum Erstellen eines Azure Monitor-Arbeitsbereichs finden Sie unter Verwalten eines Azure Monitor-Arbeitsbereichs.

Berechtigungen

Zum Ausführen der Schritte in diesem Artikel sind Administratorberechtigungen für den Cluster oder die Ressource erforderlich.

Einrichten einer Anwendung für Microsoft Entra ID

Der Prozess zum Einrichten des Prometheus-Remoteschreibzugriffs für eine Anwendung unter Verwendung der Microsoft Entra-Authentifizierung umfasst folgende Aufgaben:

Melden Sie eine Anwendung mit Microsoft Entra ID an.
Rufen Sie die Client-ID der Microsoft Entra-Anwendung ab.
Zuweisen der Rolle „Herausgeber von Überwachungsmetriken“ in der Datensammlungsregel des Arbeitsbereichs zur Anwendung
Erstellen eines Azure-Schlüsseltresors und Generieren eines Zertifikats
Hinzufügen eines Zertifikats zur Microsoft Entra-Anwendung
Hinzufügen eines CSI-Treibers und eines Speichers für den Cluster
Bereitstellen eines Sidecar-Containers zum Einrichten des Remoteschreibzugriffs

Die Aufgaben werden in den folgenden Abschnitten beschrieben.

Registrieren einer Anwendung mit Microsoft Entra ID

Führen Sie die Schritte zum Registrieren einer Anwendung mit Microsoft Entra ID und zum Erstellen eines Dienstprinzipals aus.

Abrufen der Client-ID der Microsoft Entra-Anwendung

Navigieren Sie im Azure-Portal zum Menü Microsoft Entra ID, und wählen Sie die Option App-Registrierungen aus.
Kopieren Sie in der Liste der Anwendungen den Wert für Anwendungs-ID (Client) für die registrierte Anwendung.

Zuweisen der Rolle „Herausgeber von Überwachungsmetriken“ in der Datensammlungsregel des Arbeitsbereichs zur Anwendung

Der Anwendung muss die Rolle „Herausgeber von Überwachungsmetriken“ in der Datensammlungsregel zugewiesen werden, die Ihrem Azure Monitor-Arbeitsbereich zugeordnet ist.

Wählen Sie im Ressourcenmenü für Ihren Azure Monitor-Arbeitsbereich die Option Übersicht aus. Wählen Sie unter Datensammlungsregel den Link aus.
Wählen Sie im Ressourcenmenü für die Datensammlungsregel die Option Zugriffssteuerung (IAM) aus.
Wählen Sie Hinzufügen und dann Rollenzuweisung hinzufügen aus.
Wählen Sie die Rolle Herausgeber von Überwachungsmetriken und dann Weiter aus.
Wählen Sie Benutzer, Gruppe oder Dienstprinzipal und dann Mitglieder auswählen aus. Wählen Sie die erstellte Anwendung und dann Auswählen aus.
Wählen Sie Überprüfen + zuweisen aus, um die Rollenzuweisung abzuschließen.

Erstellen eines Azure-Schlüsseltresors und Generieren eines Zertifikats

Wenn Sie noch nicht über einen Azure-Schlüsseltresor verfügen, erstellen Sie einen Tresor.
Erstellen Sie anhand der Anleitung Hinzufügen eines Zertifikats zu Key Vault ein Zertifikat.
Laden Sie das Zertifikat anhand der Anleitung Exportieren eines Zertifikats aus Key Vault im CER-Format herunter.

Hinzufügen eines Zertifikats zur Microsoft Entra-Anwendung

Wählen Sie im Ressourcenmenü für die Microsoft Entra-Anwendung die Option Zertifikate und Geheimnisse aus.
Wählen Sie auf der Registerkarte Zertifikate die Option Zertifikat hochladen und anschließend das von Ihnen heruntergeladene Zertifikat aus.

Warnung

Zertifikate haben ein Ablaufdatum. Benutzer*innen sind dafür verantwortlich, die Gültigkeit von Zertifikaten sicherzustellen.

Hinzufügen eines CSI-Treibers und eines Speichers für den Cluster

Hinweis

Die CSI-Treiberkonfiguration von Azure Key Vault ist nur eine der Möglichkeiten, ein Zertifikat in einen Pod einzubinden. Der Remoteschreibcontainer benötigt nur für den Wert <AZURE_CLIENT_CERTIFICATE_PATH> im Schritt Bereitstellen eines Sidecar-Containers zum Einrichten des Remoteschreibzugriffs einen lokalen Pfad zu einem Zertifikat im Pod.

Dieser Schritt ist nur erforderlich, wenn Sie bei der Clustererstellung nicht den Azure Key Vault-Anbieter für den Secrets Store CSI-Treiber aktiviert haben.

Führen Sie den folgenden Azure CLI-Befehl aus, um den Azure Key Vault-Anbieter für den Secrets Store CSI-Treiber für Ihren Cluster zu aktivieren:
```
az aks enable-addons --addons azure-keyvault-secrets-provider --name <aks-cluster-name> --resource-group <resource-group-name>
```

Führen Sie die folgenden Befehle aus, um der Identität Zugriff auf den Schlüsseltresor zu gewähren:

# show client id of the managed identity of the cluster
az aks show -g <resource-group> -n <cluster-name> --query addonProfiles.azureKeyvaultSecretsProvider.identity.clientId -o tsv

# set policy to access keys in your key vault
az keyvault set-policy -n <keyvault-name> --key-permissions get --spn <identity-client-id>

# set policy to access secrets in your key vault
az keyvault set-policy -n <keyvault-name> --secret-permissions get --spn <identity-client-id>

# set policy to access certs in your key vault
az keyvault set-policy -n <keyvault-name> --certificate-permissions get --spn <identity-client-id>

Erstellen Sie SecretProviderClass, indem Sie den folgenden YAML-Code in einer Datei mit dem Namen secretproviderclass.yml speichern. Ersetzen Sie die Werte für userAssignedIdentityID, keyvaultName, tenantId und die Objekte, die aus dem Schlüsseltresor abgerufen werden sollen. Informationen zu den zu verwendenden Werten, die verwendet werden sollen, finden Sie unter Verbinden Ihres Azure-Identitätsanbieters mit dem Azure Key Vault Secrets Store-CSI-Treiber in Azure Kubernetes Service (AKS).

# This is a SecretProviderClass example using user-assigned identity to access your key vault
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: azure-kvname-user-msi
spec:
  provider: azure
  parameters:
    usePodIdentity: "false"
    useVMManagedIdentity: "true"          # Set to true for using managed identity
    userAssignedIdentityID: <client-id>   # Set the client ID of the user-assigned managed identity to use
    keyvaultName: <key-vault-name>        # Set to the name of your key vault
    cloudName: ""                         # [OPTIONAL for Azure] if not provided, the Azure environment defaults to AzurePublicCloud
    objects:  |
      array:
        - |
          objectName: <name-of-cert>
          objectType: secret              # object types: secret, key, or cert
          objectFormat: pfx
          objectEncoding: base64
          objectVersion: ""
    tenantId: <tenant-id>                 # The tenant ID of the key vault

Führen Sie den folgenden Befehl für Ihren Cluster aus, um SecretProviderClass anzuwenden:
```
kubectl apply -f secretproviderclass.yml
```

Bereitstellen eines Sidecar-Containers zum Einrichten des Remoteschreibzugriffs

Kopieren Sie den folgenden YAML-Code, und speichern Sie ihn in einer Datei. In dem YAML-Code wird der Port 8081 als Lauschport verwendet. Ändern Sie diesen Wert im YAML-Code, falls Sie einen anderen Port verwenden.

prometheus:
  prometheusSpec:
    externalLabels:
      cluster: <CLUSTER-NAME>  

    ##	Azure Managed Prometheus currently exports some default mixins in Grafana.  
    ##  These mixins are compatible with data scraped by Azure Monitor agent on your 
    ##  Azure Kubernetes Service cluster. These mixins aren't compatible with Prometheus 
    ##  metrics scraped by the Kube Prometheus stack. 
    ##  To make these mixins compatible, uncomment the remote write relabel configuration below:
    ##	writeRelabelConfigs:
    ##	  - sourceLabels: [metrics_path]
    ##	    regex: /metrics/cadvisor
    ##	    targetLabel: job
    ##	    replacement: cadvisor
    ##	    action: replace
    ##	  - sourceLabels: [job]
    ##	    regex: 'node-exporter'
    ##	    targetLabel: job
    ##	    replacement: node
    ##	    action: replace  
    ## https://prometheus.io/docs/prometheus/latest/configuration/configuration/#remote_write
    remoteWrite:
      - url: 'http://localhost:8081/api/v1/write'
    
    # Additional volumes on the output StatefulSet definition.
    # Required only for Microsoft Entra ID based auth
    volumes:
      - name: secrets-store-inline
        csi:
          driver: secrets-store.csi.k8s.io
          readOnly: true
          volumeAttributes:
            secretProviderClass: azure-kvname-user-msi
    containers:
      - name: prom-remotewrite
        image: <CONTAINER-IMAGE-VERSION>
        imagePullPolicy: Always
        # Required only for Microsoft Entra ID based auth
        volumeMounts:
          - name: secrets-store-inline
            mountPath: /mnt/secrets-store
            readOnly: true
        ports:
          - name: rw-port
            containerPort: 8081
        livenessProbe:
          httpGet:
            path: /health
            port: rw-port
            initialDelaySeconds: 10
            timeoutSeconds: 10
        readinessProbe:
          httpGet:
            path: /ready
            port: rw-port
            initialDelaySeconds: 10
            timeoutSeconds: 10
        env:
          - name: INGESTION_URL
            value: '<INGESTION_URL>'
          - name: LISTENING_PORT
            value: '8081'
          - name: IDENTITY_TYPE
            value: aadApplication
          - name: AZURE_CLIENT_ID
            value: '<APP-REGISTRATION-CLIENT-ID>'
          - name: AZURE_TENANT_ID
            value: '<TENANT-ID>'
          - name: AZURE_CLIENT_CERTIFICATE_PATH
            value: /mnt/secrets-store/<CERT-NAME>
          - name: CLUSTER
            value: '<CLUSTER-NAME>'

Ersetzen Sie die folgenden Werte in der YAML-Datei:

Wert	Beschreibung
`<CLUSTER-NAME>`	Der Name Ihres AKS-Clusters.
`<CONTAINER-IMAGE-VERSION>`	`mcr.microsoft.com/azuremonitor/containerinsights/ciprod/prometheus-remote-write/images:prom-remotewrite-20240507.1` Die Version des Remoteschreibzugriff-Containerimages.
`<INGESTION-URL>`	Der Wert für Metrikerfassungsendpunkt auf der Seite Übersicht für den Azure Monitor-Arbeitsbereich.
`<APP-REGISTRATION -CLIENT-ID>`	Die Client-ID Ihrer Anwendung.
`<TENANT-ID>`	Die Mandanten-ID der Microsoft Entra-Anwendung.
`<CERT-NAME>`	Der Name des Zertifikats.
`<CLUSTER-NAME>`	Der Name des Clusters, in dem Prometheus ausgeführt wird.

Öffnen Sie Azure Cloud Shell, und laden Sie die YAML-Datei hoch.

Verwenden Sie Helm, um die YAML-Datei anzuwenden und Ihre Prometheus-Konfiguration zu aktualisieren:

# set the context to your cluster 
az aks get-credentials -g <aks-rg-name> -n <aks-cluster-name> 

# use Helm to update your remote write config 
helm upgrade -f <YAML-FILENAME>.yml prometheus prometheus-community/kube-prometheus-stack -namespace <namespace where Prometheus pod resides>

Überprüfung und Problembehandlung

Informationen zur Überprüfung und Problembehandlung finden Sie unter Problembehandlung bei Remoteschreibzugriff und Verwalteter Azure Monitor-Dienst für Prometheus-Remoteschreibzugriff.

Share via