Tjänstens huvudnamn med Azure Kubernetes Service (AKS)

För att interagera med Azure-API:er kräver ett AKS-kluster antingen ett Azure Active Directory (AD)-tjänstens huvudnamn eller en hanterad identitet. Ett huvudnamn för tjänsten eller en hanterad identitet krävs för att dynamiskt skapa och hantera andra Azure-resurser, till exempel en Azure-lastbalanserare eller ett containerregister (ACR).

Den här artikeln visar hur du skapar och använder ett tjänstens huvudnamn för AKS-kluster.

Innan du börjar

För att skapa ett Azure AD-huvudnamn för tjänsten måste du ha behörighet att registrera ett program med din Azure AD-klientorganisation, samt behörighet att tilldela programmet till en roll i din prenumeration. Om du inte har de behörigheter som du behöver kan du be din Azure AD- eller prenumerationsadministratör att tilldela de nödvändiga behörigheterna eller att skapa ett tjänstens huvudnamn att använda med AKS-klustret.

Om du använder ett huvudnamn för tjänsten från en annan Azure AD-klientorganisation finns det ytterligare överväganden kring vilka behörigheter som är tillgängliga när du distribuerar klustret. Du kanske inte har rätt behörighet att läsa och skriva kataloginformation. Mer information finns i Vilka är standardanvändarbehörigheterna i Azure Active Directory?

Du måste också ha installerat och konfigurerat Azure CLI version 2.0.59 eller senare. Kör az --version för att hitta versionen. Om du behöver installera eller uppgradera kan du läsa Installera Azure CLI.

Skapa och använda ett tjänstens huvudnamn automatiskt

När du skapar ett AKS-kluster i Azure Portal med kommandot az aks create skapar Azure en hanterad identitet.

Ett tjänstens huvudnamn har inte angetts i följande Azure CLI-exempel. I det här scenariot skapar Azure CLI en hanterad identitet för AKS-klustret.

az aks create --name myAKSCluster --resource-group myResourceGroup

Skapa ett tjänstens huvudnamn manuellt

Använd kommandot az ad sp create-for-rbac om du vill skapa ett tjänstens huvudnamn med Azure CLI manuellt.

az ad sp create-for-rbac --name myAKSClusterServicePrincipal

De utdata som genereras påminner om de i följande exempel. Anteckna dina egna appId och password. De här värdena används när du skapar ett AKS-kluster i nästa avsnitt.

{
  "appId": "559513bd-0c19-4c1a-87cd-851a26afd5fc",
  "displayName": "myAKSClusterServicePrincipal",
  "name": "http://myAKSClusterServicePrincipal",
  "password": "e763725a-5eee-40e8-a466-dc88d980f415",
  "tenant": "72f988bf-86f1-41af-91ab-2d7cd011db48"
}

Ange ett tjänstens huvudnamn för ett AKS-kluster

Om du vill använda ett befintligt huvudnamn för tjänsten när du skapar ett AKS-kluster med kommandot az aks create så använd parametrarna --service-principal och --client-secret för att ange appId och password från utdata från kommandot az ad sp create-for-rbac:

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --service-principal <appId> \
    --client-secret <password>

Anteckning

Om du använder ett befintligt huvudnamn för tjänsten med anpassad hemlighet ska du se till att hemligheten inte är längre än 190 byte.

Om du distribuerar ett AKS-kluster med hjälp av Azure Portal, så välj Konfigurera tjänstens huvudnamn i dialogrutan Skapa Kubernetes-kluster på sidan Autentisering. Välj Använd befintlig och ange följande värden:

  • Klient-ID för tjänstens huvudnamn är appId
  • Klienthemligheten för tjänstens huvudnamn är värdet lösenord

Bild som illustrerar hur du navigerar till Azure Vote

Delegera åtkomst till andra Azure-resurser

Tjänstens huvudnamn för AKS-klustret kan användas för att komma åt andra resurser. Om du till exempel vill distribuera ditt AKS-kluster till ett befintligt undernät för ett virtuellt Azure-nätverk eller ansluta till Azure Container Registry (ACR) måste du delegera åtkomst till dessa resurser till tjänstens huvudnamn.

Om du vill delegera behörigheter skapar du en rolltilldelning med kommandot az role assignment create. Tilldela till appId ett visst omfång, till exempel en resursgrupp eller virtuell nätverksresurs. En roll definierar därefter vilka behörigheter som tjänstens huvudnamn har på resursen, som visas i följande exempel:

az role assignment create --assignee <appId> --scope <resourceScope> --role Contributor

för en resurs måste vara ett fullständigt resurs-ID, till exempel --scope /subscriptions/ <guid> /resourceGroups/myResourceGroup eller /subscriptions/ <guid> /resourceGroups/myResourceGroupVnet/providers/Microsoft.Network/virtualNetworks/myVnet

Anteckning

Om du har tagit bort rolltilldelningen Deltagare från nodresursgruppen kan åtgärderna nedan misslyckas. Det kan ta upp 60 minuter att fylla i behörighet till kluster som använder system hanterad identitet.

Följande avsnitt beskriver vanliga delegeringar som du kan behöva göra.

Azure Container Registry

Om du använder Azure Container Registry (ACR) som containeravbildningsarkiv måste du bevilja behörigheter till tjänstens huvudnamn för ditt AKS-kluster för att läsa och hämta avbildningar. Den rekommenderade konfigurationen är för närvarande att använda kommandot az aks create eller az aks update för att integrera med ett register och tilldela lämplig roll för tjänstens huvudnamn. Detaljerade anvisningar finns i Autentisera med Azure Container Registry från Azure Kubernetes Service.

Nätverk

Du kan använda avancerade nätverk där det virtuella nätverket och undernätet eller offentliga IP-adresser finns i en annan resursgrupp. Tilldela den inbyggda rollen Nätverksdeltagare i undernätet i det virtuella nätverket. Du kan också skapa en anpassad roll med behörighet att komma åt nätverksresurserna i resursgruppen. Mer information finns i AKS-tjänstbehörigheter.

Storage

Du kan behöva åtkomst till befintliga diskresurser i en annan resursgrupp. Tilldela behörigheter till någon av följande uppsättningar:

  • Skapa en anpassad roll och definiera följande rollbehörigheter:
    • Microsoft.Compute/disks/read
    • Microsoft.Compute/disks/write
  • Eller tilldela den inbyggda rollen Lagringskontodeltagare i resursgruppen

Azure Container Instances

Om du använder Virtual Kubelet för att integrera med AKS och väljer att köra Azure Container Instances (ACI) i resursgruppen separat från AKS-klustret måste AKS-huvudnamn beviljas deltagarbehörigheter för ACI-resursgruppen.

Annat som är bra att tänka på

Tänk på följande när du använder AKS och Azure AD-tjänstens huvudnamn.

  • Tjänstobjektet för Kubernetes är en del av klusterkonfigurationen. Men använd inte identiteten för att distribuera klustret.
  • Som standard är autentiseringsuppgifterna för tjänstens huvudnamn giltiga i ett år. Du kan uppdatera eller rotera autentiseringsuppgifterna för tjänstens huvudnamn när som helst.
  • Varje tjänstobjekt är associerat med ett Azure AD-program. Tjänstens huvudnamn för ett Kubernetes-kluster kan associeras med ett giltigt Azure AD-programnamn (till exempel: https://www.contoso.org/example ). URL:en för programmet behöver inte vara en verklig slutpunkt.
  • När du anger Klient-ID för tjänstens huvudnamn använder du värdet för appId.
  • På agentnodens virtuella datorer i Kubernetes-klustret lagras autentiseringsuppgifterna för tjänstens huvudnamn i filen /etc/kubernetes/azure.json
  • Om du använder kommandot az aks create för att generera tjänstobjektet automatiskt skrivs autentiseringsuppgifterna för tjänstobjektet till filen ~/.azure/aksServicePrincipal.json på den dator som används för att köra kommandot.
  • Om du inte specifikt skickar ett huvudnamn för tjänsten i ytterligare AKS CLI-kommandon används standardtjänstens ~/.azure/aksServicePrincipal.json huvudnamn som finns på.
  • Du kan också ta bort filen aksServicePrincipal.json så skapar AKS ett nytt huvudnamn för tjänsten.
  • När du tar bort ett AKS-kluster som skapats av az aks create tas tjänstens huvudnamn som skapades automatiskt inte bort.
    • Om du vill ta bort tjänstens huvudnamn frågar du efter klustret servicePrincipalProfile.clientId och tar sedan bort med az ad sp delete. Ersätt följande resursgruppsnamn och klisternamn med dina egna värden:

      az ad sp delete --id $(az aks show -g myResourceGroup -n myAKSCluster --query servicePrincipalProfile.clientId -o tsv)
      

Felsöka

Autentiseringsuppgifterna för tjänstens huvudnamn för ett AKS-kluster cachelagras av Azure CLI. Om dessa autentiseringsuppgifter har upphört att gälla uppstår fel vid distribution av AKS-kluster. Följande felmeddelande när du kör az aks create kan tyda på ett problem med autentiseringsuppgifterna för det cachelagrade tjänsthuvudnamn:

Operation failed with status: 'Bad Request'.
Details: The credentials in ServicePrincipalProfile were invalid. Please see https://aka.ms/aks-sp-help for more details.
(Details: adal: Refresh request failed. Status Code = '401'.

Kontrollera ålder för filen med autentiseringsuppgifter med hjälp av följande kommando:

ls -la $HOME/.azure/aksServicePrincipal.json

Standardförfallotiden för autentiseringsuppgifter för tjänstens huvudnamn är ett år. Om filen aksServicePrincipal.json är äldre än ett år tar du bort filen och försöker distribuera ett AKS-kluster igen.

Nästa steg

Mer information om hur Azure Active Directory finns i Program- och tjänsthuvudnamnsobjekt.

Information om hur du uppdaterar autentiseringsuppgifterna finns i Uppdatera eller rotera autentiseringsuppgifterna för ett huvudnamn för tjänsten i AKS.