HTTPS ve Sertifikalar

Bağlı bir cihazdaki bir uygulama bir web arayüzü sunduğunda, appliance bunu yerleşik tüneli üzerinden erişilebilir kılar. Tarayıcıların appliance’a nasıl ulaşacağını siz seçersiniz — sıfır kurulumdan tamamen kurumsal imzalıya kadar üç mod vardır. Birini seçin ve adımlarını izleyin.

Kurumsal Proxy Arkasında ile aynı şey değildir. O sayfa, appliance’ın giden trafik için kurumsal CA’nıza güvenmesiyle ilgilidir (appliance → bulut, TLS’i araya girip inceleyen bir proxy üzerinden). Bu sayfa ise tam tersi yöndedir — ağınızdaki tarayıcılardan appliance’a ulaşan gelen trafik. İkisi birbirinden bağımsızdır.

Mod 1 — Düz HTTP (varsayılan)

Ne elde edersiniz. Her şey appliance’ın adresi üzerinden düz HTTP ile:

Her uygulama arayüzü kendi otomatik atanmış portunda yayımlanır; IronFlock arayüzü her biri için tam bağlantıyı gösterir. Uygulama arayüzleri appliance girişinin arkasında kalır — birini açmak, o cihaz için oturum açıp yetkili olmadığınız sürece girişe yönlendirir (açık olmasını istediğiniz yerde bir port, uygulama başına herkese açık olarak işaretlenebilir).

Ne yapmanız gerekir. Hiçbir şey. Bu varsayılandır — yerel ağınızda appliance’ın IP’sini veya ana makine adını kullanmanız yeterlidir. DNS yok, sertifika yok, kurumsal BT’nin dahli yok.

Ne zaman kullanılır. Güvenilir, bölümlere ayrılmış bir ağdaki bir appliance — bir makine/OT VLAN üzerindeki bir kumanda panosu — burada düz HTTP normdur ve erişim, ağ bölümlemesi ile fiziksel güvenlik tarafından denetlenir.

Mod 2 — Kendinden imzalı bir CA ile HTTPS

Ne elde edersiniz. Appliance, yerleşik HTTPS ingress’ini açar ve her şeyi alan adınız altında HTTPS ile sunar — kendi ürettiği bir sertifika kullanarak. Çalıştırılacak bir ters proxy ve yeniden yönlendirilecek URL yoktur; yükleyici her şeyi bağlar.

Ne yapmanız gerekir.

1. Kullanacak her tarayıcı ve cihaz için appliance’a çözümlenen bir alan adı seçin ve hem APPLIANCE_HOST hem de APPLIANCE_DOMAIN’i buna ayarlayın. Appliance sertifikayı kendisi verdiği için herhangi bir ad işe yarar — tek gereksinim çözümlenmesidir. Hızlı bir testin ötesindeki her şey için, kendi DNS’inizde bir wildcard kaydıyla kontrol ettiğiniz dahili bir alan adı kullanın (örneğin appliance.corp.example.com): yalıtılmış veya DNS kısıtlamalı bir appliance ağı genellikle varsayılan <host-ip>.nip.io adının dayandığı herkese açık nip.io hizmetine ulaşamaz. (Bu varsayılan, ağın internete ulaşabildiği yerlerde işe yarar — bu yüzden bir geliştirici makinesinde çalışır.)

2. Alan adı için wildcard DNS ekleyin, her iki kayıt da appliance ana makine IP’sine işaret etsin:

   • *.<APPLIANCE_DOMAIN> — uygulama arayüzlerini ve her hizmet alt alan adını kapsar.
   • <APPLIANCE_DOMAIN> (apex) — ana arayüz, adıyla.

   (nip.io gibi bir wildcard-DNS hizmeti bunları zaten otomatik olarak çözümler, dolayısıyla eklenecek kayıt yoktur — ancak bu, o harici hizmetin erişilebilir olmasına bağlıdır.)

3. --tls ile kurun:

   curl -fsSL https://instance-registry.ironflock.com/dl/appliance/install_ironflock.sh \
     | sudo bash -s -- <your-instance-key> --interactive --tls

   --interactive, APPLIANCE_HOST / APPLIANCE_DOMAIN için sorar (veya müdahalesiz kurulum için IRONFLOCK_APPLIANCE_HOST / IRONFLOCK_APPLIANCE_DOMAIN’i ayarlayın). Appliance, /opt/ironflock/certs/ca/rootCA.crt konumunda yerel bir CA ve onunla imzalanmış bir wildcard sertifika üretir.

4. CA kökünü istemci makinelere dağıtın. rootCA.crt’yi MDM’niz üzerinden dağıtın veya her makinenin işletim sistemi/tarayıcı güven deposuna ekleyin. Bir makine ona güvenene kadar tarayıcısı uyarı verir.

5. Bir yıl içinde yenileyin. Sunucu sertifikası ~1 yılla sınırlıdır — tarayıcılar daha uzun ömürlü olanları reddeder. Yenilemek için sertifika dizinindeki tls.crt/tls.key dosyalarını silin ve yükleyiciyi yeniden çalıştırın; aynı CA’ya karşı yeni bir sertifika yeniden imzalar, böylece dağıttığınız güven çalışmaya devam eder.

Cihazlar düz IP yolunda kalır. Yalnızca tarayıcı tarafı HTTPS’e geçer. Bağlı cihazlar appliance’a IP’si üzerinden ulaşmaya devam eder, bu yüzden CA’yı her cihaza kurmak zorunda değilsiniz.

Ne zaman kullanılır. Paylaşılan bir ağda HTTPS istiyorsunuz ama kurumsal BT’den bir sertifikaya sahip değilsiniz (veya beklemek istemiyorsunuz) ve arayüzü açacak makinelere bir kök CA dağıtabilirsiniz.

Mod 3 — Kurumsal sertifikanızla HTTPS

Ne elde edersiniz. Mod 2’deki ile aynı tam-appliance HTTPS’i — ancak sertifika, kökü her yönetilen makinede zaten güvenilir olan kuruluşunuzun CA’sından gelir. Tarayıcı uyarısı yok, dağıtılacak bir şey yok. Cihazlar da alan adına geçer.

Ne yapmanız gerekir.

1. Kontrol ettiğiniz dahili bir alan adı seçin ve APPLIANCE_HOST ile APPLIANCE_DOMAIN’i buna ayarlayın (örneğin appliance.corp.example.com). Burada bu mutlaka kendi alan adınız olmalıdır — bir CA yalnızca sahip olduğunuz alan adları için sertifika verir, bu yüzden bu modda bir nip.io adı işe yaramaz.
2. Wildcard DNS ekleyin — *.<APPLIANCE_DOMAIN> ve apex, appliance ana makine IP’sine işaret etsin — Mod 2, adım 2’deki gibi.
3. Dahili CA’nızdan *.<APPLIANCE_DOMAIN> için iki PEM dosyası olarak bir wildcard sertifika alın: tls.crt (tercihen tam zincir) ve şifrelenmemiş bir tls.key.
4. Sertifikanızla kurun:

   curl -fsSL https://instance-registry.ironflock.com/dl/appliance/install_ironflock.sh \
     | sudo bash -s -- <your-instance-key> --interactive \
         --tls-cert /path/to/wildcard.crt \
         --tls-key  /path/to/wildcard.key

   --tls-cert, --tls’i ima eder. Eşdeğer ortam değişkenleri: IRONFLOCK_TLS_CERT / IRONFLOCK_TLS_KEY.
5. CA’nızın takvimine göre rotasyon yapın. Yeni PEM dosyalarını sertifika dizinine bırakın ve yeniden başlatın:

   sudo cp wildcard.crt /opt/ironflock/certs/tls.crt
   sudo cp wildcard.key /opt/ironflock/certs/tls.key
   sudo chmod 0600 /opt/ironflock/certs/tls.key
   sudo systemctl restart ironflock.service

   Appliance, dosya değiştiğinde sertifikayı otomatik olarak yeniden yükler; yeniden başlatma yalnızca onu hemen uygular. Yükleyiciyi yeniden çalıştırmak, --tls-cert geçmediğiniz sürece mevcut bir sertifikanın üzerine asla yazmaz.

Cihazlar da alan adına geçer. Sertifika filo genelinde güvenilir olduğundan, cihaz trafiği — cihaz bağlantısı, kapsayıcı görüntü çekmeleri ve cihaz aracısı güncellemeleri — de alan adı üzerinden TLS ile çalışır ve insecure-registries geçici çözümüne artık gerek kalmaz. Bu, geçişten sonra derlenen uygulama imajları için geçerlidir; geçişten önce kurulmuş uygulamalar derlendikleri registry adresini korur; 0.21.3 ve sonrası cihaz aracıları bu adresi kendileri çözümler — aşağıdaki 4. gereksinime bakın.

Bu modda bağlı cihazların ihtiyaç duyduğu şeyler

Appliance’a bağlanan her uç cihazın şunları yapması gerekir:

1. Alan adını çözümlemek. <APPLIANCE_DOMAIN> ve alt alan adları (wildcard kaydı), cihazın ağından appliance’ın IP adresine çözümlenmelidir — tarayıcılara hizmet eden aynı DNS kayıtları.
2. Appliance’a 443 portu üzerinden ulaşmak — cihazların platform bağlantısı, cihaz aracısı güncellemeleri (https://registry.<APPLIANCE_DOMAIN>/dl adresinden sunulur — bu modda 15002 portuna gerek yoktur) ve geçişten sonra derlenen uygulama imajları için ihtiyaç duyduğu tek port (geçişten önce kurulmuş uygulamalar için 4. gereksinime bakın). Modu 3’ü kısıtlı ağlardaki cihazlar için doğru seçim yapan da budur: dışa doğru 443 neredeyse her yerde izinlidir ve bağlantı kurumsal bir HTTP proxy üzerinden de çalışır (proxy’yi aracıya Kurumsal Proxy Arkasında → Uç Cihazlar bölümünde anlatıldığı gibi verin). Buna karşılık basit modda cihazların appliance’ın birkaç servis portuna doğrudan erişmesi gerekir; kurumsal güvenlik duvarları ve proxy’ler bu portları sıkça engeller — bkz. Cihaz Bağlantısı.
3. Kurumsal kök CA’nıza güvenmek. Aracı ve Docker, appliance’ın sertifikasını cihazın işletim sistemi güven deposuna karşı doğrular:
   • Yönetilen makineler (etki alanına katılmış Windows, MDM ile yönetilen Linux) genellikle kurumsal kökünüze zaten güvenir — yapılacak bir şey yoktur.
   • Yönetilmeyen Windows: kök CA’yı yükseltilmiş bir komut isteminden makine deposuna kurun — certutil -addstore -f Root corporate-root-ca.crt — ardından Docker Desktop’ı (başlangıçta güvenilen kökleri Windows deposundan içe aktarır) ve aracı servisini (Restart-Service reagent) yeniden başlatın.
   • Linux: sudo cp corporate-root-ca.crt /usr/local/share/ca-certificates/ && sudo update-ca-certificates, sonra Docker’ı (sudo systemctl restart docker) ve aracıyı yeniden başlatın.
   • Uygulama konteynerleri bu güveni otomatik olarak devralır (aracı 0.21.3 ve sonrası). Bir konteyner yalnızca temel imajıyla gelen CA paketini taşır ve hiçbir temel imaj kurum içi kök sertifika içermez; bu nedenle appliance’a TLS ile bağlanan bir uygulama sertifikayı doğrulayamıyordu. Aracı artık cihazın kendi güven deposunu her uygulama konteynerine salt okunur olarak /etc/ironflock/certs/ca-bundle.crt yoluna bağlar ve yaygın çalışma zamanlarını buraya yönlendirir (SSL_CERT_FILE, REQUESTS_CA_BUNDLE, NODE_EXTRA_CA_CERTS). Yapılandırılacak bir şey yoktur; ancak aracının aktardığı şey cihazın güveni olduğundan, cihazın kök sertifikaya güveniyor olması gerekir. Kendi SSL_CERT_FILE değerini ayarlayan bir uygulama bu değeri korur.
4. Cihaz aracısını 0.21.3 veya sonrasına güncellemek — ya da geçişten önce kurulmuş uygulamaları yeniden yayınlamak. Bir uygulamanın saklanan compose dosyası, uygulama derlenirken sabitlenmiş tam nitelikli imaj referansları — <APPLIANCE_IP>:15001/apps/… — taşır. Bu referanslar veridir: appliance’ı bir alan adına taşımak hiçbir compose dosyasını yeniden yazmaz. 0.21.3 ve sonrası aracılar böyle bir referansı, cihazın kendisi için yapılandırılmış registry’ye çözümler; böylece geçişten önce kurulmuş bir uygulama hiçbir şey yapmadan alan adı üzerinden çalışmaya devam eder — güncellemeden sonraki ilk başlatma her imajı yeni adıyla bir kez çeker. Daha eski bir aracı referansı yazıldığı gibi kullanır ve eski IP ile portu aramayı sürdürür: uygulama yeniden derlenip registry.<APPLIANCE_DOMAIN> üzerinden yeniden yayınlanana kadar cihazının registry portuna (15001) yerel ağdan erişebilmesi gerekir ve tek başına 443 portu onun için yeterli değildir. Appliance kendi tarafını otomatik olarak halleder: kendi aracısı 0.21.3 öncesi olduğu ve böyle bir referans var olduğu sürece registry’yi yerel ağdan erişilebilir tutar ve etkilenen compose dosyalarını yükleyici çıktısında listeler. Aracı güncellendikten — ya da bu uygulamalar yeniden yayınlandıktan — sonra bir sonraki sudo ironflock-update bekleyecek bir şey bulamaz ve registry’yi kendiliğinden yerel ağdan çeker.

Ne zaman kullanılır. Standart kurumsal şirket içi yol: kuruluşunuz zaten dahili bir CA çalıştırıyor, böylece bir wildcard sertifika bir kez verilir ve makine başına hiçbir kurulum olmadan her yerde güvenilir olur.

Sorun Giderme

Bir uygulama arayüzü bağlantısı açılmıyor / bağlantı reddedildi. Düz modda uygulama arayüzleri http://<host>:<port> konumundadır — IronFlock arayüzünde gösterilen tam bağlantıyı kullandığınızdan (port, uygulama başına atanır) ve ağdaki hiçbir şeyin o portu engellemediğinden emin olun.

Tarayıcı sertifikanın güvenilir olmadığı uyarısını veriyor (--tls sonrası). İstemci henüz sertifikanın CA’sına güvenmiyor. Mod 2’de, appliance’ın ürettiği CA’yı (/opt/ironflock/certs/ca/rootCA.crt) istemciye dağıtın. Mod 3’te, istemcinin dahili CA kökünüze güvendiğinden emin olun.

Sertifika süresi doldu (kendinden imzalı). Kendinden imzalı bir sunucu sertifikası yaklaşık bir yıl geçerlidir (tarayıcılar daha uzun ömürlü olanları reddeder). Yenileyin: sertifika dizinindeki tls.crt/tls.key dosyalarını silin ve aynı, hâlâ güvenilir CA’ya karşı yeniden imzalamak için yükleyiciyi yeniden çalıştırın — veya kendi CA’nızdan bir --tls-cert’e geçin.

Sertifika adı uyuşmazlığı. Sertifika, kullanımdaki alan adı için bir wildcard değildir. *.<APPLIANCE_DOMAIN>’i kapsamalı ve URL’nin alan adı APPLIANCE_DOMAIN ile eşleşmelidir.

Bir alt alan adı çözümlenmiyor (--tls sonrası). Wildcard DNS eksik. Appliance ana makinesine işaret eden bir *.<APPLIANCE_DOMAIN> A kaydı ekleyin — uygulama arayüzlerini ve her hizmet alt alan adını kapsar.

Modu 3’e geçtikten sonra bir uygulama başlamıyor veya imajını çekemiyor — 15001 portunda “connection refused”. Uygulamanın compose dosyası registry’yi hâlâ appliance’ın IP adresiyle referans veriyor, çünkü ona karşı derlenmişti ve cihazın aracısı 0.21.3 öncesi — bu sürümden itibaren aracı böyle bir referansı kendi registry’sine kendisi çözümler. Cihaz aracısını güncelleyin ya da uygulamayı yeniden derleyip yeniden yayınlayın, böylece imajı registry.<APPLIANCE_DOMAIN> üzerinden çözümlenir. O zamana kadar registry’nin yerel ağdan erişilebilir kalması gerekir; bunu appliance kendisi ayarlar — sade bir sudo ironflock-update yerel ağ bağlamasını geri getirir ve hâlâ eski bir referans taşıyan compose dosyalarını adlandırır.

Bir uygulama çalışıyor ama hiç bağlanmıyor ve günlüğünde birkaç saniyede bir aynı bağlantı denemesi yineleniyor. Uygulamanın konteyneri appliance’ın sertifikasını doğrulayamıyor: TLS el sıkışması sunucu sertifikasının hemen ardından yarıda kesiliyor ve SDK sonsuza kadar yeniden deniyor. Aracı işletim sisteminin güven deposunu kullandığı, konteyner ise kullanmadığı için cihazın kendisi çevrimiçi kalır. Cihaz aracısını, cihazın güven deposunu uygulama konteynerlerine aktaran 0.21.3 veya sonrasına güncelleyin ve cihazın kurumsal kök sertifikanıza güvendiğini doğrulayın (yukarıdaki 3. gereksinim). Cihazda docker logs <konteyner> komutu sertifika doğrulama hatasını gösterir. Daha eski bir aracıda çözüm uygulama başınadır: kök CA’yı imaja ekleyin ya da bağlayıp uygulamanın compose dosyasında SSL_CERT_FILE değerini ayarlayın.

Modu 3’e geçtikten sonra bir cihaz bağlanmıyor. Yukarıdaki dört cihaz gereksinimini sırayla gözden geçirin: alan adı cihazın ağından çözümlenmeli, appliance’taki 443 portuna erişilebilmeli (doğrudan veya cihazın proxy’si üzerinden), cihaz kurumsal kök CA’nıza güvenmeli ve geçişten önce kurulmuş uygulamalar registry portuna ihtiyaç duymayı bırakmadan önce 0.21.3 aracısına ya da yeniden yayına ihtiyaç duyar. Windows’ta C:\ProgramData\IronFlock\Reagent\reagent.log (Linux’ta /var/log/reagent.log) konumundaki aracı günlüğü tam bağlantı hatasını gösterir — bir DNS hatası, bir zaman aşımı veya bir sertifika doğrulama hatası, her biri ilk üç gereksinimden birine işaret eder.