Self-hosted secrets manager karşılaştırması ve rehberi

Self-hosted bir secrets manager'ın bir parola yöneticisinden farkı

Self-hosted bir secrets manager, kimlik bilgilerini süreçlere (process) iletir. Bir parola yöneticisi ise kimlik bilgilerini insanlara iletir. Diğer tüm farklar bu temel ayrım üzerine kuruludur. Bir parola yöneticisi, başında duran ve dikkat eden bir insan tarafından kilidi açılarak kullanılır. Bir secrets manager ise saat 03:00'te, kimse uyanık değilken uygulamanıza veritabanı parolasını sağlamak zorundadır.

Hata modları, önem arz edecek şekilde birbirinden farklıdır. Kilitli bir parola yöneticisi bir zahmettir: ana parolayı tekrar girersiniz. Mühürlü (sealed) bir secrets manager ise bir kesintidir: mühürlü olduğu sırada yeniden başlatılan her servis, kimlik bilgileri olmadan ayağa kalkar ve çalışmaz durumda kalır. Vaultwarden'ı kendi parola yöneticiniz olarak çalıştırmak, insan odaklı sorunu iyi bir şekilde çözer. Ancak makine odaklı sorunu çözmez ve zaten bunun için tasarlanmamıştır. Eğer bunun yanında bir tane çalıştırıyorsanız, güçlendirilmesi gereken kısımlar kasa içeriğinden ziyade (ki istemci bunu zaten şifreler) yönetici token'ı ve yedekleme dosyasıdır; Vaultwarden için bir güçlendirme süreci her ikisini de kapsar.

Tek bir sunucu için gerçekçi seçenekler iki gruba ayrılır. OpenBao ve Infisical birer servistir: bir API, bir veritabanı, TLS (transport layer security), bir giriş adımı ve artık hayatta tutmanız gereken bir süreçtir. age ile SOPS, systemd credentials ve Docker secrets ise dosya tabanlıdır: diskte şifreli dururlar, halihazırda çalışan bir süreç tarafından şifreleri çözülür ve izlenmesi gereken ekstra bir bileşenleri yoktur.

İşte en baştan dürüst cevap: Bir veya iki kişinin kullandığı tek bir sunucu için dosya tabanlı seçenekler genellikle doğru tercihtir. Düzgün bir şekilde mührü açılmayan ve rotasyonu yapılmayan bir OpenBao, mode 600 bir env dosyasından daha kötüdür; çünkü fazladan bir hareketli parça ve yanlış yapılandırma ihtimali olan bir yedekleme süreci ekler, ancak manuel olarak yapmadığınız hiçbir rotasyon avantajı sağlamaz.

600 modunda bir env dosyası yeterli midir?

Çoğu durumda evet. Bu yöntem, sunucudaki başka bir kullanıcının veritabanı parolanızı okumasına karşı koruma sağlar. Unix dosya izinleri bunu yapar ve ağ ayağa kalkmadan önce devreye girer.

sudo install -d -m 750 -o root -g myapp /etc/myapp
sudo install -m 640 -o root -g myapp /dev/null /etc/myapp/env
sudoedit /etc/myapp/env

Bunu her iki taraftan da kontrol edin:

sudo -u myapp cat /etc/myapp/env
sudo -u nobody cat /etc/myapp/env

İlk komut dosyayı yazdırır. İkinci komut cat: /etc/myapp/env: Permission denied çıktısını verir, çünkü nobody kullanıcısı myapp grubunda değildir ve dosya herhangi bir genel (world) izin bitine sahip değildir. Tüm güvenlik modeli bundan ibarettir ve gerçek bir koruma sağlar.

Sızıntı, bir sonraki aşamada gerçekleşir. EnvironmentFile= içeren bir systemd birimi, bu değerleri süreç ortamına (process environment) kopyalar ve süreç ortamı okunabilir durumdadır.

[Service]
User=myapp
EnvironmentFile=/etc/myapp/env
ExecStart=/usr/local/bin/myapp

sudo cat /proc/$(pgrep -n myapp)/environ | tr '\0' '\n'

Bu komut, sırlarınızı düz metin olarak yazdırır; çünkü /proc/<pid>/environ dosyası root ve sürecin çalıştırıldığı kullanıcı tarafından okunabilir. Ortamı bir rapora ekleyen bir hata raporlayıcı (crash reporter) da aynı veriyi görür. Aynı hesap altında çalışan herhangi bir araç da bunu yapabilir; bu nedenle sırları yapay zeka ajanlarından uzak tutmak, öncelikle onları ortam değişkenlerinden çıkarmakla başlar. Dosyayı özel ve düşük yetkili bir servis kullanıcısı ile eşleştirin; böylece "sürecin çalıştırıldığı kullanıcı" root olmaz.

age ile SOPS: git deposuna eklenebilir şifreli sırlar

SOPS (secrets operations), YAML veya JSON dosyalarındaki değerleri şifreler ve anahtarları açık metin olarak bırakır. age, tek bir anahtar çifti sağlayan ve anahtar sunucusu gerektirmeyen küçük bir şifreleme aracıdır. Bu ikili, secrets.enc.yaml dosyasını kodunuzun yanında tutmanıza olanak tanır; böylece git diff, bir okuyucuya değerin neye dönüştüğünü söylemeden hangi ayarın değiştiğini görmenizi sağlar.

age, Ubuntu 24.04 paket depolarında mevcuttur. SOPS mevcut değildir, bu nedenle .deb dosyasını sürüm sayfasından temin edin. Ağustos 2026 itibarıyla güncel sürüm 3.13.3'tür.

sudo apt update && sudo apt install -y age
curl -LO https://github.com/getsops/sops/releases/download/v3.13.3/sops_3.13.3_amd64.deb
sudo apt install -y ./sops_3.13.3_amd64.deb
sops --version

Bir anahtar çifti oluşturun. age-keygen, özel anahtarı dosyaya yazar ve genel anahtarı ekrana basar; böylece Public key: age1... ile başlayan bir satır görürsünüz.

mkdir -p ~/.config/sops/age
age-keygen -o ~/.config/sops/age/keys.txt
chmod 600 ~/.config/sops/age/keys.txt
age-keygen -y ~/.config/sops/age/keys.txt

Genel anahtarı, deponun kök dizinindeki .sops.yaml dosyasına ekleyin; böylece komut satırında alıcıyı belirtmek zorunda kalmazsınız.

creation_rules:
  - age: age1s3cqcks5genc6ru8chl0hkkd04zmxvczsvdxq99ekffe4gmvjpzsedk23c

sops encrypt secrets.yaml > secrets.enc.yaml
sops decrypt secrets.enc.yaml

path_regex içermeyen bir kural her şeyle eşleşir; başlangıçta istediğiniz durum budur. Daha sonra bir kural eklerseniz, bunu sops komutuna verdiğiniz dosya ile eşleşecek şekilde yazın; çünkü kurallar çıktı yönlendirdiğiniz dosyaya göre değil, girdi yoluna göre kontrol edilir.

Çalışma zamanında, değerleri yalnızca tek bir sürece iletin:

sops exec-env secrets.enc.yaml './myapp'

sops exec-env, şifre çözme işlemini bellekte gerçekleştirir ve değerleri alt sürecin ortam değişkenlerine atar; böylece diske hiçbir düz metin yazılmaz. Önceki bölümdeki ortam değişkeni uyarısı, bu alt süreç için de geçerlidir.

Bu noktada kullanıcılar genellikle iki sorunla karşılaşır. systemd altında alınan Failed to get the data key required to decrypt the SOPS file hatası, neredeyse her zaman SOPS'un yanlış ev dizinine baktığı anlamına gelir; çünkü bir servis birimi sizin HOME değişkeninizi devralmaz. Birim dosyasında Environment=SOPS_AGE_KEY_FILE=/etc/sops/age.txt ile yolu açıkça belirtin. Ayrıca, .sops.yaml dosyasını düzenlemek halihazırda var olan hiçbir şeyi yeniden şifrelemez: bir iş arkadaşınızın genel anahtarını eklemek yalnızca yeni dosyaları etkiler; bu nedenle mevcut her dosya üzerinde sops updatekeys secrets.enc.yaml komutunu çalıştırın. Yapılandırmanız zaten Ansible üzerinden yürütülüyorsa, aynı değerleri Ansible Vault ile şifrelemek ikinci bir araca ihtiyaç duymadan aynı sonuca ulaşmanızı sağlar.

systemd kimlik bilgileri: ortama asla ulaşmayan gizli veriler

Ubuntu 24.04, systemd 255 sürümüyle gelir, bu nedenle herhangi bir kurulum gerekmez. systemd-creds, ana bilgisayar üzerindeki bir gizli veriyi şifreler ve systemd, bu veriyi yalnızca ilgili servisin okuyabileceği özel bir dizine şifresini çözerek aktarır.

sudo systemd-creds setup
sudo install -d -m 700 /etc/myapp
echo -n 'hunter2' | sudo systemd-creds encrypt --name=db_password - /etc/myapp/db_password.cred

[Service]
User=myapp
LoadCredentialEncrypted=db_password:/etc/myapp/db_password.cred
ExecStart=/usr/local/bin/myapp

Servis, değeri $CREDENTIALS_DIRECTORY tarafından belirtilen dizin içindeki db_password adlı bir dosyadan okur. Değer ortam değişkenlerinde bulunmadığı için /proc/<pid>/environ komutu yararlı bir çıktı göstermez ve düz metin hiçbir zaman root dosya sistemine yazılmaz.

Bir unit dosyasını bu dosyaya yönlendirmeden önce şifre çözme işleminin başarılı olduğunu doğrulayın:

sudo systemd-creds decrypt /etc/myapp/db_password.cred -

Hangi anahtarın şifreleme yaptığını bilin; çünkü yedeğinizin işe yarayıp yaramayacağına bu karar verir. Varsayılan --with-key=auto, mevcut ve kullanılabilir olduğunda TPM2 (trusted platform module version 2) çipini, aksi takdirde ana bilgisayar anahtarını kullanır. Çoğu VPS örneğinde TPM2 bulunmaz.

systemd-analyze has-tpm2

no, ana bilgisayar anahtarının kullanıldığı anlamına gelir ve bu anahtar, yalnızca root tarafından okunabilen /var/lib/systemd/credential.secret dizininde bulunur. db_password.cred dosyasını bu dosya olmadan yeni bir VPS'e geri yüklerseniz, hiçbir verinin şifresi çözülemez. credential.secret dosyasını aynı yedeğe kopyalayın veya düz metin halini erişebileceğiniz bir yerde saklayın.

Docker secrets: /run/secrets altındaki dosyalar

Compose, ana makinedeki bir dosyayı okur ve bunu container içinde /run/secrets/<name> yoluna bağlar.

services:
  app:
    image: myapp:latest
    environment:
      DB_PASSWORD_FILE: /run/secrets/db_password
    secrets:
      - db_password
secrets:
  db_password:
    file: ./db_password.txt

docker compose exec app cat /run/secrets/db_password
docker compose exec app env | grep -i password

İlk komut secret değerini ekrana yazdırır. İkinci komut ise yalnızca DB_PASSWORD_FILE=/run/secrets/db_password değerini yazdırır; asıl amaç da budur: değer hiçbir zaman container ortam değişkenlerinde yer almaz, bu nedenle docker inspect çıktısında görünmez. Birçok resmi imaj bu yapıyı halihazırda beklemektedir; örneğin Postgres imajı POSTGRES_PASSWORD_FILE dosyasını tam olarak bu şekilde okur.

Bunun ne olduğu konusunda net olunmalıdır. Swarm modu dışında hiçbir katmanda şifreleme yoktur: ./db_password.txt ana makinede düz metin bir dosyadır ve tek koruması dosya izinleri ile sahibidir. Her ikisini de kendiniz ayarlayın; çünkü Compose, herkes tarafından okunabilir bir dosyayı uyarı vermeden bağlayacaktır. Düz env_file kısayoluna kıyasla avantaj ve dezavantajların tamamı için Compose env dosyaları ve secret rehberi bölümüne bakabilirsiniz.

OpenBao ve Vault çalıştırmanın gerçek maliyeti

OpenBao, HashiCorp'un 2023 yılında Vault'u Business Source License kapsamına almasının ardından başlatılan, Linux Foundation bünyesindeki bir HashiCorp Vault çatallanmasıdır (fork). OpenBao, MPL 2.0 (Mozilla Public License) altında kalmaya devam etmektedir. Ağustos 2026 itibarıyla 2.6.2 sürümü günceldir. Aşağıdaki bilgilerin neredeyse tamamı Vault için de geçerlidir, çünkü çatallanma aynı komut setini korumuştur.

docker pull docker.io/openbao/openbao

Yükseltmelerin apt tarafından yönetilmesini tercih ederseniz, Debian ve Ubuntu paketleri OpenBao indirme sayfasında mevcuttur. Sunucu, bir dinleyici (listener) ve bir depolama arka ucu (storage backend) içeren bir yapılandırma dosyasına ihtiyaç duyar:

listener "tcp" {
  address       = "127.0.0.1:8200"
  tls_cert_file = "/path/to/full-chain.pem"
  tls_key_file  = "/path/to/private-key.pem"
}

storage "raft" {
  path = "/path/to/raft/data"
  node_id = "raft_node_1"
}

Ardından bir kez başlatın:

bao operator init

Varsayılan olarak bu işlem, root anahtarını 5 parçaya böler ve kilidi açmak için (unseal) bunların 3 tanesini gerektirir; bunlar -key-shares ve -key-threshold bayraklarıdır. Paylaşımları ve ilk root token değerini yalnızca bir kez yazdırır ve bir daha asla göstermez.

Şimdi çoğu karşılaştırmanın atladığı kısma gelelim. Yeniden başlatılan bir sunucu, kilitli bir sunucudur. OpenBao, root anahtarını yalnızca bellekte tutar; bu nedenle yeniden başlatma sonrasında, birisi eşik değerindeki paylaşımları sağlamadan kendi depolama alanının şifresini çözemez. Bir çekirdek güncellemesi veya bellek yetersizliği nedeniyle gerçekleşen bir süreç sonlandırma (OOM kill), kilitli bir sunucu ve giriş yapamayan uygulamalarla sonuçlanır.

Tek kişilik bir VPS üzerinde Shamir paylaşımı hiçbir şeyi korumaz, çünkü beş paylaşımın tamamı aynı kişiye ait aynı parola yöneticisinde son bulur. Otomatik kilit açma (auto unseal), anahtarı güvenilir bir cihaza veya servise taşır; bu durum büyük bir bulut ortamında yönetilen bir anahtar servisi anlamına gelirken, VPS üzerinde genellikle verileri koruyan diskle aynı diskte duran bir anahtar dosyası anlamına gelir. Bu, yeniden başlatma sonrasında kendi kendine ayağa kalkan bir sunucu uğruna yapılan gerçek bir güvenlik azalmasıdır. Bu takası bilinçli bir şekilde yapın ve hangi yöntemi seçtiğinizi not edin.

Infisical: Bir arayüz, bir veritabanı ve elinizde tuttuğunuz bir ana anahtar

Infisical; web arayüzü, projeler, ortamlar ve kullanıcı bazlı erişim denetimi sunan bir gizli veri (secrets) platformudur. Compose ile kendi sunucunuzda barındırmak oldukça kısadır:

curl -o docker-compose.prod.yml https://raw.githubusercontent.com/Infisical/infisical/main/docker-compose.prod.yml
curl -o .env https://raw.githubusercontent.com/Infisical/infisical/main/.env.example
docker compose -f docker-compose.prod.yml up -d

Son komuttan önce .env dosyasını düzenleyin. İki değer size özel olmalı ve bunlardan biri daha sonra asla değiştirilmemelidir:

openssl rand -hex 16
openssl rand -base64 32

İlki, 16 baytlık bir onaltılık (hex) dizi olan ENCRYPTION_KEY değeridir. Bu, gizli verilerinizin PostgreSQL içinde şifrelendiği anahtardır; bu yüzden anahtarı kaybetmek, kusursuz bir veritabanı yedeğini şifreli metin yığınına dönüştürür ve çalışan bir örnekte anahtarı değiştirmek, mevcut gizli verilerin şifresinin çözülmesini engeller. İkincisi, oturumlar için kullanılan 32 baytlık bir base64 dizisi olan AUTH_SECRET değeridir. SITE_URL, protokol dahil olmak üzere gerçekten erişeceğiniz mutlak URL olmalıdır; aksi takdirde giriş yönlendirmesi çalışmaz.

Infisical, ihtiyaç duyduğunuz şeyin insanlar olduğu durumlarda (küçük bir ekip için web arayüzü ve ortamlar arası ayrım) OpenBao'dan daha uygundur; kendi kendine süresi dolan veritabanı kimlik bilgileri yerine bu yapı tercih edilir. Bu kurulum size PostgreSQL, Redis ve bir TLS sertifikasına mal olur; bunların tümünü artık yama yapmalı ve yedeklemelisiniz.

Secrets servisi kapalıyken uygulamanız yeniden başlatıldığında ne olur

Bu soru, bir secrets servisinin tek bir sunucuda bulunup bulunmaması gerektiğini belirler. Dosyalar ağ başlamadan önce okunabilir durumdadır, ancak bir servis öyle değildir.

Sunucuyu yeniden başlattığınızda, uygulamanız ve OpenBao aynı anda çalışmaya başlar. Uygulama veritabanı parolasını ister, OpenBao henüz mühürlüdür, istek başarısız olur ve systemd, bir insan unseal paylaşımlarını girene kadar uygulamayı döngüsel olarak yeniden başlatır. Hiçbir şey bozulmaz, ancak hiçbir şey de çalışmaz.

Bunu yönetmenin iki dürüst yolu vardır. Üniteleri sıralayın ve uygulamanın yeniden denemesine izin verin: After= secrets servisi, artı Restart=on-failure ve API'yi yormayacak kadar RestartSec= uzun bir bekleme süresi. Veya açılış anı yerine dağıtım (deploy) sırasında veriyi çekin: secret değerini mode 600 bir dosyaya veya bir systemd credential öğesine işleyin; böylece çalışan sistem bir API'ye değil, bir dosyaya bağımlı hale gelir.

Token süresinin dolması, daha yavaş işleyen bir saatte aynı sorunu yaratır. OpenBao token'ları ve lease'leri bir yaşam süresine (TTL) sahiptir; bu nedenle asla yenileme yapmayan uzun soluklu bir süreç, dağıtımla ilgisi olmayan bir anda erişimini kaybeder. Bu başarısızlık, o gün hiçbir şey değişmediği için kafa karıştırıcıdır.

Deponun kendisini yedekleme

Buradaki her seçeneğin bir anahtarı vardır ve bu anahtar olmadan alınan yedek değersizdir. Anahtarınızın nerede bulunduğunu not edin.

Bir env dosyası için dosyanın kendisi gizli bilgidir, bu nedenle yedek şifrelenmelidir. SOPS için şifrelenmiş dosya herhangi bir genel alana konulabilir ancak ~/.config/sops/age/keys.txt konumundaki age özel anahtarı kaybetmemeniz gereken parçadır. systemd kimlik bilgileri için .cred dosyalarıyla birlikte /var/lib/systemd/credential.secret konumunu da yedekleyin. Infisical için bir PostgreSQL dökümü alın ve ENCRYPTION_KEY verisini bu dökümden ayrı bir yerde saklayın.

Raft depolama kullanan OpenBao kendi anlık görüntüsünü (snapshot) alır:

bao operator raft snapshot save backup.snap
bao operator raft snapshot restore backup.snap

Anlık görüntü şifrelenmiş deponuzu içerir; bu nedenle görüntüyü yeni bir sunucuya geri yüklemek için hala bao operator init konumundaki unseal paylaşımlarına ihtiyacınız vardır. Paylaşımlar hiçbir yerde saklanmazken anlık görüntüleri nesne depolama alanına kopyalayan bir gece işi, hiçbir şeyi yedeklemiyor demektir. Geri yükleme işlemini, ona güvenmeden önce geçici bir VPS üzerinde test edin.

Denetim günlüğü: hangi gizli veriyi kim okudu

Dosyalar size bir denetim izi sunmaz. Dosya modu ve sahibi, gizli veriyi kimin okuyabileceğini gösterir; ancak kimin okuduğunu asla belirtmez. Yol üzerinde bir izleme (watch) ile auditd kullanmak en yakın alternatiftir; ancak bu yöntem de hangi değerin kullanıldığını değil, yalnızca dosyanın açıldığını raporlar.

OpenBao, açıkça etkinleştirdiğiniz bir denetim cihazına gelen her isteği günlüğe kaydeder:

bao audit enable file file_path=/var/log/openbao_audit.log

Bu günlükle ilgili iki gerçek, sunucuyu nasıl çalıştıracağınızı belirler. İstek ve yanıtlardaki çoğu dizge, HMAC-SHA256 ve bir tuz (salt) değeri ile özetlenir (hash); böylece günlükte düz metin yer almadan, bildiğiniz bir değeri günlükteki kayıtla eşleştirebilirsiniz. Tamsayılar ve mantıksal değerler (boolean) ise açık metin olarak yazılır; bu nedenle sayısal bir gizli veri, bu özetleme işleminden herhangi bir koruma sağlamaz.

Operasyonel tuzak ise şudur: OpenBao, etkinleştirilmiş hiçbir denetim cihazı kayıt yapamadığında isteklere yanıt vermez. Engelleme (blocking) modunda başarısız olan bir cihaz, sorun giderilene kadar isteklerin askıda kalmasına neden olur. /var/log üzerindeki dolu bir disk, tasarım gereği gizli veri API'nizi devre dışı bırakır. Denetim günlüğüne ilk günden itibaren kendi alanını ayırın ve bir logrotate kuralı tanımlayın; bunu ilk kesintiden sonraya bırakmayın.

Hangi self-hosted secrets manager kullanılmalı?

Makine ve kullanıcı sayısını hesaplayın, ardından seçiminizi yapın.

1. Tek makine, tek kullanıcı: root tarafından sahiplenilen ve bir servis kullanıcısı tarafından okunan 600 modunda bir env dosyası kullanın. Değeri süreç ortamından (process environment) almak istediğinizde systemd credentials özelliğini ekleyin.
2. Tek makine, iki ila beş kullanıcı ve yapılandırması halihazırda git üzerinde olan sistemler: age ile birlikte SOPS kullanın. Her kullanıcıya bir anahtar çifti verin ve .sops.yaml içerisinde şifre çözme yetkisi olan her genel anahtarı listeleyin.
3. Birden fazla makine, tek bir yapılandırma deposu ve süresi dolan kimlik bilgilerine ihtiyaç duyulmayan durumlar: yine age ile SOPS kullanın; her sunucu için bir alıcı anahtarı tanımlayın. Böylece çalınan bir sunucu anahtarı yalnızca o sunucuya ait dosyaların şifresini çözebilir.
4. Birden fazla makine, birden fazla ekip ve veritabanı kimlik bilgileri için yaşam süresi (lifetime) ile denetim izi (audit trail) gerektiren durumlar: OpenBao kullanın ve operatörün unsealing (mühür açma) ve geri yükleme tatbikatları için ayda bir saatlik süreyi bütçenize ekleyin.

Bu dört senaryonun temelindeki kural aynıdır. Yüksek sesle ifade edebildiğiniz bir gereksinimi karşılayan en küçük aracı çalıştırın; çünkü çalışmayan bir secrets manager ile içi boş bir secrets manager birbirinden ayırt edilemez.

FAQ

Tek bir VPS için self-hosted bir secrets manager kullanmaya değer mi?

Genellikle hayır; eğer OpenBao veya Infisical gibi bir servisten bahsediyorsanız. Tek bir sunucuda ve bir veya iki kullanıcıyla çalışırken, 600 modunda bir env dosyası veya systemd şifreli kimlik bilgisi, diğer yerel kullanıcılara karşı aynı korumayı sağlar; üstelik unseal (mühür açma) adımı gerektirmez ve yama yapılması gereken ekstra bir servis yükü oluşturmaz. Bir secrets servisi, birden fazla makineniz ve kullanıcınız olduğunda veya elle yenilenmesi gerekmeyen, süresi dolan kimlik bilgilerine gerçek bir ihtiyacınız olduğunda maliyetini karşılamaya başlar.

Bir parola yöneticisi ile bir secrets manager arasındaki fark nedir?

Parola yöneticisi, bir kişinin yazdığı kimlik bilgilerini saklar ve insan başındayken kilidini açar. Secrets manager ise kimlik bilgilerini süreçlere (process) verir; bu nedenle saat 03:00'te, başında kimse yokken çalışmak zorundadır. Aralarındaki farkı belirleyen sonuç budur: kilitli bir parola yöneticisi ana parolayı tekrar girmenizi ister, mühürlü bir secrets manager ise mühürlü olduğu sürece yeniden başlatılan her servisi durdurur.

Yeniden başlatma sonrasında OpenBao mühürlenirse uygulamalarıma ne olur?

Uygulamalar kimlik bilgilerini çekemez, bu yüzden başlatılamazlar. Siz unseal eşiğini (varsayılan olarak 5 paydan 3'ü) sağlayana kadar systemd bunları döngüsel olarak yeniden başlatmaya çalışır. OpenBao kök anahtarı yalnızca bellekte tutar, bu nedenle her yeniden başlatma onu tekrar mühürler. Ya auto unseal özelliğini açın (tek bir VPS'de unseal anahtarının verilerle aynı diskte kalacağını kabul ederek) ya da dağıtım sırasında sırları bir dosyaya yazdırın; böylece sistemin açılışı hiçbir şekilde API'ye bağımlı olmaz.

SOPS ile şifrelenmiş dosyaları herkese açık bir depoya (repository) gönderebilir miyim?

Değerler şifrelidir, bu nedenle age özel anahtarına sahip olmayan hiç kimse için bir risk oluşturmazlar. Anahtarlar şifreli değildir: bir okuyucu, STRIPE_SECRET_KEY ve SMTP_PASSWORD değerlerini tuttuğunuzu ve her birinin ne sıklıkla değiştiğini görebilir. Bu meta veri çoğu proje için kabul edilebilir, bazıları için ise kabul edilemezdir. age özel anahtarını depodan uzak tutun ve her alıcı eklediğinizde veya çıkardığınızda mevcut tüm dosyalar üzerinde sops updatekeys komutunu çalıştırın.