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

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:

• Hasonlítsa össze a Kubenet és az Azure Container Networking Interface (CNI) hálózati módokat 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.
• Kubenet-hálózatkezelés: Az Azure a fürt üzembe helyezésekor kezeli a virtuális hálózati erőforrásokat, és a Kubenet Kubernetes beépülő modult használja.

Az Azure CNI és a Kubenet egyaránt érvényes lehetőségek az éles környezetekhez.

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 az éles környezetben lehetővé teszi az erőforrások felügyeletének é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 identitásához az erőforrások eléréséhez és kezeléséhez. Az AKS-fürt által használt fürtidentitásnak legalább hálózati közreműködői engedélyekkel kell rendelkeznie a virtuális hálózaton belüli alhálózaton.

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 AKS alapértelmezés szerint egy felügyelt identitást használ a fürt identitásához. Ehelyett azonban használhat szolgáltatásnevet.

• 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.
  • A Kubenet és 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.

Kubenet-hálózatkezelés

Bár a Kubenet nem követeli meg a virtuális hálózatok konfigurálását a fürt üzembe helyezése előtt, a várakozás hátrányai vannak, például:

• Mivel a csomópontok és podok különböző IP-alhálózatokon vannak elhelyezve, a felhasználói útválasztás (UDR) és az IP-továbbítás a podok és csomópontok közötti forgalmat irányítja. Ez a további útválasztás csökkentheti a hálózati teljesítményt.
• Csatlakozás meglévő helyszíni hálózatokhoz vagy más Azure-beli virtuális hálózatokhoz való társviszony-létesítés összetett lehet.

Mivel nem az AKS-fürttől külön hozza létre a virtuális hálózatot és alhálózatokat, a Kubenet ideális a következő forgatókönyvekhez:

• Kis fejlesztési vagy tesztelési számítási feladatok.
• Egyszerű, alacsony forgalmú webhelyek.
• Számítási feladatok emelése és áthelyezése tárolókba.

Éles üzembe helyezés esetén a kubenet és az Azure CNI is érvényes lehetőség. Azok a környezetek, amelyek az irányítás és a felügyelet elkülönítését igénylik, az Azure CNI lehet az előnyben részesített lehetőség. Emellett a Kubenet csak olyan Linux-környezetekhez használható, ahol az IP-címtartomány megőrzése prioritást élvez.

A kubenet használatával saját IP-címtartományokat és virtuális hálózatokat is konfigurálhat. Az Azure CNI hálózatkezeléséhez hasonlóan ezek a címtartományok sem fedik egymást, sem a fürthöz társított hálózatokat (virtuális hálózatok, alhálózatok, helyszíni és társhálózatok).

A korlátozásokkal és a címtartományok méretezésével kapcsolatos részletekért lásd : Kubenet-hálózatkezelés használata saját IP-címtartományokkal 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. A bejövő forgalom az alkalmazás URL-címe alapján terjeszthető, és kezeli a TLS/SSL-lezárásokat. A bejövő forgalom emellett csökkenti a felfedett és leképezett IP-címek számát.

Terheléselosztó esetén minden alkalmazáshoz általában hozzá kell rendelni egy nyilvános IP-címet, és le kell képezni a szolgáltatást az AKS-fürtben. 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övőforgalom-vezérlő

Bejövő erőforrás

A bejövő erőforrás a KÖVETKEZŐ YAML-jegyzékfájlja kind: Ingress: . Meghatározza a gazdagépet, a tanúsítványokat és a szabályokat, hogy a forgalmat az AKS-fürtön futó szolgáltatásokhoz irányíthassa.

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

Bemeneti 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 a Contour, HAProxy, Traefik stb.

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.

Bejövő forgalom az alkalmazás útválasztási bővítményével

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.

A bejövőforgalom-vezérlő általában egy Kubernetes-erőforrás az AKS-fürtben, amely szolgáltatásokat és alkalmazásokat osztja el a forgalommal. 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 forgalom útválasztásának vagy TLS-leállításának egy része kiszervezése az AKS-fürtn kívüli hálózati erőforrásba.
• 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-alkalmazás Átjáró (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érené az AKS-fürtöt é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 le a podok felé irányuló forgalmat. Alapértelmezés szerint a fürt 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 podok dinamikusan jönnek létre egy AKS-fürtben, a szükséges hálózati szabályzatok automatikusan alkalmazhatók.

A hálózati házirend használatához engedélyezze a szolgáltatást egy új AKS-fürt létrehozásakor. Meglévő AKS-fürtön nem engedélyezheti a hálózati házirendet. Tervezze meg előre, hogy engedélyezze a hálózati szabályzatot a szükséges fürtökön.

Feljegyzés

A hálózati házirend csak Linux-alapú csomópontokhoz és podokhoz használható az AKS-ben.

YaML-jegyzék használatával hozzon létre 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 bemeneti szabály csak az alkalmazással rendelkező podok forgalmát engedélyezi: előtércímkét .

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 használatának első lépéseit az Azure Kubernetes Service (AKS) hálózati házirendek használatával történő biztonságossá tételéről szóló cikkben tekintheti meg.

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 megerősített gazdagépet vagy jump boxot egy felügyeleti virtuális hálózaton. 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áshoz és a karbantartáshoz és támogatáshoz irányíthatja 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 megerősített gazdagép felügyeleti 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