Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
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.serviceAccountNameSatz ist festgelegt. - Die Bezeichnung
azure.workload.identity/use: "true"wird festgelegt.
- Der
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"