مقارنة مديري الأسرار المستضافين ذاتياً لخادم واحد

ما الذي يفعله مدير الأسرار المستضاف ذاتياً ولا يفعله مدير كلمات المرور

يسلّم مدير الأسرار المستضاف ذاتياً بيانات الاعتماد إلى العمليات. أما مدير كلمات المرور فيسلّم بيانات الاعتماد إلى الأشخاص. وينتج كل ما عدا ذلك عن هذا الفرق الواحد. يفتح مدير كلمات المرور شخص حاضر ومنتبه. أما مدير الأسرار فعليه أن يسلّم تطبيقك كلمة مرور قاعدة البيانات عند الساعة 03:00، عندما لا يكون أحد مستيقظاً.

تختلف أنماط الفشل بطريقة مهمة. يكون مدير كلمات المرور المقفل مصدر إزعاج: تكتب كلمة المرور الرئيسية مرة أخرى. أما مدير الأسرار المختوم فيتسبب في انقطاع الخدمة: كل خدمة تعيد التشغيل أثناء بقائه مختوماً تبدأ من دون بيانات اعتماد وتظل متوقفة. يحل تشغيل Vaultwarden كمدير كلمات مرور خاص بك مشكلة المستخدمين جيداً. لكنه لا يحل مشكلة الآلات، ولم يُبنَ لهذا الغرض أصلاً. إذا شغّلته إلى جانب هذا الحل، فالأجزاء التي تستحق التقوية هي رمز الإدارة وملف النسخ الاحتياطي، لا محتويات الخزنة التي يشفرها العميل بالفعل، كما يغطي إجراء تقوية على Vaultwarden الأمرين.

تنقسم الخيارات الواقعية لخادم واحد إلى مجموعتين. OpenBao وInfisical خدمتان: API، وقاعدة بيانات، وTLS (أمان طبقة النقل)، وخطوة تسجيل دخول، وعملية يجب عليك إبقاؤها قيد التشغيل. أما SOPS مع age، وsystemd credentials، وDocker secrets فهي ملفات: مشفرة في حالة السكون، ويفك تشفيرها مكوّن يعمل بالفعل، من دون شيء إضافي لمراقبته.

إليك الإجابة الصريحة أولاً. بالنسبة إلى خادم واحد يستخدمه شخص أو شخصان، تكون الخيارات القائمة على الملفات صحيحة عادةً. يكون OpenBao الذي لا ينجح أحد في إلغاء ختمه بطريقة صحيحة ولا يدير أحد تدوير الأسرار فيه أسوأ من ملف env بصلاحية mode 600، لأنه يضيف مكوّناً متغيراً ونسخة احتياطية ستخطئ في إعدادها، ولا يوفر لك أي تدوير لم تكن تنفذه يدوياً من قبل.

هل يكفي استخدام ملف بيئة بالوضع 600؟

غالباً، نعم. التهديد الذي يواجهه هذا الإعداد هو أن يقرأ مستخدم آخر على الخادم كلمة مرور قاعدة البيانات. تتولى أذونات ملفات Unix ذلك، وتطبّقها قبل تشغيل الشبكة.

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

تحقق من ذلك من الجانبين:

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

يطبع الأمر الأول محتوى الملف. ويطبع الثاني cat: /etc/myapp/env: Permission denied، لأن nobody ليس ضمن المجموعة myapp، ولأن الملف لا يتضمن أي أذونات للمستخدمين الآخرين. هذا هو نموذج الأمان بأكمله، وهو نموذج فعلي.

يحدث التسريب بعد ذلك. تنسخ وحدة systemd التي تحتوي على EnvironmentFile= هذه القيم إلى بيئة العملية، وتكون بيئة العملية قابلة للقراءة.

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

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

يطبع ذلك أسرارك بنص واضح، لأن /proc/<pid>/environ قابل للقراءة بواسطة root وبواسطة المستخدم الذي تعمل العملية بحسابه. ويرى مُبلّغ الأعطال الذي يرفق البيئة بتقرير الشيء نفسه. وينطبق ذلك أيضاً على أي أداة تعمل بالحساب نفسه، ولذلك يبدأ إبقاء الأسرار خارج وكلاء الذكاء الاصطناعي بإخراجها من البيئة. اربط الملف أيضاً بـمستخدم خدمة مخصص منخفض الصلاحيات حتى لا يكون "المستخدم الذي تعمل العملية بحسابه" هو root.

SOPS مع age: أسرار مشفّرة يمكنك إيداعها في git

يشفّر SOPS (عمليات الأسرار) القيم الموجودة في ملف YAML أو JSON، ويترك المفاتيح بنص واضح. أما age فهي أداة تشفير صغيرة تمنحك زوج مفاتيح واحداً من دون خادم مفاتيح. يتيح لك استخدامهما معاً إيداع secrets.enc.yaml بجانب الشفرة، بينما يظل git diff يوضح لك الإعداد الذي تغيّر من دون أن يكشف للقارئ القيمة الجديدة.

تأتي age ضمن حزم Ubuntu 24.04. أما SOPS فلا تأتي ضمنها، لذلك نزّل .deb من صفحة الإصدارات. كان الإصدار 3.13.3 هو الأحدث في August 2026.

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

أنشئ زوج مفاتيح. يكتب age-keygen المفتاح الخاص في الملف ويطبع المفتاح العام، لذلك سترى سطراً يبدأ بـ Public key: age1....

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

ضع المفتاح العام في .sops.yaml عند جذر المستودع، حتى لا تضطر إلى تذكّر المستلم في سطر الأوامر.

creation_rules:
  - age: age1s3cqcks5genc6ru8chl0hkkd04zmxvczsvdxq99ekffe4gmvjpzsedk23c

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

تطابق القاعدة التي لا تحتوي على path_regex كل شيء، وهذا ما تريده في البداية. إذا أضفت واحداً لاحقاً، فاكتبه بحيث يطابق الملف الذي تمرّره إلى sops، لأن القواعد تُفحص مقابل مسار الإدخال، وليس مقابل الملف الذي تعيد توجيه الإخراج إليه.

أثناء التشغيل، مرّر القيم إلى عملية واحدة فقط:

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

يفك sops exec-env التشفير في الذاكرة ويعيّن القيم في بيئة العملية الابنة، لذلك لا يُكتب أي نص واضح على القرص. وينطبق على تلك العملية الابنة أيضاً التحذير المتعلق بالبيئة الوارد في القسم السابق.

هناك مشكلتان تتسببان في أخطاء متكررة هنا. الخطأ Failed to get the data key required to decrypt the SOPS file تحت systemd يعني غالباً أن SOPS بحث في الدليل المنزلي الخطأ، لأن الوحدة لا ترث HOME الخاص بك. عيّن المسار صراحةً باستخدام Environment=SOPS_AGE_KEY_FILE=/etc/sops/age.txt في الوحدة. وبشكل منفصل، لا تؤدي عملية تحرير .sops.yaml إلى إعادة تشفير أي شيء موجود مسبقاً: تؤثر إضافة المفتاح العام لزميل في الملفات الجديدة فقط، لذلك شغّل sops updatekeys secrets.enc.yaml على كل ملف موجود. إذا كان إعدادك يمر بالفعل عبر Ansible، فإن تشفير القيم نفسها باستخدام Ansible Vault يوصلك إلى النتيجة نفسها من دون أداة ثانية.

بيانات اعتماد systemd: أسرار لا تصل إلى البيئة

تتضمن Ubuntu 24.04 الإصدار systemd 255، لذلك لا تحتاج إلى تثبيته. تعمل systemd-creds على تشفير سر على المضيف، ويفك systemd تشفيره داخل دليل خاص لا يمكن للخدمة المعنية وحدها قراءته.

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

تقرأ الخدمة القيمة من ملف اسمه db_password داخل الدليل الذي تحدده $CREDENTIALS_DIRECTORY. لا توجد القيمة في البيئة، لذلك لا يعرض /proc/<pid>/environ شيئاً مفيداً، كما أن النص الصريح لا يُكتب أبداً على نظام الملفات الجذري.

تحقق من إمكانية فك تشفير الملف قبل ربط وحدة systemd به:

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

اعرف المفتاح الذي شُفِّر به الملف، لأن ذلك يحدد ما إذا كانت نسختك الاحتياطية مفيدة. تستخدم --with-key=auto الافتراضياً شريحة TPM2 (وحدة النظام الأساسي الموثوقة، الإصدار 2) عند توفرها وإمكانية استخدامها، وتستخدم مفتاح المضيف في غير ذلك. لا تحتوي معظم مثيلات VPS على TPM2.

systemd-analyze has-tpm2

تعني no أن مفتاح المضيف استُخدم، ويوجد هذا المفتاح في /var/lib/systemd/credential.secret، ولا يمكن قراءته إلا بواسطة root. إذا استعدت db_password.cred على VPS جديد من دون هذا الملف، فلن يتمكن أي شيء من فك تشفيره، مطلقاً. انسخ credential.secret إلى النسخة الاحتياطية نفسها، أو احتفظ بالنص الصريح في مكان لا يزال بإمكانك الوصول إليه.

أسرار Docker: الملفات ضمن /run/secrets

يقرأ Compose ملفاً من المضيف ويحمّله داخل الحاوية في /run/secrets/<name>.

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

يعرض الأمر الأول السر. أما الثاني فيعرض DB_PASSWORD_FILE=/run/secrets/db_password فقط، وهذه هي النقطة الأساسية: لا تظهر القيمة مطلقاً ضمن بيئة الحاوية، ولذلك لا تظهر في مخرجات docker inspect. تتوقع العديد من الصور الرسمية هذا الشكل مسبقاً، وتقرأ صورة Postgres POSTGRES_PASSWORD_FILE بهذه الطريقة تحديداً.

كن واضحاً بشأن طبيعة هذا الأسلوب. خارج وضع Swarm، لا يوجد تشفير في أي طبقة: ./db_password.txt ملف نص عادي على المضيف، والحماية الوحيدة له هي وضعه ومالكه. اضبط كليهما بنفسك، لأن Compose سيحمّل ملفاً قابلاً للقراءة من الجميع من دون إظهار أي تحذير. يرد شرح مجموعة المفاضلات الأوسع مقارنة بالاختصار العادي env_file في الدليل إلى ملفات البيئة والأسرار في Compose.

ما التكلفة الفعلية لتشغيل OpenBao وVault

OpenBao هو تفرّع من HashiCorp Vault تتولى Linux Foundation صيانته، وقد بدأ بعد أن أعادت HashiCorp ترخيص Vault بموجب Business Source License في 2023. يظل OpenBao خاضعاً لترخيص MPL 2.0 (Mozilla Public License). كان الإصدار 2.6.2 هو الإصدار الحالي في أغسطس 2026. ينطبق كل ما يرد أدناه تقريباً على Vault أيضاً، لأن التفرّع أبقى على واجهة الأوامر نفسها.

docker pull docker.io/openbao/openbao

تتوفر حزم Debian وUbuntu في صفحة تنزيلات OpenBao إذا كنت تفضّل أن يتولى apt إدارة التحديثات. يحتاج الخادم إلى ملف إعداد يحتوي على مستمع وواجهة تخزين:

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"
}

ثم شغّله مرة واحدة:

bao operator init

يقسم ذلك مفتاح root افتراضياً إلى 5 حصص، ويتطلب 3 منها لإلغاء الختم. وهما الرايتان -key-shares و-key-threshold. يطبع الحصص ورمز root المميز الأولي مرة واحدة، ولا يطبعهما مجدداً.

وهنا الجزء الذي تتجاهله معظم المقارنات. الخادم الذي أُعيد تشغيله يكون مختوماً. يحتفظ OpenBao بمفتاح root في الذاكرة فقط. لذلك لا يستطيع بعد إعادة التشغيل فك تشفير وحدة التخزين الخاصة به إلى أن يقدّم شخص ما العدد المطلوب من الحصص. لذلك ينتهي تحديث kernel أو إنهاء العملية بسبب نفاد الذاكرة بخادم مختوم وتطبيقات لا تستطيع تسجيل الدخول.

على VPS يديره شخص واحد، لا يوفر تقسيم Shamir حماية فعلية، لأن الحصص الخمس تنتهي في مدير كلمات المرور نفسه الذي يملكه الشخص نفسه. ينقل الإلغاء التلقائي للختم المفتاح إلى جهاز أو خدمة موثوقة. في السحابة الكبيرة يعني ذلك عادةً خدمة مفاتيح مُدارة، أما على VPS فعادةً يعني ملف مفتاح موجوداً على القرص نفسه الذي توجد عليه البيانات التي يحميها. هذا خفض فعلي لمستوى الأمان، مقابل خادم يعود إلى العمل تلقائياً بعد إعادة التشغيل. اتخذ هذا القرار بوعي، وسجّل الخيار الذي اعتمدته.

Infisical: واجهة مستخدم وقاعدة بيانات ومفتاح رئيسي لا يزال بحوزتك

Infisical منصة لإدارة الأسرار، وتوفّر واجهة ويب ومشاريع وبيئات وضبطاً للتحكم في الوصول لكل مستخدم. ويكون استضافتها ذاتياً باستخدام Compose أمراً مختصراً:

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

عدّل .env قبل تنفيذ الأمر الأخير. يجب أن تكون القيمتان ملكك، ويجب ألا تتغير إحداهما بعد ذلك مطلقاً:

openssl rand -hex 16
openssl rand -base64 32

القيمة الأولى هي ENCRYPTION_KEY، وهي سلسلة سداسية عشرية بطول 16 بايت. هذا هو المفتاح الذي تُشفَّر به أسرارك داخل PostgreSQL، لذلك يؤدي فقدانه إلى تحويل نسخة احتياطية سليمة تماماً من قاعدة البيانات إلى مجموعة من النصوص المشفَّرة، ويؤدي تغييره في مثيل قيد التشغيل إلى منع فك تشفير الأسرار الحالية. والقيمة الثانية هي AUTH_SECRET، وهي سلسلة base64 بطول 32 بايت تُستخدم للجلسات. يجب أن تكون SITE_URL عنوان URL المطلق الذي ستصل إليه فعلياً، بما في ذلك البروتوكول، وإلا يفشل إعادة توجيه تسجيل الدخول.

يكون Infisical أنسب من OpenBao عندما تكون حاجتك الفعلية هي إدارة المستخدمين: واجهة ويب لفريق صغير وفصل بين البيئات، بدلاً من بيانات اعتماد قواعد البيانات التي تنتهي صلاحيتها تلقائياً. لكنه يتطلب منك PostgreSQL وRedis وشهادة TLS، وعليك تحديث هذه المكونات ونسخها احتياطياً.

ما الذي يحدث عندما تكون خدمة الأسرار متوقفة ويُعاد تشغيل تطبيقك

يحدد هذا السؤال ما إذا كانت خدمة الأسرار مناسبة للتشغيل على خادم واحد. يمكن قراءة الملفات قبل بدء الشبكة، أما الخدمة فلا يمكن ذلك.

أعد تشغيل الخادم، وسيبدأ تطبيقك وOpenBao في الوقت نفسه. يطلب التطبيق كلمة مرور قاعدة البيانات، بينما لا يزال OpenBao في حالة sealed، فتفشل الطلبات، ويعيد systemd تشغيل التطبيق في حلقة حتى يُدخل أحد المسؤولين unseal shares يدوياً. لا يوجد عطل فعلي. لكن لا شيء يعمل أيضاً.

هناك طريقتان واضحتان للتعامل مع ذلك. رتّب الوحدات واجعل التطبيق يعيد المحاولة: After= خدمة الأسرار، بالإضافة إلى Restart=on-failure وRestartSec= بمدة كافية حتى لا ترسل طلبات متكررة إلى API. أو اجلب السر أثناء النشر بدلاً من وقت الإقلاع: اكتب السر في ملف بصلاحيات mode 600 أو في systemd credential، بحيث يعتمد النظام قيد التشغيل على ملف بدلاً من API.

انتهاء صلاحية الرمز هو المشكلة نفسها، لكن على مقياس زمني أبطأ. تحتوي رموز OpenBao وleases على مدة صلاحية، لذلك يفقد process طويل التشغيل لا يجدد الرمز وصوله في وقت لا يرتبط بأي عملية نشر. يكون هذا الفشل محيراً تحديداً لأن شيئاً لم يتغير في ذلك اليوم.

النسخ الاحتياطي للمتجر نفسه

لكل خيار هنا مفتاح، والنسخة الاحتياطية التي لا تتضمن ذلك المفتاح لا قيمة لها. دوّن مكان وجود مفتاحك.

في حالة ملف env، يكون الملف هو السر، لذلك يجب تشفير النسخة الاحتياطية. في SOPS، يمكن وضع الملف المشفّر في أي مكان عام، أما مفتاح age الخاص الموجود في ~/.config/sops/age/keys.txt فهو الشيء الذي يجب ألّا تفقده. بالنسبة إلى systemd credentials، انسخ /var/lib/systemd/credential.secret احتياطياً إلى جانب ملفات .cred. وبالنسبة إلى Infisical، أنشئ تفريغاً لقاعدة PostgreSQL وخزّن ENCRYPTION_KEY في مكان منفصل عنه.

ينشئ OpenBao مع تخزين raft لقطة خاصة به:

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

تحتوي اللقطة على التخزين المشفّر، لذلك يتطلب استعادتها إلى خادم جديد أيضاً حصص إلغاء القفل الموجودة في bao operator init. إنّ مهمة ليلية تنسخ اللقطات إلى تخزين الكائنات بينما لا تُخزَّن الحصص في أي مكان هي نسخة احتياطية لا تحمي شيئاً. اختبر الاستعادة على VPS مؤقت قبل الاعتماد عليها.

تدقيق السجلات: من قرأ أي سر

لا توفّر الملفات مسار تدقيق. يخبرك النمط والمالك فقط بمن يمكنه قراءة السر. ولا يخبرانك أبداً بمن قرأه فعلياً. يُعد auditd مع مراقبة المسار أقرب بديل، لكنه يوضح أن ملفاً فُتح، ولا يوضح أي قيمة استُخدمت.

يسجّل OpenBao كل طلب في جهاز تدقيق تفعّله صراحةً:

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

هناك حقيقتان بشأن هذا السجل تغيّران طريقة تشغيل الخادم. تُجزّأ معظم السلاسل النصية في الطلبات والاستجابات باستخدام HMAC-SHA256 وملح، لذلك يمكنك مطابقة قيمة تعرفها مسبقاً مع السجل دون أن يحتوي السجل نفسه على النص الصريح. أما الأعداد الصحيحة والقيم المنطقية فتُكتب بصيغتها الواضحة، لذلك لا تحصل الأسرار الرقمية على حماية التجزئة هذه.

ثم يأتي الخطر التشغيلي: لا يستجيب OpenBao للطلبات عندما لا يستطيع أي جهاز تدقيق مفعّل تسجيلها، كما أن الجهاز الذي يتعطل بطريقة حاجبة يجعل الطلبات معلّقة إلى أن يصلحه أحد. امتلاء القرص في /var/log يوقف واجهة برمجة الأسرار عمداً. خصّص مساحة مستقلة لسجل التدقيق وأضف قاعدة logrotate منذ اليوم الأول، لا بعد أول انقطاع.

ما مدير الأسرار المستضاف ذاتياً الذي ينبغي لك تشغيله؟

أحصِ الآلات والأشخاص، ثم اختر.

1. آلة واحدة وشخص واحد: استخدم ملف بيئة بصلاحيات 600، يملكه root ويقرؤه مستخدم الخدمة. أضف بيانات اعتماد systemd عندما تريد إبقاء القيمة خارج بيئة العملية.
2. آلة واحدة وشخصان إلى خمسة أشخاص، مع وجود الإعدادات في git: استخدم SOPS مع age. يحصل كل شخص على زوج مفاتيح، ويسرد .sops.yaml كل مفتاح عام مسموح له بفك التشفير.
3. عدة آلات ومستودع إعدادات واحد، من دون حاجة إلى بيانات اعتماد تنتهي صلاحيتها: استخدم SOPS مع age أيضاً، مع مفتاح مستلم واحد لكل مضيف، بحيث لا يتيح مفتاح مضيف مسروق فك تشفير إلا ملفات ذلك المضيف.
4. عدة آلات وفرق متعددة تحتاج فعلياً إلى بيانات اعتماد قاعدة بيانات ذات مدة صلاحية، مع سجل تدقيق يراجعه أحد: استخدم OpenBao، وخصّص في الميزانية ساعة واحدة شهرياً من وقت المشغّل لتنفيذ تمارين إلغاء الختم والاستعادة.

القاعدة المشتركة بين الحالات الأربع هي نفسها. شغّل أصغر مكوّن يلبّي متطلباً يمكنك صياغته بوضوح، لأن مدير الأسرار المتوقف لا يختلف عملياً عن مدير أسرار فارغ.

FAQ

هل يستحق مدير الأسرار المستضاف ذاتياً الاستخدام على VPS واحد؟

عادةً لا، إذا كنت تقصد خدمة مثل OpenBao أو Infisical. على خادم واحد يستخدمه شخص أو شخصان، يوفّر ملف بيئة بصلاحية 600 أو اعتماد مشفّر في systemd الحماية نفسها من مستخدم محلي آخر، من دون خطوة فك الختم ومن دون خدمة إضافية تحتاج إلى تحديثات أمنية. تبدأ خدمة الأسرار بتبرير تكلفتها عندما يكون لديك عدة أجهزة وعدة أشخاص، أو حاجة فعلية إلى بيانات اعتماد تنتهي صلاحيتها من دون أن يدوّرها أحد يدوياً.

ما الفرق بين مدير كلمات المرور ومدير الأسرار؟

يخزّن مدير كلمات المرور بيانات الاعتماد التي يكتبها شخص، ويفتحه شخص أثناء وجوده. أما مدير الأسرار فيسلّم بيانات الاعتماد إلى العمليات، لذلك يجب أن يعمل عند الساعة 03:00 من دون أن يراقبه أحد. وهذا هو الفرق العملي بينهما: يجبرك مدير كلمات المرور المقفل على إعادة كتابة كلمة المرور الرئيسية، بينما يوقف مدير الأسرار المختوم كل خدمة تعيد التشغيل أثناء بقائه مختوماً.

ماذا يحدث لتطبيقاتي إذا أصبح OpenBao مختوماً بعد إعادة التشغيل؟

لا تستطيع التطبيقات جلب أسرارها، لذلك تفشل في البدء، ويعيد systemd تشغيلها في حلقة إلى أن يوفّر أحدهم حد فك الختم، وهو 3 من أصل 5 أجزاء افتراضياً. يحتفظ OpenBao بالمفتاح الجذر في الذاكرة فقط، لذلك يعيد كل تشغيل ختمه. يمكنك تفعيل فك الختم التلقائي، مع قبول أن مفتاح فك الختم على VPS واحد سينتهي به الأمر على القرص نفسه الذي توجد عليه البيانات، أو إنشاء الأسرار في ملف وقت النشر حتى لا يعتمد الإقلاع مطلقاً على API.

هل يمكنني إيداع ملفات SOPS المشفّرة في مستودع عام؟

القيم مشفّرة، لذلك تكون محمية من أي شخص لا يملك مفتاح age الخاص. أما المفاتيح نفسها فليست مشفّرة: يستطيع القارئ رؤية أنك تحتفظ بـ STRIPE_SECRET_KEY وSMTP_PASSWORD، ومعرفة معدل تغيّر كل منهما. تكون هذه البيانات الوصفية مقبولة في معظم المشاريع وغير مقبولة في بعض المشاريع. أبقِ مفتاح age الخاص خارج المستودع، وشغّل sops updatekeys على كل ملف موجود كلما أضفت مستلماً أو أزلته.