Azure Kubernetes Service'te (AKS) pod güvenliği için en iyi yöntemler

Azure Kubernetes Service'te (AKS) uygulama geliştirirken ve çalıştırırken podlarınızın güvenliği önemli bir noktadır. Uygulamalarınız gereken en az sayıda ayrıcalık ilkesi için tasarlanmalıdır. Özel verilerin güvenliğini sağlamak, müşteriler için en önemli özelliktir. Veritabanı bağlantı dizesi, anahtarlar veya gizli diziler ve sertifikalar gibi kimlik bilgilerinin, bir saldırganın kötü amaçlı amaçlarla bu gizli dizilerden yararlanabileceği dış dünyaya açık olmasını istemezsiniz. Bunları kodunuza eklemeyin veya kapsayıcı görüntülerinize eklemeyin. Kapsayıcı görüntülerinin yeniden oluşturulması gerekeceğinden, bu yaklaşım açığa çıkarma riski oluşturur ve bu kimlik bilgilerini döndürme becerisini sınırlandırır.

Bu en iyi yöntemler makalesi AKS'de podların güvenliğini sağlama konusuna odaklanır. Şunları yapmayı öğreneceksiniz:

Küme güvenliği ve kapsayıcı görüntüsü yönetimi için en iyi yöntemleri de okuyabilirsiniz.

Kaynaklara pod erişiminin güvenliğini sağlama

En iyi yöntem kılavuzu - Farklı bir kullanıcı veya grup olarak çalışmak ve temel düğüm işlemlerine ve hizmetlerine erişimi sınırlamak için pod güvenlik bağlamı ayarlarını tanımlayın. Gereken en az sayıda ayrıcalık atayın.

Uygulamalarınızın doğru çalışması için podlar kök olarak değil, tanımlı bir kullanıcı veya grup olarak çalıştırılmalıdır. securityContext Bir pod veya kapsayıcı için, uygun izinleri varsaymak için runAsUser veya fsGroup gibi ayarları tanımlamanıza olanak tanır. Yalnızca gerekli kullanıcı veya grup izinlerini atayın ve ek izinleri varsaymak için güvenlik bağlamını bir araç olarak kullanmayın. runAsUser, ayrıcalık yükseltme ve diğer Linux özellikleri ayarları yalnızca Linux düğümlerinde ve podlarında kullanılabilir.

Kök olmayan bir kullanıcı olarak çalıştırdığınızda, kapsayıcılar 1024 altındaki ayrıcalıklı bağlantı noktalarına bağlanamaz. Bu senaryoda Kubernetes Services, bir uygulamanın belirli bir bağlantı noktasında çalıştığı gerçeğini gizlemek için kullanılabilir.

Pod güvenlik bağlamı, işlemlere ve hizmetlere erişmek için ek özellikler veya izinler de tanımlayabilir. Aşağıdaki yaygın güvenlik bağlamı tanımları ayarlanabilir:

• allowPrivilegeEscalation, pod'un kök ayrıcalıkları varsayabileceğini tanımlar. Bu ayarın her zaman false olarak ayarlanması için uygulamalarınızı tasarlar.
• Linux özellikleri pod'un temel düğüm işlemlerine erişmesine olanak sağlar. Bu özellikleri atamaya dikkat edin. Gereken en az sayıda ayrıcalık atayın. Daha fazla bilgi için bkz . Linux özellikleri.
• SELinux etiketleri hizmetler, işlemler ve dosya sistemi erişimi için erişim ilkeleri tanımlamanızı sağlayan bir Linux çekirdek güvenlik modülüdür. Yine, gereken en az sayıda ayrıcalık atayın. Daha fazla bilgi için bkz . Kubernetes'te SELinux seçenekleri

Aşağıdaki örnek pod YAML bildirimi, güvenlik bağlamı ayarlarını tanımlayacak şekilde ayarlar:

• Pod, kullanıcı kimliği 1000 ve grup kimliği 2000'in bir parçası olarak çalışır
• Ayrıcalıkları kullanmak için yükseltemiyorum root
• Linux özelliklerinin ağ arabirimlerine ve konağın gerçek zamanlı (donanım) saatine erişmesine izin verir

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    fsGroup: 2000
  containers:
    - name: security-context-demo
      image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
      securityContext:
        runAsUser: 1000
        allowPrivilegeEscalation: false
        capabilities:
          add: ["NET_ADMIN", "SYS_TIME"]

Hangi güvenlik bağlamı ayarlarına ihtiyacınız olduğunu belirlemek için küme operatörünüzle birlikte çalışın. Ek izinleri en aza indirmek ve pod'a erişmek için gereken uygulamalarınızı tasarlamayı deneyin. AppArmor ve seccomp (güvenli bilgi işlem) kullanarak erişimi sınırlamak için küme operatörleri tarafından uygulanabilecek ek güvenlik özellikleri vardır. Daha fazla bilgi için bkz . Kaynaklara kapsayıcı erişiminin güvenliğini sağlama.

Kimlik bilgisi kullanımını sınırla

En iyi yöntem kılavuzu - Uygulama kodunuzda kimlik bilgilerini tanımlamayın. Podunuzun diğer kaynaklara erişim istemesine izin vermek için Azure kaynakları için yönetilen kimlikleri kullanın. Dijital anahtarları ve kimlik bilgilerini depolamak ve almak için Azure Key Vault gibi bir dijital kasa da kullanılmalıdır. Pod ile yönetilen kimlikler yalnızca Linux podları ve kapsayıcı görüntüleriyle kullanılmak üzere tasarlanmıştır.

Uygulama kodunuzda kimlik bilgilerinin kullanıma sunulma riskini sınırlamak için, sabit veya paylaşılan kimlik bilgilerinin kullanımından kaçının. Kimlik bilgileri veya anahtarlar doğrudan kodunuz içinde yer almamalıdır. Bu kimlik bilgileri kullanıma sunulursa uygulamanın güncelleştirilmesi ve yeniden dağıtılması gerekir. Podlara kendi kimliklerini ve kimliklerini doğrulamanın veya dijital kasadan kimlik bilgilerini otomatik olarak almalarını sağlamak daha iyi bir yaklaşımdır.

Microsoft Entra İş Yükü Kimliği kullanma

İş yükü kimliği, pod üzerinde çalışan ve kendisini destekleyen Depolama veya SQL gibi diğer Azure hizmetlerinde kimlik doğrulaması yapabilen bir uygulama tarafından kullanılan bir kimliktir. Dış kimlik sağlayıcılarıyla federasyon sağlamak için Kubernetes'e özgü özelliklerle tümleşir. Bu güvenlik modelinde AKS kümesi belirteç veren olarak görev yapar; Microsoft Entra ID, genel imzalama anahtarlarını bulmak ve bir Microsoft Entra belirteci için takas etmeden önce hizmet hesabı belirtecinin orijinalliğini doğrulamak için OpenID Connect kullanır. İş yükünüz, Azure SDK'sını veya Microsoft Kimlik Doğrulama Kitaplığı'nı (MSAL) kullanarak Azure Identity istemci kitaplığını kullanarak bir Microsoft Entra belirteci için birimine yansıtılan bir hizmet hesabı belirtecini değiştirebilir.

İş yükü kimlikleri hakkında daha fazla bilgi için bkz. Aks kümesini uygulamalarınızla Microsoft Entra İş Yükü Kimliği kullanacak şekilde yapılandırma

Gizli Dizi Deposu CSI Sürücüsü ile Azure Key Vault kullanma

Microsoft Entra İş Yükü Kimliği kullanılması, Azure hizmetlerini desteklemeye karşı kimlik doğrulamasını etkinleştirir. Azure kaynakları için yönetilen kimlikleri olmayan kendi hizmetleriniz veya uygulamalarınız için kimlik bilgilerini veya anahtarları kullanarak kimlik doğrulaması yapabilirsiniz. Bu gizli dizi içeriklerini depolamak için dijital kasa kullanılabilir.

Uygulamalar kimlik bilgilerine ihtiyaç duyduğunda dijital kasayla iletişim kurar, en son gizli dizi içeriğini alır ve gerekli hizmete bağlanır. Azure Key Vault bu dijital kasa olabilir. Pod ile yönetilen kimlikleri kullanarak Azure Key Vault'tan kimlik bilgilerini almaya yönelik basitleştirilmiş iş akışı aşağıdaki diyagramda gösterilmiştir:

Key Vault ile kimlik bilgileri, depolama hesabı anahtarları veya sertifikalar gibi gizli dizileri depolar ve düzenli olarak döndürürsiniz. Gizli Dizi Deposu CSI Sürücüsü için Azure Key Vault sağlayıcısını kullanarak Azure Key Vault'un aks kümesiyle tümleştirilmesini sağlayabilirsiniz. Gizli Dizi Deposu CSI sürücüsü, AKS kümesinin Key Vault'tan gizli dizi içeriğini yerel olarak almasını ve bunları yalnızca istekte bulunan poda güvenli bir şekilde sağlamasını sağlar. Gizli Dizi Deposu CSI Sürücüsünü AKS çalışan düğümlerine dağıtmak için küme operatörünüzle birlikte çalışın. Key Vault'a erişim istemek ve Gizli Dizi Deposu CSI Sürücüsü aracılığıyla gerekli gizli dizi içeriğini almak için bir Microsoft Entra İş Yükü Kimliği kullanabilirsiniz.

Sonraki adımlar

Bu makale, podlarınızın güvenliğini sağlama konusuna odaklanmıştır. Bu alanlardan bazılarını uygulamak için aşağıdaki makalelere bakın:

• AKS ile Azure kaynakları için Microsoft Entra İş Yükü Kimliği kullanma
• Azure Key Vault'la AKS'yi tümleştirme