NixOS dan rahasia

 (isabelroses.com)
1 poin oleh GN⁺ 2 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Jika rahasia di NixOS disimpan dalam konfigurasi Nix, repositori Git privat, atau git-crypt dalam bentuk plaintext, Nix store dapat dibaca oleh siapa pun sehingga siapa pun yang memiliki akses ke mesin bisa membaca rahasia tersebut
  • sops-nix mengenkripsi file rahasia dengan aturan .sops.yaml dan alur edit sops, lalu saat aktivasi mendekripsinya dengan kunci SSH host dan menaruh plaintext di tmpfs pada /run/secrets/<name>
  • agenix menetapkan kunci publik penerima untuk tiap rahasia di secrets.nix, mendekripsi file .age ke tmpfs pada /run/agenix/<name>, dan memerlukan rekeying saat menambah host baru atau mengganti kunci
  • Pendekatan menaruh rahasia langsung di filesystem bisa dipakai untuk satu server atau laptop, tetapi jika dibaca pada waktu evaluasi seperti builtins.readFile "/var/lib/myservice/token", nilainya akan masuk ke Nix store sehingga harus dihindari
  • Jika baru memulai dan hanya punya beberapa token yang independen, agenix butuh prosedur yang lebih sedikit; jika host seperti mail server punya banyak rahasia yang saling terkait, sops-nix yang menggabungkan banyak nilai dalam satu file lebih cocok

Risiko dasar saat menangani rahasia di NixOS

  • Pengelolaan rahasia di NixOS umumnya terbagi ke sops-nix, agenix/ragenix, pemanfaatan filesystem, repositori Git privat, git-crypt, dan menuliskannya langsung ke konfigurasi Nix
  • Metode repositori Git privat, git-crypt, dan menulis langsung ke konfigurasi Nix tidak boleh dipakai jika mesin dibagi pakai atau jika Anda berencana memublikasikan konfigurasi
  • Rahasia setidaknya pernah bocor dua kali dari konfigurasi yang dipublikasikan, dan contohnya masih ada di 1, 2

sops-nix

  • sops-nix bisa terasa sulit dikonfigurasi saat pertama kali ditemui, tetapi dokumentasinya sudah jauh membaik dan peningkatan besar lainnya adalah sops kini mendukung enkripsi/dekripsi rahasia dengan kunci SSH secara bawaan
  • Namun sops-nix masih tertinggal dalam dukungan kunci SSH ini, dan pekerjaan terkait sedang berlangsung di sops-nix#779, sops-nix#922
  • Alur penggunaannya adalah membuat aturan enkripsi/dekripsi di .sops.yaml, lalu mengedit file rahasia dengan perintah sops
    • Contohnya, untuk path secrets/*.yaml, kunci publik SSH ditetapkan sebagai penerima age
    • Menjalankan sops secrets/shush.yaml akan membuka editor pilihan Anda, dan Anda bisa menulis nilai YAML seperti hello: sops
    • Saat editor ditutup, nilainya akan dienkripsi dalam bentuk ENC[AES256_GCM,...], dan bisa diedit lagi dengan perintah yang sama
  • Dalam konfigurasi NixOS, modul sops-nix menangani sebagian besar pekerjaan
    • defaultSopsFile = ./secrets/shush.yaml; menetapkan file rahasia default
    • age.sshKeyPaths = [ "/etc/ssh/ssh_host_ed25519_key" ]; menetapkan kunci SSH host
    • Di secrets."hello", owner, group, dan mode dapat ditetapkan untuk mengatur izin file
  • Pada saat aktivasi, sops-nix mendekripsi file dengan kunci SSH host dan menaruh plaintext di /run/secrets/<name>
    • Path ini berada di tmpfs, jadi rahasia tidak menyentuh disk
    • Layanan yang membutuhkan nilainya cukup membaca path tersebut
  • Fitur template berguna dalam konfigurasi bersama atau konfigurasi yang dirujuk pengguna lain
    • Jika file konfigurasi layanan membutuhkan plaintext dan sebagian nilai rahasia sekaligus, Anda tidak perlu mengenkripsi seluruh file
    • Misalnya, SMTP_USER=isabel bisa dibiarkan sebagai plaintext, lalu placeholder rahasia ditaruh seperti SMTP_PASSWORD=${config.sops.placeholder."mailserver/smtp_password"}

agenix

  • agenix, tidak seperti sops-nix, mengatur rahasia dan kunci yang boleh mengaksesnya di secrets.nix, sehingga terasa lebih dekat dengan gaya Nix
  • secrets.nix mengikat kunci publik pengguna dan host, lalu menetapkan kunci publik mana yang boleh mengakses tiap file .age
    • Misalnya, "secret1.age".publicKeys = [ isabel host1 ];, "secret2.age".publicKeys = [ isabel host2 ]; memungkinkan daftar penerima yang berbeda untuk tiap rahasia
  • File rahasia harus dibuat dengan CLI agenix
    • Perintah agenix -e secret1.age dapat digunakan untuk membuat secret1.age atau mengeditnya lagi nanti
  • Cara menghubungkannya ke konfigurasi host mirip dengan sops-nix, tetapi karena tiap rahasia adalah file terpisah, permukaannya lebih kecil
    • age.secrets.secret1.file = ./secrets/secret1.age; menetapkan file
    • owner, group, dan mode menetapkan kepemilikan dan izin
  • Saat boot, tiap file .age didekripsi dengan kunci SSH host dan ditaruh di /run/agenix/<name>
    • Path ini juga berada di atas tmpfs
  • Bagian yang paling sering menjadi hambatan adalah rekeying
    • Jika host baru ditambahkan atau kunci diganti, semua rahasia yang daftar publicKeys-nya berubah di secrets.nix harus dienkripsi ulang
    • agenix --rekey menangani ini, tetapi membutuhkan kunci privat dari salah satu penerima saat ini untuk membaca ciphertext yang ada
    • Dalam praktiknya, rekeying dilakukan pada mesin yang paling dipercaya, bukan pada host baru yang akan dinaikkan

Pendekatan yang hanya memakai filesystem

  • Menaruh rahasia langsung di filesystem punya biaya bahwa konfigurasi tidak lagi sepenuhnya menjelaskan mesin
  • Saat reinstall, semua file harus dikembalikan lagi ke lokasi dan kepemilikan yang benar
    • Dalam pekerjaan pemulihan, seperti saat memulihkan server pada pukul 2 pagi, ini bisa menjadi bencana besar
  • Pola yang harus dihindari adalah bentuk seperti builtins.readFile "/var/lib/myservice/token"
    • Cara ini membaca file pada waktu evaluasi dan memasukkan isinya ke Nix store
    • Karena Nix store dapat dibaca siapa pun, hasilnya persis sama dengan pola kegagalan yang diperingatkan di awal
  • Sebagai gantinya, yang diberikan ke layanan bukan nilainya langsung melainkan path-nya
  • Untuk satu server atau laptop ini mungkin cukup baik, tetapi jika Anda mengelola armada mesin atau ingin dapat membangun ulang dari nol hanya dari konfigurasi, sops-nix atau agenix lebih cocok
  • Jika tiap mesin hanya punya satu-dua nilai yang benar-benar tidak boleh masuk repositori, pendekatan ini masih bisa diterima, tetapi tanggung jawab untuk menaruhnya kembali nanti akan diwariskan kepada diri Anda di masa depan

Perbandingan sops-nix dan agenix

  • Alasan utama memilih sops-nix adalah kemampuannya menggabungkan sebanyak mungkin data ke dalam satu file
    • Untuk kasus seperti mail server yang memiliki banyak rahasia terkait, lebih banyak rahasia bisa diletakkan dalam satu file alih-alih dipecah menjadi sekitar lima file seperti pada agenix
    • Ini cocok untuk terus dipakai sebagai alat yang kuat, dan layak menjadi pilihan pertama pada host seperti mail server yang punya sangat banyak rahasia
  • agenix unggul dalam kesederhanaan
    • Tidak ada skema YAML yang perlu dipelajari
    • Tidak ada .sops.yaml yang harus disinkronkan
    • Karena secrets.nix hanyalah Nix biasa, binding let ... in yang Anda pakai untuk host dan pengguna bisa diterapkan apa adanya juga pada kunci
    • Model mentalnya adalah “satu rahasia, satu file, satu daftar penerima”, dan ini selaras dengan cara kerja kontrol akses
    • Karena jumlah komponen bergeraknya paling sedikit sambil tetap menyediakan kontrol akses berbasis kunci per host, ini adalah pilihan yang mudah direkomendasikan kepada orang yang baru pertama kali bertanya tentang pengelolaan rahasia di mesin NixOS
  • Kedua alat menyelesaikan masalah yang sama, dan perbedaannya saat ini kebanyakan terkait usability
    • Jika baru memulai dan beberapa layanan membutuhkan sekumpulan rahasia yang saling terkait, sops-nix lebih mudah diskalakan
    • Jika baru memulai dan sebagian besar hanya punya beberapa token independen, agenix mencapai tujuan dengan prosedur yang lebih sedikit
    • Jika memilih alat rahasia pertama, ada baiknya mulai dengan agenix untuk membiasakan diri dengan alurnya, lalu berpindah ke sops-nix ketika Anda benar-benar merasakan ketidaknyamanan model “satu file per rahasia”
  • Bagian terkait ketahanan kuantum telah dikoreksi
    • age dan sops mendukung kunci enkripsi aman tahan kuantum
    • age#578 telah ditutup dan v1.3.0 telah dirilis
    • Saat membuat kunci age, cukup sertakan -pq, misalnya age-keygen -pq -o key.txt

Bacaan terkait

1 komentar

 
GN⁺ 2 jam lalu
Komentar Lobste.rs
  • Saya pernah melihat penjelasan bahwa sops-nix dan agenix tidak menyimpan secret yang sudah didekripsi ke disk, tetapi saya penasaran apa keuntungan nyatanya
    Bukankah secret terenkripsi dan kuncinya sama-sama ada di disk? Atau salah satunya disimpan di tempat seperti TPM?
    Saya baru mulai memakai Nix, dan untuk deployment self-hosting kecil saya memakai cara sederhana dengan menaruhnya ke filesystem via scp
    Setelah sedikit mencari, sepertinya SSH private key bisa dilindungi dengan TPM, dan saya juga penasaran apakah itu bisa dilakukan di VM, tetapi ternyata mungkin ada dukungan vTPM, jadi saya seperti sudah menjawab pertanyaan saya sendiri
    • Di server saya, saya memakai sops-nix, dan menurut saya itu sudah cukup baik untuk model ancaman saya serta berjalan dengan baik. Sekarang saya jadi penasaran dengan cara menyimpan SSH private key di TPM
      Saya juga punya akses NixOps di sisi server. Lihat saja cara yang dilakukan Colmena: https://colmena.cli.rs/0.4/features/keys.html
      Intinya adalah mesin tepercaya yang memegang secret mendorongnya ke server jarak jauh. Mirip dengan yang Anda lakukan sekarang memakai scp, hanya saja prosesnya dijalankan dengan cara yang lebih ala Nix
    • Saatnya mengeluarkan ungkapan favorit saya. “Tergantung situasinya!” Di sini pengelolaan secret menangani dua masalah sekaligus: melindungi file secret di atas disk, dan melindungi secret di dalam konfigurasi yang dipakai untuk membangun sistem. Pada akhirnya nilai-nilai itu memang harus ada di suatu tempat
      Karena saya baru menghabiskan beberapa malam terakhir untuk menyiapkan ulang rangkaian agenix di flake sistem saya, saya hanya bisa berbicara tentang agenix. Untuk yang tertarik, saya memilih agenix-rekey, karena saya tidak perlu menyimpan file .yml yang berisi secret, dan bisa mengatur semua secret langsung di dalam Nix seperti yang sudah saya lakukan
      Secret terenkripsi ada di Nix store, dan seperti hal lain di Nix store, dapat dibaca secara global. SSH private key untuk membuka secret itu biasanya adalah private key milik server SSH yang sebenarnya, meskipun secara opsional bisa juga tidak demikian. Secret didekripsi saat aktivasi, kira-kira pada waktu boot, lalu ditempatkan di /run/agenix/<user>
      Alat bernama secrix melangkah lebih jauh dengan mengikat secret ke service systemd, lalu mengikat service itu kembali ke service yang membutuhkan secret tersebut. Jadi secret hanya didekripsi saat service itu berjalan. Namun dalam praktiknya, pengguna NixOS jarang menyalakan dan mematikan service sesering itu, jadi biasanya artinya service tersebut tetap berjalan terus. Ini mungkin cocok untuk secret aktivasi sistem seperti pembuatan pengguna
      agenix-rekey membuat rekeying tidak terlalu merepotkan, dan menggantikan secrets.nix dengan output flake. Ia memakai ID split YubiKey untuk satu setengah bagian dari kunci. Rekeying adalah proses mengautentikasi dengan kunci itu dan separuh lainnya untuk mendekripsi secret, lalu mengenkripsi ulangnya dengan SSH public key milik server. Public key itu dibuat saat instalasi sistem, dan saya mengambil kunci yang dibuat dari closure instalasi memakai --copy-host-keys di nixos-anywhere. Secret terenkripsi saya simpan di dalam repositori, tetapi di submodule terpisah yang hanya bisa diakses builder tepercaya
      Sebagai catatan, vTPM biasanya tidak berbasis hardware, dan banyak penyedia, bahkan ketika menyediakan TPM, kebanyakan hanya menyediakan TPM v1.2 alih-alih TPM v2. Penyedia saya, BinaryLane, juga begitu. Memang ini menambah satu lapis keamanan, tetapi ini bukan HSM ajaib seperti TPM sungguhan, dan tidak akan melindungi Anda dari kompromi penyedia atau node host. Untuk memungkinkan vTPM berbasis HSM sungguhan, dari sisi penyedia tampaknya biayanya akan sangat besar, dan AWS tampaknya menawarkannya dengan harga khas AWS
    • Saya memakai agenix + agenix-rekey + age-plugin-1p
      Master key saya ada di 1Password, jadi saya bisa mengedit, melihat, dan me-rekey password server mana pun tanpa menyimpan kredensial apa pun di disk laptop
      Saya bisa memberi akses ke server yang memerlukan akses kunci saat runtime. Saya memberi tahu agenix-rekey kunci mana yang boleh dilihat server itu dan menjalankan agenix rekey, lalu versi kunci terenkripsi yang bisa didekripsi server tersebut dicatat ke Nix store. SSH private key milik server itu hanya ada di server tersebut dan tidak pernah keluar. agenix-rekey hanya memerlukan public key untuk rekeying
      Jadi, secret akan bocor jika akun 1Password saya dibobol, atau jika server yang memakai secret itu dibobol
    • Di Agenix, secara default secret terenkripsi didekripsi dengan /etc/ssh/ssh_host_ed25519_key, lalu diletakkan di ramfs yang dimount di /run/agenix.d
      Jadi benar. Konten terenkripsi, kunci enkripsi, dan konten yang sudah didekripsi semuanya bisa diakses dari filesystem
    • Dengan cara ini, Anda juga bisa membagikan seluruh konfigurasi NixOS secara publik. Memang tidak banyak orang yang melakukan itu, tetapi rasanya setengah dari janji Nix adalah orang lain juga bisa ikut membantu men-debug masalah sistem saya
  • Saya sudah lama berpikir untuk mencoba agenix dan agenix-rekey. Sepertinya itu cukup mengurangi banyak titik sakit yang sering dibicarakan orang, tetapi saya sendiri belum mencobanya
    https://github.com/oddlama/agenix-rekey
  • Saya dulu mengelola kredensial dengan agenix, lalu pindah ke cara menaruhnya langsung di filesystem. Lebih sederhana, dan reinstalasi juga jarang terjadi bagi saya
    Selain itu, kredensial yang bertahan lama juga makin sedikit. Saya sedang menjauh dari menyalin kredensial jangka panjang menuju kredensial berbasis hardware, lalu memakainya secara langsung atau menukarnya dengan kredensial berumur pendek