Ajánlott eljárások a hálózati kapcsolatokhoz és a biztonsághoz a Azure Kubernetes Service (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 szüksége lesz arra, hogyfrissítsen az Azure Container Networking Interface (CNI) átfedésreaz adott nap előtt, amikor a kubenetet használó AKS számítási feladatok már nem lesznek támogatottak.

Amikor fürtöket hoz létre és kezel a Azure Kubernetes Service (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:

• Ismertesse az AKS-ben az Azure Tárolóhálózati Interfész (CNI) hálózati módot.
• 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

A meglévő virtuális hálózatokkal vagy helyszíni hálózatokkal való integrációhoz használja Azure CNI-hálózatokat az AKS-ben. 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 a 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.

Azure CNI érvényes lehetőség a produkciós környezetekhez.

CNI-hálózatkezelés

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 virtuális hálózatokhoz való csatlakozáskor. Minden csomópont és pod-erőforrás egy IP-címet kap a Azure 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ózat a termelési környezetben lehetővé teszi az erőforrások irányításának és kezelésé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. A 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.

Ha Azure CNI-hálózatkezelést használ, a virtuális hálózati erőforrás egy külön erőforráscsoportban van az AKS-fürtől. 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ás főfelhasználó delegálásáról további információé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 Azure CNI-hálózatkezelés esetén 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 kapcsolatot a helyszíni vagy kapcsolt hálózatokkal az Azure-ban.
• A léptékbővítési események vagy fürtfrissítések kezeléséhez a hozzárendelt alhálózatban további IP-címekre van szükség.
  • 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. A Windows Server csomópontokkal kapcsolatos további információkért lásd: Csomópontkészlet hozzáadása az AKS-ben.

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

Ha Azure CNI-hálózattal rendelkező fürtöt hoz létre, 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: Az 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. A 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 az Application Gatewayt tárolókhoz, Contourhoz, HAProxyhoz, Traefikhez 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.

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 egy teljes mértékben felügyelt bejövőforgalom-vezérlő Azure Kubernetes Service (AKS) számára, 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ó a Azure DNS a nyilvános és privát zónakezeléshez.

• SSL-leállítás Azure Key Vault 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 Barracuda WAF-ot Azure vagy Azure Application Gateway tárolókhoz. 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 Alkalmazás-átjáró konténerekhez egy WAF, amely integrálódik az AKS-fürtökkel, és alkalmazza ezeket a biztonsági funkciókat, mielőtt a forgalom elérné 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. Azure Application Gateway tárolókhoz központilag felügyelhető egy erőforrásdefinícióval rendelkező bejövő vezérlőként. Első lépésként hozzon létre egy Application Gateway for Containerst.

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ályzatokkal való kezdéshez lásd: Hogyan tegyük biztonságossá a podok közötti forgalmat hálózati szabályzatokkal az Azure Kubernetes Service-ben (AKS).

DNS-feloldás optimalizálása LocalDNS használatával

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

Engedélyezze a LocalDNS-t az AKS-csomópontkészleteken a DNS teljesítményének, megbízhatóságának és a központi CoreDNS-podok terhelésének csökkentéséhez.

A DNS-feloldás kritikus fontosságú a Kubernetes szolgáltatásközi kommunikációja szempontjából. Alapértelmezés szerint a podokról érkező DNS-lekérdezések a központosított CoreDNS-podokra kerülnek, ami nagy léptékben szűk keresztmetszetté válhat. Az AKS LocalDNS-t kínál, amely minden csomóponton üzembe helyez egy DNS-proxyt szolgáltatásként systemd . Ez a proxy helyileg kezeli a DNS-lekérdezéseket, csökkentve a hálózati ugrásokat és a felbontás késését.

A LocalDNS emellett kiküszöböli conntrack a DNS-forgalom táblabejegyzéseit, megakadályozva conntrack a táblák kimerülését és a megszakadt kapcsolatokat okozó versenyfeltételeket. A helyi gyorsítótár és a CoreDNS közötti kapcsolatok TCP-re frissülnek, lehetővé téve a kapcsolatok újraegyensúlyozását és a nyomkövetési bejegyzések gyorsabb törlését.

A magas DNS-rendelkezésre állást igénylő számítási feladatok esetében a LocalDNS támogatja az elavult gyorsítótárazott válaszok konfigurálható ideig történő kiszolgálását, ha a felső szintű DNS nem érhető el. Ez a képesség segít fenntartani a podkapcsolatot és a szolgáltatás megbízhatóságát az átmeneti DNS-kimaradások során.

További információ a LocalDNS architektúrájáról és képességeiről: DNS-feloldás az AKS-ben. A konfigurációs utasításokért lásd: LocalDNS konfigurálása.

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.

Az AKS legtöbb műveletét a Azure felügyeleti eszközökkel vagy a Kubernetes API-kiszolgálón keresztül hajthatja végre. 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 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. További információkért a Kubernetes hálózat alapjairól tekintse meg a következő oldalt: Hálózati fogalmak az alkalmazásokhoz az Azure Kubernetes Service (AKS)