Kubernetes Auth 101

Giriş

Kubernetes kullanan, kullanmış veya ilgilenmiş herkes kubectl veya dashboard'u duymuştur. Kubernetes master'larına gidiyoruz, istek atıyoruz, podlar oluşturup siliyoruz. Peki prod ortamda herkesin erişmesini istemediğimizde kubernetes bize ne sunuyor?

Standart bir kubernetes cluster'ında api, 443 portundan hizmet verir. Tabi 443 portundan https ile konuşur. Siz aksini belirtmemişseniz, genelde kurulum sırasında otomatik olarak imzalanır. Biz de cli, rest call vs ile bu server üzerinden konuşuyoruz. 

Gelelim asıl mevzuya, kubernetes api server güvenliğini 3 adımda gerçekleştirir.

• Kimlik Doğrulama (Authentication)
• Yetkilendirme (Authorization)
• Kabul Kontrol (Admission Control)

Authentication - Kimlik Doğrulama

Koronaya rağmen el sıkıştıktan sonra, http isteği artık authentication, burası karıştırılmasın kimlik doğrulama, adımına geçer. Kimlik doğrulama adımında birden fazla modül kullanıldığı zaman biri başarılı oluncaya kadar sırayla denenir.

Kimlik doğrulama modülleri

• İstemci sertifikaları
• Parola
• Token
• Bootstrap token
• JWT token ( service accountlar için kullanılır )

Bu modüllerin detayları bu yazının kapsamı dahilinde değil. Belki ilerde bir yazı ile burayada değiniriz.

Eğer ki isteğin kimliği doğrulanamazsa, http 401 ile reddedilir.

Authorization - Yetkilendirme

Yapılan istek, isteği yapan kullanıcının, kullancı adı, istenilen eylemi (get,delete,create vs ) ve hedef objeyi (deployment,pod vs) içermelidir. İsteğin varolan bir policy ile eşleşmesi durumunda işlem gerçekleştirilir. Biraz aksiyon alalım;

Misal şirketimizin bütçesi kısıtlı ve test ile staging ortamlar aynı cluster üzerinde koşuyor. Devops stajerinin staginge readonly erişebilmelerini istiyoruz.

Şöyle bir policyimiz olduğunu varsayalım;

{
    "apiVersion": "abac.authorization.kubernetes.io/v1beta1",
    "kind": "Policy",
    "spec": {
        "user": "kaan",
        "namespace": "kubernetesturkey",
        "resource": "pods",
        "readonly": true
    }
}

Pod nesnesi için, kubernetesturkey namespace'inde sadece readonly yetkimiz var.

Ama create, delete vs gibi bir istek alırsam denied alıcaktım. Bu sayede namespacelerin aslında sadece network izolasyonu için değil, aynı zamanda yetki izolasyonu içinde çok önemli olduğunu görmüş olduk.

Sıkıcı konulara dönücek olursak, kubernetes yetkilendirme mekanizması rest özelliklerini gerektirir bu sadece kendi api serverları için değil cloud veya on-prem ile de entegre olabilmesini sağlar. Örn: AWS/GCP IAM policies. ( azure bilmiyorum, vardır onda da heralde )

Yetkilendirme üzerine daha detaylı bir bakış için şu yazıma bakabilirsiniz -> 

Kabul Kontrol

Diğer iki adımdan farklı olarak eğer bir tane bile kabul kontrol modülü fail olursa istek direk reddedilir.

Enable etmek için;
kube-apiserver --enable-admission-plugins=NamespaceLifecycle,LimitRanger ...

Disable etmek için;
kube-apiserver --disable-admission-plugins=PodNodeSelector,AlwaysDeny ...

Default olarak enable gelen modüller;

NamespaceLifecycle, LimitRanger, ServiceAccount, TaintNodesByCondition, Priority, DefaultTolerationSeconds, DefaultStorageClass, StorageObjectInUseProtection, PersistentVolumeClaimResize, RuntimeClass, CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, MutatingAdmissionWebhook, ValidatingAdmissionWebhook, ResourceQuota

Yav diğer ikisi tamamda bu ne şimdi .... demeyin  🙂

• Misal persistent volume claim oluşturdunuz, birden fazla default storage classınız var. Nolucak? Kabul kontrol red...
• Var olmayan bir namespace üzerinde nesne create isteği geldi, kabul kontrol red... 

Bu liste uzarda uzar.