Azure Kubernetes Service (AKS) içinde ağ ilkelerini kullanarak podlar arasındaki trafiğin güvenliğini sağlama

Kubernetes'te modern, mikro hizmet tabanlı uygulamalar çalıştırarak genellikle birbirleriyle iletişim kuracak bileşenleri denetlemeyi istersiniz. En az ayrıcalık ilkesi, trafiğin bir Azure Kubernetes Service (AKS) kümesinde podlar arasında akışına uygulanmalıdır. Büyük olasılıkla doğrudan arka uç uygulamalarına trafiği engellemek istediğinizi diyelim. Kubernetes'in Ağ İlkesi özelliği, kümede podlar arasında giriş ve çıkış trafiği için kurallar tanımlamaya olanak sağlar.

Bu makalede AKS'de podlar arasındaki trafik akışını kontrol etmek için ağ ilkesi altyapısını yükleme ve Kubernetes ağ ilkeleri oluşturma açıklanmıştır. Ağ ilkesi yalnızca AKS'de Linux tabanlı düğümler ve podlar için kullanılmalıdır.

Başlamadan önce

Azure CLI 2.0.61 veya sonraki bir sürümün yüklü ve yapılandırılmış olması gerekir. Sürümü bulmak için az --version komutunu çalıştırın. Yüklemeniz veya yükseltmeniz gerekirse, bkz. Azure CLI yükleme.

Ağ ilkesine genel bakış

AKS kümesinde yer alan tüm podlar varsayılan olarak sınırlama olmadan trafik gönderebilir ve alır. Güvenliği artırmak için trafik akışını kontrol altına alan kurallar tanımlayabilirsiniz. Arka uç uygulamaları genellikle yalnızca gerekli ön uç hizmetleri için kullanılır, örneğin. Veya veritabanı bileşenlerine yalnızca onlara bağlanan uygulama katmanları tarafından erişilebilir.

Ağ İlkesi, Podlar arasındaki iletişim için erişim ilkelerini tanımlayan bir Kubernetes belirtimidir. Ağ İlkelerini kullanarak, trafik gönderecek ve alacak ve bunları bir veya daha fazla etiket seçicisi ile eşan bir pod koleksiyonuna uygulayacak bir dizi kural tanımlarsınız.

Bu ağ ilkesi kuralları YAML bildirimleri olarak tanımlanır. Ağ ilkeleri, aynı zamanda bir dağıtım veya hizmet oluşturan daha geniş bir bildirimin parçası olarak dahil olabilir.

AKS'de ağ ilkesi seçenekleri

Azure, ağ ilkesi uygulamak için iki yol sağlar. AKS kümesi oluşturmada bir ağ ilkesi seçeneği seçersiniz. İlke seçeneği, küme oluşturulduktan sonra değiştirilemez:

• Azure'ın Azure Ağ İlkeleri olarak adlandırılan kendi uygulaması.
• Lifea tarafından kurulan açık kaynak bir ağ ve ağ güvenlik çözümü olan Buco Ağ İlkeleri.

Her iki uygulama da belirtilen ilkeleri zorlamak için Linux IPTable'ları kullanır. İlkeler izin verilen ve izin verilmeyen IP çiftleri kümesine çevrilir. Bu çiftler daha sonra IPTable filtre kuralları olarak programlanır.

Azure veLifeco ilkeleri arasındaki farklar ve bunların özellikleri

AKS kümesi oluşturma ve ağ ilkesi etkinleştirme

Ağ ilkelerinin nasıl olduğunu görmek için trafik akışını tanımlayan bir ilke oluşturacağız ve genişleteceğiz:

• Poda gelen tüm trafiği reddedin.
• Pod etiketlerine göre trafiğe izin ver.
• Ad alanına göre trafiğe izin ver.

İlk olarak, ağ ilkesi destekleyen bir AKS kümesi oluştur o zaman.

Azure Ağ İlkesi'ne sahip olmak için, Azure CNI eklentisini kullanmalı ve kendi sanal ağ ve alt ağlarınızı tanımlamelisiniz. Gerekli alt ağ aralıklarını planlama hakkında daha ayrıntılı bilgi için bkz. Gelişmiş ağ yapılandırma. Bu aynı eklentiyle veya Kubenet CNI eklentisiyle Azure CNI Olarak Daleco Ağ İlkesi kullanılabilir.

Aşağıdaki örnek betik:

• Bir sanal ağ ve alt ağ oluşturur.
• AKS kümesi Azure Active Directory için bir hizmet sorumlusu (Azure AD) oluşturur.
• Sanal ağ üzerinde AKS kümesi hizmet sorumlusu için Katkıda Bulunan izinleri atar.
• Tanımlı sanal ağ içinde bir AKS kümesi oluşturur ve ağ ilkesi etkinleştirir.
  • Azure Ağ ilkesi seçeneği kullanılır. Bunun yerine ağ ilkesi seçeneği olarakLifeco'yu kullanmak için parametresini --network-policy calico kullanın. Not: Veya ile Bazıco --network-plugin azure --network-plugin kubenet kullanılabilir.

Hizmet sorumlusu kullanmak yerine izinler için yönetilen kimlik kullanabileceğiniz unutmayın. Daha fazla bilgi için bkz. Yönetilen kimlikleri kullanma.

Kendi güvenli SP_PASSWORD. Aşağıdaki değişkenleri RESOURCE_GROUP_NAME ve CLUSTER_NAME değiştirebilirsiniz:

RESOURCE_GROUP_NAME=myResourceGroup-NP
CLUSTER_NAME=myAKSCluster
LOCATION=canadaeast

# Create a resource group
az group create --name $RESOURCE_GROUP_NAME --location $LOCATION

# Create a virtual network and subnet
az network vnet create \
    --resource-group $RESOURCE_GROUP_NAME \
    --name myVnet \
    --address-prefixes 10.0.0.0/8 \
    --subnet-name myAKSSubnet \
    --subnet-prefix 10.240.0.0/16

# Create a service principal and read in the application ID
SP=$(az ad sp create-for-rbac --role Contributor --output json)
SP_ID=$(echo $SP | jq -r .appId)
SP_PASSWORD=$(echo $SP | jq -r .password)

# Wait 15 seconds to make sure that service principal has propagated
echo "Waiting for service principal to propagate..."
sleep 15

# Get the virtual network resource ID
VNET_ID=$(az network vnet show --resource-group $RESOURCE_GROUP_NAME --name myVnet --query id -o tsv)

# Assign the service principal Contributor permissions to the virtual network resource
az role assignment create --assignee $SP_ID --scope $VNET_ID --role Contributor

# Get the virtual network subnet resource ID
SUBNET_ID=$(az network vnet subnet show --resource-group $RESOURCE_GROUP_NAME --vnet-name myVnet --name myAKSSubnet --query id -o tsv)

Azure ağ ilkeleri için AKS kümesi oluşturma

AKS kümesi oluşturun ve ağ eklentisi ve ağ ilkesi için sanal ağı, hizmet sorumlusu bilgilerini ve Azure'u belirtin.

az aks create \
    --resource-group $RESOURCE_GROUP_NAME \
    --name $CLUSTER_NAME \
    --node-count 1 \
    --generate-ssh-keys \
    --service-cidr 10.0.0.0/16 \
    --dns-service-ip 10.0.0.10 \
    --docker-bridge-address 172.17.0.1/16 \
    --vnet-subnet-id $SUBNET_ID \
    --service-principal $SP_ID \
    --client-secret $SP_PASSWORD \
    --network-plugin azure \
    --network-policy azure

Kümenin oluşturulması birkaç dakika sürer. Küme hazır olduğunda az kubectl aks get-credentials komutunu kullanarak Kubernetes kümenize bağlanın. Bu komut kimlik bilgilerini indirir ve Kubernetes CLI'yi bunları kullanmak üzere yapılandırıyor:

az aks get-credentials --resource-group $RESOURCE_GROUP_NAME --name $CLUSTER_NAME

Grupco ağ ilkeleri için AKS kümesi oluşturma

AKS kümesi oluşturun ve sanal ağı, hizmet sorumlusu bilgilerini, ağ eklentisi için azure'ı ve ağ ilkesi içinco'yu belirtin. Ağ ilkesi olarak networkco'yu kullanmak hem Linux hem de düğüm havuzlarında Windows sağlar.

Kümenize bir düğüm Windows eklemeyi planlıyorsanız, sunucu parolası gereksinimlerini Windows windows-admin-username windows-admin-password ve parametrelerini dahil edin. Düğüm havuzlarını kullanarak Windows Için, ayrıca kaydını da kaydetmeniz Microsoft.ContainerService/EnableAKSWindowsCalico gerekir.

Aşağıdaki EnableAKSWindowsCalico örnekte gösterildiği gibi az feature register komutunu kullanarak özellik bayrağını kaydetme:

az feature register --namespace "Microsoft.ContainerService" --name "EnableAKSWindowsCalico"

az feature list komutunu kullanarak kayıt durumunu kontrol edin:

az feature list -o table --query "[?contains(name, 'Microsoft.ContainerService/EnableAKSWindowsCalico')].{Name:name,State:properties.state}"

Hazır olduğunda az provider register komutunu kullanarak Microsoft.ContainerService kaynak sağlayıcısının kaydını yenileyin:

az provider register --namespace Microsoft.ContainerService

Windows düğümlerine sahip Olan Güncelco ağ ilkeleri şu anda önizlemededir.

Kümeniz üzerinde Windows Server kapsayıcıları için yönetici kimlik bilgileri olarak kullanmak üzere bir kullanıcı adı oluşturun. Aşağıdaki komutlar sizden bir kullanıcı adı WINDOWS_USERNAME sonraki bir komutta kullanmak üzere bir kullanıcı adı ayarlayın (bu makaledeki komutların bir BASH kabuğuna girilir).

echo "Please enter the username to use as administrator credentials for Windows Server containers on your cluster: " && read WINDOWS_USERNAME

az aks create \
    --resource-group $RESOURCE_GROUP_NAME \
    --name $CLUSTER_NAME \
    --node-count 1 \
    --generate-ssh-keys \
    --service-cidr 10.0.0.0/16 \
    --dns-service-ip 10.0.0.10 \
    --docker-bridge-address 172.17.0.1/16 \
    --vnet-subnet-id $SUBNET_ID \
    --service-principal $SP_ID \
    --client-secret $SP_PASSWORD \
    --windows-admin-username $WINDOWS_USERNAME \
    --vm-set-type VirtualMachineScaleSets \
    --kubernetes-version 1.20.2 \
    --network-plugin azure \
    --network-policy calico

Kümenin oluşturulması birkaç dakika sürer. Varsayılan olarak, kümeniz yalnızca bir Linux düğüm havuzuyla oluşturulur. Düğüm havuzlarını kullanmak Windows, bir tane eklersiniz. Örnek:

az aks nodepool add \
    --resource-group $RESOURCE_GROUP_NAME \
    --cluster-name $CLUSTER_NAME \
    --os-type Windows \
    --name npwin \
    --node-count 1

Küme hazır olduğunda az kubectl aks get-credentials komutunu kullanarak Kubernetes kümenize bağlanın. Bu komut kimlik bilgilerini indirir ve Kubernetes CLI'yi bunları kullanmak üzere yapılandırıyor:

az aks get-credentials --resource-group $RESOURCE_GROUP_NAME --name $CLUSTER_NAME

Poda gelen tüm trafiği reddet

Belirli ağ trafiğine izin verecek kuralları tanımlamadan önce tüm trafiği reddedecek bir ağ ilkesi oluşturun. Bu ilke, yalnızca istenen trafik için bir izin verme listesi oluşturmak üzere başlangıç noktası sağlar. Ağ ilkesi uygulandığında trafiğin bırakıldığına da açıkça bakabilirsiniz.

Örnek uygulama ortamı ve trafik kuralları için önce örnek podları çalıştırmak üzere geliştirme adlı bir ad alanı oluşturacağız:

kubectl create namespace development
kubectl label namespace/development purpose=development

NGINX'i çalıştıran örnek bir arka uç podu oluşturun. Bu arka uç podu, örnek bir arka uç web tabanlı uygulamanın benzetimini yapmak için kullanılabilir. Geliştirme ad alanına bu podu oluşturun ve web trafiğine hizmet vermek için 80 bağlantı noktasını açın. Sonraki bölümde bir ağ ilkesiyle hedeflemek için poda app=webapp,role=backend etiketini kullanın:

kubectl run backend --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --labels app=webapp,role=backend --namespace development --expose --port 80

Başka bir pod oluşturun ve varsayılan NGINX web sayfasına başarıyla ulaşabilirsiniz. Test etmek için bir terminal oturumu oluşturun:

kubectl run --rm -it --image=mcr.microsoft.com/aks/fundamental/base-ubuntu:v0.0.11 network-policy --namespace development

Kabuk isteminde kullanarak varsayılan wget NGINX web sayfasına erişebilirsiniz:

wget -qO- http://backend

Aşağıdaki örnek çıktı, varsayılan NGINX web sayfasının döndürüldü olduğunu gösterir:

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
[...]

Ekli terminal oturumundan çıkın. Test pod'u otomatik olarak silinir.

exit

Ağ ilkesi oluşturma ve uygulama

Örnek arka uç pod'larında temel NGINX web sayfasını kullanabileceğiniz onaylandıktan sonra tüm trafiği reddeden bir ağ ilkesi oluşturun. adlı bir dosya oluşturun backend-policy.yaml ve aşağıdaki YAML bildirimini yapıştırın. Bu bildirim, ilkeyi app:webapp,role:backend etiketine sahip olan podlara eklemek için örnek NGINX pod'uz gibi bir podSelector kullanır. Giriş altında hiçbir kural tanımlanmamıştır, bu nedenle poda gelen tüm trafik reddedilir:

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: backend-policy
  namespace: development
spec:
  podSelector:
    matchLabels:
      app: webapp
      role: backend
  ingress: []

Tarayıcınızda https://shell.azure.com Azure Cloud Shell açın.

kubectl apply komutunu kullanarak ağ ilkesi uygulama ve YAML bildiriminizin adını belirtin:

kubectl apply -f backend-policy.yaml

Ağ ilkesi test

Arka uç podda NGINX web sayfasını yeniden kullanabileceğiniz bir bakalım. Başka bir test pod'u oluşturun ve terminal oturumu oluşturun:

kubectl run --rm -it --image=mcr.microsoft.com/aks/fundamental/base-ubuntu:v0.0.11 network-policy --namespace development

Kabuk isteminde, varsayılan wget NGINX web sayfasına erişenin olup olamay olduğunu görmek için kullanın. Bu kez, zaman aşımı değerini 2 saniye olarak ayarlayın. Ağ ilkesi artık tüm gelen trafiği engeller, bu nedenle aşağıdaki örnekte gösterildiği gibi sayfa yüklenemiyor:

wget -O- --timeout=2 --tries=1 http://backend

wget: download timed out

Ekli terminal oturumundan çıkın. Test pod'u otomatik olarak silinir.

exit

Pod etiketine göre gelen trafiğe izin verme

Önceki bölümde bir arka uç NGINX podu zamanlandı ve tüm trafiği reddetmek için bir ağ ilkesi oluşturuldu. Ön uç podunu oluşturacağız ve ağ ilkesini ön uç podlarından gelen trafiğe izin verecek şekilde güncelleştirin.

App:webapp,role:frontend etiketlerini kullanarak podlardan gelen trafiğe izin vermek için ağ ilkesi güncelleştirin. Önceki backend-policy.yaml dosyasını düzenleyin ve bildiriminizin aşağıdaki örnekte olduğu gibi görünüyor olacak şekilde matchLabels giriş kuralları ekleyin:

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: backend-policy
  namespace: development
spec:
  podSelector:
    matchLabels:
      app: webapp
      role: backend
  ingress:
  - from:
    - namespaceSelector: {}
      podSelector:
        matchLabels:
          app: webapp
          role: frontend

Kubectl apply komutunu kullanarak güncelleştirilmiş ağ ilkesi uygulama ve YAML bildiriminizin adını belirtin:

kubectl apply -f backend-policy.yaml

app=webapp,role=frontend olarak etiketlenmiş bir pod zamanlaması ve terminal oturumu ekleme:

kubectl run --rm -it frontend --image=mcr.microsoft.com/aks/fundamental/base-ubuntu:v0.0.11 --labels app=webapp,role=frontend --namespace development

Kabuk isteminde kullanarak varsayılan wget NGINX web sayfasına erişebilirsiniz:

wget -qO- http://backend

Giriş kuralı şu etiket uygulamasına sahip podlarla trafiğe izin verir: webapp,rol: ön uç, ön uç poddan gelen trafiğe izin verilir. Aşağıdaki örnek çıktı, döndürülen varsayılan NGINX web sayfasını gösterir:

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
[...]

Ekli terminal oturumundan çıkın. Pod otomatik olarak silinir.

exit

Eşleşen etiket olmadan podu test etmek

Ağ ilkesi uygulama: webapp,rol: ön uç etiketli podlardan gelen trafiğe izin verir, ancak diğer tüm trafiği reddeder. Bu etiketlere sahip olmayan başka bir pod'un arka uç NGINX pod'a erişip erişe olmadığını test edin. Başka bir test pod'u oluşturun ve terminal oturumu oluşturun:

kubectl run --rm -it --image=mcr.microsoft.com/aks/fundamental/base-ubuntu:v0.0.11 network-policy --namespace development

Kabuk isteminde, varsayılan wget NGINX web sayfasına erişenin olup olamay olduğunu görmek için kullanın. Ağ ilkesi gelen trafiği engeller, bu nedenle aşağıdaki örnekte gösterildiği gibi sayfa yüklenemiyor:

wget -O- --timeout=2 --tries=1 http://backend

wget: download timed out

Ekli terminal oturumundan çıkın. Test pod'u otomatik olarak silinir.

exit

Yalnızca tanımlı bir ad alanının içindeki trafiğe izin ver

Önceki örneklerde, tüm trafiği reddeden bir ağ ilkesi oluşturduktan sonra ilkeyi belirli bir etikete sahip podlardan gelen trafiğe izin verecek şekilde güncelleştirildi. Bir diğer yaygın ihtiyaç ise trafiği yalnızca belirli bir ad alanı içinde sınırlamaktır. Önceki örnekler bir geliştirme ad alanı trafiği içinse, üretim gibi başka bir ad alanlarından gelen trafiğin podlara ulaşmasını engelleyen bir ağ ilkesi oluşturun.

İlk olarak, üretim ad alanının benzetimini yapmak için yeni bir ad alanı oluşturun:

kubectl create namespace production
kubectl label namespace/production purpose=production

üretim ad alanının app=webapp,role=frontend olarak etiketlenmiş bir test podunu zamanlaması. Terminal oturumu ekleme:

kubectl run --rm -it frontend --image=mcr.microsoft.com/aks/fundamental/base-ubuntu:v0.0.11 --labels app=webapp,role=frontend --namespace production

Kabuk isteminde kullanarak varsayılan wget NGINX web sayfasına erişebilirsiniz:

wget -qO- http://backend.development

Pod etiketleri ağ ilkesinde şu anda izin verilen etiketlerle eş olduğundan trafiğe izin verilir. Ağ ilkesi ad alanlarına değil yalnızca pod etiketlerine bakar. Aşağıdaki örnek çıktı, döndürülen varsayılan NGINX web sayfasını gösterir:

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
[...]

Ekli terminal oturumundan çıkın. Test pod'u otomatik olarak silinir.

exit

Ağ ilkesi güncelleştirme

Şimdi namespaceSelector giriş kuralını yalnızca geliştirme ad alanı içinde gelen trafiğe izin verecek şekilde güncelleştirin. Backend-policy.yaml bildirim dosyasını aşağıdaki örnekte gösterildiği gibi düzenleyin:

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: backend-policy
  namespace: development
spec:
  podSelector:
    matchLabels:
      app: webapp
      role: backend
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          purpose: development
      podSelector:
        matchLabels:
          app: webapp
          role: frontend

Daha karmaşık örneklerde namespaceSelector ve ardından podSelector gibi birden çok giriş kuralı tanımlayabilirsiniz.

Kubectl apply komutunu kullanarak güncelleştirilmiş ağ ilkesi uygulama ve YAML bildiriminizin adını belirtin:

kubectl apply -f backend-policy.yaml

Güncelleştirilmiş ağ ilkesi test

Üretim ad alanına başka bir pod zamanlama ve terminal oturumu ekleme:

kubectl run --rm -it frontend --image=mcr.microsoft.com/aks/fundamental/base-ubuntu:v0.0.11 --labels app=webapp,role=frontend --namespace production

Kabuk isteminde, ağ wget ilkesinde artık trafiğin geri doğru olduğunu görmek için kullanın:

wget -O- --timeout=2 --tries=1 http://backend.development

wget: download timed out

Test pod'unu çıkın:

exit

Üretim ad alanının trafiği reddedilirken, geliştirme ad alanına geri bir test pod'u zamanlaması ve bir terminal oturumu eklemesi gerekir:

kubectl run --rm -it frontend --image=mcr.microsoft.com/aks/fundamental/base-ubuntu:v0.0.11 --labels app=webapp,role=frontend --namespace development

Kabuk isteminde, ağ wget ilkesinde trafiğe izin verili olduğunu görmek için kullanın:

wget -qO- http://backend

Pod, ağ ilkesinde izin verilenle eşleşen ad alanı içinde zamanlandığı için trafiğe izin verilir. Aşağıdaki örnek çıktı, döndürülen varsayılan NGINX web sayfasını gösterir:

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
[...]

Ekli terminal oturumundan çıkın. Test pod'u otomatik olarak silinir.

exit

Kaynakları temizleme

Bu makalede iki ad alanı oluşturduk ve bir ağ ilkesi uyguladık. Bu kaynakları temizlemek için kubectl delete komutunu kullanın ve kaynak adlarını belirtin:

kubectl delete namespace production
kubectl delete namespace development

Sonraki adımlar

Ağ kaynakları hakkında daha fazla bilgi için bkz. Ağ (AKS) Azure Kubernetes Service uygulamaları için ağ kavramları.

İlkeler hakkında daha fazla bilgi edinmek için bkz. Kubernetes ağ ilkeleri.