Güvenlik Profesyonelleri için Kubernetes Ağ Politikalarına Giriş

Not. tercüme: Makalenin yazarı Reuven Harrison, yazılım geliştirme alanında 20 yılı aşkın deneyime sahiptir ve bugün güvenlik politikası yönetimi çözümleri üreten bir şirket olan Tufin'in CTO'su ve kurucu ortağıdır. Kubernetes ağ politikalarını bir kümedeki ağ bölümlendirmesi için oldukça güçlü bir araç olarak görse de bunların pratikte uygulanmasının o kadar kolay olmadığına da inanıyor. Oldukça hacimli olan bu materyal, uzmanların bu konudaki farkındalığını artırmayı ve gerekli konfigürasyonları oluşturmalarına yardımcı olmayı amaçlamaktadır.

Günümüzde pek çok şirket uygulamalarını çalıştırmak için giderek daha fazla Kubernetes'i tercih ediyor. Bu yazılıma ilgi o kadar yüksek ki bazıları Kubernetes'i "veri merkezinin yeni işletim sistemi" olarak adlandırıyor. Kubernetes (veya k8s), ağ güvenliği de dahil olmak üzere olgun iş süreçlerinin organizasyonunu gerektiren işin kritik bir parçası olarak yavaş yavaş algılanmaya başlıyor.

Kubernetes ile çalışmaktan kafası karışan güvenlik profesyonelleri için gerçek açıklama, platformun varsayılan politikası olabilir: her şeye izin ver.

Bu kılavuz, ağ politikalarının iç yapısını anlamanıza yardımcı olacaktır; normal güvenlik duvarlarının kurallarından ne kadar farklı olduklarını anlayın. Ayrıca bazı tuzakları ele alacak ve Kubernetes'teki uygulamaların güvenliğini sağlamaya yardımcı olacak öneriler sunacak.

Kubernetes ağ politikaları

Kubernetes ağ politikası mekanizması, platformda konuşlandırılan uygulamaların ağ katmanındaki (OSI modelinde üçüncü) etkileşimini yönetmenize olanak tanır. Ağ ilkeleri, modern güvenlik duvarlarının OSI Katman 7 uygulaması ve tehdit tespiti gibi bazı gelişmiş özelliklerinden yoksundur, ancak iyi bir başlangıç ​​noktası olan temel düzeyde ağ güvenliği sağlarlar.

Ağ politikaları bölmeler arasındaki iletişimi kontrol eder

Kubernetes'teki iş yükleri, birlikte konuşlandırılan bir veya daha fazla konteynerden oluşan bölmeler arasında dağıtılır. Kubernetes, her bölmeye diğer bölmelerden erişilebilen bir IP adresi atar. Kubernetes ağ politikaları, buluttaki güvenlik gruplarının sanal makine örneklerine erişimi denetlemek için kullanıldığı gibi, bölme grupları için erişim haklarını ayarlar.

Ağ Politikalarını Tanımlama

Diğer Kubernetes kaynakları gibi ağ politikaları da YAML'de belirtilir. Aşağıdaki örnekte uygulama balance erişim postgres:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: postgres
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: balance
  policyTypes:
  - Ingress

(Not. tercüme: Bu ekran görüntüsü, sonraki tüm benzerleri gibi, yerel Kubernetes araçları kullanılarak değil, orijinal makalenin yazarının şirketi tarafından geliştirilen ve materyalin sonunda bahsedilen Tufin Orca aracı kullanılarak oluşturulmuştur.)

Kendi ağ politikanızı tanımlamak için temel YAML bilgisine ihtiyacınız olacak. Bu dil girintiye dayalıdır (sekmeler yerine boşluklarla belirtilir). Girintili bir öğe, üstündeki en yakın girintili öğeye aittir. Yeni bir liste öğesi kısa çizgiyle başlar, diğer tüm öğeler şu biçimdedir: anahtar/değer çifti.

YAML'deki politikayı tanımladıktan sonra şunu kullanın: Kubectlkümede oluşturmak için:

kubectl create -f policy.yaml

Ağ Politikası Belirtimi

Kubernetes ağ politikası spesifikasyonu dört unsuru içerir:

1. podSelector: bu politikadan etkilenen bölmeleri tanımlar (hedefler) - gerekli;
2. policyTypes: buna ne tür politikaların dahil edildiğini belirtir: giriş ve/veya çıkış - isteğe bağlıdır, ancak bunu her durumda açıkça belirtmenizi öneririm;
3. ingress: izin verileni tanımlar gelen hedef bölmelere giden trafik - isteğe bağlı;
4. egress: izin verileni tanımlar dışa dönük Hedef bölmelerden gelen trafik isteğe bağlıdır.

Kubernetes web sitesinden alınan örnek (değiştirdim role üzerinde app), dört öğenin tamamının nasıl kullanıldığını gösterir:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:    # <<<
    matchLabels:
      app: db
  policyTypes:    # <<<
  - Ingress
  - Egress
  ingress:        # <<<
  - from:
    - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 172.17.1.0/24
    - namespaceSelector:
        matchLabels:
          project: myproject
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 6379
  egress:         # <<<
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 5978

Lütfen dört öğenin tamamının dahil edilmesi gerekmediğini unutmayın. Sadece zorunludur podSelector, diğer parametreler istenildiği gibi kullanılabilir.

atlarsanız policyTypespolitika şu şekilde yorumlanacaktır:

• Varsayılan olarak giriş tarafını tanımladığı varsayılır. Politika bunu açıkça belirtmiyorsa sistem tüm trafiğin yasaklandığını varsayacaktır.
• Çıkış tarafındaki davranış, karşılık gelen çıkış parametresinin varlığı veya yokluğu ile belirlenecektir.

Hatalardan kaçınmak için tavsiye ederim her zaman açıkça söyle policyTypes.

Yukarıdaki mantığa göre eğer parametreler ingress ve / veya egress atlanırsa politika tüm trafiği reddeder (aşağıdaki "Soyulma Kuralı"na bakın).

Varsayılan politika İzin Ver'dir

Hiçbir politika tanımlanmazsa Kubernetes varsayılan olarak tüm trafiğe izin verir. Tüm bölmeler kendi aralarında serbestçe bilgi alışverişinde bulunabilir. Bu, güvenlik açısından mantık dışı görünebilir, ancak Kubernetes'in başlangıçta geliştiriciler tarafından uygulamaların birlikte çalışabilirliğini sağlamak için tasarlandığını unutmayın. Ağ politikaları daha sonra eklendi.

Ad alanları

Ad alanları Kubernetes'in işbirliği mekanizmasıdır. Mantıksal ortamları birbirlerinden yalıtmak için tasarlanmışlardır ve alanlar arasındaki iletişime varsayılan olarak izin verilmektedir.

Çoğu Kubernetes bileşeni gibi ağ politikaları da belirli bir ad alanında bulunur. Blokta metadata politikanın hangi alana ait olduğunu belirtebilirsiniz:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: my-namespace  # <<<
spec:
...

Ad alanı meta verilerde açıkça belirtilmemişse sistem kubectl'de belirtilen ad alanını kullanacaktır (varsayılan olarak) namespace=default):

kubectl apply -n my-namespace -f namespace.yaml

Öneririm ad alanını açıkça belirtinaynı anda birden fazla ad alanını hedefleyen bir politika yazmıyorsanız.

birincil элемент podSelector politikada, politikanın ait olduğu ad alanından bölmeler seçilecektir (başka bir ad alanından bölmelere erişim reddedilir).

Benzer şekilde, podSelectors giriş ve çıkış bloklarında elbette bunları birleştirmediğiniz sürece, yalnızca kendi ad alanlarından bölmeler seçebilirsiniz. namespaceSelector (Bu, “Ad alanlarına ve bölmelere göre filtreleme” bölümünde ele alınacaktır).

Politika Adlandırma Kuralları

İlke adları aynı ad alanı içinde benzersizdir. Aynı alanda aynı ada sahip iki politika olamaz ancak farklı alanlarda aynı ada sahip politikalar bulunabilir. Bu, aynı politikayı birden fazla alana yeniden uygulamak istediğinizde kullanışlıdır.

Adlandırma yöntemlerinden biri özellikle hoşuma gitti. Ad alanı adının hedef bölmelerle birleştirilmesinden oluşur. Örneğin:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres  # <<<
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: postgres
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: admin
  policyTypes:
  - Ingress

Etiketler

Pod'lar ve ad alanları gibi Kubernetes nesnelerine özel etiketler ekleyebilirsiniz. Etiketler (etiketler - etiketler) buluttaki etiketlerin eşdeğeridir. Kubernetes ağ politikaları seçmek için etiketleri kullanır kapsüllerbunlar için geçerlidir:

podSelector:
  matchLabels:
    role: db

… veya ad alanlarıhangilerine başvuruyorlar. Bu örnek, ilgili etiketlere sahip ad alanlarındaki tüm bölmeleri seçer:

namespaceSelector:
  matchLabels:
    project: myproject

Bir uyarı: kullanırken namespaceSelector seçtiğiniz ad alanlarının doğru etiketi içerdiğinden emin olun. Gibi yerleşik ad alanlarının olduğunu unutmayın. default и kube-system, varsayılan olarak etiket içermez.

Bunun gibi bir alana etiket ekleyebilirsiniz:

kubectl label namespace default namespace=default

Aynı zamanda bölümdeki ad alanı metadata etikete değil gerçek alan adına atıfta bulunmalıdır:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default   # <<<
spec:
...

Kaynak ve hedef

Güvenlik duvarı politikaları, kaynakları ve hedefleri olan kurallardan oluşur. Kubernetes ağ politikaları, bir hedef (uygulanacakları bir dizi bölme) için tanımlanır ve ardından giriş ve/veya çıkış trafiği için kurallar ayarlanır. Örneğimizde politikanın hedefi ad alanındaki tüm bölmeler olacaktır. default anahtarlı etiketli app ve anlam db:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: db   # <<<
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 172.17.1.0/24
    - namespaceSelector:
        matchLabels:
          project: myproject
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 6379
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 5978

Alt bölüm ingress Bu politikada, hedef bölmelere gelen trafiği açar. Başka bir deyişle, giriş kaynak, hedef ise karşılık gelen varış noktasıdır. Aynı şekilde, çıkış varış noktasıdır ve hedef de onun kaynağıdır.

Bu, iki güvenlik duvarı kuralına eşdeğerdir: Giriş → Hedef; Hedef → Çıkış.

Çıkış ve DNS (önemli!)

Giden trafiği sınırlandırarak, DNS'e özellikle dikkat edin - Kubernetes bu hizmeti, hizmetleri IP adreslerine eşlemek için kullanır. Örneğin aşağıdaki politika uygulamaya izin vermediğiniz için çalışmayacaktır. balance DNS'ye erişim:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.balance
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: balance
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: postgres
  policyTypes:
  - Egress

DNS hizmetine erişimi açarak sorunu düzeltebilirsiniz:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.balance
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: balance
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: postgres
  - to:               # <<<
    ports:            # <<<
    - protocol: UDP   # <<<
      port: 53        # <<<
  policyTypes:
  - Egress

Son eleman to boştur ve bu nedenle dolaylı olarak seçer tüm ad alanlarındaki tüm bölmeler, izin vermek balance DNS sorgularını uygun Kubernetes hizmetine gönderin (genellikle alanda çalışır) kube-system).

Bu yaklaşım işe yarıyor ancak aşırı hoşgörülü ve güvensiz, çünkü DNS sorgularının küme dışına yönlendirilmesine izin verir.

Bunu birbirini takip eden üç adımda iyileştirebilirsiniz.

1. Yalnızca DNS sorgularına izin verin içinde ekleyerek kümeleyin namespaceSelector:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.balance
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: balance
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: postgres
  - to:
    - namespaceSelector: {} # <<<
    ports:
    - protocol: UDP
      port: 53
  policyTypes:
  - Egress

2. Yalnızca ad alanı içindeki DNS sorgularına izin verin kube-system.

Bunu yapmak için ad alanına bir etiket eklemeniz gerekir. kube-system: kubectl label namespace kube-system namespace=kube-system - ve bunu kullanarak politikaya yazın namespaceSelector:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.balance
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: balance
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: postgres
  - to:
    - namespaceSelector:         # <<<
        matchLabels:             # <<<
          namespace: kube-system # <<<
    ports:
    - protocol: UDP
      port: 53
  policyTypes:
  - Egress

3. Paranoyak insanlar daha da ileri giderek DNS sorgularını belirli bir DNS hizmetiyle sınırlandırabilirler. kube-system. “Ad alanlarına VE bölmelere göre filtrele” bölümü size bunu nasıl başaracağınızı anlatacaktır.

Başka bir seçenek de DNS'yi ad alanı düzeyinde çözümlemektir. Bu durumda her hizmet için açılmasına gerek kalmayacaktır:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.dns
  namespace: default
spec:
  podSelector: {} # <<<
  egress:
  - to:
    - namespaceSelector: {}
    ports:
    - protocol: UDP
      port: 53
  policyTypes:
  - Egress

boş podSelector ad alanındaki tüm bölmeleri seçer.

İlk maç ve kural sırası

Geleneksel güvenlik duvarlarında, bir paket üzerindeki eylem (İzin Ver veya Reddet), karşıladığı ilk kurala göre belirlenir. Kubernetes'te politikaların sırası önemli değildir.

Varsayılan olarak, hiçbir politika belirlenmediğinde bölmeler arasındaki iletişime izin verilir ve bölmeler serbestçe bilgi alışverişinde bulunabilir. İlkeleri formüle etmeye başladığınızda, bunlardan en az birinden etkilenen her bölme, onu seçen tüm ilkelerin ayrıklığına (mantıksal VEYA) göre izole edilir. Herhangi bir politikadan etkilenmeyen bölmeler açık kalır.

Bu davranışı bir ayırma kuralı kullanarak değiştirebilirsiniz.

Çıkarma kuralı (“Reddet”)

Güvenlik duvarı politikaları genellikle açıkça izin verilmeyen tüm trafiği reddeder.

Kubernetes'te reddetme eylemi yokancak benzer bir etki, boş bir kaynak bölme (giriş) grubu seçilerek normal (izin veren) bir politikayla elde edilebilir:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Ingress

Bu politika, ad alanındaki tüm bölmeleri seçer ve girişi tanımsız bırakarak gelen tüm trafiği reddeder.

Benzer şekilde, bir ad alanından giden tüm trafiği kısıtlayabilirsiniz:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-egress
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress

Lütfen unutmayın Trafiğin ad alanındaki bölmelere gitmesine izin veren tüm ek politikalar bu kurala göre öncelikli olacaktır (güvenlik duvarı yapılandırmasında reddetme kuralından önce izin verme kuralı eklemeye benzer).

Her şeye izin ver (Herhangi biri-Herhangi biri-İzin ver)

Tümüne İzin Ver politikası oluşturmak için yukarıdaki Reddet politikasını boş bir öğeyle tamamlamanız gerekir ingress:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all
  namespace: default
spec:
  podSelector: {}
  ingress: # <<<
  - {}     # <<<
  policyTypes:
  - Ingress

Şuradan erişime izin verir: tüm ad alanlarındaki tüm bölmelerden (ve tüm IP'lerden) ad alanındaki herhangi bir bölmeye default. Bu davranış varsayılan olarak etkindir, dolayısıyla genellikle daha fazla tanımlanmasına gerek yoktur. Ancak bazen sorunu teşhis etmek için bazı belirli izinleri geçici olarak devre dışı bırakmanız gerekebilir.

Kural yalnızca erişime izin verecek şekilde daraltılabilir belirli bir kapsül seti (app:balance) ad alanında default:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all-to-balance
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: balance
  ingress: 
  - {}
  policyTypes:
  - Ingress

Aşağıdaki politika, küme dışındaki herhangi bir IP'ye erişim de dahil olmak üzere tüm giriş ve çıkış trafiğine izin verir:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all
spec:
  podSelector: {}
  ingress:
  - {}
  egress:
  - {}
  policyTypes:
  - Ingress
  - Egress

Birden Çok Politikayı Birleştirme

Politikalar mantıksal VEYA kullanılarak üç düzeyde birleştirilir; Her bölmenin izinleri, onu etkileyen tüm politikaların ayrılığına uygun olarak ayarlanır:

1. Tarlalarda from и to Üç tür öğe tanımlanabilir (hepsi OR kullanılarak birleştirilir):

• namespaceSelector — ad alanının tamamını seçer;
• podSelector — bölmeleri seçer;
• ipBlock — bir alt ağ seçer.

Ayrıca, alt bölümlerdeki öğelerin sayısı (aynı olanlar bile) from/to limitsiz. Hepsi mantıksal VEYA ile birleştirilecektir.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres
  namespace: default
spec:
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: indexer
    - podSelector:
        matchLabels:
          app: admin
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
  - Ingress

2. Politika bölümünün içinde ingress birçok öğeye sahip olabilir from (mantıksal VEYA ile birleştirilir). Benzer şekilde bölüm egress birçok unsur içerebilir to (ayrıca ayırma yoluyla birleştirilir):

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres
  namespace: default
spec:
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: indexer
  - from:
    - podSelector:
        matchLabels:
          app: admin
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
  - Ingress

3. Farklı politikalar aynı zamanda mantıksal VEYA ile birleştirilir

Ancak bunları birleştirirken bir sınırlama vardır: Ben Chris Cooney: Kubernetes yalnızca farklı politikalarla birleştirilebilir policyTypes (Ingress veya Egress). Girişi (veya çıkışı) tanımlayan politikalar birbirinin üzerine yazacaktır.

Ad alanları arasındaki ilişki

Varsayılan olarak ad alanları arasında bilgi paylaşımına izin verilir. Bu, ad alanına giden ve/veya gelen trafiği kısıtlayacak bir reddetme politikası kullanılarak değiştirilebilir (yukarıdaki "Soyulma Kuralı"na bakın).

Bir ad alanına erişimi engelledikten sonra (yukarıdaki "Soyulma Kuralı"na bakın), aşağıdakileri kullanarak belirli bir ad alanından gelen bağlantılara izin vererek reddetme politikasında istisnalar yapabilirsiniz. namespaceSelector:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: database.postgres
  namespace: database
spec:
  podSelector:
    matchLabels:
      app: postgres
  ingress:
  - from:
    - namespaceSelector: # <<<
        matchLabels:
          namespace: default
  policyTypes:
  - Ingress

Sonuç olarak, ad alanındaki tüm bölmeler default bölmelere erişime sahip olacak postgres ad alanında database. Peki ya erişimi açmak istiyorsanız postgres ad alanında yalnızca belirli bölmeler default?

Ad alanlarına ve bölmelere göre filtreleyin

Kubernetes sürüm 1.11 ve üzeri, operatörleri birleştirmenize olanak tanır namespaceSelector и podSelector mantıksal AND kullanarak şuna benzer:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: database.postgres
  namespace: database
spec:
  podSelector:
    matchLabels:
      app: postgres
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          namespace: default
      podSelector: # <<<
        matchLabels:
          app: admin
  policyTypes:
  - Ingress

Bu neden her zamanki OR yerine AND olarak yorumlanıyor?

Lütfen dikkat: podSelector kısa çizgi ile başlamaz. YAML'de bu şu anlama gelir: podSelector ve onun önünde duruyorum namespaceSelector aynı liste öğesine bakın. Bu nedenle mantıksal VE ile birleştirilirler.

Önüne kısa çizgi ekleme podSelector öncekiyle birleştirilecek yeni bir liste öğesinin ortaya çıkmasına neden olacaktır namespaceSelector mantıksal VEYA kullanarak.

Belirli bir etikete sahip bölmeleri seçmek için tüm ad alanlarında, boş girin namespaceSelector:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: database.postgres
  namespace: database
spec:
  podSelector:
    matchLabels:
      app: postgres
  ingress:
  - from:
    - namespaceSelector: {}
      podSelector:
        matchLabels:
          app: admin
  policyTypes:
  - Ingress

Birden fazla etiket I ile iş birliği yapıyor

Birden fazla nesneye (ana bilgisayarlar, ağlar, gruplar) sahip bir güvenlik duvarına ilişkin kurallar, mantıksal VEYA kullanılarak birleştirilir. Paket kaynağı eşleşirse aşağıdaki kural çalışacaktır Host_1 VEYA Host_2:

| Source | Destination | Service | Action |
| ----------------------------------------|
| Host_1 | Subnet_A    | HTTPS   | Allow  |
| Host_2 |             |         |        |
| ----------------------------------------|

Aksine Kubernetes'teki çeşitli etiketler podSelector veya namespaceSelector mantıksal VE ile birleştirilir. Örneğin, aşağıdaki kural her iki etikete de sahip olan bölmeleri seçecektir; role=db И version=v2:

podSelector:
  matchLabels:
    role: db
    version: v2

Aynı mantık tüm operatör türleri için geçerlidir: politika hedefi seçicileri, bölme seçicileri ve ad alanı seçicileri.

Alt ağlar ve IP adresleri (IPBloklar)

Güvenlik duvarları bir ağı bölümlere ayırmak için VLAN'ları, IP adreslerini ve alt ağları kullanır.

Kubernetes'te IP adresleri bölmelere otomatik olarak atanır ve sık sık değişebilir; dolayısıyla ağ ilkelerinde bölmeleri ve ad alanlarını seçmek için etiketler kullanılır.

Alt ağlar (ipBlocks) gelen (giriş) veya giden (çıkış) harici (Kuzey-Güney) bağlantıları yönetirken kullanılır. Örneğin, bu politika ad alanındaki tüm bölmelere açılır default Google DNS hizmetine erişim:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: egress-dns
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 8.8.8.8/32
    ports:
    - protocol: UDP
      port: 53

Bu örnekteki boş bölme seçici, "ad alanındaki tüm bölmeleri seç" anlamına gelir.

Bu politika yalnızca 8.8.8.8'e erişime izin verir; başka herhangi bir IP'ye erişim yasaktır. Yani aslında dahili Kubernetes DNS hizmetine erişimi engellediniz. Eğer yine de açmak istiyorsanız bunu açıkça belirtin.

Genellikle ipBlocks и podSelectors bölmelerin dahili IP adresleri kullanılmadığından birbirini dışlar. ipBlocks. Belirterek dahili IP bölmeleri, aslında bu adreslerle bölmelere/bölmelerden bağlantılara izin vereceksiniz. Uygulamada hangi IP adresini kullanacağınızı bilemezsiniz; bu nedenle bölmeleri seçmek için kullanılmamaları gerekir.

Karşı örnek olarak aşağıdaki politika tüm IP'leri içerir ve bu nedenle diğer tüm bölmelere erişime izin verir:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: egress-any
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0

Pod'ların dahili IP adresleri hariç, yalnızca harici IP'lere erişimi açabilirsiniz. Örneğin, kapsülünüzün alt ağı 10.16.0.0/14 ise:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: egress-any
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0
        except:
        - 10.16.0.0/14

Bağlantı noktaları ve protokoller

Genellikle bölmeler bir bağlantı noktasını dinler. Bu, politikalarda bağlantı noktası numaralarını belirtemeyeceğiniz ve her şeyi varsayılan olarak bırakamayacağınız anlamına gelir. Ancak politikaları mümkün olduğunca kısıtlayıcı hale getirmeniz önerilir; böylece bazı durumlarda yine de bağlantı noktalarını belirtebilirsiniz:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres
  namespace: default
spec:
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: indexer
    - podSelector:
        matchLabels:
          app: admin
    ports:             # <<<
      - port: 443      # <<<
        protocol: TCP  # <<<
      - port: 80       # <<<
        protocol: TCP  # <<<
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
  - Ingress

Seçicinin ports bloktaki tüm öğeler için geçerlidir to veya from, içerir. Farklı öğe kümeleri için farklı bağlantı noktaları belirtmek amacıyla ingress veya egress ile birkaç alt bölüme to veya from ve her kayıtta portlarınız:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres
  namespace: default
spec:
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: indexer
    ports:             # <<<
     - port: 443       # <<<
       protocol: TCP   # <<<
  - from:
    - podSelector:
        matchLabels:
          app: admin
    ports:             # <<<
     - port: 80        # <<<
       protocol: TCP   # <<<
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
  - Ingress

Varsayılan bağlantı noktası işlemi:

• Bağlantı noktası tanımını tamamen atlarsanız (ports), bu, tüm protokoller ve tüm bağlantı noktaları anlamına gelir;
• Protokol tanımını atlarsanız (protocol), bu TCP anlamına gelir;
• Bağlantı noktası tanımını atlarsanız (port), bu tüm bağlantı noktaları anlamına gelir.

En iyi uygulama: Varsayılan değerlere güvenmeyin; neye ihtiyacınız olduğunu açıkça belirtin.

Lütfen servis bağlantı noktalarını değil, pod bağlantı noktalarını kullanmanız gerektiğini unutmayın (bununla ilgili daha fazla bilgi bir sonraki paragrafta).

Kapsüller veya hizmetler için politikalar tanımlanmış mı?

Genellikle Kubernetes'teki bölmeler birbirlerine bir hizmet (trafiki hizmeti uygulayan bölmelere yönlendiren sanal bir yük dengeleyici) aracılığıyla erişir. Ağ politikalarının hizmetlere erişimi kontrol ettiğini düşünebilirsiniz ancak durum böyle değil. Kubernetes ağ politikaları, hizmet bağlantı noktalarında değil, bölme bağlantı noktalarında çalışır.

Örneğin, bir hizmet 80 numaralı bağlantı noktasını dinliyorsa ancak trafiği bölmelerinin 8080 numaralı bağlantı noktasına yönlendiriyorsa, ağ politikasında tam olarak 8080'i belirtmeniz gerekir.

Böyle bir mekanizmanın idealin altında olduğu düşünülmelidir: Hizmetin iç yapısı (podların dinlediği bağlantı noktaları) değişirse, ağ politikalarının güncellenmesi gerekecektir.

Service Mesh'i kullanan yeni mimari yaklaşım (örneğin, aşağıdaki Istio hakkında bakın - yaklaşık çeviri.) bu sorunla başa çıkmanızı sağlar.

Hem Giriş hem de Çıkışın kaydedilmesi gerekli midir?

Kısa cevap evet, A bölmesinin B bölmesi ile iletişim kurabilmesi için, giden bir bağlantı oluşturmasına izin verilmesi gerekir (bunun için bir çıkış politikası yapılandırmanız gerekir) ve B bölmesinin gelen bağlantıyı kabul edebilmesi gerekir ( bunun için buna göre bir giriş politikasına ihtiyacınız var).

Ancak pratikte, bir veya her iki yöndeki bağlantılara izin vermek için varsayılan politikaya güvenebilirsiniz.

Eğer biraz kapsül-kaynak bir veya daha fazla kişi tarafından seçilecektir çıkış-Siyasetçiler, kendilerine getirilen kısıtlamaları onların ayrılıklarıyla belirleyecek. Bu durumda, bölmeye bağlantıya açıkça izin vermeniz gerekecektir.muhatap. Bir bölme herhangi bir politika tarafından seçilmezse, giden (çıkış) trafiğine varsayılan olarak izin verilir.

Benzer şekilde kapsülün kaderi deadres, bir veya daha fazla kişi tarafından seçilmiş giriş-siyasetçiler, ayrılıklarına göre belirlenecek. Bu durumda, kaynak bölmeden trafik almasına açıkça izin vermelisiniz. Herhangi bir politika tarafından bir kapsül seçilmezse, bunun için tüm giriş trafiğine varsayılan olarak izin verilir.

Aşağıdaki Durum Bilgili veya Durum Bilgisi Olmayan bölümüne bakın.

Kütükler

Kubernetes ağ politikaları trafiği günlüğe kaydedemez. Bu, bir politikanın amaçlandığı gibi çalışıp çalışmadığını belirlemeyi zorlaştırır ve güvenlik analizini büyük ölçüde karmaşıklaştırır.

Harici hizmetlere giden trafiğin kontrolü

Kubernetes ağ politikaları, çıkış bölümlerinde tam nitelikli bir alan adı (DNS) belirtmenize izin vermez. Bu gerçek, trafiği sabit bir IP adresine sahip olmayan harici hedeflerle (aws.com gibi) sınırlamaya çalışırken önemli sıkıntılara yol açmaktadır.

Politika Kontrolü

Güvenlik duvarları sizi uyaracak, hatta yanlış politikayı kabul etmeyi reddedecektir. Kubernetes ayrıca bazı doğrulamalar da yapıyor. Kubectl aracılığıyla bir ağ politikası belirlerken Kubernetes bunun yanlış olduğunu beyan edebilir ve kabul etmeyi reddedebilir. Diğer durumlarda Kubernetes politikayı alıp eksik ayrıntılarla dolduracaktır. Komutu kullanarak görülebilirler:

kubernetes get networkpolicy <policy-name> -o yaml

Kubernetes doğrulama sisteminin hatasız olmadığını ve bazı hata türlerini gözden kaçırabileceğini unutmayın.

Infaz

Kubernetes, ağ politikalarını kendisi uygulamaz; yalnızca kontrol yükünü Konteyner Ağ Arayüzü (CNI) adı verilen temel bir sisteme devreden bir API ağ geçididir. Uygun CNI'yı atamadan Kubernetes kümesinde politikalar ayarlamak, güvenlik duvarı yönetim sunucusunda politikalar oluşturup bunları güvenlik duvarlarına yüklemeden aynı şeydir. Uygun bir CNI'ye sahip olduğunuzdan veya Kubernetes platformları söz konusu olduğunda bulutta barındırıldığından emin olmak size kalmıştır. (sağlayıcıların listesini görebilirsiniz burada - yaklaşık. trans.), sizin için CNI'yi ayarlayacak ağ politikalarını etkinleştirin.

Uygun yardımcı CNI olmadan bir ağ politikası ayarlarsanız Kubernetes'in sizi uyarmayacağını unutmayın.

Devletli mi, Vatansız mı?

Karşılaştığım tüm Kubernetes CNI'leri durum bilgilidir (örneğin Calico, Linux bağlantısını kullanıyor). Bu, bölmenin, başlattığı TCP bağlantısını yeniden kurmaya gerek kalmadan yanıt almasına olanak tanır. Ancak durumsallığı garanti edecek bir Kubernetes standardının farkında değilim.

Gelişmiş Güvenlik Politikası Yönetimi

Kubernetes'te güvenlik politikasının uygulanmasını iyileştirmenin bazı yolları:

1. Service Mesh mimari modeli, hizmet düzeyinde ayrıntılı telemetri ve trafik kontrolü sağlamak için sepet konteynerlerini kullanır. Örnek olarak alabiliriz Istio.
2. CNI sağlayıcılarından bazıları araçlarını Kubernetes ağ politikalarının ötesine geçecek şekilde genişletti.
3. Tufin Orka Kubernetes ağ politikalarının görünürlüğünü ve otomasyonunu sağlar.

Tufin Orca paketi, Kubernetes ağ politikalarını yönetir (ve yukarıdaki ekran görüntülerinin kaynağıdır).

ek bilgi

• GKE'den Ahmet Alp Balkan'ın hazırladığı ağ politikası örnekleri;
• Resmi Kubernetes web sitesinden belgeler;
• Kubernetes Ağ Modeline Yönelik Kılavuz;
• Ağ politikalarını kontrol etmek için komut dosyası.

Sonuç

Kubernetes ağ politikaları, kümeleri bölümlere ayırmak için iyi bir araç seti sunar, ancak bunlar sezgisel değildir ve pek çok inceliğe sahiptir. Bu karmaşıklık nedeniyle mevcut küme politikalarının çoğunun hatalı olduğuna inanıyorum. Bu soruna olası çözümler arasında politika tanımlarının otomatikleştirilmesi veya diğer segmentasyon araçlarının kullanılması yer alır.

Bu kılavuzun bazı soruları yanıtlamanıza ve karşılaşabileceğiniz sorunları çözmenize yardımcı olacağını umuyorum.

çevirmenden PS

Blogumuzda da okuyun:

• "Istio ile mikro hizmetlere geri dön": 1. bölüm (ana özelliklere giriş), bölüm 2 (yönlendirme, trafik kontrolü), bölüm 3 (güvenlik);
• "Kubernetes'te Ağ Oluşturmaya Yönelik Resimli Bir Kılavuz": bölüm 1 ve 2 (ağ modeli, yer paylaşımlı ağlar), bölüm 3 (hizmetler ve trafik işleme);
• «Güvenlik açısından hassas ortamlarda Docker ve Kubernetes";
• «9 Kubernetes Güvenlik En İyi Uygulamaları";
• «Kubernetes Saldırısının Kurbanı Olmanın (Olmamanın) 11 Yolu'.

Kaynak: habr.com