Ajánlott eljárások hitelesítéshez és engedélyezéshez az Azure Kubernetes Service-ben (AKS)

Amikor fürtöket helyez üzembe és tart fenn az Azure Kubernetes Service-ben (AKS), implementálhatja az erőforrásokhoz és szolgáltatásokhoz való hozzáférés kezelését. A következő vezérlők nélkül:

• A fiókok hozzáférhetnek a szükségtelen erőforrásokhoz és szolgáltatásokhoz.
• A módosítások elvégzéséhez használt hitelesítő adatok nyomon követése nehéz lehet.

Ebben a cikkben bemutatjuk, hogy milyen ajánlott eljárásokat követhet egy fürtoperátor az AKS-fürtök hozzáférésének és identitásának kezeléséhez. A következőket fogja megtanulni:

A Microsoft Entra-azonosító használata

Ajánlott eljárások útmutatója

AKS-fürtök üzembe helyezése a Microsoft Entra-integrációval. A Microsoft Entra ID használata központosítja az identitáskezelési réteget. A felhasználói fiók vagy a csoport állapotának bármilyen módosítása automatikusan frissül az AKS-fürthöz való hozzáféréskor. A felhasználók vagy csoportok hatóköre a minimális engedélymennyiségre szerepkörök, clusterRoles vagy kötések használatával.

A Kubernetes-fürt fejlesztőinek és alkalmazástulajdonosainak különböző erőforrásokhoz kell hozzáférnie. A Kubernetes nem rendelkezik identitáskezelési megoldással, amellyel szabályozhatja azokat az erőforrásokat, amelyekkel a felhasználók interakcióba léphetnek. Ehelyett integrálhatja a fürtöt egy meglévő identitáskezelési megoldással, például a Microsoft Entra ID-val, amely egy nagyvállalati szintű identitáskezelési megoldás.

Az AKS-ben integrált Microsoft Entra-fürtökkel szerepköröket vagy fürtrolokat hozhat létre, amelyek meghatározzák az erőforrásokhoz való hozzáférési engedélyeket. Ezután a szerepköröket a Microsoft Entra-azonosítóból származó felhasználókhoz vagy csoportokhoz köti . Ezekről a Kubernetes RBAC-ről a következő szakaszban olvashat bővebben. A Microsoft Entra integrációja és az erőforrásokhoz való hozzáférés szabályozása az alábbi ábrán látható:

1. A fejlesztő a Microsoft Entra-azonosítóval hitelesít.
2. A Microsoft Entra-jogkivonat kiállítási végpontja kiadja a hozzáférési jogkivonatot.
3. A fejlesztő végrehajt egy műveletet a Microsoft Entra-jogkivonat használatával, például kubectl create pod.
4. A Kubernetes a Microsoft Entra-azonosítóval érvényesíti a jogkivonatot, és lekéri a fejlesztő csoporttagságait.
5. A Kubernetes RBAC és a fürtszabályzatok érvényesek.
6. A fejlesztő kérése a Microsoft Entra-csoporttagság, a Kubernetes RBAC és szabályzatok korábbi ellenőrzése alapján sikeres.

A Microsoft Entra ID-t használó AKS-fürt létrehozásához lásd : Microsoft Entra ID integrálása az AKS-sel.

A Kubernetes szerepköralapú hozzáférés-vezérlésének használata (Kubernetes RBAC)

Ajánlott eljárások útmutatója

Felhasználói vagy csoportengedélyek definiálása fürterőforrásokhoz a Kubernetes RBAC-vel. Olyan szerepköröket és kötéseket hozhat létre, amelyek a minimálisan szükséges engedélyeket rendelik hozzá. Integrálható a Microsoft Entra-azonosítóval a felhasználói állapotok vagy csoporttagságok módosításának automatikus frissítéséhez, valamint a fürterőforrásokhoz való hozzáférés naprakészen tartásához.

A Kubernetesben részletes hozzáférés-vezérlést biztosít a fürterőforrásokhoz. Az engedélyeket a fürt szintjén vagy adott névtereken határozhatja meg. Ön határozza meg, hogy mely erőforrások kezelhetők, és milyen engedélyekkel. Ezután ezeket a szerepköröket kötéssel rendelkező felhasználókra vagy csoportokra alkalmazza. A szerepkörökről, a ClusterRolesről és a kötésekről további információt az Azure Kubernetes Service (AKS) hozzáférési és identitásbeállításai című témakörben talál.

Létrehozhat például egy olyan szerepkört, amely teljes hozzáféréssel rendelkezik az erőforrásokhoz a finance-app névtérben, ahogyan az a következő YAML-jegyzékben is látható:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: finance-app-full-access-role
  namespace: finance-app
rules:
- apiGroups: [""]
  resources: ["*"]
  verbs: ["*"]

Ezután létre kell hoznia egy RoleBinding-et , és hozzá kell kötnie a Microsoft Entra-felhasználót developer1@contoso.com az alábbi YAML-jegyzékben látható módon:

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: finance-app-full-access-role-binding
  namespace: finance-app
subjects:
- kind: User
  name: developer1@contoso.com
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: finance-app-full-access-role
  apiGroup: rbac.authorization.k8s.io

Ha developer1@contoso.com az AKS-fürtön hitelesítik őket, teljes engedélyekkel rendelkeznek a pénzügyi alkalmazás névterében lévő erőforrásokhoz. Ily módon logikailag elkülönítheti és szabályozhatja az erőforrásokhoz való hozzáférést. A Kubernetes RBAC használata a Microsoft Entra ID-integrációval.

Ha tudni szeretné, hogyan szabályozhatja a Kubernetes-erőforrásokhoz való hozzáférést a Kubernetes RBAC használatával a Microsoft Entra-csoportok használatával, olvassa el a fürterőforrások hozzáférésének szabályozása szerepköralapú hozzáférés-vezérléssel és Microsoft Entra-identitásokkal az AKS-ben című témakört.

Az Azure RBAC használata

Ajánlott eljárások útmutatója

Az Azure RBAC használatával definiálhatja az AKS-erőforrásokhoz minimálisan szükséges felhasználói és csoportengedélyeket egy vagy több előfizetésben.

Az AKS-fürtök teljes működéséhez két hozzáférési szint szükséges:

• Az AKS-erőforrás elérése az Azure-előfizetésben.

  Ez a hozzáférési szint lehetővé teszi a következőt:

  • A fürt skálázásának vagy frissítésének szabályozása az AKS API-k használatával
  • Húzza le a kubeconfig.

  Az AKS-erőforráshoz és a kubeconfigfürtkonfigurációs fájlhoz való hozzáférés korlátozásával kapcsolatos tudnivalókért lásd : Hozzáférés korlátozása a fürtkonfigurációs fájlhoz.

• Hozzáférés a Kubernetes API-hoz.

  Ezt a hozzáférési szintet a következők vezérlik:

  • Kubernetes RBAC (hagyományosan) vagy
  • Az Azure RBAC és az AKS integrálásával a kubernetes-engedélyezéshez.

  A Kubernetes API-nak az Azure RBAC használatával történő részletes engedélyezéséről további információt az Azure RBAC használata a Kubernetes-engedélyezéshez című témakörben talál.

Pod által felügyelt identitások használata

Ne használjon rögzített hitelesítő adatokat a podokon vagy tárolólemezképeken belül, mert azok ki vannak téve az expozíciónak vagy a visszaélésnek. Ehelyett pod-identitások használatával automatikusan kérjen hozzáférést a Microsoft Entra ID használatával.

Más Azure-erőforrások, például az Azure Cosmos DB, a Key Vault vagy a Blob Storage eléréséhez a podnak hitelesítési hitelesítő adatokra van szüksége. Megadhatja a hitelesítési hitelesítő adatokat a tároló lemezképével, vagy kubernetes-titkos kódként is beszúrhatja őket. Akárhogy is, manuálisan kell létrehoznia és hozzárendelnie őket. Ezeket a hitelesítő adatokat általában újra felhasználják a podok között, és nem forgatják rendszeresen.

Az Azure-erőforrások pod által felügyelt identitásaival (előzetes verzió) automatikusan hozzáférést kérhet a szolgáltatásokhoz a Microsoft Entra-azonosítón keresztül. A pod által felügyelt identitások jelenleg előzetes verzióban érhetőek el az AKS-hez. Első lépésként tekintse meg a Microsoft Entra pod által felügyelt identitások használatát az Azure Kubernetes Service (előzetes verzió) dokumentációjában.

A Microsoft Entra pod által felügyelt identitás (előzetes verzió) két működési módot támogat:

• Standard mód: Ebben a módban a következő 2 összetevő van üzembe helyezve az AKS-fürtben:

  • Managed Identity Controller(MIC): Kubernetes-vezérlő, amely a Kubernetes API-kiszolgálón keresztül figyeli a podok, az AzureIdentity és az AzureIdentityBinding módosításait. Ha releváns módosítást észlel, a MIC szükség szerint hozzáadja vagy törli az AzureAssignedIdentitást . Konkrétan egy pod ütemezésekor a MIC hozzárendeli a felügyelt identitást az Azure-ban a csomópontkészlet által a létrehozási fázisban használt mögöttes virtuálisgép-méretezési csoporthoz. Az identitást használó összes pod törlésekor eltávolítja az identitást a csomópontkészlet virtuálisgép-méretezési csoportjából, kivéve, ha ugyanazt a felügyelt identitást más podok használják. A MIC hasonló műveleteket hajt végre az AzureIdentity vagy az AzureIdentityBinding létrehozásakor vagy törlésekor.

  • Csomópontalapú felügyelt identitás (NMI): egy pod, amely DaemonSetként fut az AKS-fürt minden csomópontján. Az NMI minden csomóponton elfogja a biztonsági jogkivonat-kérelmeket az Azure Instance Metadata Service-hez . Átirányítja a kéréseket önmagának, és ellenőrzi, hogy a pod rendelkezik-e hozzáféréssel ahhoz az identitáshoz, amelyhez jogkivonatot kér, és lekéri a jogkivonatot a Microsoft Entra-bérlőtől az alkalmazás nevében.

• Felügyelt mód: Ebben a módban csak NMI van. Az identitást a felhasználónak manuálisan kell hozzárendelnie és felügyelnie. További információ: Pod Identity felügyelt módban. Ebben a módban, amikor az az aks pod-identity add paranccsal ad hozzá podidentitást egy Azure Kubernetes Service-fürthöz (AKS- fürthöz), a paraméter által --namespace megadott névtérben hozza létre az AzureIdentity és az AzureIdentityBinding metódust, míg az AKS-erőforrás-szolgáltató a paraméter által --identity-resource-id megadott felügyelt identitást az AKS-fürt egyes csomópontkészleteinek virtuálisgép-méretezési csoportjához rendeli hozzá.

A managed mód a következő előnyöket nyújtja a standardkövetkezőkhöz képest:

• A csomópontkészlet virtuálisgép-méretezési csoportjának identitás-hozzárendelése akár 40-60-as éveket is igénybe vehet. Az identitáshoz hozzáférést igénylő és a hozzárendelés késleltetését nem tűrő cronjobs vagy alkalmazások esetén a legjobb managed mód, mivel az identitást előre hozzárendelték a csomópontkészlet virtuálisgép-méretezési csoportjához. Manuálisan vagy az az aks pod-identity add paranccsal.
• standard Módban a MIC írási engedélyeket igényel az AKS-fürt által használt virtuálisgép-méretezési csoporthoz és Managed Identity Operator a felhasználó által hozzárendelt felügyelt identitásokhoz. Ha be van futva managed mode, mivel nincs mikrofon, a szerepkör-hozzárendelések nem szükségesek.

A podok hitelesítő adatainak manuális megadása helyett a pod által felügyelt identitások valós időben kérnek hozzáférési jogkivonatot, és csak a hozzájuk rendelt erőforrásokhoz férnek hozzá. Az AKS-ben két összetevő kezeli a műveleteket, amelyek lehetővé teszik a podok számára a felügyelt identitások használatát:

• A Csomópontkezelési identitás (NMI) kiszolgáló egy pod, amely DaemonSetként fut az AKS-fürt minden csomópontján. Az NMI-kiszolgáló figyeli az Azure-szolgáltatások podkéréseit.
• Az Azure Resource Provider lekérdezi a Kubernetes API-kiszolgálót, és egy podnak megfelelő Azure-identitásleképezést keres.

Amikor a podok biztonsági jogkivonatot kérnek a Microsoft Entra ID-tól egy Azure-erőforráshoz való hozzáféréshez, a hálózati szabályok átirányítják a forgalmat az NMI-kiszolgálóra.

1. Az NMI-kiszolgáló:

   • Azonosítja azOkat a podokat, amelyek távoli címük alapján hozzáférést kérnek az Azure-erőforrásokhoz.
   • Lekérdezi az Azure-erőforrás-szolgáltatót.

2. Az Azure Resource Provider ellenőrzi az Azure-identitásleképezéseket az AKS-fürtben.

3. Az NMI-kiszolgáló hozzáférési jogkivonatot kér a Microsoft Entra-azonosítótól a pod identitásleképezése alapján.

4. A Microsoft Entra ID hozzáférést biztosít az NMI-kiszolgálóhoz, amelyet a rendszer visszaad a podnak.

   • Ezt a hozzáférési jogkivonatot a pod használhatja, hogy ezután hozzáférést kérjen az Azure-beli erőforrásokhoz.

A következő példában egy fejlesztő létrehoz egy podot, amely felügyelt identitással kér hozzáférést az Azure SQL Database-hez:

1. A fürt operátora létrehoz egy szolgáltatásfiókot az identitások leképezéséhez, amikor a podok hozzáférést kérnek az erőforrásokhoz.
2. Az NMI-kiszolgáló üzembe van helyezve, hogy továbbítsa a podkérelmeket az Azure Resource Providerrel együtt a Microsoft Entra ID-hoz való hozzáférési jogkivonatokhoz.
3. A fejlesztő egy felügyelt identitással rendelkező podot helyez üzembe, amely hozzáférési jogkivonatot kér az NMI-kiszolgálón keresztül.
4. A jogkivonat visszakerül a podra, és az Azure SQL Database elérésére szolgál

Pod által felügyelt identitások használatához lásd : Microsoft Entra pod által felügyelt identitások használata az Azure Kubernetes Service-ben (előzetes verzió).

Következő lépések

Ez az ajánlott eljárásokkal foglalkozó cikk a fürt és az erőforrások hitelesítésére és engedélyezésére összpontosított. Az ajánlott eljárások némelyikének implementálásához tekintse meg az alábbi cikkeket:

• A Microsoft Entra ID integrálása az AKS-sel
• Microsoft Entra pod által felügyelt identitások használata az Azure Kubernetes Service-ben (előzetes verzió)

Az AKS-fürtműveletekkel kapcsolatos további információkért tekintse meg az alábbi ajánlott eljárásokat:

• Több-bérlős és fürtelkülönítés
• A Kubernetes scheduler alapfunkciói
• A Kubernetes scheduler speciális funkciói