NixOS ve gizli değerler

 (isabelroses.com)
1 puan yazan GN⁺ 2 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • NixOS'ta gizli değerleri Nix yapılandırmasında, özel Git deposunda veya git-crypt içinde düz metin olarak tutarsanız Nix store herkes tarafından okunabildiği için makineye erişimi olan kişiler bu gizli değerleri okuyabilir
  • sops-nix, .sops.yaml kuralları ve sops düzenleme akışıyla gizli değer dosyalarını şifreler; etkinleştirme sırasında ana makinenin SSH anahtarıyla çözüp düz metni /run/secrets/<name> altındaki tmpfs içinde tutar
  • agenix, secrets.nix içinde her gizli değer için alıcı açık anahtarlarını tanımlar ve .age dosyalarını /run/agenix/<name> altındaki tmpfs içinde çözer; yeni ana makine eklerken veya anahtar değiştirirken yeniden anahtarlama gerekir
  • Gizli değerleri doğrudan dosya sisteminde tutma yöntemi tek sunucu veya dizüstü için mümkün olabilir; ancak builtins.readFile "/var/lib/myservice/token" gibi değerlendirme anında okursanız değer Nix store içine gireceği için bundan kaçınılmalıdır
  • Yeni başlıyor ve yalnızca birkaç bağımsız token kullanıyorsanız agenix daha az prosedür gerektirir; posta sunucusu gibi ilişkili çok sayıda gizli değeri olan bir ana makinede ise birçok değeri tek dosyada toplamak için sops-nix daha uygundur

NixOS'ta gizli değerleri yönetirken temel risk

  • NixOS'ta gizli değer yönetimi; sops-nix, agenix/ragenix, dosya sistemini kullanma, özel Git deposu, git-crypt ve doğrudan Nix yapılandırmasına yazma yaklaşımlarına ayrılır
  • Özel Git deposu, git-crypt ve doğrudan Nix yapılandırmasına yazma yöntemleri; makineyi paylaşıyorsanız veya yapılandırmayı yayımlamayı planlıyorsanız kullanılmamalıdır
  • Yayımlanmış yapılandırmalarda gizli değerlerin en az iki kez sızdığı görüldü; örnekler 1, 2 bağlantılarında duruyor

sops-nix

  • sops-nix, ilk bakışta kurulumu zor görünebilse de belgeleri büyük ölçüde iyileşti; ayrıca sopsun varsayılan olarak SSH anahtarlarıyla gizli değer şifreleme ve çözmeyi desteklemeye başlaması önemli bir gelişme
  • Ancak sops-nix, bu SSH anahtarı desteğinde hâlâ geride ve ilgili çalışmalar sops-nix#779 ile sops-nix#922 içinde sürüyor
  • Kullanım akışı, .sops.yaml içinde şifreleme/çözme kuralları oluşturup gizli değer dosyalarını sops komutuyla düzenlemeye dayanır
    • Örneğin secrets/*.yaml yolu için age alıcısı olarak SSH açık anahtarı tanımlanabilir
    • sops secrets/shush.yaml komutunu çalıştırdığınızda seçtiğiniz düzenleyici açılır ve hello: sops gibi YAML değerleri yazabilirsiniz
    • Düzenleyiciden çıktığınızda değerler ENC[AES256_GCM,...] biçiminde şifrelenir ve aynı komutla yeniden düzenlenebilir
  • NixOS yapılandırmasında işin çoğunu sops-nix modülü üstlenir
    • defaultSopsFile = ./secrets/shush.yaml; ile varsayılan gizli değer dosyası tanımlanır
    • age.sshKeyPaths = [ "/etc/ssh/ssh_host_ed25519_key" ]; ile ana makinenin SSH anahtarı belirtilir
    • secrets."hello" altında owner, group, mode tanımlanarak dosya izinleri ayarlanır
  • Etkinleştirme sırasında sops-nix, ana makinenin SSH anahtarıyla dosyayı çözer ve düz metni /run/secrets/<name> altında tutar
    • Bu yol tmpfs üzerinde olduğu için gizli değerler diske yazılmaz
    • Değere ihtiyaç duyan servisler ilgili yolu okuyabilir
  • Şablon özelliği, paylaşılan yapılandırmalarda veya başka kullanıcıların başvurduğu ayarlarda kullanışlıdır
    • Bir servis yapılandırma dosyası düz metinle birlikte bazı gizli değerler gerektiriyorsa tüm dosyayı şifrelemeniz gerekmez
    • Örneğin SMTP_USER=isabel düz metin kalabilirken, SMTP_PASSWORD=${config.sops.placeholder."mailserver/smtp_password"} gibi bir gizli değer yer tutucusu eklenebilir

agenix

  • agenix, sops-nixten farklı olarak gizli değerleri ve erişebilen anahtarları secrets.nix içinde tanımladığı için Nix'e daha yakın bir kullanım hissi verir
  • secrets.nix içinde kullanıcı ve ana makine SSH açık anahtarları bağlanır ve her .age dosyasına hangi açık anahtarların erişebileceği belirtilir
    • Örneğin "secret1.age".publicKeys = [ isabel host1 ];, "secret2.age".publicKeys = [ isabel host2 ]; gibi her gizli değer için farklı alıcı listeleri tanımlanabilir
  • Gizli değer dosyaları agenix CLI ile oluşturulmalıdır
    • agenix -e secret1.age komutuyla secret1.age oluşturabilir veya daha sonra yeniden düzenleyebilirsiniz
  • Ana makine yapılandırmasına bağlama yöntemi sops-nixe benzer; ancak her gizli değer ayrı dosya olduğundan görünür yüzeyi daha küçüktür
    • age.secrets.secret1.file = ./secrets/secret1.age; ile dosya belirtilir
    • owner, group, mode ile sahiplik ve izinler tanımlanır
  • Açılışta ana makinenin SSH anahtarıyla her .age dosyası çözülür ve /run/agenix/<name> altına yerleştirilir
    • Bu yol da tmpfs üzerindedir
  • En sık takılan nokta yeniden anahtarlama (rekeying) sürecidir
    • Yeni bir ana makine eklendiğinde veya anahtar değiştirildiğinde, secrets.nix içinde publicKeys listesi değişen tüm gizli değerlerin yeniden şifrelenmesi gerekir
    • agenix --rekey bunu yapar; ancak mevcut şifreli içeriği okuyabilmek için mevcut alıcılardan birinin özel anahtarı gerekir
    • Pratikte yeniden anahtarlama, eklenecek yeni ana makinede değil, en çok güvendiğiniz makinede yapılır

Yalnızca dosya sistemini kullanma yaklaşımı

  • Gizli değerleri doğrudan dosya sisteminde tutmak, yapılandırmanın artık makineyi tamamen tanımlayamaması gibi bir maliyet doğurur
  • Yeniden kurulumda tüm dosyaları doğru konum ve sahiplikle tekrar yerleştirmeniz gerekir
    • Özellikle sabaha karşı 2'de sunucu kurtarma gibi senaryolarda bu, kurtarma sürecini felakete çevirebilir
  • Kaçınılması gereken desen builtins.readFile "/var/lib/myservice/token" gibi kullanımlardır
    • Bu yöntem dosyayı değerlendirme anında okur ve içeriği Nix store içine dahil eder
    • Nix store herkes tarafından okunabildiğinden, bu durum başta uyarılan başarısız yöntemle tamamen aynıdır
  • Bunun yerine servise değerin kendisini değil, yolu vermek gerekir
  • Tek bir sunucu veya dizüstünde kabul edilebilir olabilir; ancak bir filo yönetiyorsanız ya da yalnızca yapılandırmadan sıfırdan yeniden kurmak istiyorsanız sops-nix veya agenix daha uygundur
  • Makine başına gerçekten depoya koyulmaması gereken bir veya iki değer varsa işe yarayabilir; ancak bunları ileride tekrar yerleştirme sorumluluğu gelecekteki size kalır

sops-nix ve agenix karşılaştırması

  • sops-nixi seçmenin başlıca nedeni, mümkün olduğunca çok veriyi tek dosyada toplayabilmesidir
    • Posta sunucusu gibi ilişkili çok sayıda gizli değer olduğunda, agenixteki gibi yaklaşık 5 ayrı dosyaya bölmek yerine daha fazla değeri tek dosyada tutabilirsiniz
    • Güçlü bir araç olarak uzun süre kullanıma uygundur ve posta sunucusu gibi çok sayıda gizli değeri olan ana makinelerde önce düşünülmesi gereken seçenektir
  • agenix, basitlik konusunda öne çıkar
    • Öğrenmeniz gereken bir YAML şeması yoktur
    • Eşzamanlı tutmanız gereken bir .sops.yaml yoktur
    • secrets.nix doğrudan Nix olduğu için, ana makine ve kullanıcılar için kullandığınız let ... in bağlamalarını anahtarlar için de aynen kullanabilirsiniz
    • Zihinsel model “bir gizli değer, bir dosya, bir alıcı listesi” şeklindedir ve erişim kontrolü yaklaşımıyla iyi örtüşür
    • Hareketli parça sayısı en az düzeyde kalırken ana makine bazlı anahtar erişim kontrolü sunduğu için, NixOS makinelerinde gizli değer yönetimine yeni başlayanlara önerilmesi kolay bir seçenektir
  • Her iki araç da sorunu çözer; bugün farkların çoğu kullanılabilirlik düzeyindedir
    • Yeni başlıyor ve birden fazla servis ilişkili gizli değer kümeleri gerektiriyorsa sops-nix daha iyi ölçeklenir
    • Yeni başlıyor ve çoğunlukla yalnızca birkaç bağımsız token varsa agenix, amaca daha az prosedürle ulaştırır
    • İlk gizli değer aracınızı seçiyorsanız, akışa alışmak için agenix ile başlamak ve “her gizli değer için bir dosya” yaklaşımının rahatsızlığını gerçekten hissettiğiniz noktada sops-nixe geçmek daha mantıklıdır
  • Kuantum dayanımıyla ilgili kısım düzeltilmiştir
    • age ve sops, kuantum dayanımlı güvenli şifreleme anahtarlarını destekler
    • age#578 kapatıldı ve v1.3.0 yayımlandı
    • age anahtarı oluştururken -pq eklemeniz yeterlidir; örnek: age-keygen -pq -o key.txt

İlgili okumalar

1 yorum

 
GN⁺ 2 시간 전
Lobste.rs görüşleri
  • sops-nix ve agenix'in çözülen gizli değerleri diske kaydetmediği açıklamasını gördüm ama bunun pratikte ne fayda sağladığını merak ediyorum
    Şifrelenmiş gizli değer ile onun anahtarı ikisi de diskte değil mi? Yoksa bunlardan biri TPM gibi bir yerde mi tutuluyor?
    Nix kullanmaya daha yeni başladım ve küçük self-hosting dağıtımlarında basit olduğu için dosya sistemine scp ile atma yöntemini kullanıyorum
    Biraz bakınınca SSH özel anahtarını TPM ile korumanın mümkün göründüğünü fark ettim; VM'de de olur mu diye merak ediyordum ama vTPM desteği olabileceğini görünce kendi soruma cevap vermiş oldum
    • Ben sunucularımda sops-nix kullanıyorum; benim tehdit modelim için yeterli ve iyi çalışıyor. Şimdi SSH özel anahtarlarını TPM'de tutma yöntemini merak etmeye başladım
      Sunucu tarafında NixOps erişimi de var. Colmena'nın bunu nasıl yaptığına bakabilirsin: https://colmena.cli.rs/0.4/features/keys.html
      Özünde, gizli değerleri barındıran güvenilir bir makinenin bunları uzak sunucuya itmesi söz konusu. Şu an scp ile yaptığın şeye benziyor ama süreci daha Nix usulü çalıştırıyor
    • En sevdiğim ifadeyi kullanma zamanı geldi. “Duruma bağlı!” Burada gizli değer yönetimi aynı anda iki sorunu ele alıyor: diskte duran gizli dosyaları korumak ve sistemi derlemek için kullanılan yapılandırmadaki gizli değerleri korumak. Sonuçta bu değerler bir yerde bulunmak zorunda
      Son birkaç gecemi kendi sistem flake'imde agenix türü yapıyı yeniden kurmaya ayırdığım için yalnızca agenix hakkında konuşabilirim. İlgilenenler için agenix-rekey seçtim; çünkü gizli değerler içeren .yml dosyaları bulundurmak gerekmiyor ve sende zaten olduğu gibi tüm gizli değerleri doğrudan Nix içinde ayarlayabiliyorsun
      Şifrelenmiş gizli değerler Nix store'da bulunur ve Nix store'daki diğer her şey gibi herkes tarafından okunabilir. Bu gizli değerleri çözen SSH özel anahtarı genelde gerçek SSH sunucusunun özel anahtarıdır; istenirse böyle olmayacak şekilde de ayarlanabilir. Gizli değerler etkinleştirme anında, aşağı yukarı önyükleme sırasında çözülür ve /run/agenix/<user> içine yerleştirilir
      secrix adlı araç bunu daha da ileri götürüp gizli değerleri bir systemd servisine bağlar; sonra da o servisi gizli değerlere ihtiyaç duyan servise bağlar. Böylece gizli değerler yalnızca ilgili servis çalışırken çözülür. Ama pratikte NixOS kullanıcıları servisleri sık sık açıp kapatmadığı için çoğu zaman bu, servislerin sürekli çalıştığı anlamına gelir. Kullanıcı oluşturma gibi sistem etkinleştirmesi için gereken gizli değerlerde işe yarayabilir
      agenix-rekey, yeniden anahtarlamayı daha az can sıkıcı hale getirir ve secrets.nix yerine flake çıktıları koyar. Anahtarın bir yarısı olarak YubiKey bölünmüş kimliği kullanır. Yeniden anahtarlama; o anahtar ve diğer yarıyla kimlik doğrulayıp gizli değerleri çözmek, ardından sunucunun SSH açık anahtarıyla onları yeniden anahtarlamak sürecidir. Açık anahtarlar sistem kurulurken üretilir; ben nixos-anywhere içinde --copy-host-keys kullanarak kurulum closure'ında üretilen anahtarları alıyorum. Şifrelenmiş gizli değerleri depoda tutuyorum ama yalnızca güvenilir builder'ların erişebildiği ayrı bir submodule içinde
      Bu arada vTPM genelde donanım tabanlı değildir ve birçok sağlayıcı TPM sunsa bile çoğu zaman TPM v2 değil TPM v1.2 sunar. Benim sağlayıcım BinaryLane de böyle. Elbette ek bir güvenlik katmanı sağlar ama gerçek bir HSM gibi sihirli değildir; sağlayıcının ya da host düğümünün ele geçirilmesine karşı koruma sağlamaz. Gerçek HSM tabanlı vTPM sunabilmek sağlayıcı açısından muhtemelen çok maliyetlidir; AWS ise bunu AWS fiyatlarıyla sunuyor gibi görünüyor
    • Ben agenix + agenix-rekey + age-plugin-1p kullanıyorum
      Ana anahtarım 1Password içinde olduğu için dizüstü bilgisayarımın diskinde hiçbir kimlik bilgisi tutmadan herhangi bir sunucunun parolalarını düzenleyebiliyor, görüntüleyebiliyor ve yeniden anahtarlayabiliyorum
      Çalışma zamanında anahtarlara erişmesi gereken sunuculara yetki verebilirsin. agenix-rekey'e o sunucunun hangi anahtarları görebileceğini söylersin ve agenix rekey çalıştırırsın; sonra ilgili sunucunun çözebileceği şifreli anahtar sürümü Nix store'a yazılır. O sunucunun SSH özel anahtarı yalnızca o sunucuda bulunur ve asla dışarı çıkmaz. agenix-rekey yeniden anahtarlama için yalnızca açık anahtara ihtiyaç duyar
      Dolayısıyla gizli değerlerin ele geçirilmesi ya 1Password hesabımın hacklenmesiyle ya da o gizli değerleri kullanan sunucunun ele geçirilmesiyle olur
    • Agenix varsayılan olarak şifreli gizli değerleri /etc/ssh/ssh_host_ed25519_key ile çözüp /run/agenix.d üzerine bağlanmış ramfs içine koyar
      Yani evet. Şifreli içerik, şifreleme anahtarı ve çözülmüş içerik dosya sistemi üzerinden erişilebilir durumda olur
    • Böyle yapınca tüm NixOS yapılandırmasını herkese açık biçimde de paylaşabilirsin. Bunu yapan çok kişi yok ama bence Nix'in vaadinin yarısı, başkalarının da sistemindeki sorunları seninle birlikte debug edebilmesi
  • agenix ve agenix-rekey'i denemeyi düşünüyordum sadece. Birçok kişinin bahsettiği sıkıntılı noktaları epey azaltacak gibi görünüyor ama henüz denemedim
    https://github.com/oddlama/agenix-rekey
  • agenix ile kimlik bilgilerini yönetiyordum ama sonra düz dosya sistemi yaklaşımına geri döndüm. Daha basit ve benim için yeniden kurulum da nadir olduğu için daha uygun
    Üstelik uzun ömürlü kimlik bilgileri de giderek azalıyor. Uzun süreli kimlik bilgisi kopyalama modelinden uzaklaşıp donanım tabanlı kimlik bilgilerine geçiyorum; bunları ya doğrudan kullanıyorum ya da kısa ömürlü kimlik bilgileriyle takas ediyorum