Kontrollera åtkomst med hjälp av Azure AD och Kubernetes RBAC-Azure Kubernetes Service på Azure Stack HCI och Windows Server

  • Artikel
  • 7 minuter för att läsa

Gäller för: AKS på Azure Stack HCI och Windows Server

Azure Kubernetes Service (AKS) på Azure Stack HCI och Windows Server kan konfigureras att använda Azure Active Directory (Azure AD) för användarautentisering. I den här konfigurationen loggar du in på ett AKS-kluster med en Azure AD autentiseringstoken. När du har autentiserats kan du använda den inbyggda rollbaserade åtkomstkontrollen för Kubernetes (Kubernetes RBAC) för att hantera åtkomst till namnrymder och klusterresurser baserat på en användares identitets- eller gruppmedlemskap.

Den här artikeln visar hur du styr åtkomsten med Kubernetes RBAC i ett AKS-kluster baserat på Azure AD gruppmedlemskap. Du skapar en demogrupp och användare i Azure AD. Sedan skapar du roller och rollbindningar i AKS-klustret för att bevilja rätt behörigheter för att skapa och visa resurser.

Förutsättningar

Innan du konfigurerar Kubernetes RBAC med hjälp av Azure AD identitet behöver du:

  • Ett AKS-kluster med AKS på Azure Stack HCI och Windows Server

    Du behöver ett AKS-kluster med AKS på Azure Stack HCI och Windows Server. Om du behöver konfigurera klustret hittar du instruktioner för hur du använder Windows Admin Center eller PowerShell för att distribuera AKS på Azure Stack HCI och Windows Server.

  • Azure Arc-anslutning

    Du måste ha en Azure Arc-anslutning till ditt AKS-kluster på Azure Stack HCI och Windows Server. Anvisningar om hur du aktiverar Azure Arc finns i Ansluta en Azure Kubernetes Service på Azure Stack HCI-kluster till Azure Arc-aktiverade Kubernetes.

  • Du behöver åtkomst till följande kommandoradsverktyg:

    • Azure CLI

      Kommandoradsgränssnitt för Azure (CLI) är en uppsättning kommandon som används för att skapa och hantera Azure-resurser. Om du vill kontrollera om du har Azure CLI öppnar du ett kommandoradsverktyg och skriver: az -v.

      Anvisningar om hur du installerar finns i Så här installerar du Azure CLI.

    • Kubectl

      Med kommandoradsverktyget Kubernetes, kubectl, kan du köra kommandon som riktar sig mot dina Kubernetes-kluster. Om du vill kontrollera om du har kubectl öppnar du ett kommandoradsverktyg och skriver: kubectl version --client. Kontrollera att kubectl-klientversionen är minst v1.24.0.

      Anvisningar finns i kubectl.

    • PowerShell och AksHci PowerShell-modulen

      PowerShell är en plattformsoberoende lösning för uppgiftsautomatisering som består av ett kommandoradsgränssnitt, ett skriptspråk och ett ramverk för konfigurationshantering. Om du har installerat AKS på Azure Stack HCI och Windows Server har du åtkomst till AksHci PowerShell-modulen.

Valfria första steg

Om du inte redan har en Azure AD grupp som innehåller medlemmar kanske du vill skapa en grupp och lägga till några medlemmar för att följa anvisningarna i den här artikeln.

Om du vill demonstrera hur du arbetar med Azure AD och Kubernetes RBAC kan du skapa en Azure AD grupp för programutvecklare som kan användas för att visa hur Kubernetes RBAC och Azure AD styra åtkomsten till klusterresurser. I produktionsmiljöer kan du använda befintliga användare och grupper i en Azure AD klientorganisation.

Skapa en demogrupp i Azure AD

Skapa först gruppen i Azure AD i klientorganisationen för programutvecklare med kommandot az ad group create. I följande exempel loggar du in på din Azure-klient och skapar sedan en grupp med namnet appdev:

az login
az ad group create --display-name appdev --mail-nickname appdev

Lägga till användare i din grupp

När exempelgruppen har skapats i Azure AD för våra programutvecklare ska vi lägga till en användare i appdev gruppen. Om du vill testa Kubernetes RBAC-integreringen i slutet av artikeln loggar du in på AKS-klustret med det här användarkontot.

Lägg till en användare i appdev-gruppen som skapades i föregående avsnitt med kommandot az ad group member add . Om du har avslutat sessionen måste du återansluta till Azure med .az login

$AKSDEV_ID = az ad user create --display-name <name> --password <strongpassword> --user-principal-name <name>@contoso.onmicrosoft.com
az ad group member add --group appdev --member-id $AKSDEV_ID

Skapa en anpassad Kubernetes RBAC-rollbindning på AKS-klusterresursen för gruppen Azure AD

Konfigurera AKS-klustret så att din Azure AD grupp får åtkomst till AKS-klustret. Om du vill lägga till en grupp och användare för att följa stegen i den här guiden kan du läsa Skapa demogrupper i Azure AD.

  1. Hämta autentiseringsuppgifterna för klusteradministratören med hjälp av kommandot Get-AksHciCredential .

    Get-AksHciCredential -name <name-of-your-cluster>

  2. Skapa ett namnområde i AKS-klustret med hjälp av kommandot kubectl create namespace . I följande exempel skapas ett namnutvecklingsnamn för namnområdet:

    kubectl create namespace dev

    I Kubernetes definierar roller de behörigheter som ska beviljas och Rollbindningar tillämpar behörigheterna på önskade användare eller grupper. Dessa tilldelningar kan tillämpas på ett visst namnområde eller i ett helt kluster. Mer information finns i Använda Kubernetes RBAC-auktorisering.

    Skapa en roll för utvecklingsnamnområdet . Den här rollen ger namnområdet fullständiga behörigheter. I produktionsmiljöer kanske du vill ange mer detaljerade behörigheter för olika användare eller grupper.

  3. Skapa en fil med namnet role-dev-namespace.yaml och klistra in följande YAML-manifest:

    kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: dev-user-full-access
  namespace: dev
rules:
- apiGroups: ["", "extensions", "apps"]
  resources: ["*"]
  verbs: ["*"]
- apiGroups: ["batch"]
  resources:
  - jobs
  - cronjobs
  verbs: ["*"]

  4. Skapa rollen med kommandot kubectl apply och ange filnamnet för YAML-manifestet:

    kubectl apply -f role-dev-namespace.yaml

  5. Hämta resurs-ID:t för appdev-gruppen med kommandot az ad group show . Den här gruppen anges som ämnet för en Rollbindning i nästa steg.

    az ad group show --group appdev --query objectId -o tsv

    Az ad-gruppen returnerar det värde som du ska använda som groupObjectId.

    38E5FA30-XXXX-4895-9A00-050712E3673A

  6. Skapa en fil med namnet rolebinding-dev-namespace.yaml och klistra in följande YAML-manifest. Du etablerar Rollbindning för appdev-gruppen för att använda role-dev-namespace rollen för namnområdesåtkomst. På den sista raden ersätter groupObjectId du med gruppobjekt-ID:t som genereras av az ad group show kommandot :

    kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: dev-user-access
  namespace: dev
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: dev-user-full-access
subjects:
- kind: Group
  namespace: dev
  name: groupObjectId

    Tips

    Om du vill skapa Rollbindning för en enskild användare anger kind: User och ersätter groupObjectId du med användarens huvudnamn (UPN) i exemplet.

  7. Skapa RoleBinding med kommandot kubectl apply och ange filnamnet för YAML-manifestet:

    kubectl apply -f rolebinding-dev-namespace.yaml

    rolebinding.rbac.authorization.k8s.io/dev-user-access created

Använda inbyggda Kubernetes RBAC-roller för din AKS-klusterresurs

Kubernetes tillhandahåller också inbyggda användarinriktade roller. Dessa inbyggda roller omfattar:

  • Superanvändarroller (klusteradministratör)
  • Roller som är avsedda att beviljas klusteromfattande med Hjälp av ClusterRoleBindings
  • Roller som är avsedda att beviljas inom vissa namnområden med hjälp av rollbindningar (administratör, redigera, visa)

Mer information om inbyggda Kubernetes RBAC-roller finns i Användarinriktade Kubernetes RBAC-roller

Användarriktade roller

Standardklusterroll StandardklusterRoleBinding Beskrivning
klusteradministratör system:masters group Tillåter superanvändaråtkomst att utföra alla åtgärder på alla resurser. När den används i en ClusterRoleBinding ger den fullständig kontroll över varje resurs i klustret och i alla namnområden. När den används i en Rollbindning ger den fullständig kontroll över varje resurs i rollbindningens namnområde, inklusive själva namnområdet.
administratör Ingen Tillåter administratörsåtkomst, avsedd att beviljas inom ett namnområde med hjälp av ett rollbindning. Om det används i en Rollbindning, tillåter läs-/skrivåtkomst till de flesta resurser i ett namnområde, inklusive möjligheten att skapa roller och rollbindningar inom namnområdet. Den här rollen tillåter inte skrivåtkomst till resurskvoten eller till själva namnområdet. Den här rollen tillåter inte heller skrivåtkomst till slutpunkter i kluster som skapats med Kubernetes v1.22+. Mer information finns i avsnittet Skrivåtkomst för slutpunkter .
redigera Ingen Tillåter läs-/skrivåtkomst till de flesta objekt i ett namnområde. Den här rollen tillåter inte visning eller ändring av roller eller rollbindningar. Den här rollen tillåter dock åtkomst till hemligheter och poddar som alla ServiceAccount i namnområdet, så den kan användas för att få API-åtkomstnivåerna för alla ServiceAccount i namnområdet. Den här rollen tillåter inte heller skrivåtkomst till slutpunkter i kluster som skapats med Kubernetes v1.22+. Mer information finns i avsnittet Skrivåtkomst för slutpunkter .
visa Ingen Tillåter skrivskyddad åtkomst för att se de flesta objekt i ett namnområde. Det tillåter inte visning av roller eller rollbindningar. Den här rollen tillåter inte visning av hemligheter, eftersom läsning av innehållet i Hemligheter ger åtkomst till ServiceAccount-autentiseringsuppgifter i namnområdet, vilket skulle tillåta API-åtkomst som alla ServiceAccount i namnområdet (en form av behörighetseskalering).

Använda en inbyggd Kubernetes RBAC-roll med Azure AD

  1. Använd den inbyggda Kubernetes RBAC-rollen view för din Azure AD grupp:

    kubectl create clusterrolebinding <name of your cluster role binding> --clusterrole=view --group=<Azure AD group object ID>

  2. Använd den inbyggda view Kubernetes RBAC-rollen för var och en av dina Azure AD användare:

    kubectl create clusterrolebinding <name of your cluster role binding> --clusterrole=view --user=<Azure AD user object ID>

Arbeta med klusterresurser med Azure AD identiteter

Testa de förväntade behörigheterna när du skapar och hanterar resurser i ett AKS-kluster. I de här exemplen schemalägger och visar du poddar i användarens tilldelade namnområde. Sedan försöker du schemalägga och visa poddar utanför det tilldelade namnområdet.

  1. Logga in på Azure med det $AKSDEV_ID användarkonto som du skickade som indata till az ad group member add kommandot. az connectedk8s proxy Kör kommandot för att öppna en kanal till AKS-klustret:

    az connectedk8s proxy -n <cluster-name> -g <resource-group>

  2. När proxykanalen har upprättats öppnar du en annan session och schemalägger en NGINX-podd med kommandot kubectl run i dev-namnområdet :

    kubectl run nginx-dev --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace dev

    När NGINX har schemalagts visas följande utdata:

    pod/nginx-dev created

  3. Använd nu kommandot kubectl get pods för att visa poddar i dev-namnområdet .

    kubectl get pods --namespace dev

    När NGINX har körts visas följande utdata:

    $ kubectl get pods --namespace dev

NAME        READY   STATUS    RESTARTS   AGE
nginx-dev   1/1     Running   0          4m

Skapa och visa klusterresurser utanför det tilldelade namnområdet

Försök att visa poddar utanför dev-namnområdet . Använd kommandot kubectl get pods till med --all-namespaces flaggan .

kubectl get pods --all-namespaces

Användarens gruppmedlemskap har inte en Kubernetes-roll som tillåter den här åtgärden. Utan behörighet genererar kommandot ett fel.

Error from server (Forbidden): pods is forbidden: User cannot list resource "pods" in API group "" at the cluster scope

Nästa steg

Läs mer om säkerheten med AKS på Azure Stack HCI och Windows Server, se Säkerhet i AKS på Azure Stack HCI och Windows Server