Merhaba;
OCI ile ilgili yazdığım ilk makalede, İkinci bölümde, OCI’ın “compute” ile bize sunduğu olanaklardan, depolama birimi seçeneklerinden bahsedeceğimi belirtmiştim. “Identity and Access Management (IAM)” sayesinde, kullanıcılardan oluşan grupların hangi kaynaklara ne tür erişimler yapabileceğini nasıl kontrol edebileceğimizi aktaracağımı ifade etmiştim. O zaman öncelikle IAM ile başlayalım.
IAM hizmeti, bulut kaynaklarımıza kimlerin erişebileceğini kontrol etmemize imkan sağlar. Kullanıcılardan
oluşan grubun, hangi belirli kaynaklara ne şekilde erişebileceğini
belirleyebilirsiniz. IAM servisi, varsayılan olarak (“default”) en az ayrıcalıklı
güvenlik ilkesini uygulamamızı sağlar. Yeni kullanıcılar, uygun izinler verilene kadar hiçbir kaynak üzerinde herhangi bir işlem yapamazlar.
IAM servisi sayesinde, tüm Oracle Cloud Altyapı (OCI) hizmetlerinde kimlik doğrulama ve yetkilendirme için tek bir model kullanabilirsiniz. IAM, tek bir projede çalışan bir kişiden, aynı anda birçok projede çalışan birçok gruba sahip büyük şirketlere kadar, her büyüklükteki kuruluşun bulut kaynaklarına erişimi yönetmesini kolaylaştırır.
IAM servis bileşenleri nedir?
Kaynak (“resource”): Organizasyon çalışanınızın, OCI ile etkileşimde bulunurken oluşturduğu bulut nesnesidir. Hesaplama oluşumları (“compute instance”), blok depolama birimleri, volümler (“volume”), sanal bulut ağları (“virtual cloud networks”), subnet’ler, “route” tabloları kaynaklara örnek olarak verilebilir.
Kullanıcı (“user”): Organizasyon’da “Oracle Cloud” altyapısı kaynaklarını yönetmesi veya kullanması gereken bireysel bir çalışan veya sistem olarak düşünülebilir. Kullanıcıların,
“compute instance”ları başlatması, uzak
diskleri yönetmesi, sanal bulut ağınızla (“virtual cloud network”)
çalışması gerekebilir. Uygulamalarınızı
çalıştıran son kullanıcılar genellikle IAM kullanıcıları değildir. Kullanıcıların
bir veya daha fazla IAM kimlik bilgisi olabilir.
Grup: Aynı erişimlerle belirli bir kaynak setine ulaşmaya ihtiyaç duyan kullanıcılardan oluşan bir küme olarak düşünebiliriz.
Compartment: Birbiriyle ilişkili kaynaklardan oluşan bir koleksiyon olarak düşünebiliriz. “Compartment”,
bulut kaynaklarımızı düzenlemek ve birbirinden izole etmek için OCI’ın temel
bir bileşenidir. Bulut kaynaklarının kullanım oranlarını ve maliyetlerini
projelere/birimlere/bölümlere göre ölçebilmek, farklı politikalara göre her
birime, projeye farklı erişim türleri oluşturmak, bölümlerin/birimlerin bulut
kaynaklarına erişimlerinde izolasyon oluşturmak için kullanılır. “Compartment” oluşturma
konusundaki en iyi pratik,
organizasyonun her büyük bölümü için bir “compartment” yapılandırmaktır.
Tenancy: Organizasyonun tüm “Oracle Cloud” altyapı kaynaklarını içeren kök “compartment”dır. Oracle,
organizasyonun kiracılığını (“tenancy”) sizin için otomatik olarak oluşturur. “Tenancy”
içinde IAM varlıklarınız (kullanıcılar, gruplar, “compartment”lar ve
politikalar gibi) vardır. “Compartment” içine diğer bulut kaynağı türlerini de
(örneğin, “instance”lar, sanal ağlar (“virtual networks”) ve blok depolama
volümleri (block storage volumes)) oluşturabilirsiniz.
Policy: Kimin hangi kaynaklara ne şekilde erişebileceğini belirten kurallar setidir. Erişim
grup düzeyinde ve “compartment” seviyesinde verilir. Yani, bir “compartment”
içinde, bir gruba belirli türde bir erişim verebilirsiniz. Örneğin, “tenancy”e bir grup erişimi
verdiğinizde, grup, otomatik olarak “tenancy” içinde olan tüm “compartment”lara
aynı türde erişim alır.
Home Region: IAM kaynaklarımızın bulunduğu bölgedir. Tüm IAM
kaynakları globaldir ve tüm bölgelerde kullanılabilir, ancak master tanım
kümesi tek bir bölgede, ana bölgede bulunur. Kendi bölgenizdeki IAM kaynaklarınızda değişiklik yaptığınızda, değişiklikler otomatik olarak tüm bölgelere yayılır.
Şekil 1., “Tenancy”, “Compartment” arasındaki bağlantıyı göstermektedir. Şekil’de, bir “Tenancy” içinde iki tane “compartment” vardır: “Compartment A” ve “Compartment B”. “Compartment A” için tanımlanan “PolicyA”, Grup X’in bu “compartment” içinde olan kaynakları yönetmesine izin verir. “PolicyB” ise, Grup Y’nin, “Compartment B” içinde olan tüm kaynakları yönetmesine izin verir.
Şekil 1. “Tenancy” ve “Compartment” arasındaki ilişki.
Bir kullanıcı oluştururken, “Tenancy” içindeki ismi tek olmalıdır. Yeni kullanıcının, siz kullanıcıyı bir grup içine ekleyene kadar herhangi bir izni yoktur. Kullanıcıyı, en azından bir “policy”si olan bir gruba eklediğinizde, grup iznini “tenancy” veya “compartment”e vermis olursunuz. Öncelikle, yeni kullanıcılarınızın rollerini kesin olarak belirlemeli, ardından kullanıcılarınızı, uygun yönetim politikalarına sahip gruplara eklemelisiniz. Mesela, bir kullanıcı DBA ise, bu kullanıcıyı, ilgili “compartment” için, “database-family” kaynak türünü yönetebilecek izinleri içeren politikalara sahip veritabanı yöneticisi grubuna ekleyebilirsiniz.
“Instance Principal” ve “Dynamic Group” dediğimiz iki kavram daha var. “Instance Principal” sayesinde, “instance”larımızı, dinamik grupların içine ekleyebiliyoruz. Normalde, gerek “bare metal” üzerinde olsun gerekse sanal makinelerde olsun, “instance”lardaki kimlik bilgilerini yönetmek zorundayız. “Instance principal” sayesinde, “instance”lar üzerinde çalışan servisler için, kullanıcı kimlik bilgilerinin yapılandırılması gerekmez. “Instance”ların kendileri yeni bir “principal” türüdür. “Instance”ları, mantıksal dinamik gruplar şeklinde gruplayabilirsiniz. Uygulamalar, “instance principal”ları kullanarak, “compute”, “networking”, “block volumes”, “object storage”, “load balancing”, database” OCI servislerine çağrı yapabilirler. Dinamik gruplar, Oracle Cloud Infrastructure Compute oluşumlarını/örneklerini (“OCI instances”), kullanıcı gruplarına benzer şekilde “principal” aktörler olarak gruplandırmamızı sağlar. Daha
sonra, “instance”ların Oracle Cloud Altyapı servislerine API çağrıları
yapmasına izin vermek için politikalar oluşturabiliriz. Dinamik
bir grup oluştururken, “tenancy” içinde ismi
tek olmalıdır.
Oracle Cloud Infrastructure IAM, (SAML) 2.0 protokolünü kullanarak “Oracle Cloud Identity” Servisleri ve “Microsoft Active Directory Federation Services (AD FS)” ile federasyonu destekler.
Güvenlik listesi (“Security List”), bir “instance” için içeri ve dışarı izin verilen trafik türlerini belirten giriş (“ingress”) ve çıkış (“egress”) kurallarına sahip bir sanal güvenlik duvarı görevi görür. Her güvenlik listesi VNIC düzeyinde uygulanır. Ancak,
güvenlik listelerinizi alt ağ (“subnet”) düzeyinde de yapılandırabilirsiniz. Yani
bu durumda belirli bir alt ağdaki tüm VNIC’ler aynı güvenlik listelerine tabi
olabilir. Güvenlik
listeleri, VCN’de bulunan farklı bir “instance” ile veya VCN’nin dışından
bulunan başka bir host ile iletişim kuran VNIC’e uygulanabilir.
Her alt ağın (“subnet”) kendisiyle ilişkili birden fazla güvenlik listesi olabilir ve her listenin de birden çok kuralı olabilir. Listelerden herhangi birindeki kural, trafiğe izin veriyorsa (veya trafik izlenen mevcut bir bağlantının parçasıysa) söz konusu pakete izin verilir.
Her bulut network’ü, varsayılan (“default”) bir güvenlik listesine sahiptir. VCN için siz farklı güvenlik listeleri de oluşturabilirsiniz. Alt ağ (“subnet”) oluşturduğunuzda eğer bir veya daha fazla güvenlik listesi ataması yapmazsanız, alt ağ, otomatik olarak varsayılan güvenlik listesi ile ilişkilendirilir. Herhangi bir zamanda, alt ağ ile ilişkilendirilen güvenlik listelerini değiştirebilirsiniz. Aynı şekilde listedeki kuralları da değiştirebilirsiniz.
OCI’ın sunduğu “compute” modellerinden genel olarak bahsedip ikinci bölümü tamamlamayı düşünüyorum. Paylaşımlı çok-kiracılı model (“shared multi-tenant model”), opsiyonlardan bir tanesidir. Oracle, bu yapıyı “bare metal” bir sistem üzerinde hipervizör katmanı ile sağlamaktadır. Bizim sistemi veya üzerinde çalışan hipervizörü dert etmemize gerek yok. VM’lerimizi oluşturup hedefimize dönük çalışmalarımıza başlayabiliriz. Diğer model, tamamen bize atanmış bir VM host (“dedicated VM host”) modelidir. VM’lerinizi, “single-tenant” yapıda başka bir müşteriyle paylaşmadan sadece kendinize ait bir şekilde yapılandırıp kullanabilirsiniz. Bu yapıda, hipervizör katmanını sizin yönetmeniz gerekir. Performans odaklı uygulamalarınız için tercih etmek isteyebilirsiniz. Çalıştırmak istediğiniz Uygulama, belli bir hipervizör katmanını destekleyebilir. Yine bu durumda, “bare metal” modeli ile ilerleyerek, kendi hipervizör yapınızı kurmak isteyebilirsiniz. OVM, KVM ve Microsoft Hyper-v hipervizörlerini yapılandırabilirsiniz.
OCI’da “shape”, çok önemli bir kavramdır. “Shape” aslında bir şablondur. Bu şablona ile, oluşturacağınız “instance”a atayacağınız CPU sayısını, bellek miktarını ve diğer kaynakları belirlersiniz. Örneğin, “flexible shape” de siz OCPU sayısını, iş yükünüze göre seçersiniz. Bellek, ağ bant genişliği ve VNIC sayısı OCPU sayısı ile orantılı olarak ölçeklenir.
Oracle’ın sağladığı aşağıdaki imajlar “flexible shape” ile uyumludur.
Oracle Autonomous Linux 7.x
Oracle Linux 6.x (VMs only)
Oracle Linux 7.x
CentOS 7.x
Ubuntu 16.04
Ubuntu 18.04
Windows Server 2012 (VMs only)
Windows Server 2016 (VMs only)
Windows Server 2019 (VMs only)
“Bare metal shape”ler, “standart”, “Dense IO”, “GPU” ve “HPC” olarak sıralanabilir. Örneğin, “bare metal” GPU serisine örnek olarak verebileceğim BM.GPU3, X7 tabanlıdır. NVIDIA Tesla V100 içerir.
VM içinde aynı şekilde, “standart”, “dense IO”, GPU “shape”leri vardır.
Ikinci bölümü bu şekilde tamamlıyorum. Üçüncü bölümde OCI’ın diğer servislerinden bahsediyor olacağım.
Asiye Yiğit – 17 Mayıs 2020 Pazar
Kaynakça:
Kullandığım yağlı boya tablosu, “Castle in the Clouds” by Liese Chavez.
https://docs.cloud.oracle.com/en-us/iaas/Content/Compute/References/computeshapes.htm
Leave A Comment