Freigeben über


Bereitstellen und Konfigurieren einer Anwendung mithilfe der Workloadidentität in einem Azure Red Hat OpenShift Managed Identity Cluster

In diesem Artikel werden die folgenden Aufgaben erläutert:

  • Erstellen Sie eine Microsoft Entra-Workload-ID und ein Kubernetes-Dienstkonto.
  • Konfigurieren der verwalteten Identität für den Tokenverbund
  • Erstellen Sie einen Microsoft Azure Key Vault mit einem neuen Geheimnis und den Rollenzuweisungen (für eine Demo).
  • Bereitstellen der Workload und Überprüfen der Authentifizierung mit der Workloadidentität
  • Gewähren Sie einem Pod im Cluster Zugriff auf geheime Schlüssel in einem Azure Key Vault.

Der Prozess umfasst Folgendes:

  • Rufen Sie die OpenID Connect(OIDC)-Aussteller-URL ab.
  • Erstellen Sie eine vom Benutzer zugewiesene verwaltete Identität für Ihre Anwendung.
  • Führen Sie die Rollenzuordnung für die gewünschte Ressource aus.
  • Erstellen Sie ein Kubernetes-Dienstkonto.
  • Legen Sie die Anmerkung für das Dienstkonto fest.
  • Erstellen Sie die federierten Anmeldeinformationen.
  • Stellen Sie die Anwendung bereit, und stellen Sie folgendes sicher:
    • Der .spec.serviceAccountName Satz ist festgelegt.
    • Die Bezeichnung azure.workload.identity/use: "true" wird festgelegt.

Voraussetzungen

Sie benötigen einen vorhandenen azure Red Hat OpenShift-Cluster mit verwalteter Identität.

Überprüfen der Pod-Identity-Webhook-Bereitstellung

Es gibt einen Mutating Admission Webhook, der ein signiertes Dienstkontotoken in einen bekannten Pfad projiziert und Authentifizierungsbezogene Umgebungsvariablen in die Anwendungs pods eingibt. Weitere Informationen finden Sie unter Mutating Admission Webhook.

Stellen Sie sicher, dass die Anmerkung target.workload.openshift.io/management für die Pod-Identity-Webhook-Bereitstellung im openshift-cloud-credential-operator Namespace festgelegt ist, indem Sie den folgenden Befehl ausführen:

oc describe deployment pod-identity-webhook -n openshift-cloud-credential-operator | grep 'target.workload.openshift.io/management'

Es sollte eine Antwort wie folgt angezeigt werden:

Annotations: target.workload.openshift.io/management: {"effect": "PreferredDuringScheduling"}

Wenn Sie feststellen, dass die Anmerkung fehlt, öffnen Sie einen Supportfall.

Exportieren von Umgebungsvariablen

Legen Sie zunächst Umgebungsvariablen fest, die Ihrer vorhandenen verwalteten Identität azure Red Hat OpenShift-Cluster entsprechen. Stellen Sie sicher, dass Sie die richtigen RESOURCE_GROUP, , LOCATION, CLUSTER_NAMENamespaces und gewünschten Identitätsnamen festlegen:

export KEYVAULT_NAME="azwi-kv-$(openssl rand -hex 2)"
export KEYVAULT_SECRET_NAME="my-secret"
export KEYVAULT_LOCATION="eastus"
export RESOURCE_GROUP="<ARO_CLUSTER_RESOURCE_GROUP>"
export CLUSTER_NAME="<ARO_CLUSTER_NAME>"
export SUBSCRIPTION="$(az account show --query id --output tsv)"
export USER_ASSIGNED_IDENTITY_NAME="example-user-assigned-identity"
export FEDERATED_IDENTITY_CREDENTIAL_NAME="example-federated-identity"
export SERVICE_ACCOUNT_NAMESPACE="example-project"
export SERVICE_ACCOUNT_NAME="example-workload-identity-sa"

Abrufen der OIDC-Zertifikataussteller-URL

Rufen Sie die Azure Red Hat OpenShift-Cluster-OIDC-Aussteller-URL mit OpenShift CLI (OC) ab, und legen Sie die Umgebungsvariable fest:

export ARO_OIDC_ISSUER="$(oc get authentication cluster -o jsonpath='{.spec.serviceAccountIssuer}')"

Wenn Sie keinen Clusterzugriff haben, rufen Sie optional die Azure Red Hat OpenShift Cluster OIDC-Aussteller-URL mithilfe der Azure CLI ab:

export ARO_OIDC_ISSUER="$(az aro show --subscription "${SUBSCRIPTION}" \
    --name "${CLUSTER_NAME}" \
    --resource-group "${RESOURCE_GROUP}" \
    --query "clusterProfile.oidcIssuer" \
    --output tsv)"

Überprüfen Sie, ob die richtige URL festgelegt ist:

echo $ARO_OIDC_ISSUER
https://eastus.oic.aro.azure.net/00000000-0000-0000-0000-000000000000/11111111-1111-1111-1111-111111111111

Standardmäßig wird der Aussteller auf die Basis-URL https://{region}.oic.aro.azure.net/{tenant_id}/{uuid} festgelegt, wobei der Wert für {region} dem Speicherort entspricht, an dem der Azure Red Hat OpenShift-Cluster bereitgestellt wird. Der Wert {uuid} stellt den OIDC-Schlüssel dar, bei dem es sich um eine unveränderliche, zufällig generierte, clusterspezifische GUID handelt.

Erstellen einer Beispielressource

In diesem Beispiel wird ein neuer Microsoft Azure Key Vault mit einem neuen geheimen Schlüssel erstellt und später über die Microsoft Entra Workload-ID aufgerufen. Verwenden Sie das Azure-Befehlszeilentool az , um den Schlüsseltresor zu erstellen, auf den später zugegriffen wird.

Stellen Sie sicher, dass Sie sich die Rolle der Azure-rollenbasierten Zugriffssteuerung (Azure RBAC) Key Vault Secrets Officer zuweisen.

# If necessary, create the Resource Group
az group create --resource-group "${RESOURCE_GROUP}" --location "${KEYVAULT_LOCATION}"

# Create the Keyvault and set a secret value
az keyvault create --resource-group "${RESOURCE_GROUP}" --location "${KEYVAULT_LOCATION}" --name "${KEYVAULT_NAME}"
az keyvault secret set --vault-name "${KEYVAULT_NAME}" --name "${KEYVAULT_SECRET_NAME}" --value "Hello world"

# Create an environment variable for the key vault URL:
export KEYVAULT_URL="$(az keyvault show --resource-group ${RESOURCE_GROUP} --name ${KEYVAULT_NAME} --query properties.vaultUri --output tsv)"

# Create an environment variable for the key vault Resource ID:
export KEYVAULT_RESOURCE_ID=$(az keyvault show --resource-group "${RESOURCE_GROUP}" --name "${KEYVAULT_NAME}" | jq -r '.id')

Erstellen einer verwalteten Identität und Erteilen der Berechtigung für den Zugriff auf Azure Key Vault

Erstellen Sie in den nächsten Schritten eine vom Benutzer zugewiesene verwaltete Identität und die entsprechende Rollenzuweisung:

# Create the identity
az identity create --name "${USER_ASSIGNED_IDENTITY_NAME}" --resource-group "${RESOURCE_GROUP}"

# Assign Key Vault Secrets User to the identity
export USER_ASSIGNED_IDENTITY_OBJECT_ID="$(az identity show --name "${USER_ASSIGNED_IDENTITY_NAME}" --resource-group "${RESOURCE_GROUP}" --query 'principalId' -o tsv)"
export USER_ASSIGNED_IDENTITY_CLIENT_ID="$(az identity show --name "${USER_ASSIGNED_IDENTITY_NAME}" --resource-group "${RESOURCE_GROUP}" --query 'clientId' -o tsv)"

az role assignment create --assignee-object-id "${USER_ASSIGNED_IDENTITY_OBJECT_ID}" --role "Key Vault Secrets User" --scope "${KEYVAULT_RESOURCE_ID}" --assignee-principal-type ServicePrincipal

Erstellen eines Kubernetes-Dienstkontos

  • Erstellen Sie auf der OpenShift Container Platform das Dienstkonto unter Verwendung der zuvor erstellten azure.workload.identity/client-id.
  • Weitere Informationen zum Erstellen von Dienstkonten finden Sie unter Erstellen von Dienstkonten.

Erstellen Sie das neue Projekt für diese Beispiel-App:

oc new-project ${SERVICE_ACCOUNT_NAMESPACE}

Erstellen Sie das Dienstkonto:

cat <<EOF | oc apply -f -
apiVersion: v1
kind: ServiceAccount
metadata:
  name: ${SERVICE_ACCOUNT_NAME}
  namespace: ${SERVICE_ACCOUNT_NAMESPACE}
  annotations:
    azure.workload.identity/client-id: ${USER_ASSIGNED_IDENTITY_CLIENT_ID}
EOF

Erstellen von Anmeldeinformationen für eine Verbundidentität

Erstellen Sie einen Azure-Verbundidentitätsnachweis, der das Dienstkonto in der OpenShift-Containerplattform mit der benutzerdefinierten verwalteten Identität in Azure verknüpft.

az identity federated-credential create \
--name "${FEDERATED_IDENTITY_CREDENTIAL_NAME}" \
--identity-name "${USER_ASSIGNED_IDENTITY_NAME}" \
--resource-group "${RESOURCE_GROUP}" \
--issuer "${ARO_OIDC_ISSUER}" \
--subject "system:serviceaccount:${SERVICE_ACCOUNT_NAMESPACE}:${SERVICE_ACCOUNT_NAME}"

Bereitstellen der Anwendung

Das OpenShift Container Platform Service Account ist jetzt wie erwartet konfiguriert. Beachten Sie, dass die .spec.serviceAccountName Einstellung festgelegt ist und die Bezeichnung azure.workload.identity/use: "true" verwendet wird:

cat <<EOF | oc apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: quick-start
  namespace: ${SERVICE_ACCOUNT_NAMESPACE}
  labels:
    azure.workload.identity/use: "true"
spec:
  serviceAccountName: ${SERVICE_ACCOUNT_NAME}
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
    - image: ghcr.io/azure/azure-workload-identity/msal-go
      name: oidc
      securityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop: [ "ALL" ]
      env:
        - name: KEYVAULT_URL
          value: ${KEYVAULT_URL}
        - name: SECRET_NAME
          value: ${KEYVAULT_SECRET_NAME}
EOF

Überprüfen Sie die bereitgestellte Arbeitslast

Überprüfen Sie in der neu bereitgestellten Workload, ob die Umgebungsvariablen und das projizierte Volume vorhanden sind. Führen Sie den folgenden Befehl aus:

oc describe pod quick-start

Sehen Sie sich die folgende Beispielausgabe an:

[..]
 Environment:
   KEYVAULT_URL:                https://azwi-kv-45ff.vault.azure.net/
   SECRET_NAME:                 my-secret
   AZURE_CLIENT_ID:             00001111-aaaa-2222-bbbb-3333cccc4444
   AZURE_TENANT_ID:             aaaabbbb-0000-cccc-1111-dddd2222eeee
   AZURE_FEDERATED_TOKEN_FILE:  /var/run/secrets/azure/tokens/azure-identity-token
   AZURE_AUTHORITY_HOST:        https://login.microsoftonline.com/
[..]
Volumes:
[..]
 azure-identity-token:
   Type:                    Projected (a volume that contains injected data from multiple sources)
   TokenExpirationSeconds:  3600

Überprüfen Sie in den Protokollen, dass die Workload mithilfe der eingefügten Schlüssel auf den Microsoft Azure Key Vault zugreifen konnte:

$ oc logs quick-start
I0816 09:43:37.961113       1 main.go:63] "successfully got secret" secret="Hello world"

Nächste Schritte