[TR] HPE Morpheus Enterprise’da Clients Ayarları ile API, CLI ve Otomasyon Erişiminin Güvenli Yönetimi

HPE Morpheus Enterprise ile bir süredir çalışıyorsanız platformun büyük kısmını arayüz üzerinden tıklayarak, formları doldurarak yönettiğinizi fark etmişsinizdir. Ancak Morpheus’un asıl gücü neredeyse her şeyin bir API çağrısına karşılık gelmesinde yatar.

Otomasyon görevleri, Terraform entegrasyonları, CLI komutları, harici sistemlerden gelen istekler… Bunların hepsi arka planda aynı kapıdan geçer. İşte Administration > Settings > Clients sekmesi tam olarak bu kapının anahtarlarını yönettiğiniz yerdir.

HPE Morpheus Enterprise’da Administration > Settings > Clients ekranı ilk bakışta küçük bir ayar sayfası gibi görünse de platform güvenliği ve otomasyon yönetimi açısından oldukça kritik bir bölümdür.

Bu sekme ilk bakışta sade görünür. Birkaç satır, birkaç sayı… Ama o satırların her biri ortamınızdaki bir token akışının ömrünü ve güvenliğini belirler.

Bu makalemde Clients ayarlarının ne işe yaradığını, varsayılan istemcilerin neden var olduğunu ve kendi senaryolarınız için bunları nasıl yapılandırmanız gerektiğini ayrıntılı biçimde ele alacağım.

Clients Ne anlama Geliyor?

Morpheus’un API’si OAuth 2.0 tabanlı bir kimlik doğrulama modeli kullanır. Yani API’ye gönderdiğiniz her isteğin başında bir access token taşımanız gerekir. Bu token olmadan çoğu uç nokta size kapısını açmaz.

Token’ları üreten ve doğrulayan mekanizmanın merkezinde “OAuth client” dediğimiz nesneler durur.

Bir OAuth istemcisini belirli bir kullanım amacına atanmış bir kimlik şablonu gibi düşünebilirsiniz. Her istemcinin bir kimliği (Client ID) isteğe bağlı bir gizli anahtarı (secret) ve en önemlisi token ömürlerini tanımlayan iki süre değeri vardır. Bir kullanıcı belirli bir istemci üzerinden token ürettiğinde, o token o istemcinin kurallarına tabi olur.

Burada kritik bir nokta var Clients ayarları yalnızca Primary Tenant (birincil kiracı) içinde görünür ve yapılan değişiklikler tüm kiracıları etkiler.

Yani bu bir “kiracıya/tenant’a özel” ayar değildir appliance genelinde geçerli, küresel bir yapılandırmadır. Bu yüzden buradaki bir düzenleme, görünenden daha geniş bir etki alanına sahiptir ve dikkatle ele alınmalıdır.

Tekrar’dan hatırlatmakda fayda var buradaki “Clients” ifadesi son kullanıcıları veya tenant müşterilerini değil Morpheus üzerinde API, CLI, otomasyon ve entegrasyon amaçlı kullanılan OAuth istemcilerini ifade eder.

Yani bu ekran hangi istemci kimliğiyle token üretilebileceğini bu tokenların ne kadar süre geçerli kalacağını ve ilgili istemcilerin nasıl yönetileceğini belirleyen merkezi bir güvenlik alanıdır.

HPE dokümantasyonuna göre Morpheus Enterprise hazır tanımlı OAuth client’lar ile gelir ve yöneticiler ihtiyaç halinde ek client’lar oluşturabilir. Bu ayarlar yalnızca Primary Tenant üzerinden yönetilir ve yapılan değişiklikler tüm tenant’ları etkiler. Bu nedenle Clients ekranında yapılan her değişiklik sadece tek bir kullanıcıyı değil tüm platformdaki API ve otomasyon davranışını etkileyebilir.

Clients Ekranının Amacı

Morpheus Enterprise’da API üzerinden işlem yapmak CLI kullanmak, otomasyon görevleri çalıştırmak veya üçüncü parti sistemlerle entegrasyon kurmak için erişim token’larına ihtiyaç duyulur.

Bu token’ların üretildiği temel yapı ise OAuth client tanımlarıdır.

Bir client kabaca “bu uygulama veya kullanım tipi Morpheus’a hangi kimlikle bağlanacak ve tokenları ne kadar süre geçerli olacak?” sorusunun cevabını verir.

Ekranda görülen temel sütunlar şunlardır:

Client ID	OAuth istemcisinin referans adıdır. Örneğin morph-api, morph-cli, morph-automation gibi.
Access Token Validity Interval	Access token’ın kaç saniye geçerli kalacağını belirler.
Refresh Token Validity Interval	Refresh token’ın kaç saniye geçerli kalacağını belirler.

Access token API çağrılarında doğrudan kullanılan kimlik bilgisidir. Refresh token ise access token süresi dolduğunda yeni token üretmek için kullanılır.

HPE dokümantasyonunda yeni client oluşturulurken Client ID, isteğe bağlı Secret, Access Token Validity Interval ve Refresh Token Validity Interval alanlarının yapılandırıldığı belirtilir.

Varsayılan Client’ler ve Görevleri

HPE Morpheus Enterprise kurulumla birlikte birkaç hazır OAuth client’I getirir. Ekran görüntünüzde de göreceğiniz gibi listede morph-api, morph-automation, morph-cli, morph-customer ve morpheus-terraform yer alıyor.

Bunların her birinin belirli bir varlık nedeni vardır ve hangisinin ne için kullanılması gerektiğini bilmek sağlıklı bir entegrasyon mimarisinin temelidir.

morph-api: adından da anlaşılacağı gibi standart API erişimi için tasarlanmıştır ve harici uygulamalardan kendi yazdığınız betiklerden veya entegrasyon araçlarınızdan Morpheus API’sine erişirken kullanmanız önerilen varsayılan istemcidir.

Yeni bir entegrasyon kurarken aksini gerektiren özel bir neden yoksa tercih etmeniz gereken istemci budur.

morph-cli: Morpheus komut satırı aracı (CLI) için ayrılmıştır. CLI üzerinden oturum açtığınızda kimlik doğrulaması bu istemci üzerinden yürür.
morph-automation: Platformun iç görev motoru (Task engine) ve jRuby tipi görevlerin API çağrıları yapması için kullanılır.

Bu istemci dışarıya açık entegrasyonlar için tasarlanmamıştır harici otomasyonda kullanılmamalıdır. Arayüzde görünür olmasının nedeni kullanıcıların bu istemciye ait bir token olup olmadığını görebilmesi ve gerektiğinde temizleyebilmesidir yoksa elle token üretmeniz beklenen bir istemci değildir.

morph-customer: Daha çok geçmişe dönük uyumluluk için duran bir istemcidir.

Eskiden özel API erişimi için morph-api’ye benzer biçimde önerilirdi. Bugün kullanılması tavsiye edilmez ancak hâlâ sahada çalışmakta olan eski özel otomasyonların bozulmaması için listede tutulur. Yeni bir proje kuruyorsanız bu istemciden uzak durunuz.

morpheus-terraform: İse Terraform entegrasyonlarının ihtiyaç duyduğu token akışını yönetir.

Morpheus’u Terraform sağlayıcısı (provider) ile birlikte kullanan ekipler için bu istemci doğrudan ilgili olacaktır.

Bu varsayılan istemcilerin ortak bir özelliği vardır: Düzenlenebilirler ama silinemezler. Token ömürlerini ihtiyacınıza göre değiştirebilirsiniz fakat istemcinin kendisini listeden kaldıramazsınız. Buna karşılık sizin oluşturduğunuz istemciler hem düzenlenebilir hem de silinebilir.

Bu ayrım platformun kendi iç işleyişini yanlışlıkla bozmanızı engelleyen bir güvenlik önlemidir.

Ekran Görüntüsündeki Değerlerin Anlamı

Clients listesindeki her satırda iki sütun dikkatinizi çekecektir. Access Token Validity Interval ve Refresh Token Validity Interval. İkisi de saniye cinsindendir ve bir istemcinin davranışını gerçek anlamda belirleyen değerler bunlardır.

Access token: API isteklerinde fiilen taşıdığınız anahtardır.

Geçerlilik süresi dolduğunda o token artık kabul edilmez.

Refresh token ise access token süresi dolduğunda yeniden oturum açmadan yeni bir access token almanızı sağlayan ikinci anahtardır.

Yani access token kısa ömürlü çalışma anahtarı, refresh token ise onu yenileme yetkisidir.

31.536.000 saniye -> tam olarak 365 güne yani bir yıla karşılık gelir. morph-api, morph-cli ve morph-customer istemcileri bu değerle yapılandırılmış durumda. Bu ilgili token’ların üretildikten sonra bir yıl boyunca geçerli kalacağı anlamına gelir.

1.440 saniye -> yalnızca 24 dakikadır. morph-automation ve morpheus-terraform istemcileri bu kısa süreyle ayarlanmış. Bu da iç otomasyon ve Terraform akışlarının token’larının çok kısa ömürlü olduğunu, sürekli yenilenerek çalıştığını gösterir.

Bu fark tesadüf değildir !!! Uzun ömürlü token’lar kullanım kolaylığı sağlar bir script token’ı bir kez koyarsınız uzun süre dokunmazsınız. Ancak aynı uzunluk bir güvenlik riskidir o token sızdığında saldırgan onu uzun bir süre boyunca kullanabilir.

Kısa ömürlü token’lar ise tam tersini yapar ele geçseler bile geçerlilik pencereleri o kadar dardır ki pratikte değersizleşirler fakat karşılığında sürekli yenilenmeleri gereken bir altyapı gerektirirler.

Burada akılda tutulması gereken denge şudur kolaylık ile güvenlik arasında bir tercih yapıyorsunuz. Bir yıllık geçerlilik üzerinde düşünülmeden bırakılacak bir değer değildir. Birçok kurumun güvenlik politikası, hizmet hesabı token’larının bu kadar uzun yaşamasına izin vermez.

Varsayılan Client’lar Ne İşe Yarar?

Morpheus Enterprise ortamlarında genellikle bazı client’lar hazır gelir. HPE dokümantasyonunda morph-api client’in Morpheus Enterprise API erişimi için kullanıldığı ve varsayılan token tipi olarak tercih edilmesi gerektiği; morph-cli istemcisinin ise CLI erişimi için kullanıldığı belirtilir.

morph-automation daha çok Morpheus’un kendi iç otomasyon mekanizmalarıyla ilişkilidir. HPE dokümantasyonunda bu client’ın internal task engine ve jRuby türü task’ların API çağrıları için kullanıldığı harici erişim veya dış otomasyonlar için kullanılmaması gerektiği ifade edilir.

morph-customer ise eski uygulamalardan gelen uyumluluk amacıyla bulunabilir yeni entegrasyonlarda öncelikli tercih olmamalıdır.

Ekranınızda ayrıca morpheus-terraform benzeri bir client da görünüyor. Bu tür client’lar genellikle Terraform, IaC veya özel otomasyon senaryoları için oluşturulmuş olabilir. Ancak bunun varsayılan mı yoksa ortamınıza özel mi olduğunu kesinleştirmek için ilgili entegrasyon dokümantasyonu ve kullanım geçmişi kontrol edilmelidir.

Yeni OAuth Client Oluşturma

Varsayılan client’lar birçok senaryoyu karşılar ancak bazı durumlarda kendi istemcinizi tanımlamak isteyebilirsiniz.

Örneğin belirli bir entegrasyona özel, kısa ömürlü ve izlenebilir bir kimlik istiyorsanız ya da farklı ekiplerin token’larını birbirinden ayrı yönetmek istiyorsanız ayrı bir istemci mantıklı olur. Listenin sağ üst köşesindeki “+ Add” düğmesine tıkladığınızda karşınıza birkaç alan çıkar;

Client ID : İstemci için bir referans adı. Bunu anlamlı seçin; “test1” yerine “ci-pipeline-prod” gibi, ne işe yaradığını altı ay sonra hatırlatacak bir ad kullanın.
Secret : İsteğe bağlı bir OAuth istemci gizli anahtarı. Daha sıkı bir kimlik doğrulama akışı için tanımlayabilirsiniz.
Access Token Validity Interval (Seconds) : Access token’ın saniye cinsinden geçerlilik süresi.
Refresh Token Validity Interval (Seconds) : Refresh token’ın saniye cinsinden geçerlilik süresi.

Alanları doldurduktan sonra Save Changes ile kaydedersiniz ve istemci anında listeye eklenir.

Not : Client ID belirlerken anlaşılır ve standart bir isimlendirme kullanmak önemlidir.

Örneğin:

morph-api-backup
morph-monitoring-integration
morph-terraform-prod
morph-servicenow-integration

Bu yaklaşım ileride hangi client’ın hangi sistem için oluşturulduğunu anlamayı kolaylaştırır.

Token’lar Nerede Üretilir?

Sık karşılaşılan bir kafa karışıklığını burada netleştirmek gerekir. Clients sekmesi token üretmez. Burada clientlerin kurallarını tanımlarsınız ama gerçek access ve refresh token’lar başka bir yerde kullanıcı bazında üretilir.

Token üretmek için sağ üst köşedeki kullanıcı adınıza tıklayıp User Settings bölümüne oradan da API Access alanına gidersiniz.

Açılan pencerede her Client ID için bir token yoksa “ACTIONS” menüsünden Generate varsa ve süresi dolmuşsa Regenerate seçeneğini kullanırsınız. Bir token’ı tamamen iptal etmek isterseniz Clear seçeneği bunu yapar.

Burada çok önemli bir uyarı var üretilen access token’lar yalnızca üretildikleri anda görüntülenir.

API Access sayfasından ayrıldığınızda token’ın tam değeri maskelenir ve bir daha gösterilmez. Bu yüzden yeni bir token ürettiğinizde, sayfadan çıkmadan önce token’ı kopyalayıp güvenli bir yere kaydetmeniz şarttır. Aksi halde tek yapabileceğiniz şey token’ı yeniden üretmektir ki bu da o token’ı kullanan tüm betiklerin güncellenmesi gerektiği anlamına gelir.

Client Düzenleme ve Silme

Clients ekranındaki kalem simgesi ile mevcut client düzenlenebilir. Çöp kutusu simgesi ise silme işlemi için kullanılır.

Ancak burada önemli bir ayrım vardır; HPE dokümantasyonuna göre hazır gelen varsayılan client’lar düzenlenebilir fakat silinemez, kullanıcı tarafından oluşturulan client’lar ise düzenlenebilir veya silinebilir.

Bu nedenle varsayılan client’lar üzerinde değişiklik yaparken dikkatli olunmalıdır. Özellikle morph-api veya morph-cli gibi client’ların token sürelerini plansız şekilde değiştirmek, mevcut API script’lerinin, CLI işlemlerinin veya otomasyonların beklenmedik şekilde hata almasına neden olabilir.

Güvenlik Açısından Dikkat Edilmesi Gerekenler

Clients ayarlarında en kritik konu token süreleridir. Çok uzun süreli access token’lar operasyonel kolaylık sağlar fakat güvenlik riskini artırır. Çok kısa süreli token’lar ise daha güvenlidir ancak otomasyon tarafında refresh mekanizması düzgün kurulmamışsa kesintilere neden olabilir.

İyi bir pratik olarak dış sistemlerle kullanılan client’larda access token süresi mümkün olduğunca kısa tutulmalı refresh token ise kontrollü bir süreyle sınırlandırılmalıdır. Kritik üretim ortamlarında token kullanımının kim tarafından hangi amaçla ve hangi sistemde kullanıldığı kayıt altına alınmalıdır. Paylaşılan kişisel kullanıcı token’ları yerine izlenebilir entegrasyon hesapları ve minimum yetki prensibi tercih edilmelidir.

Token veya secret bilgileri e-posta, düz metin dosyası ya da ortak dokümanlarda saklanmamalıdır. Bunun yerine kurumun parola kasası, secret management çözümü veya güvenli credential yönetim sistemi kullanılmalıdır. Bir token’ın sızdırıldığından şüpheleniliyorsa ilgili token temizlenmeli veya yeniden üretilmeli; bu token’ı kullanan tüm sistemler de güncellenmelidir.

Önerilen Yönetim Yaklaşımı

Morpheus Enterprise’da Clients ekranı için düzenli bir yönetim standardı oluşturmak faydalıdır. Her client’ın amacı net olmalı kullanılmayan client’lar temizlenmeli, token süreleri güvenlik politikasıyla uyumlu hale getirilmeli ve özellikle uzun ömürlü token’lar periyodik olarak gözden geçirilmelidir.

Pratik bir yaklaşım şöyle olabilir API ve CLI erişimleri için ayrı client’lar kullanılmalı Terraform veya ServiceNow gibi entegrasyonlara özel client’lar ayrı tanımlanmalı, otomasyon client’ları kişisel kullanıcı işlemlerinden ayrılmalı ve tüm client’lar isimlendirme standardına göre yönetilmelidir. Böylece hem sorun giderme kolaylaşır hem de güvenlik denetimlerinde daha anlaşılır bir yapı elde edilir.