Hálózati kapcsolatra és biztonságra vonatkozó ajánlott eljárások az Azure Kubernetes Service-ben (AKS)

Fontos

2028. március 31-én az Azure Kubernetes Service (AKS) kubenet-hálózatkezelése megszűnik.

A szolgáltatáskimaradások elkerülése érdekében frissítenie kell az Azure Container Networking Interface (CNI) átfedésreazelőtt a dátum előtt, amikor a kubenet használatával futó számítási feladatok az AKS-hez már nem lesznek támogatottak.

Amikor fürtöket hoz létre és kezel az Azure Kubernetes Service-ben (AKS), hálózati kapcsolatot biztosít a csomópontokhoz és alkalmazásokhoz. Ezek a hálózati erőforrások ip-címtartományokat, terheléselosztókat és bejövőforgalom-vezérlőket tartalmaznak.

Ez az ajánlott eljárásokat ismertető cikk a fürtüzemeltetők hálózati kapcsolatára és biztonságára összpontosít. Ebben a cikkben az alábbiakkal ismerkedhet meg:

• Az Azure Container Network Interface (CNI) hálózati módjának ismertetése az AKS-ben.
• Tervezze meg a szükséges IP-címzést és -kapcsolatot.
• Forgalom elosztása terheléselosztók, bejövőforgalom-vezérlők vagy webalkalmazási tűzfal (WAF) használatával.
• Biztonságos csatlakozás fürtcsomópontokhoz.

Válassza ki a megfelelő hálózati modellt

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

Azure CNI-hálózatkezelés használata az AKS-ben meglévő virtuális hálózatokkal vagy helyszíni hálózatokkal való integrációhoz. Ez a hálózati modell lehetővé teszi az erőforrások és vezérlők nagyobb elkülönítését egy vállalati környezetben.

A virtuális hálózatok alapvető kapcsolatot biztosítanak az AKS-csomópontok és az ügyfelek számára az alkalmazások eléréséhez. Az AKS-fürtök virtuális hálózatokban való üzembe helyezésének két különböző módja van:

• Azure CNI-hálózatkezelés: Üzembe helyez egy virtuális hálózaton, és az Azure CNI Kubernetes beépülő modult használja. A podok olyan egyéni IP-címeket kapnak, amelyek más hálózati szolgáltatásokhoz vagy helyszíni erőforrásokhoz irányíthatók.

Az Azure CNI megfelelő választás az éles rendszerekhez.

CNI-hálózatkezelés

Az Azure CNI egy szállítósemleges protokoll, amely lehetővé teszi, hogy a tároló futtatókörnyezet kéréseket küldjön egy hálózati szolgáltatónak. IP-címeket rendel a podokhoz és csomópontokhoz, és IP-címkezelési (IPAM) funkciókat biztosít a meglévő Azure-beli virtuális hálózatokhoz való csatlakozáskor. Minden csomópont és pod-erőforrás kap egy IP-címet az Azure-beli virtuális hálózaton. Nincs szükség további útválasztásra más erőforrásokkal vagy szolgáltatásokkal való kommunikációhoz.

Nevezetesen, az Azure CNI-hálózatkezelés termelési környezetben lehetővé teszi az erőforrások irányításának és felügyeletének elkülönítését. Biztonsági szempontból gyakran azt szeretné, hogy a különböző csapatok felügyelhessék és védhessék ezeket az erőforrásokat. Az Azure CNI hálózatkezelésével közvetlenül az egyes podokhoz rendelt IP-címeken keresztül csatlakozhat meglévő Azure-erőforrásokhoz, helyszíni erőforrásokhoz vagy egyéb szolgáltatásokhoz.

Az Azure CNI-hálózatkezelés használatakor a virtuális hálózati erőforrás egy külön erőforráscsoportban található az AKS-fürthöz. Engedélyek delegálása az AKS-fürt azonosítójához az erőforrások eléréséhez és kezeléséhez. Az AKS-fürt által használt fürtidentitásnak a virtuális hálózaton belüli alhálózaton legalább hálózati közreműködői engedélyekkel kell rendelkeznie.

Ha a beépített hálózati közreműködői szerepkör használata helyett egyéni szerepkört szeretne definiálni, a következő engedélyekre van szükség:

• Microsoft.Network/virtualNetworks/subnets/join/action
• Microsoft.Network/virtualNetworks/subnets/read

Az alapértelmezés szerint az AKS felügyelt identitást használ a fürtazonosítójához. Ehelyett azonban használhat szolgáltatási főszereplőt.

• Az AKS szolgáltatásnév-delegálásával kapcsolatos további információkért lásd : Hozzáférés delegálása más Azure-erőforrásokhoz.
• A felügyelt identitásokról további információt a Felügyelt identitások használata című témakörben talál.

Mivel minden csomópont és pod saját IP-címet kap, tervezze meg az AKS-alhálózatok címtartományait. Tartsa szem előtt a következő feltételeket:

• Az alhálózatnak elég nagynak kell lennie ahhoz, hogy IP-címeket adjon meg minden üzembe helyezendő csomóponthoz, podhoz és hálózati erőforráshoz.
  • Az Azure CNI hálózatkezelésével minden futó csomópont alapértelmezett korlátokkal rendelkezik a podok számára.
• Kerülje a meglévő hálózati erőforrásokkal átfedésben lévő IP-címtartományok használatát.
  • Engedélyezni kell a helyszíni vagy társhálózatokhoz való kapcsolódást az Azure-ban.
• A vertikális felskálázási események vagy fürtfrissítések kezeléséhez további IP-címekre van szükség a hozzárendelt alhálózatban.
  • Ez a további címtér különösen fontos, ha Windows Server-tárolókat használ, mivel ezek a csomópontkészletek frissítésre szorulnak a legújabb biztonsági javítások alkalmazásához. További információ a Windows Server-csomópontokról: Csomópontkészlet frissítése az AKS-ben.

A szükséges IP-cím kiszámításához lásd : Azure CNI-hálózatkezelés konfigurálása az AKS-ben.

Az Azure CNI-hálózatkezeléssel rendelkező fürtök létrehozásakor meg kell adnia a fürt egyéb címtartományait, például a Docker-híd címét, a DNS-szolgáltatás IP-címét és a szolgáltatáscímtartományt. Általában győződjön meg arról, hogy ezek a címtartományok nem fedik egymást vagy a fürthöz társított hálózatokat, beleértve a virtuális hálózatokat, alhálózatokat, helyszíni és társhálózatokat.

A címtartományok korlátaival és méretezésével kapcsolatos részletekért lásd : Azure CNI-hálózatkezelés konfigurálása az AKS-ben.

Bejövő forgalom elosztása

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

A HTTP- vagy HTTPS-forgalom alkalmazásokhoz való elosztásához használjon bejövő erőforrásokat és vezérlőket. Az Azure-terheléselosztóhoz képest a bejövőforgalom-vezérlők további funkciókat biztosítanak, és natív Kubernetes-erőforrásokként kezelhetők.

Bár egy Azure-terheléselosztó el tudja osztani az ügyfélforgalmat az AKS-fürtön lévő alkalmazások között, ennek a forgalomnak a megértése korlátozott. A terheléselosztó-erőforrás a 4. rétegben működik, és protokoll vagy portok alapján osztja el a forgalmat.

A HTTP-t vagy HTTPS-t használó webalkalmazások többsége a Kubernetes bejövő erőforrásait és vezérlőit használja, amelyek a 7. rétegben működnek. Az Ingress terjesztheti a bejövő forgalmat az alkalmazás URL-címe alapján, és kezeli a TLS/SSL kapcsolat lezárását. A bejövő forgalom emellett csökkenti a felfedett és leképezett IP-címek számát.

Terheléselosztóval minden alkalmazásnak általában szüksége van egy nyilvános IP-címre, amit hozzárendelnek az AKS-fürtben lévő szolgáltatáshoz. Bejövő erőforrás esetén egyetlen IP-cím több alkalmazás számára is elosztja a forgalmat.

A bejövő forgalomnak két összetevője van:

1. Bejövő erőforrás
2. Bejárati vezérlő

Bejövő erőforrás

A ingressz erőforrás a kind: Ingress YAML-manifesztje. Meghatározza a hosztot, a tanúsítványokat és a szabályokat a forgalom irányítására az AKS-fürtben futó szolgáltatásokhoz.

Az alábbi YAML-jegyzék a myapp.com forgalmát két szolgáltatás, a blogszolgáltatás vagy a storeservice egyikére osztja el, és az ügyfeleket az általuk elért URL-cím alapján irányítja az egyik szolgáltatásra vagy a másikra.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 name: myapp-ingress
spec:
 ingressClassName: PublicIngress
 tls:
 - hosts:
   - myapp.com
   secretName: myapp-secret
 rules:
   - host: myapp.com
     http:
      paths:
      - path: /blog
        backend:
         service:
           name: blogservice
           port: 80
      - path: /store
        backend:
         service:
           name: storeservice
           port: 80

Ingress vezérlő

A bejövőforgalom-vezérlő egy démon, amely egy AKS-csomóponton fut, és figyeli a bejövő kéréseket. A forgalom ezután a bejövő erőforrásban meghatározott szabályok alapján lesz elosztva. Bár a leggyakoribb bejövőforgalom-vezérlő az NGINX-en alapul, az AKS nem korlátozza Önt egy adott vezérlőre. Használhatja Contour, HAProxy, Traefik például.

A bejövőforgalom-vezérlőket Linux-csomóponton kell ütemezni. Jelezze, hogy az erőforrásnak Linux-alapú csomóponton kell futnia egy csomópontválasztóval a YAML-jegyzékben vagy a Helm-diagram üzembe helyezésében. További információ: Csomópontválasztók használata a podok AKS-ben való ütemezésének szabályozásához.

Az alkalmazás útválasztási kiegészítőjével történő bejárat

Az alkalmazás-útválasztási bővítmény ajánlott módja egy bejövőforgalom-vezérlő konfigurálásának az AKS-ben. Az alkalmazás-útválasztási bővítmény az Azure Kubernetes Service (AKS) teljes körűen felügyelt bejövőforgalom-vezérlője, amely a következő funkciókat biztosítja:

• Felügyelt NGINX bejövőforgalom-vezérlők egyszerű konfigurálása Kubernetes NGINX bejövőforgalom-vezérlő alapján.

• Integráció az Azure DNS-sel a nyilvános és privát zónakezeléshez.

• SSL-leállítás az Azure Key Vaultban tárolt tanúsítványokkal.

További információ az alkalmazás-útválasztási bővítményről: Felügyelt NGINX-bejövő forgalom az alkalmazás-útválasztási bővítményrel.

Forgalom védelme webalkalmazási tűzfallal (WAF)

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

A bejövő forgalom lehetséges támadások kereséséhez használjon webalkalmazási tűzfalat (WAF), például az Azure-hoz készült Barracuda WAF-et vagy Azure-alkalmazás Gatewayt. Ezek a fejlettebb hálózati erőforrások a forgalmat csak HTTP- és HTTPS-kapcsolatokon vagy alapszintű TLS-végpontokon túl is irányíthatják.

Az ingress vezérlő általában egy Kubernetes-erőforrás az AKS-fürtben, amely irányítja a forgalmat szolgáltatásokhoz és alkalmazásokhoz. A vezérlő démonként fut egy AKS-csomóponton, és felhasználja a csomópont egyes erőforrásait, például a processzort, a memóriát és a hálózati sávszélességet. Nagyobb környezetekben érdemes megfontolni a következőket:

• A forgalomirányítás egy részének vagy a TLS-lezárásnak az áttelepítése az AKS-fürtön kívüli hálózati erőforrásra.
• Potenciális támadások keresése a bejövő forgalomban.

Ennél a biztonsági rétegnél egy webalkalmazási tűzfal (WAF) szűri a bejövő forgalmat. Az Open Web Application Security Project (OWASP) szabályokkal figyeli az olyan támadásokat, mint a helyek közötti szkriptelés vagy a cookie-mérgezés. Azure Application Gateway (jelenleg előzetes verzióban az AKS-ben) egy WAF, amely integrálható az AKS-fürtökkel, és zárolja ezeket a biztonsági funkciókat, mielőtt a forgalom elérné az AKS-fürtöket és alkalmazásokat.

Mivel más külső megoldások is elvégzik ezeket a funkciókat, továbbra is használhatja a meglévő beruházásokat vagy szakértelmet az előnyben részesített termékben.

A terheléselosztó vagy a bejövő erőforrások folyamatosan futnak az AKS-fürtön, és finomítják a forgalomeloszlást. Az App Gateway központilag kezelhető bejövőforgalom-vezérlőként, erőforrásdefinícióval. Első lépésként hozzon létre egy Application Gateway bejövőforgalom-vezérlőt.

Forgalom szabályozása hálózati szabályzatokkal

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

Hálózati házirendek használatával engedélyezheti vagy tilthatja meg a podokhoz érkező forgalmat. Alapértelmezés szerint a klaszter podjai között minden forgalom engedélyezett. A nagyobb biztonság érdekében definiáljon olyan szabályokat, amelyek korlátozzák a podok közötti kommunikációt.

A hálózati házirend az AKS-ben elérhető Kubernetes-szolgáltatás, amely lehetővé teszi a podok közötti forgalom szabályozását. Engedélyezheti vagy letilthatja a pod felé irányuló forgalmat olyan beállítások alapján, mint a hozzárendelt címkék, a névtér vagy a forgalmi port. A hálózati házirendek natív felhőbeli módon szabályozják a podok forgalmát. Mivel a podokat dinamikusan hozzák létre egy AKS-fürtben, a szükséges hálózati szabályzatok automatikusan érvénybe lépnek.

A hálózati szabályzatok AKS-ben való használatához a szolgáltatás engedélyezhető a fürt létrehozásakor vagy már egy meglévő AKS-fürt beállításakor. Ha hálózati szabályzatokat szeretne használni, győződjön meg arról, hogy a szolgáltatás engedélyezve van az AKS-fürtön.

Feljegyzés

A hálózati házirendek linuxos vagy Windows-alapú csomópontokhoz és podokhoz használhatók az AKS-ben.

YAML-manifesztum használatával létrehoz egy hálózati szabályzatot Kubernetes-erőforrásként. A szabályzatok meghatározott podokra lesznek alkalmazva, a forgalomfolyamatot meghatározó bejövő vagy kimenő szabályokkal.

Az alábbi példa egy hálózati házirendet alkalmaz az alkalmazással rendelkező podokra: a háttércímkére alkalmazva. A beérkező szabály csak a app: frontend címkével rendelkező podok forgalmát engedélyezi.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: backend-policy
spec:
  podSelector:
    matchLabels:
      app: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend

A szabályzatok megismeréséhez tekintse meg a hálózati házirendekkel történő forgalom biztosításáról az Azure Kubernetes Service-ben (AKS) című cikket.

Biztonságos csatlakozás csomópontokhoz megerősített gazdagépen keresztül

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

Ne tegye elérhetővé az AKS-csomópontokhoz való távoli kapcsolatot. Hozzon létre egy ugró szervert vagy jump boxot egy felügyeleti célú virtuális hálózatban. A megerősített gazdagép használatával biztonságosan irányíthatja a forgalmat az AKS-fürtbe távoli felügyeleti feladatokhoz.

A legtöbb műveletet az AKS-ben az Azure felügyeleti eszközeivel vagy a Kubernetes API-kiszolgálón keresztül végezheti el. Az AKS-csomópontok csak magánhálózaton érhetők el, és nem csatlakoznak a nyilvános internethez. A csomópontokhoz való csatlakozás, karbantartás és támogatás érdekében irányítsa a kapcsolatokat egy megerősített gazdagépen vagy jump boxon keresztül. Ellenőrizze, hogy ez a gazdagép egy különálló, biztonságosan társviszonyban lévő felügyeleti virtuális hálózatban található-e az AKS-fürt virtuális hálózatával.

A bástya gazdagép menedzsment hálózatát is biztonságossá kell tenni. Azure ExpressRoute- vagy VPN-átjáró használatával csatlakozhat egy helyszíni hálózathoz, és hálózati biztonsági csoportokkal szabályozhatja a hozzáférést.

Következő lépések

Ez a cikk a hálózati kapcsolatra és a biztonságra összpontosított. A Kubernetes hálózati alapjaival kapcsolatos további információkért tekintse meg az Azure Kubernetes Service (AKS) alkalmazásainak hálózati fogalmait