Openshift Bölüm 5: Project ve User

Namespace

Bir Openshift cluster’ın onlarca, yüzlerce servis çalışabilir. Birçok ekip, bu ekiplere dahil onlarca kişi de çalışabilir. Bunların tamamı her şeye erişirse sorun yaşanma ihtimali yüksektir. Sorun yaşanmasa dahi bir ekibin erişmesi gereken kısma diğer bir ekibin erişmemesi gerekebilir. Böyle bir izolasyon sağlayabilmek için Kubernetes’te Namespace’ler vardır.

Namespace bize temelde aşağıdaki konularda yardımcı olur:

• İsimlendirme çakışmalarını önler. Mesela anımsıyorsanız hangi kullanıcı ile girersek girelim My Project adında default bir projemiz olduğunu görüyorduk. Aynı isimde olmasının temel sebebi birbirinden yalıtılmış namespace’lerdir.
• Güvenilirt (trusted) kullanıcılar için yönetim yetkisinin devri (delegation).
• Toplulukların tüketeceği kaynakların sınırlandırılabilmesi.

 

Project

Openshift’teki bir project, aslında bazı annotation içeren namespace’dir ve kaynaklara erişimin yönetildiği merkezi araçtır. Projeler aracılığı ile ekipleri ve çalışmalarını birbirinden izole ettiğimiz gibi, kaynak kullanımını da sınırlayabiliyoruz.

Projeler 3 tanım bulunur: name, displayName ve description. Bir proje yaratırken:

name zorunludur. Proje için benzersiz bir tanımlayıcıdır. Maksimum 63 karakter uzunluğunda olabilir. CLI veya API kullanıldığında projelerimizi listelerken name kısmını görmüş oluyoruz.

displayName isteğe bağlıdır, eğer girilmezse default olarak name’i alır. Web UI’dan girdiğimizde bunu görürüz.

description isteğe bağlıdır. Proje ayrıntıları hakkında bilgilendirme için kullanılır. Web UI’da görülür.

Her project kendi scope’una sahiptir.

Object’ler	Pod, Service, Replication Controller vb.
Policy’ler	Kullanıcıların object’ler üzerinde yapabileceği işlemlerle ilgili kurallar.
Constraint’ler	Object’ler için sınırlamalar
Service Account’lar	Project içinde object’lere dizayn edilmiş erişim ile otomatik hareket ederler.

Cluster admin’ler bir proje oluşturabilir ve ekipten birine bu proje üzerindeki yetkileri devredebilir. Bununla birlikte admin’ler kişilere kendi projelerini oluşturabilmeleri için yetki de verebilirler.

 

User’lar

OpenShift ile etkileşim bir kullanıcıyla ilişkilidir. OpenShift user nesnesi , onlara veya gruplarına roller eklenerek sistemde izinler verilebilecek bir aktörü temsil eder.

Birkaç tür kullanıcı mevcut olabilir:

Regular User	Bu, çoğu etkileşimli OpenShift kullanıcısının temsil edilme şeklidir. Regular kullanıcılar, ilk girişte sistemde otomatik olarak oluşturulur veya API aracılığıyla oluşturulabilir. Regular kullanıcılar User nesne ile temsil edilir. Ör: developer’lar
System User	Bunların çoğu, temel olarak altyapının API ile güvenli bir şekilde etkileşime girmesini sağlamak amacıyla, altyapı tanımlandığında otomatik olarak oluşturulur. Bir cluster yöneticisi (her şeye erişime sahip), node başına bir kullanıcı, router’lar ve registry’ler tarafından kullanılacak kullanıcılar ve diğer türleri içerirler. Son olarak, anonymous kimliği doğrulanmamış istekler için varsayılan olarak kullanılan bir sistem kullanıcısı vardır. Ör: system:admin system:openshift-registry system:node:node1.example.com
Service Account	Bunlar, projelerle ilişkili özel sistem kullanıcılarıdır; bazıları proje ilk oluşturulduğunda otomatik olarak oluşturulurken, proje yöneticileri her bir projenin içeriğine erişimi tanımlamak amacıyla daha fazlasını oluşturabilir . Servis hesapları ServiceAccount nesne ile temsil edilir . Ör: system:serviceaccount:default:deployer system:serviceaccount:foo:builder

OpenShift’e erişmek için her kullanıcının bir şekilde kimlik doğrulaması yapması gerekir . Kimlik doğrulaması veya geçersiz kimlik doğrulaması olmayan API istekleri, anonymoussistem kullanıcısı tarafından istek olarak doğrulanır. Policy, kimlik doğrulandıktan sonra kullanıcının ne yapmaya yetkili olduğunu belirler.

Oauth Server

Openshift Master üzerinde built-in olarak bulunur. Kullanıcılar, API kullanarak kimlik doğrulama işlemi yaparken token kullanmak zorundadır. Bu token’lar Oauth Server tarafından oluşturulurlar. Bir kullanıcı token almak istediğinde, Oauth Server identity provider ile iletişim kurar, kullanıcı ile eşleşmeyi bulur, ilişkili bir token oluşturur ve token bilgisi döndürür.

Bizim çalışmalarımız için kullndığımız Minishift gibi All In One Node yapsısında Oauth Server default olarak Allow All modunda çalışır. Bu sebeple girdiğimiz şifreler aslında tam olarak şifre değildir, ne girdiğimiz bir önemi yoktur, sadece kullanıcı adı bilgisi yeterlidir ve şifre kısmı boş geçilemediği için canımız ne istersen onu girebiliyoruz. Hatta girdiğimiz kullanıcı eğer yoksa otomatik olarakta oluşturulurlar.

Productionda çalıştığımız Single Master + Multiple Nodes veya Multiple Master + Multiple Nodes kurulumlarda ise Oauth Server çalışma modu Deny All’dur. Cluster admin’ler manuel olarak kullanıcıları create etmek ve yetkilendirme zorundadır.

Bu kısımda bir değişiklik yapmak istersek /etc/openshift/master/master-config.yaml konfigürasyon dosyasında değişiklik yapabiliyoruz.

Örnek User ve Project İşlemleri

Öncelikle CLI üzerinden system:admin kullanıcısı olarak giriş yapalım:

Projelerimizi listeleyelim:

Kullanıcılarımızı görelim:

Identities kısmında gördüğünüz gibi Allow On modunda çalıştığımızdan anypassword olarak işaretlendiğini görüyoruz. Hatta kullanıcı olmasa dahi oluşturulduğunu söylemiştik. Şimdi Web UI’dan isterseniz bir kullanıcı girişi yapalım rastgele olarak.

Şimdi tekrar kullanıcılarımızı listeleyelim:

Gördüğünüz gibi ferhatsarikaya kullanıcısı girişim ile birlikte otomatik olarak oluşturulmuş oldu.

CLI ile Openshift’e system kullanıcısı ile bağlanmıştık; ama aynı kullanıcı ile Web UI’a giriş yapamayabiliriz, eski sürümlerde buna izin verilmiyordu; ama bizim çalıştığımız Mnishift üzerinde bunu yapabiliyoruz. Buna karşın eski modeli de düşünerek şöyle bir yol izlememiz gerekiyor. Web UI için bir kullanıcı oluşturup, bu kullanıcıya admin yetkisi vermek.

Kullanıcı listesinde admin kullanıcısını görüyorsunuz. Ben o kullanıcı için admin yetkilerini tanımlıyor olacağım.

Artık admin kullanıcımız Cluster Admin rolünün bir üyesi ve her şeyi yapmaya yetkili hale geldi. Şimdi admin ile Web UI’dan girdiğimizde tüm projeleri görebiliyor ve yönetebiliyor olacağız.