Self-hosted Gizli Veri Yöneticisi Seçimi ve Karşılaştırma

Self-hosted bir gizli veri yöneticisinin, parola yöneticisinden farkı

Self-hosted bir gizli veri yöneticisi (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ın sonucudur. Bir parola yöneticisi, başında duran ve dikkat eden bir insan tarafından kilidi açılarak kullanılır. Bir gizli veri yöneticisi 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ü bir gizli veri yöneticisi 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.

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ç. SOPS ile age, 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 fazladan bir bileşenleri yoktur.

Dürüst cevap şudur: 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, 600 modundaki 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, buna karşılık el ile yapmadığınız hiçbir rotasyon avantajı sağlamaz.

600 modunda bir env dosyası yeterli midir?

Çoğu zaman 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ğ bağlantısı kurulmadan ö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) erişim izni içermez. 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 raporlama aracı da aynı şeyi 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 işlenebilir şifreli sırlar

SOPS (secrets operations), YAML veya JSON dosyalarındaki değerleri şifrelerken anahtarları açık metin olarak bırakır. age, tek bir anahtar çifti sağlayan ve herhangi bir anahtar sunucusuna ihtiyaç duymayan küçük bir şifreleme aracıdır. Bu ikili, secrets.enc.yaml dosyasını kodunuzun yanında saklamanıza olanak tanır; böylece git diff komutu, bir okuyucuya içeriğin 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 ise 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; bu sayede 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 yerleştirin; 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; bu sayede diske hiçbir açık metin yazılmaz. Önceki bölümde belirtilen ortam değişkeni uyarısı, bu alt süreç için de geçerlidir.

Bu noktada kullanıcıların karşılaştığı iki yaygın sorun vardı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 halihazırda 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 üzerinde bir gizli veriyi şifreler ve systemd, bu veriyi yalnızca ilgili servisin okuyabileceği özel bir dizine şifresini çözerek yerleştirir.

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 adlandırılan dizin içindeki db_password adlı bir dosyadan okur. Değer ortam değişkenlerinde bulunmaz, bu nedenle /proc/<pid>/environ hiçbir yararlı bilgi göstermez ve düz metin asla root dosya sistemine yazılmaz.

Bir unit dosyasını bu dosyaya yönlendirmeden önce şifre çözme işleminin çalıştığını doğrulayın:

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

Hangi anahtarın şifreleme yaptığını bilin; çünkü yedeklerinizin 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 üzerine geri yüklerseniz, hiçbir verinin şifresi çözülemez. credential.secret dosyasını aynı yedekleme içine kopyalayın veya düz metin halini erişebileceğiniz bir yerde saklayın.

Docker secrets: /run/secrets altındaki dosyalar

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

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 çıktısını verir; 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 desteklemektedir; örneğin Postgres imajı POSTGRES_PASSWORD_FILE dosyasını tam olarak bu şekilde okur.

Bunun ne olduğunu net bir şekilde anlamak gerekir. Swarm modu dışında hiçbir katmanda şifreleme yoktur: ./db_password.txt ana makine üzerinde düz metin (plaintext) bir dosyadır ve tek koruması dosya izinleri ile sahibidir. Bu izinleri kendiniz ayarlayın; çünkü Compose, herkes tarafından okunabilir bir dosyayı hiçbir uyarı vermeden bağlayacaktır. Düz env_file kısayoluna kıyasla avantaj ve dezavantajların karşılaştırması 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 servisi bir kez başlatın:

bao operator init

Varsayılan olarak bu işlem, kök anahtarı 5 parçaya böler ve kilidi açmak (unseal) için bunların 3 tanesini gerektirir; bunlar -key-shares ve -key-threshold bayraklarıdır. Sistem, parçaları ve ilk kök belirteci (root token) 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, kök anahtarı yalnızca bellekte tutar; bu nedenle yeniden başlatma sonrasında, birisi eşik değerindeki parçaları sağlamadan kendi depolama alanının şifresini çözemez. Bir çekirdek güncellemesi veya bellek yetersizliği (OOM) nedeniyle gerçekleşen bir sonlandırma, kilitli bir sunucu ve giriş yapamayan uygulamalarla sonuçlanır.

Tek kişilik bir VPS üzerinde Shamir bölmesi hiçbir şeyi korumaz, çünkü beş parçanın tamamı aynı kişiye ait aynı parola yöneticisinde toplanır. Otomatik kilit açma (auto unseal) işlemi, 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 kendiliğinden 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 ait olmalı ve bunlardan biri daha sonra asla değiştirilmemelidir:

openssl rand -hex 16
openssl rand -base64 32

Bunlardan ilki, 16 baytlık bir onaltılık (hex) dizisi 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 bu 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 şey aslında insanlarsa OpenBao'dan daha uygundur: kendi kendine süresi dolan veritabanı kimlik bilgileri yerine, küçük bir ekip için web arayüzü ve ortamlar arası ayrım sağlar. Bu yapı size PostgreSQL, Redis ve bir TLS sertifikasına mal olur; bunların tümünü artık sizin yamamanız ve yedeklemeniz gerekir.

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 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 (sealed), istek başarısız olur ve systemd, bir insan gelip 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 uzun bir RestartSec=. Ya da önyükleme anında değil, dağıtım (deploy) anında çekin: secret değerini 600 modunda bir dosyaya veya bir systemd credential öğesine yazdırın; böylece çalışan sistem bir API'ye değil, bir dosyaya bağımlı hale gelir.

Token süresinin dolması, daha yavaş bir saatte gerçekleşen aynı sorundur. 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. O hata, tam olarak 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 bir yedek değersizdir. Anahtarınızın nerede bulunduğunu not edin.

Bir env dosyası için dosyanın kendisi gizli bilgidir, bu nedenle yedekleme şifrelenmelidir. SOPS için şifrelenmiş dosya herkese açık herhangi bir yere konulabilir, ancak ~/.config/sops/age/keys.txt konumundaki age özel anahtarı kaybetmemeniz gereken parçadır. systemd kimlik bilgileri için /var/lib/systemd/credential.secret dosyasını .cred dosyalarıyla birlikte yedekleyin. Infisical için bir PostgreSQL dökümü alın ve ENCRYPTION_KEY dosyasını ondan 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 onu yeni bir sunucuya geri yüklemek için hala bao operator init içindeki unseal paylaşımlarına ihtiyacınız vardır. Paylaşımlar hiçbir yerde saklanmazken anlık görüntüleri nesne depolama birimine kopyalayan gece çalıştırılan bir görev, hiçbir şeyi yedeklemez. Ona güvenmeden önce geri yükleme işlemini 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. auditd ile bir yol üzerinde izleme (watch) yapmak 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 aygıtına gelen her isteği günlüğe kaydeder:

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

Bu günlük kaydıyla 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 (hashed); böylece günlük dosyasının kendisi düz metin içermese bile, zaten bildiğiniz bir değeri günlükle eşleştirebilirsiniz. Tam sayı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 aygıtı kayıt yapamadığında isteklere yanıt vermez ve engelleme (blocking) modunda başarısız olan bir aygıt, 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 ilk kesintiden sonra değil, kurulum aşamasında bir logrotate kuralı tanımlayı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 kullanıcısına ait ve servis kullanıcısı tarafından okunan 600 modunda bir env dosyası. Değerin süreç ortamından (process environment) çıkarılmasını istediğinizde systemd credentials kullanın.
2. Tek makine, iki ila beş kullanıcı, yapılandırma halihazırda git üzerinde: age ile SOPS. Her kullanıcıya bir anahtar çifti verilir ve .sops.yaml şifre çözme yetkisi olan tüm açık anahtarları listeler.
3. Birden fazla makine, tek bir yapılandırma deposu, süresi dolan kimlik bilgilerine ihtiyaç yok: yine age ile SOPS; her sunucu için bir alıcı anahtarı kullanılır, böylece çalınan bir sunucu anahtarı yalnızca o sunucunun dosyalarının şifresini çözer.
4. Birden fazla makine ve yaşam süresi olan veritabanı kimlik bilgilerine gerçekten ihtiyaç duyan birden fazla ekip, ayrıca birinin okuduğu bir denetim izi (audit trail): OpenBao; mühür açma (unsealing) ve geri yükleme tatbikatları için operatör süresinden ayda bir saat bütçe ayırın.

Dört senaryonun da temelindeki kural aynıdır. Yüksek sesle ifade edebileceğiniz bir gereksinimi karşılayan en küçük yapıyı çalıştırın; çünkü çalışmayan bir secrets manager ile 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; OpenBao veya Infisical gibi bir servisten bahsediyorsanız durum böyledir. Tek bir sunucuda ve bir veya iki kullanıcıyla çalışırken, 600 izinlerine sahip bir env dosyası veya systemd encrypted credential, diğer yerel kullanıcılara karşı aynı korumayı sağlar; üstelik unseal 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 manuel rotasyon gerektirmeyen, süresi dolan kimlik bilgilerine gerçek bir ihtiyacınız olduğunda anlam kazanır.

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

Parola yöneticisi, bir kişinin yazdığı kimlik bilgilerini saklar ve insan müdahalesiyle kilidi açılır. Secrets manager ise kimlik bilgilerini süreçlere (process) sunar; bu nedenle gece saat 03:00'te, başında kimse yokken çalışabilmesi gerekir. Aralarındaki temel fark da buradan kaynaklanır: kilitli bir parola yöneticisi ana parolayı tekrar girmenizi ister; kilitli (sealed) bir secrets manager ise kilitli kaldığı sürece yeniden başlatılan her servisi durdurur.

Yeniden başlatma sonrasında OpenBao kilitlenirse uygulamalarıma ne olur?

Uygulamalar kimlik bilgilerini çekemez, bu nedenle başlatılamazlar. Siz unseal eşiğini (varsayılan olarak 5 paydan 3'ü) girene 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 işlemi onu tekrar kilitler. Ya auto unseal özelliğini açın (tek bir VPS üzerinde 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 bunlara erişemez. Anahtarlar şifreli değildir: bir okuyucu, STRIPE_SECRET_KEY ve SMTP_PASSWORD değerlerine sahip olduğunuzu ve her birinin ne sıklıkla değiştiğini görebilir. Bu meta veri çoğu proje için kabul edilebilir olsa da bazıları için uygun değildir. 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.