Azure Kubernetes Service’de (AKS) Sertifika Rotasyonu

Ercan KURT


Azure Kubernetes Service (AKS), birçok bileşeniyle birlikte kimlik doğrulama için sertifikalar kullanır. Mart 2022’den sonra oluşturulan RBAC özellikli kümeler, sertifika otomatik rotasyonuyla birlikte etkinleştirilir. Güvenlik veya politika nedenleriyle bu sertifikaları düzenli aralıklarla rotasyona tabi tutmanız gerekebilir. Örneğin, tüm sertifikalarınızı 90 günde bir rotasyona tabi tutacak bir güvenlik politikanız olabilir. (Eğer mart 2022 den önce oluşturduğunuz AKS var ise buna RBAC ekleyip açmanız gerekiyor k8s ortamınıza göre dikkatli bi şekilde kendinize göre ayarlamalisiniz)

Sertefika rotasyon işlemine başlamadan önce Azure CLI sürüm 2.0.77 yada üstü kullanacağiz yüklü olduğunu varsayiyorum değil ise https://learn.microsoft.com/en-us/cli/azure/install-azure-cli hizlica yükleyebilirsiniz.

AKS sertifikaları, Sertifika Yetkilileri ve Hizmet Hesapları

AKS aşağıdaki sertifikaları, Certificate Authoritie leri (CA) ve Service Account ları (SA) oluşturur ve kullanır:

Microsoft, Cluster sertifikası dışında bu bölümde bahsedilen tüm sertifikaların bakımını ve yenilemesini yapabilir.

Burada Dikkat etmemiz gereken bir güncelleme var yeni eski AKS ortamlari için
Mayıs 2019’dan önce oluşturulan AKS kümeleri, süresi iki yıl sonra dolacak şekilde sertifikalara sahiptir.
Mayıs 2019’dan sonra oluşturulan AKS kümeleri, süresi 30 yıl sonra dolacak şekilde Cluster
CA sertifikalarına sahiptir.
Peki bu AKS clusterlerimizin sertefikalarının ne kadar günü kaldi tarihi nedir nasil öğreneceğiz ?

Azure CLI ile AKS Sunucumuza bağlanıyoruz

#Bu kod AKS Node larının yaşını gösterir burdan hizlica tahmin edebiliriz.
kubectl get nodes

NAME STATUS   ROLES    AGE  VERSION
node1 Ready < MASTER > 457d v1.27.2
node2 Ready < WORKERs> 487d v1.27.2
node3 Ready < WORKERs> 303d v1.27.2

#Gördüğünüz gibi age 457 ve 303 gün olarak yaşadiği günleri görüyoruz

Aşaği yukari 457 günden hesap edersek 1yil 92 gün ediyor sertefika ömrü daha çok var gibi ama sayili gün çabuk geçer

Diyelim ki biz sertefikayi manuel yada başka bi sağlayicidan alip yüklemiş yada kendi üretiğimiz sertefikayi kullaniyoruz diyelim ve ne zaman yaptik hatirlamiyoruz ne yapacağiz ?

# AKS Clusterimizin ayarlarını göreceğimiz komut
kubectl config view.

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: <certificate-authority-data>
    server: <cozumparktech.mobil>
  name: MobileApp-cozumpark
contexts:
- context:
    cluster: MobileApp-cozumpark
    user: clusterUser_ercan
  name: MobileApp-cozumpark
current-context: MobileApp-cozumpark-aks-context
kind: Config
preferences: {}
users:
- name: clusterUser_ercan -MobileApp-cozumpark
  user:
    client-certificate-data: <client-certificate-data>
    client-key-data: <client-key-data>

Bu komut ile AKS clusterlerinizin ayar dosyasini okuyabilir ordan sertefika detaylarına bakabiliriz ama her zaman burdan net bilgi alamayabiliriz AKS yapisi ve görevleri farkli şekilde ayarlamış olabiliriz default devam ediyorsak extra bişey yapmadıysak yazar

Peki yazmadı yada çok fazla uygulama cluster vs uygulamamiz var config dosyamız oldukça kabarık ve bir sürü sertefikamız var hepsini tek tek nasil bulcağim dediğinizi duyar gibiyim endişelenmeyin bunda tek bir komut ile klasik linux ve K8s deki gibi listeleyeceğiz

#Bu komut ile cluster sertefikalarını toplu bi şekilde listeliyoruz ilgili alanlara kendi cluster adınızı resource name,user bilgilerinizi doğru şekilde yazmanız gerekiyor

kubectl config view --raw -o jsonpath="{.users[?(@.name == 'clusterUser_rg_myAKSCluster')].user.client-certificate-data}" | base64 -d | openssl x509 -text | grep -A2 Validity

Komutu sizin için açiklayayim standart linux kodları aslında bazı şeyler AKS ye özgü olabiliyor ama bunda öyle bir komut setine rastamiyorum

kubectl config view --raw: Bu bölüm, Kubernetes yapılandırma dosyanızı (kubeconfig) görüntülemek için kullanılır. --raw bayrağı, yapılandırmanın düz metin çıktısını almanızı sağlar. Diğer bir deyişle, yapılandırma dosyasının işlenmemiş halini döndürür.
-o jsonpath="{.users[?(@.name == 'clusterUser_rg_myAKSCluster')].user.client-certificate-data}": Bu bölüm, kubectl config view çıktısındaki JSON verisini işlemek için jsonpath kullanır. Bu komut, belirli bir kullanıcının sertifika verisini seçer.
Özellikle, clusterUser_rg_myAKSCluster adlı kullanıcının user.client-certificate-data alanını alır.
Ara komut etiketleride bu şekilde bildiğimiz linux

  1. | base64 -d: Bu bölüm, elde edilen sertifika verisini base64 kodlamadan çözmek için kullanılır. Sertifika verisi base64 kodlanmıştır ve bu komut bu veriyi çözerek orijinal sertifika verisini elde eder.
  2. | openssl x509 -text: Bu komut, sertifika verisini OpenSSL kullanarak okur ve sertifika hakkında ayrıntılı bilgileri görüntüler.
  3. | grep -A2 Validity: Son olarak, bu komut, sertifikanın geçerlilik bilgilerini çıktıda bulur. grep komutu, “Validity” kelimesini arar ve bu kelimenin bulunduğu satırı ve bir sonraki 2 satırı (-A2) görüntüler. Bu, sertifika geçerlilik dönemini gösteren bilgileri almanıza yardımcı olur.

Böylece tüm cluster sertefikalarını tarih bilgileri ile birlikte listeledik.

API sertefikası için tarih detayı için curl ile hizlica bakabiliriz API hizmeti olduğu için cluster içinde cevap dönecektir yada dişaryi ya açiksa dişardanda cevap dönebilir.

curl https://{apiserver-fqdn} -k -v 2>&1 |grep expire

Daha bitmedi birde VMAS (Virtual Machine Agent and Extensions) sertefikamız var peki bu nedir ?
Azure Kubernetes Service (AKS) kullanırken, VMAS (Virtual Machine Agent and Extensions) ajanı, AKS düğümlerine ilişkin işlevleri etkinleştirmek ve yönetmek için kullanılan bir Azure hizmetidir. VMAS agenti, AKS clusterlerinde Azure Portal, Azure CLI veya diğer Azure yönetim araçları aracılığıyla erişmeye ve yönetmeye yardımcı olur büyük nimettir hep unutulur bu agentin sertefikasinida aşağidaki komut ile görebiliriz

#Azure Cloud Shell imizde çaliştiriyoruz
 (ilgili alanları kendi yapımıza göre yazip)

az vm run-command invoke -g MC_rg_myAKSCluster_region -n vm-name --command-id RunShellScript --query 'value[0].message' -otsv --scripts "openssl x509 -in /etc/kubernetes/certs/apiserver.crt -noout -enddate"

Tam bitti oh derken AKS autoscale kullandiğimiz aklimiza geldi (kullanmiyorda olabilirsiniz) bununda sertefikasi var bazen gerçekten zor olabiliyor en baştada belirtiğim gibi AKS yapımızda ne nasil ne kadar hangi servis gibi topoloji önemli buna göre nerde hangi hizmet sertefika servis ve cost (ücret) gibi cevapları verebilmeliyiz

#AutoScale Sertefika bilgileri 
(ilgili alanları kendi yapımıza göre yazip)

az vmss run-command invoke --resource-group "MC_rg_myAKSCluster_region" --name "vmss-name" --command-id RunShellScript --instance-id 1 --scripts "openssl x509 -in /etc/kubernetes/certs/apiserver.crt -noout -enddate" --query "value[0].message"

Böylece Tüm sertefikalarımız hakkında bilgi sahibi olduk
Azure AKS Sertefika işlemlerini Yenileme/Değiştirme için

Mart 2022’den sonrasida oluşturulan veya upgrade edilen tüm AKS clusterleri için Azure Kubernetes Hizmeti, hem kontrol düzlemindeki hem de aracı clusterlardaki CA dışı sertifikaları, cluster için herhangi bir kesinti olmadan süre sona ermeden önce cilent sertifikası geçerlilik süresi %80’i ninde otomatik olarak rotate edip yenileyecektir.

Pratikte yapacaktır edecektir diyorum ama yapamayabilir yada yapamayabiliriz bu noktada makaleyi hazirlarken temel azure, temel K8s ve linux bilginiz olduğunu varsayiyorum.

Exit mobile version