Použití Azure RBAC v clusterech Kubernetes s podporou Azure Arc

Článek
11/02/2024

Typy objektů Kubernetes ClusterRoleBinding a RoleBinding pomáhají nativně definovat autorizaci v Kubernetes. Pomocí této funkce můžete pomocí ID Microsoft Entra a přiřazení rolí v Azure řídit kontroly autorizace v clusteru. Přiřazení rolí Azure umožňují podrobné řízení, kteří uživatelé můžou číst, zapisovat a odstraňovat objekty Kubernetes, jako je nasazení, pod a služba.

Koncepční přehled této funkce najdete v Azure RBAC v Kubernetes s podporou Azure Arc.

Požadavky

Nainstalujte nebo upgradujte Azure CLI na nejnovější verzi.
Nainstalujte nejnovější verzi connectedk8s rozšíření Azure CLI:
```
az extension add --name connectedk8s
```
connectedk8s Pokud už je rozšíření nainstalované, můžete ho aktualizovat na nejnovější verzi pomocí následujícího příkazu:
```
az extension update --name connectedk8s
```
Připojte existující cluster Kubernetes s podporou Azure Arc:
- Pokud jste cluster ještě nepřipojili, použijte naše rychlé zprovoznění.
- Upgradujte agenty na nejnovější verzi.

Poznámka:

Azure RBAC není k dispozici pro nabídky Red Hat OpenShift nebo spravované kubernetes, kde je omezený uživatelský přístup k serveru API (např. Amazon Elastic Kubernetes Service (EKS), Google Kubernetes Engine (GKE)).

Azure RBAC v současné době nepodporuje clustery Kubernetes fungující v architektuře ARM64. Ke správě řízení přístupu pro clustery Kubernetes založené na ARM64 použijte Kubernetes RBAC .

U clusterů Azure Kubernetes Service (AKS) je tato funkce dostupná nativně a nevyžaduje připojení clusteru AKS ke službě Azure Arc.

Pro clustery Azure Kubernetes Service (AKS) povolené službou Azure Arc ve službě Azure Stack HCI 23H2 se povolení Azure RBAC v současné době podporuje pouze při vytváření clusteru Kubernetes. Pokud chcete vytvořit cluster AKS povolený službou Azure Arc s povoleným Azure RBAC, postupujte podle průvodce autorizací Azure RBAC pro Kubernetes. Mějte na paměti, že Azure RBAC se nepodporuje pro Azure Stack HCI verze 22H2.

Povolení Azure RBAC v clusteru

Spuštěním následujícího příkazu získejte identitu MSI clusteru:
```
az connectedk8s show -g <resource-group> -n <connected-cluster-name>
```
Získejte ID (identity.principalId) z výstupu a spuštěním následujícího příkazu přiřaďte roli Čtenář CheckAccess spravované identity připojeného clusteru ke službě MSI clusteru:
```
az role assignment create --role "Connected Cluster Managed Identity CheckAccess Reader" --assignee "<Cluster MSI ID>" --scope <cluster ARM ID>
```
Spuštěním následujícího příkazu povolte řízení přístupu na základě role (RBAC) v clusteru Kubernetes s podporou Azure Arc:
```
az connectedk8s enable-features -n <clusterName> -g <resourceGroupName> --features azure-rbac
```
Poznámka:

Než spustíte předchozí příkaz, ujistěte se, že kubeconfig soubor na počítači ukazuje na cluster, na kterém povolíte funkci Azure RBAC.

Použije --skip-azure-rbac-list se s předchozím příkazem pro čárkami oddělený seznam uživatelských jmen, e-mailů a připojení OpenID procházejících autorizačními kontrolami pomocí nativních ClusterRoleBinding objektů Kubernetes místo RoleBinding Azure RBAC.

Obecný cluster, ve kterém není spuštěn žádný odsouhlasovač ve `apiserver` specifikaci

SSH do každého hlavního uzlu clusteru a proveďte následující kroky:

Pokud se jedná kube-apiserver o statický pod:

Tajný azure-arc-guard-manifests kód v kube-system oboru názvů obsahuje dva soubory: guard-authn-webhook.yaml a guard-authz-webhook.yaml. Zkopírujte tyto soubory do /etc/guard adresáře uzlu.

sudo mkdir -p /etc/guard
kubectl get secrets azure-arc-guard-manifests -n kube-system -o json | jq -r '.data."guard-authn-webhook.yaml"' | base64 -d > /etc/guard/guard-authn-webhook.yaml
kubectl get secrets azure-arc-guard-manifests -n kube-system -o json | jq -r '.data."guard-authz-webhook.yaml"' | base64 -d > /etc/guard/guard-authz-webhook.yaml

apiserver Otevřete manifest v režimu úprav:

sudo vi /etc/kubernetes/manifests/kube-apiserver.yaml

Do části volumes:

- hostPath
    path: /etc/guard
    type: Directory
name: azure-rbac

Do části volumeMounts:

- mountPath: /etc/guard
    name: azure-rbac
    readOnly: true

Pokud se nejedná kube-apiserver o statický pod:

apiserver Otevřete manifest v režimu úprav:

sudo vi /etc/kubernetes/manifests/kube-apiserver.yaml

Do části volumes:

- name: azure-rbac
    secret:
    secretName: azure-arc-guard-manifests

Do části volumeMounts:

- mountPath: /etc/guard
    name: azure-rbac
    readOnly: true

Přidejte následující apiserver argumenty:

- --authentication-token-webhook-config-file=/etc/guard/guard-authn-webhook.yaml
- --authentication-token-webhook-cache-ttl=5m0s
- --authorization-webhook-cache-authorized-ttl=5m0s
- --authorization-webhook-config-file=/etc/guard/guard-authz-webhook.yaml
- --authorization-webhook-version=v1
- --authorization-mode=Node,RBAC,Webhook

Pokud je cluster Kubernetes verze 1.19.0 nebo novější, musíte také nastavit následující apiserver argument:

- --authentication-token-webhook-version=v1

Uložte a zavřete editor a aktualizujte pod apiserver .

Cluster vytvořený pomocí rozhraní API clusteru

Zkopírujte tajný klíč ochrany, který obsahuje konfigurační soubory webhooku pro ověřování a autorizaci z clusteru úloh na váš počítač:
```
kubectl get secret azure-arc-guard-manifests -n kube-system -o yaml > azure-arc-guard-manifests.yaml
```
namespace Změňte pole v souboru azure-arc-guard-manifests.yaml na obor názvů v clusteru pro správu, ve kterém používáte vlastní prostředky pro vytváření clusterů úloh.

Použít tento manifest:

kubectl apply -f azure-arc-guard-manifests.yaml

Upravte KubeadmControlPlane objekt spuštěním kubectl edit kcp <clustername>-control-planepříkazu :

Do části filespřidejte následující fragment kódu:

- contentFrom:
    secret:
      key: guard-authn-webhook.yaml
      name: azure-arc-guard-manifests
  owner: root:root
  path: /etc/kubernetes/guard-authn-webhook.yaml
  permissions: "0644"
- contentFrom:
    secret:
      key: guard-authz-webhook.yaml
      name: azure-arc-guard-manifests
  owner: root:root
  path: /etc/kubernetes/guard-authz-webhook.yaml
  permissions: "0644"

Do části apiServer>extraVolumespřidejte následující fragment kódu:

- hostPath: /etc/kubernetes/guard-authn-webhook.yaml
    mountPath: /etc/guard/guard-authn-webhook.yaml
    name: guard-authn
    readOnly: true
- hostPath: /etc/kubernetes/guard-authz-webhook.yaml
    mountPath: /etc/guard/guard-authz-webhook.yaml
    name: guard-authz
    readOnly: true

Do části apiServer>extraArgspřidejte následující fragment kódu:

authentication-token-webhook-cache-ttl: 5m0s
authentication-token-webhook-config-file: /etc/guard/guard-authn-webhook.yaml
authentication-token-webhook-version: v1
authorization-mode: Node,RBAC,Webhook
authorization-webhook-cache-authorized-ttl: 5m0s
authorization-webhook-config-file: /etc/guard/guard-authz-webhook.yaml
authorization-webhook-version: v1

Uložte a zavřete aktualizaci objektu KubeadmControlPlane . Počkejte, až se tyto změny zobrazí v clusteru úloh.

Vytvoření přiřazení rolí pro uživatele umožňujících přístup ke clusteru

Vlastníci prostředku Kubernetes s podporou Služby Azure Arc můžou k udělení přístupu k clusteru Kubernetes použít předdefinované role nebo vlastní role.

Předdefinované role

Role	Popis
Prohlížeč Kubernetes Azure Arc	Umožňuje přístup jen pro čtení k zobrazení většiny objektů v oboru názvů. Tato role neumožňuje zobrazování tajných kódů, protože `read` oprávnění k tajným kódům by umožňovala přístup k `ServiceAccount` přihlašovacím údajům v oboru názvů. Tyto přihlašovací údaje by zase umožňovaly přístup k rozhraní API prostřednictvím této `ServiceAccount` hodnoty (forma eskalace oprávnění).
Azure Arc Kubernetes Writer	Umožňuje přístup pro čtení a zápis k většině objektů v oboru názvů. Tato role neumožňuje zobrazení nebo úpravy rolí nebo vazeb rolí. Tato role ale umožňuje přístup k tajným kódům a spouštění podů jako libovolnou `ServiceAccount` hodnotu v oboru názvů, takže ji lze použít k získání úrovní přístupu rozhraní API libovolné `ServiceAccount` hodnoty v oboru názvů.
Správce Kubernetes Azure Arc	Umožňuje přístup správce. Má být udělena v rámci oboru názvů prostřednictvím `RoleBinding`. Pokud ho používáte, `RoleBinding`umožňuje přístup pro čtení a zápis k většině prostředků v oboru názvů, včetně možnosti vytvářet role a vazby rolí v rámci oboru názvů. Tato role neumožňuje přístup k zápisu do kvóty prostředků ani k samotnému oboru názvů.
Správce clusteru Azure Arc Kubernetes	Umožňuje přístup superuživatele k provedení jakékoli akce u jakéhokoli prostředku. Když ho použijete, `ClusterRoleBinding`získáte úplnou kontrolu nad každým prostředkem v clusteru a ve všech oborech názvů. Když ji použijete v `RoleBinding`, poskytuje úplnou kontrolu nad každým prostředkem v oboru názvů vazby role, včetně samotného oboru názvů.

Přiřazení rolí s vymezeným oborem na cluster Kubernetes s podporou Azure Arc můžete vytvořit na webu Azure Portal v podokně Řízení přístupu (IAM) prostředku clusteru. Můžete také použít následující příkazy Azure CLI:

az role assignment create --role "Azure Arc Kubernetes Cluster Admin" --assignee <AZURE-AD-ENTITY-ID> --scope $ARM_ID

V těchto příkazech AZURE-AD-ENTITY-ID může být uživatelské jméno (například testuser@mytenant.onmicrosoft.com) nebo dokonce appId hodnota instančního objektu.

Tady je další příklad vytvoření přiřazení role s vymezeným oborem názvů v rámci clusteru:

az role assignment create --role "Azure Arc Kubernetes Viewer" --assignee <AZURE-AD-ENTITY-ID> --scope $ARM_ID/namespaces/<namespace-name>

Poznámka:

Přiřazení rolí s vymezeným oborem clusteru můžete vytvořit pomocí webu Azure Portal nebo Azure CLI. K vytváření přiřazení rolí v oboru názvů se ale dají použít jenom Azure CLI.

Vlastní role

Můžete si vytvořit vlastní definici role pro použití v přiřazeních rolí.

Projděte si následující příklad definice role, která uživateli umožňuje pouze čtení nasazení. Další informace najdete v úplném seznamu akcí dat, které můžete použít k vytvoření definice role.

Zkopírujte následující objekt JSON do souboru s názvem custom-role.json. <subscription-id> Zástupný symbol nahraďte skutečným ID předplatného. Vlastní role používá jednu z akcí dat a umožňuje zobrazit všechna nasazení v oboru (clusteru nebo oboru názvů), ve kterém se přiřazení role vytvoří.

{
    "Name": "Arc Deployment Viewer",
    "Description": "Lets you view all deployments in cluster/namespace.",
    "Actions": [],
    "NotActions": [],
    "DataActions": [
        "Microsoft.Kubernetes/connectedClusters/apps/deployments/read"
    ],
    "NotDataActions": [],
    "assignableScopes": [
        "/subscriptions/<subscription-id>"
    ]
}

Definici role vytvořte spuštěním následujícího příkazu ze složky, do které jste uložili custom-role.json:
```
az role definition create --role-definition @custom-role.json
```

Pomocí této vlastní definice role vytvořte přiřazení role:

az role assignment create --role "Arc Deployment Viewer" --assignee <AZURE-AD-ENTITY-ID> --scope $ARM_ID/namespaces/<namespace-name>

Konfigurace kubectl s přihlašovacími údaji uživatele

Soubor kubeconfig, který potřebujete pro přístup ke clusteru, můžete získat dvěma způsoby:

Použijete funkci připojení clusteru (az connectedk8s proxy) clusteru Kubernetes s podporou Služby Arc.
Správce clusteru sdílí soubor kubeconfig s každým dalším uživatelem.

Použití připojení ke clusteru

Spuštěním následujícího příkazu spusťte proces proxy serveru:

az connectedk8s proxy -n <clusterName> -g <resourceGroupName>

Po spuštění procesu proxy serveru můžete v konzole otevřít další kartu a začít odesílat požadavky do clusteru.

Použití sdíleného souboru kubeconfig

Použití sdílené kubeconfig vyžaduje mírně odlišné kroky v závislosti na vaší verzi Kubernetes.

Verze >Kubernetes = 1.26
Kubernetes < v1.26

Spuštěním následujícího příkazu nastavte přihlašovací údaje pro uživatele. Zadejte serverApplicationId jako 6256c85f-0aad-4d50-b960-e6e9b21efe35 a clientApplicationId jako 3f4439ff-e698-4d6d-84fe-09c9d574f06b:

kubectl config set-credentials <testuser>@<mytenant.onmicrosoft.com> \
--auth-provider=azure \
--auth-provider-arg=environment=AzurePublicCloud \
--auth-provider-arg=client-id=<clientApplicationId> \
--auth-provider-arg=tenant-id=<tenantId> \
--auth-provider-arg=apiserver-id=<serverApplicationId>

Otevřete soubor kubeconfig, který jste vytvořili dříve. V části contextsOvěřte, že kontext přidružený ke clusteru odkazuje na přihlašovací údaje uživatele, které jste vytvořili v předchozím kroku. Pokud chcete nastavit aktuální kontext na tyto přihlašovací údaje uživatele, spusťte následující příkaz:
```
kubectl config set-context --current=true --user=<testuser>@<mytenant.onmicrosoft.com>
```
Přidejte nastavení režimu konfigurace v části>userconfig:
```
name: testuser@mytenant.onmicrosoft.com
user:
    auth-provider:
    config:
        apiserver-id: $SERVER_APP_ID
        client-id: $CLIENT_APP_ID
        environment: AzurePublicCloud
        tenant-id: $TENANT_ID
        config-mode: "1"
    name: azure
```
Poznámka:

Modul plug-in Exec je strategie ověřování Kubernetes, která umožňuje kubectl spustit externí příkaz pro příjem přihlašovacích údajů uživatele k odeslání apiserver. Počínaje Kubernetes verze 1.26 už výchozí modul plug-in client-go pro autorizaci Azure není součástí a kubectl. V novějších verzích musíte použít modul plug-in exec k získání přihlašovacích údajů uživatele, musíte použít Azure Kubelogin, client-go modul plug-in přihlašovacích údajů (exec), který implementuje ověřování Azure.

Nainstalujte Azure Kubelogin:

Pro Windows nebo Mac postupujte podle pokynů k instalaci Azure Kubelogin.

V případě Linuxu nebo Ubuntu stáhněte nejnovější verzi kubeloginu a spusťte následující příkazy:

curl -LO https://github.com/Azure/kubelogin/releases/download/"$KUBELOGIN_VERSION"/kubelogin-linux-amd64.zip 

unzip kubelogin-linux-amd64.zip 

sudo mv bin/linux_amd64/kubelogin /usr/local/bin/ 

sudo chmod +x /usr/local/bin/kubelogin

Kubelogin se dá použít k ověření pomocí clusterů s podporou Azure Arc vyžádáním tokenu poP (proof-of-possession). Převeďte kubeconfig pomocí kubeloginu tak, aby používal příslušný režim přihlášení. Například pro přihlášení kódu zařízení s uživatelem Microsoft Entra by příkazy byly následující:
```
export KUBECONFIG=/path/to/kubeconfig

kubelogin convert-kubeconfig --pop-enabled --pop-claims 'u=<ARM ID of cluster>"
```

kubectl config set-credentials <testuser>@<mytenant.onmicrosoft.com> \
--auth-provider=azure \
--auth-provider-arg=environment=AzurePublicCloud \
--auth-provider-arg=client-id=<clientApplicationId> \
--auth-provider-arg=tenant-id=<tenantId> \
--auth-provider-arg=apiserver-id=<serverApplicationId>

Otevřete soubor kubeconfig, který jste vytvořili dříve. V části contextsOvěřte, že kontext přidružený ke clusteru odkazuje na přihlašovací údaje uživatele, které jste vytvořili v předchozím kroku. Pokud chcete nastavit aktuální kontext na tyto přihlašovací údaje uživatele, spusťte následující příkaz:
```
kubectl config set-context --current=true --user=<testuser>@<mytenant.onmicrosoft.com>
```

Přidejte nastavení režimu konfigurace v části>userconfig:

name: testuser@mytenant.onmicrosoft.com
user:
    auth-provider:
    config:
        apiserver-id: $SERVER_APP_ID
        client-id: $CLIENT_APP_ID
        environment: AzurePublicCloud
        tenant-id: $TENANT_ID
        config-mode: "1"
    name: azure

Odesílání požadavků do clusteru

Spusťte libovolný kubectl příkaz. Příklad:
- kubectl get nodes
- kubectl get pods
Po zobrazení výzvy k ověření na základě prohlížeče zkopírujte přihlašovací adresu URL zařízení (https://microsoft.com/devicelogin) a otevřete ji ve webovém prohlížeči.
Zadejte kód vytištěný v konzole. Zkopírujte a vložte kód v terminálu do výzvy k zadání vstupu ověřování zařízení.
Zadejte uživatelské jméno (testuser@mytenant.onmicrosoft.com) a přidružené heslo.

Pokud se zobrazí podobná chybová zpráva, znamená to, že nemáte oprávnění k přístupu k požadovanému prostředku:

Error from server (Forbidden): nodes is forbidden: User "testuser@mytenant.onmicrosoft.com" cannot list resource "nodes" in API group "" at the cluster scope: User doesn't have access to the resource in Azure. Update role assignment to allow access.

Správce musí vytvořit nové přiřazení role, které uživateli autorizuje přístup k prostředku.

Použití podmíněného přístupu s ID Microsoft Entra

Když integrujete ID Microsoft Entra s clusterem Kubernetes s podporou Azure Arc, můžete k řízení přístupu ke clusteru použít také podmíněný přístup .

Poznámka:

Podmíněný přístup Microsoft Entra je funkce Microsoft Entra ID P2.

Vytvoření ukázkové zásady podmíněného přístupu pro použití s clusterem:

V horní části webu Azure Portal vyhledejte a vyberte ID Microsoft Entra.
V nabídce pro Microsoft Entra ID na levé straně vyberte Podnikové aplikace.
V nabídce podnikových aplikací na levé straně vyberte Podmíněný přístup.
V nabídce podmíněného přístupu na levé straně vyberte Zásady>Nové zásady.
Zadejte název zásady, například arc-k8s-policy.
Vyberte Uživatelé a skupiny. V části Zahrnout zvolte Vybrat uživatele a skupiny. Pak zvolte uživatele a skupiny, u kterých chcete zásadu použít. V tomto příkladu zvolte stejnou skupinu Microsoft Entra, která má přístup správce ke clusteru.
Vyberte Cloudové aplikace nebo akce. V části Zahrnout zvolte Vybrat aplikace. Pak vyhledejte a vyberte serverové aplikace, kterou jste vytvořili dříve.
V části Řízení přístupu vyberte Udělit. Vyberte Udělit přístup>Vyžadovat, aby zařízení bylo označené jako vyhovující.
V části Povolit zásadu vyberte Při>vytvoření.

Znovu přejděte ke clusteru. Spuštěním kubectl get nodes příkazu například zobrazte uzly v clusteru:

kubectl get nodes

Podle pokynů se znovu přihlaste. Chybová zpráva uvádí, že jste úspěšně přihlášení, ale váš správce vyžaduje zařízení, které žádá o přístup ke správě pomocí ID Microsoft Entra, aby bylo možné získat přístup k prostředku. Postupujte následovně:

Na webu Azure Portal přejděte na MICROSOFT Entra ID.
Vyberte Podnikové aplikace. Potom v části Aktivita vyberte Přihlášení.
Položka v horní části zobrazuje selhání stavu a úspěchu podmíněného přístupu. Vyberte položku a v podrobnostech vyberte Podmíněný přístup. Všimněte si, že jsou uvedené zásady podmíněného přístupu.

Konfigurace přístupu ke clusteru za běhu pomocí ID Microsoft Entra

Další možností pro řízení přístupu ke clusteru je použít Privileged Identity Management (PIM) pro požadavky za běhu.

Poznámka:

Microsoft Entra PIM je funkce Microsoft Entra ID P2. Další informace o skladových posílacích Microsoft Entra ID najdete v průvodci cenami.

Pokud chcete nakonfigurovat žádosti o přístup za běhu pro váš cluster, proveďte následující kroky:

V horní části webu Azure Portal vyhledejte a vyberte ID Microsoft Entra.
Poznamenejte si ID tenanta. Ve zbývající části těchto pokynů budeme na toto ID odkazovat jako <tenant-id>na .
V nabídce pro Microsoft Entra ID na levé straně v části Spravovat vyberte Skupiny>Nová skupina.
Ujistěte se, že je pro typ skupiny vybráno zabezpečení. Zadejte název skupiny, například myJITGroup. V části Role Microsoft Entra je možné přiřadit této skupině (Preview) možnost Ano. Nakonec vyberte Vytvořit.
Vrátíte se zpět na stránku Skupiny . Vyberte nově vytvořenou skupinu a poznamenejte si ID objektu. Ve zbývající části těchto pokynů budeme na toto ID odkazovat jako <object-id>na .
Zpět na webu Azure Portal v nabídce aktivity na levé straně vyberte Privileged Access (Preview). Pak vyberte Povolit privilegovaný přístup.
Vyberte Přidat přiřazení a začněte udělovat přístup.
Vyberte roli člena a vyberte uživatele a skupiny, kterým chcete udělit přístup ke clusteru. Správce skupiny může tato přiřazení kdykoli upravit. Až budete chtít pokračovat, vyberte Další.
Zvolte typ přiřazení Aktivní, zvolte požadovanou dobu trvání a zadejte odůvodnění. Až budete připraveni pokračovat, vyberte Přiřadit. Další informace otypech

Po zadání ověřte, že přístup za běhu funguje tak, že přistupuje ke clusteru. Pomocí příkazu můžete například kubectl get nodes zobrazit uzly v clusteru:

kubectl get nodes

Poznamenejte si požadavek na ověření a postupujte podle kroků k ověření. Pokud je ověřování úspěšné, měl by se zobrazit výstup podobný tomuto:

To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code AAAAAAAAA to authenticate.

NAME      STATUS   ROLES    AGE      VERSION
node-1    Ready    agent    6m36s    v1.18.14
node-2    Ready    agent    6m42s    v1.18.14
node-3    Ready    agent    6m33s    v1.18.14

Další kroky

Bezpečně se připojte ke clusteru pomocí služby Cluster Connect.
Přečtěte si o architektuře Azure RBAC v Kubernetes s podporou Arc.

Sdílet prostřednictvím

Použití Azure RBAC v clusterech Kubernetes s podporou Azure Arc

Požadavky

Povolení Azure RBAC v clusteru

Obecný cluster, ve kterém není spuštěn žádný odsouhlasovač ve `apiserver` specifikaci

Cluster vytvořený pomocí rozhraní API clusteru

Vytvoření přiřazení rolí pro uživatele umožňujících přístup ke clusteru

Předdefinované role

Vlastní role

Konfigurace kubectl s přihlašovacími údaji uživatele

Použití připojení ke clusteru

Použití sdíleného souboru kubeconfig

Odesílání požadavků do clusteru

Použití podmíněného přístupu s ID Microsoft Entra

Konfigurace přístupu ke clusteru za běhu pomocí ID Microsoft Entra

Další kroky

Váš názor

Další materiály

Sdílet prostřednictvím

Použití Azure RBAC v clusterech Kubernetes s podporou Azure Arc

Požadavky

Povolení Azure RBAC v clusteru

Obecný cluster, ve kterém není spuštěn žádný odsouhlasovač ve apiserver specifikaci

Cluster vytvořený pomocí rozhraní API clusteru

Vytvoření přiřazení rolí pro uživatele umožňujících přístup ke clusteru

Předdefinované role

Vlastní role

Konfigurace kubectl s přihlašovacími údaji uživatele

Použití připojení ke clusteru

Použití sdíleného souboru kubeconfig

Odesílání požadavků do clusteru

Použití podmíněného přístupu s ID Microsoft Entra

Konfigurace přístupu ke clusteru za běhu pomocí ID Microsoft Entra

Další kroky

Váš názor

Další materiály

Obecný cluster, ve kterém není spuštěn žádný odsouhlasovač ve `apiserver` specifikaci