Monopam mimarisi ve kurulumu
Neler değişti
Her içerik güncellemesi sürümlenir. Bir sürümü seçerek öncekiyle karşılaştırın.
Sürüm 1 → 2
Güncelleme4 ders güncellendisüre
İçerik güncellemesi. Kayıtlı öğrenciler bilgilendirildi.
Süre 11 dakikadan 15 dakikaya değişti.
Monopam yerel parola tutmaz. Kullanıcı, kiracı için yapılandırılmış kimlik sağlayıcıya, normalde Monosign'a yönlendirilir ve Monopam'in bir kimlik doğrulama çerezinde sakladığı imzalı bir sonuçla geri döner. Bu tek tasarım kararı birkaç planlama sorusunu birden yanıtlar.
| Soru | Yanıt | Neden |
| --- | --- | --- |
| MFA'yı nerede zorunlu kılarız? | Kimlik sağlayıcıda | Monopam'in kendi MFA'sı yoktur. Kimlik bilgileri ve MFA sağlayıcının işidir; böylece Monosign erişim politikaları ayrıcalıklı kullanıcılara da uygulanır |
| Gruplar ve yetkiler nereden gelir? | Sağlayıcıdan, kimlik doğrulama çerezinin içinde | Monopam bunları her istekte çerezden okur |
| Rol değişikliği neden henüz geçerli olmadı? | Kullanıcının yeniden oturum açması gerekir | Çerez hâlâ eski grupları taşır |
::diagram pam-signin-path
### Vekil tuzağı
Gruplar ve yetkiler çerezde taşındığı için oturum açmayı bitiren yanıt büyüktür ve kullanıcının üye olduğu her grupla büyür. Yanıt başlığı arabellekleri küçük olan bir ters vekil bu yanıtı reddeder.
Tipik bir durum: bir şirket Monopam'in önüne nginx koyar. Çoğu kişi sorunsuz oturum açar. Onlarca gruba üye olan platform ekibi ise Monosign'dan dönerken `502 Bad Gateway` alır ve nginx günlüğünde `upstream sent too big header` yazar. Hesaplarında bir sorun yoktur. Çözüm, Monopam'in önündeki **her** vekil atlamasında yanıt başlığı arabelleklerini büyütmektir (nginx için `proxy_buffer_size` ve `proxy_buffers`). Unutulan tek bir atlama oturum açmayı bozmaya yeter ve yalnızca çok gruplu kullanıcıları etkilediği için yetki sorunu gibi görünür.
> Tipİpucu: oturum açma yalnızca çok yetkili kullanıcılarda başarısız oluyorsa politikalardan önce vekillere bakın.
### Lisans kullanımı Monosign üzerinden akar
Monopam, Monofor servislerini kendisi çağırmaz. Her 15 dakikada bir her kiracının lisanslı modüllerini sayar ve yalnızca sayıları, ad ya da öğe içeriği olmadan, kiracının Monosign'ına gönderir. Monosign bunları kendi lisans sinyaline ekler. Monopam'in kullandığı Monosign REST API anahtarının `System.API.System.Usage` yetkisine ihtiyacı vardır. Eski bir sürümden yükseltilen kurulum bu yetki olmadan çalışmaya devam eder ama hiçbir şey raporlamaz: Monopam günlüğünde `License usage could not be reported to Monosign` görünür ve yetki verilene kadar lisans portalında Monopam kullanımı çıkmaz.
### Önce neye bakılır
| Belirti | Önce bakılacak yer |
| --- | --- |
| Monosign dönüşünde `502 Bad Gateway`, yalnızca çok gruplu kullanıcılarda | Her proxy adımındaki yanıt başlığı arabellekleri |
| Yeni rol ya da grup uygulanmıyor | Kullanıcının değişiklikten sonra yeniden oturum açıp açmadığı |
| Lisans portalında Monopam kullanımı görünmüyor | Monosign REST API anahtarındaki `System.API.System.Usage` izni ve `License usage could not be reported to Monosign` günlük satırı |
Monopam web sunucusu hedeflere oturum açmaz. Bunu bir **gateway** yapar: hedeflere ulaşabildiği yerde durur ve oturumu Monopam'e taşır. Dolayısıyla üretim sunucuları yalıtılmış bir segmentteyse segmente port ya da VPN açmazsınız. Segmente ulaşabilen bir gateway kurar ve oturumları onun üzerinden geçirirsiniz. Segmentasyon bozulmaz, her oturum aracılı ve kayıtlı kalır.
::diagram pam-gateway-path
### Siteler: konuma duyarlı yönlendirme
**Site**, fabrika, şube ya da veri merkezi gibi bir konumdur. Gateway'ler ve kaynaklar ona atanır (gateway'de `Site`, kaynakta `Advanced` > `Site`). Siteler isteğe bağlıdır: hiç site oluşturmayan kurulum eskisi gibi davranır. Varsayılan `Unassigned` değeridir.
Monopam bir bağlantının gateway'ini katı bir sırayla seçer:
| Sıra | Kural | Sonuç |
| --- | --- | --- |
| 1 | Kaynakta ya da politikada açıkça bir gateway seçilmiş | Bu seçim her zaman kazanır |
| 2 | Kaynak, gateway'i olan bir siteye atanmış | Yalnızca sitenin gateway'leri kullanılır |
| 3 | İkisi de yok | Herhangi bir etkin gateway |
::diagram pam-gateway-order
Bu tablodan doğrudan iki olay çıkar.
**Toparlama sonrası "Gateway not found".** Bir ekip "Bursa Fabrikası" sitesini oluşturur, fabrikanın gateway'ini atar ve kırk kaynağı siteye taşır. O ana kadar bu kaynaklar herhangi bir etkin gateway'i kullanabiliyordu. Artık yalnızca sitenin gateway'lerini kullanabilirler. O gateway etkin değilse ya da gereken bağlantı türünde değilse her bağlantı `Gateway not found` ile başarısız olur. `Sites` listesindeki `Gateways` rozeti etkin gateway sayısını gösterir ve sıfırda kehribar rengine döner. Siteler kimin bağlanabileceğine değil, yalnızca hangi gateway'in kullanılacağına karar verir.
**Sitesini yok sayan kaynak.** Bir sunucu, gateway'leri sağlıklı olan İstanbul sitesine atanmıştır ama oturumları Ankara üzerinden gider. Bunu 1. kural açıklar: kaynakta ya da politikasında çok önce seçilmiş bir gateway hâlâ kazanır. Açık seçimi temizleyin, site devreye girer.
### Veritabanı kaynakları için bir ayrıntı
Veritabanı proxy'sinin kullanıcıları istemcilerini, bağlantı penceresinde gösterilen gateway proxy portuna bağlar. Veritabanı kaynağının `Port` alanı ise başka bir şeydir: veritabanının kendi portudur (PostgreSQL için 5432) ve proxy arka uca ulaşmak için bunu kullanır. Buraya proxy portunu yazmak proxy'nin kendini aramasına ve bağlantıların başarısız olmasına yol açar.
> İpucu: bir bağlantı `Gateway not found` ile başarısız olursa sırayı baştan izleyin. Kaynakta ya da politikasında açıkça seçilmiş bir gateway var mı? Kaynak bir sitede mi? O sitenin `Gateways` rozeti etkin bir gateway gösteriyor mu ve bu gateway gereken bağlantı türünde mi?
Bir Monopam kurulumu **tek veritabanı, tek Redis ve tek vault anahtarı** demektir. Yine de birden çok uygulama sunucusunda çalışabilir. Örneğin bir hizmet sağlayıcı çoğu müşteri için bir ana sunucu tutar ve büyük bir müşteri için özel bir sunucu ekler. Bir isteğin kiracısı yalnızca isteğin ana bilgisayar adından türetilir ve açılmış bir oturum, verildiği kiracıya bağlıdır.
Her uygulama sunucusunun ortam değişkenlerinde ayarlanan iki bağımsız listesi vardır:
| Ayar | Neye karar verir | Yanlışsa |
| --- | --- | --- |
| `MONOPAM_SERVED_TENANTS` | Bu sunucunun hangi kiracıların web isteklerini yanıtladığına | Liste dışındaki bir kiracıya eşlenen ana bilgisayar, kiracının bu sunucuda sunulmadığını söyleyen bir sayfa alır |
| `MONOPAM_JOB_TENANTS` | Bu sunucunun hangi kiracılar için arka plan işlerini çalıştırdığına: rotasyon, uyarılar, eşitlemeler, ajan güncellemeleri | İki sunucuda yer alan kiracının işleri iki kez çalışır. Hiçbir sunucuda yer almayan kiracının işleri kuyrukta bekler |
| `MONOPAM_VAULT_KEY` | Vault verisini çözen anahtara | Farklı anahtarlı sunucu çözemez, bağlantılar başarısız olur |
::diagram pam-multi-server
İlk ikisi bilerek ayrıdır. Bir kiracıyı sunmak o sunucunun işlerini de çalıştırması anlamına gelmez; tersi de geçerlidir.
### Örnek
Sağlayıcı "acme" kiracısı için B sunucusunu ekler ve acme'nin DNS'ini ona yönlendirir.
1. Kullanıcılar "Tenant 'acme' is not served by this server." görür. Veritabanı ve Redis sağlıklıdır. B sunucusu acme'yi `MONOPAM_SERVED_TENANTS` içinde listelemiyordur. Ekleyin.
2. Bir hafta sonra acme'nin parolaları iki kez döner ve uyarı e-postaları çift gelir. A sunucusu acme'yi hâlâ `MONOPAM_JOB_TENANTS` içinde tutuyor, B sunucusu da artık listeliyor. Bir kiracının işleri **tam olarak bir** sunucuda olmalıdır. Birinden çıkarın.
3. Her iki sunucu ve her gateway aynı `MONOPAM_VAULT_KEY` değerini taşımalı ve aynı Redis'e ulaşmalıdır. Sunucudan sunucuya değişen kısım iki kiracı listesidir.
### Özel veritabanının vermediği şey
Bir kiracıya kendi veritabanı verilebilir. Müşteriler bunu bazen verileri ile kurulumun diğer uygulama sunucuları arasında bir güvenlik duvarı olarak yorumlar. Öyle değildir: vault anahtarı ve kontrol düzlemi tüm kurulumca paylaşılır. Konu açıldığında bunu açıkça söyleyin. Bu tür bir ayrım isteyen müşterinin ayrı bir kuruluma ihtiyacı vardır.
### Önce neye bakılır
| Belirti | Önce bakılacak yer |
| --- | --- |
| Sayfa, kiracının bu sunucuda sunulmadığını söylüyor | Ana bilgisayar adının gösterdiği sunucudaki `MONOPAM_SERVED_TENANTS` |
| Rotasyonlar ya da uyarı e-postaları iki kez gerçekleşiyor | Her sunucudaki `MONOPAM_JOB_TENANTS`: kiracı iki sunucuda listelenmiş |
| Bir kiracının işleri kuyrukta bekliyor | `MONOPAM_JOB_TENANTS`: kiracı hiçbir sunucuda listelenmemiş |
| Bağlantılar yalnızca bir sunucu ya da gateway üzerinden başarısız | Oradaki `MONOPAM_VAULT_KEY` diğerlerinden farklı |
Monofor ajanı bir Windows, Linux ya da macOS ana bilgisayarında çalışır ve hesap keşfi, betik çalıştırma gibi yerel işlemleri sunar. Ömrünün dört anı yönetici kararı gerektirir.
::diagram pam-agent-lifecycle
### 1. Kayıt
`Import Resource with Agent`, içine bir **kurulum anahtarı** gömülü tek satırlık bir kurulum betiği üretir. Anahtar 24 saat geçerlidir ve birçok makineyi kaydedebilir. Betiği elinde tutan ve Monopam'e ulaşabilen herkes, anahtarın süresi dolana kadar kiracınıza makine kaydedebilir. Bu yüzden betiğe kimlik bilgisi gibi davranın: kurulumu yapan kişiye verin, wiki'ye koymayın, bir sonraki sefer yenisini üretin.
### 2. Bağlantı
| Yol | Yön | Ne zaman |
| --- | --- | --- |
| Agent Channel | Ajan Monopam'i arar ve bağlantıyı açık tutar. Monopam istekleri bu bağlantıdan gönderir | Her zaman tercih edilir. NAT arkasında ve gelen güvenlik duvarı kuralı olmadan çalışır |
| Gelen dinleyici | Bir gateway ajanı arar | Yedek yol, yalnızca gateway ana bilgisayara ulaşabiliyorsa |
`Agents` sayfasındaki `Connection` sütunu o andaki durumu `Channel` ya da `Inbound` olarak gösterir.
### 3. Güven
Monopam'den ajana giden her istek imzalıdır. Ajan, kayıt sırasında Monopam'in açık anahtarını sabitler ve her imzayı, bir zaman damgasını ve tek kullanımlık bir sayıyı denetler; bu yüzden çalınmış bir ajan API anahtarı tek başına ajanı yönetemez. İki işletim sonucu:
- **Saatler.** Ajan ve sunucu saatleri arasındaki fark en çok 300 saniye olabilir. Kayıt başarılı olduğu hâlde yeni kaydedilmiş bir ajan her şeye 401 yanıtı veriyorsa önce iki uçtaki zaman eşitlemesine bakın.
- **Geri yüklemeler.** Monopam'in özel imzalama anahtarı, uygulamanın veri koruma anahtarıyla korunur. Monopam'i bu anahtar olmadan yeni bir ana bilgisayara geri yüklerseniz imzalama anahtarı okunamaz, yenisi üretilir ve her ajan yeniden kaydedilene kadar onu reddeder. Veri koruma anahtarını yedekleme planınıza alın.
### 4. Güncellemeler
Satırdaki `Update agent` ya da `Update all agents`, ajanlara hangi sürümü kuracaklarını söyler. Ajan paketi indirir, sağlama toplamını doğrular, kendi ikili dosyasını değiştirir ve yeniden başlar. Yapılandırmaya ve kayda dokunulmaz, hiçbir şey kendiliğinden güncellenmez.
İki şeyi planlayın. Filo güncellemesi kiracı başına her 30 saniyede beş ajan hızında ilerler; yüz ana bilgisayar yaklaşık on dakika sürer. Ayrıca her ajan birkaç saniyeliğine yeniden başlar; o anda ajan üzerinden yürüyen bir işlem başarısız olur ve yeniden denenmelidir. `config.json` dosyasında `"AllowUpdate": false` olan bir ajan reddeder ve bunu iş sonucunda bildirir: ayarı ana bilgisayarda değiştirin ya da kurulum programıyla güncelleyin.
### Önce neye bakılır
| Belirti | Önce bakılacak yer |
| --- | --- |
| Yeni kaydedilen ajan her şeye 401 yanıtı veriyor | İki uçta saat eşitlemesi: saatler 300 saniye içinde olmalıdır |
| Yeni ana bilgisayara geri yüklemeden sonra her ajan Monopam'i reddediyor | Veri koruma anahtarı geri yüklenmemiş, bu yüzden yeni bir imzalama anahtarı üretilmiş. Ajanlar yeniden kaydedilmelidir |
| Bir ajan `Update agent` işlemini reddediyor | `config.json` dosyasındaki `"AllowUpdate": false`. İş sonucu bunu belirtir |
| Filo güncellenirken bir işlem başarısız oldu | Ajan o anda yeniden başlıyordu. İşlemi yeniden çalıştırın |