أفضل أدوات إدارة أسرار Kubernetes في عام 2026: Vault وESO وSealed Secrets والمزيد

تحتوي كل مجموعة Kubernetes على كائن “سري” مدمج. يبدو مثل الأمن. إنه شعور مثل الأمن. إنه ليس الأمن.

افتراضيًا، يعد سر Kubernetes مجرد سلسلة مشفرة بقاعدة 64 مخزنة في الخ - يمكن قراءتها من قبل أي شخص لديه وصول إلى المجموعة ويمكن فك تشفيرها بشكل تافه باستخدام سطر واحد: echo "c2VjcmV0" | Base64 -د. ما لم تقم بتمكين التشفير أثناء الراحة بشكل صريح (ومعظم الفرق لم تفعل ذلك)، فإن كلمات مرور قاعدة البيانات الخاصة بك، والرموز المميزة لواجهة برمجة التطبيقات (API)، ومفاتيح TLS الخاصة تظل غير مشفرة في مخزن بيانات مستوى التحكم الخاص بمجموعتك. قم بتنفيذ بيان Kubernetes الذي يحتوي على “سر” لـ Git، وستظل بيانات الاعتماد هذه في تاريخ المستودع الخاص بك إلى الأبد.

هذه هي المشكلة التي ظهر جيل جديد من أدوات إدارة الأسرار لحلها - وفي عام 2026، نضج النظام البيئي بشكل كبير. يغطي هذا الدليل أهم ستة أدوات لإدارة الأسرار في بيئات Kubernetes: ما يفعلونه، وما لا يفعلونه، وأي منها يناسب مستوى نضج فريقك.

قراءة ذات صلة: إذا كنت قلقًا بشأن تسرب الأسرار عبر مسار CI/CD، فراجع تقريرنا عن أفضل أدوات مسار CI/CD. للحصول على صورة أوسع لأمن الحاويات، راجع دليل أدوات فحص الثغرات الأمنية.

لماذا تفشل أسرار Kubernetes الافتراضية؟

قبل التعمق في الأدوات، من المفيد أن تكون دقيقًا بشأن ما تفتقر إليه Kubernetes Secrets — لأن فهم الفجوة هو ما يتيح لك اختيار الحل الصحيح.

** لا يوجد تشفير في حالة عدم النشاط بشكل افتراضي. ** يقوم etcd بتخزين أسرار Kubernetes كـ base64، غير مشفر. يعد تمكين التشفير في حالة الراحة خطوة تكوين على مستوى المجموعة يتعامل معها موفرو Kubernetes المُدارون (EKS وGKE وAKE) بشكل مختلف، وتتخطاها العديد من المجموعات المُدارة ذاتيًا بالكامل.

لا يوجد دوران سري. لا توجد آلية مدمجة لسر Kubernetes لمعرفة أن بيانات اعتماد الدعم الخاصة به قد تغيرت. يمكنك تدوير كلمة مرور قاعدة البيانات خارجيًا، وتستمر الكبسولات الخاصة بك في استخدام الكلمة القديمة حتى تقوم بتحديث السر يدويًا وإعادة تشغيل البودات المتأثرة.

لا يوجد سجل تدقيق للوصول السري. سجلات تسجيل تدقيق Kubernetes القياسية تعديلات الكائن السرية، ولكن معظم التكوينات لا تسجل عمليات القراءة الفردية - مما يعني أنه لا يمكنك الإجابة على “ما هي الخدمة التي وصلت إلى هذا الرمز المميز ومتى؟”

Git معاد حسب التصميم. النصيحة القياسية هي “لا تلتزم أبدًا بالأسرار لـ Git.” ولكن في عالم GitOps حيث يكون كل شيء بمثابة رمز هو الهدف، يعد الحفاظ على هذا الاستثناء مؤلمًا.

RBAC كأداة غير حادة. يتيح لك Kubernetes RBAC منح أو رفض الوصول إلى الكائنات السرية على مستوى مساحة الاسم. لا يمكنها التعبير عن “الخدمة أ يمكنها قراءة السر X ولكن ليس السر Y”، أو “تنتهي صلاحية هذا السر خلال 24 ساعة.”

لا يعد أي من هذه الأسباب سببًا للتخلي عن Kubernetes، بل هو سبب لاستخدام أدوات مخصصة لإدارة الأسرار فوقه.

TL;DR — مقارنة الميزات

⚠️ = يتطلب مكونات إضافية

1. HashiCorp Vault — المعيار الذهبي لأسرار المؤسسات

HashiCorp Vault هو المعيار الذي يتم من خلاله قياس كل أدوات إدارة الأسرار الأخرى. لقد تم اختباره في بيئات المؤسسات لما يقرب من عقد من الزمن، وتعكس مجموعة ميزاته هذا العمق.

القدرة الأساسية لـ Vault هي الأسرار الديناميكية — بيانات الاعتماد التي يتم إنشاؤها عند الطلب وتنتهي صلاحيتها تلقائيًا. بدلاً من تخزين كلمة مرور PostgreSQL ثابتة، يقوم Vault بإنشاء زوج فريد من اسم المستخدم/كلمة المرور لكل خدمة طالبة، وتكون صالحة لفترة إيجار قابلة للتكوين (على سبيل المثال، ساعة واحدة). عند انتهاء عقد الإيجار، يتم إبطال بيانات الاعتماد. يؤدي هذا إلى التخلص من فئات كاملة من اتساع بيانات الاعتماد ويجعل احتواء الاختراقات أسهل بشكل كبير.

بالنسبة إلى Kubernetes، فإن Vault Agent Injector أو Vault Secrets Operator هي مسارات التكامل. يعمل الحاقن كخطاف ويب متحول يقوم تلقائيًا بنقل وكيل Vault إلى الكبسولات الخاصة بك، والذي يقوم بالمصادقة على Vault باستخدام حساب خدمة Kubernetes الخاص بالبود ويكتب الأسرار إلى وحدة تخزين مشتركة في الذاكرة. يقوم Vault Secrets Operator (VSO)، وهو النهج الأحدث، بمزامنة أسرار Vault مع كائنات Kubernetes السرية الأصلية - وهي مألوفة أكثر للمشغلين، على حساب الأسرار الموجودة لفترة وجيزة وما إلى ذلك.

** محركات Vault السرية ** تغطي نطاقًا رائعًا:

• بيانات اعتماد قاعدة البيانات (PostgreSQL، وMySQL، وMongoDB، والمزيد)
• بيانات الاعتماد الديناميكية AWS وGCP وAzure
• إنشاء شهادات PKI وTLS
• توقيع شهادة SSH
• الرموز المميزة لحساب خدمة Kubernetes

ما يفعله Vault بشكل جيد: بيانات الاعتماد الديناميكية، وسياسات الوصول الدقيقة، وسجل التدقيق الشامل، ونظام بيئي إضافي ناضج. إذا كنت بحاجة إلى إدارة سرية على مستوى الامتثال مع تتبع كامل لمن قام بالوصول وماذا ومتى، فغالبًا ما يكون Vault هو الخيار المعقول الوحيد.

ما يجب الحذر منه: يتميز Vault بتعقيد تشغيلي. يتطلب تشغيله في وضع التوفر العالي اهتمامًا دقيقًا بواجهات التخزين الخلفية (يُعد Raft الآن الخيار الموصى به)، وإجراءات الكشف، ومسارات الترقية. منحنى التعلم حقيقي. ميزانية وقت هندسة المنصة.

السعر: الإصدار مفتوح المصدر مجاني ويغطي معظم الاحتياجات. HashiCorp Cloud Platform (HCP) Vault هو العرض المُدار بسعر يعتمد على ساعات المجموعة والعمليات السرية. أدى [تغيير ترخيص BSL] (https://www.hashicorp.com/blog/hashicorp-adopts-business-source-license) اعتبارًا من عام 2023 إلى ظهور شوكة OpenTofu لـ Terraform، ولكن ما يعادل شوكة Vault (OpenBao) لا يزال في مرحلة النضج.

📚 القراءة الموصى بها: Hacking Kubernetes بقلم Andrew Martin وMichael Hausenblas - تغطية ممتازة لأسطح هجوم Kubernetes بما في ذلك سيناريوهات التسلل السرية.

2. مشغل الأسرار الخارجية (ESO) — طبقة التكامل الأصلية لـ K8s

يتخذ مشغل الأسرار الخارجية موقفًا معماريًا مختلفًا تمامًا: فبدلاً من كونه متجر أسرار في حد ذاته، فهو عبارة عن جسر بين Kubernetes وأي متجر خارجي لديك بالفعل. يقوم ESO بمزامنة الأسرار من AWS Secrets Manager، وGCP Secret Manager، وAzure Key Vault، وHashiCorp Vault، و1Password، وDoppler، وقائمة متزايدة من الواجهات الخلفية الأخرى في كائنات Kubernetes Secret الأصلية.

التجريد الأساسي هو المورد المخصص ExternalSecret:

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: database-credentials
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-secrets-manager
    kind: ClusterSecretStore
  target:
    name: db-creds
  data:
    - secretKey: password
      remoteRef:
        key: production/db/password

تراقب ESO هذا المورد، وتجلب السر من AWS Secrets Manager (أو من أي مكان)، وتقوم بإنشاء سر Kubernetes قياسي. يقرأ تطبيقك “db-creds” تمامًا مثل أي سر آخر من أسرار Kubernetes - ولا يلزم إجراء تغييرات في التعليمات البرمجية. عند تحديد refreshInterval، يقوم ESO بإعادة جلب السر وتحديثه تلقائيًا.

** لماذا تحظى ESO بشعبية كبيرة في عام 2026: ** إنها تعمل بشكل جيد مع الاستثمارات الحالية. تمتلك مؤسستك بالفعل AWS Secrets Manager (أو Vault، أو GCP Secret Manager) - تجعل ESO هذه الأسرار قابلة للاستهلاك في Kubernetes دون تغيير رمز التطبيق الخاص بك أو سير عمل التناوب السري الحالي.

ESO أو Vault Secrets Operator؟ إذا كنت تقوم بتشغيل Vault، فإن VSO يتمتع بتكامل أكثر إحكامًا خاصًا بـ Vault (أسرار Vault الديناميكية، Vault PKI). إذا كنت في المتجر السري الأصلي لموفر السحابة، فإن ESO هو الخيار الأنظف. تقوم العديد من الفرق بتشغيل كليهما — ESO للأسرار الثابتة المخزنة على السحابة، وVSO لبيانات الاعتماد الديناميكية المُدارة بواسطة Vault.

السعر: ESO مجاني ومفتوح المصدر (Apache 2.0)، ويتم صيانته بواسطة مشروع وضع الحماية CNCF بدعم قوي من المجتمع.

3. الأسرار المختومة — أسرار مشفرة متوافقة مع GitOps

[الأسرار المختومة] (https://github.com/bitnami-labs/sealed-secrets) من Bitnami تحل مشكلة محددة: كيف يمكنك تخزين بيانات Kubernetes Secret في Git دون تخزين النص العادي الفعلي؟ الجواب هو التشفير غير المتماثل.

تعمل وحدة التحكم Sealed Secrets في مجموعتك وتحمل مفتاحًا خاصًا. تقوم واجهة سطر الأوامر “kubeseal” بتشفير بيان Kubernetes Secret باستخدام المفتاح العام للمجموعة، مما ينتج عنه CRD “SealedSecret”. يمكن التزام هذا البيان المشفر بـ Git بأمان - فقط المفتاح الخاص للمجموعة يمكنه فك تشفيره، ولا يمكن فك تشفيره إلا في تلك المجموعة المحددة (افتراضيًا، يرتبط النص المشفر بمساحة الاسم + الاسم).

# Encrypt a secret for Git storage
kubectl create secret generic db-creds \
  --from-literal=password=s3cr3t \
  --dry-run=client -o yaml | \
  kubeseal --format=yaml > db-creds-sealed.yaml

# This file is safe to commit
git add db-creds-sealed.yaml

عند تطبيق “SealedSecret” على المجموعة، تقوم وحدة التحكم بفك تشفيرها وإنشاء الكائن “Secret” المقابل.

** ما هي الأسرار المختومة التي تعمل بشكل جيد: ** سير عمل GitOps. إذا كنت تستخدم Argo CD أو Flux وتريد تخزين كل موارد المجموعة (بما في ذلك الأسرار) بشكل صريح في Git، فإن Sealed Secrets يناسب هذا النموذج تمامًا. لا يتطلب أي تبعيات خارجية تتجاوز وحدة التحكم داخل المجموعة.

ما لا يفعله: التناوب أو بيانات الاعتماد الديناميكية أو تسجيل التدقيق بما يتجاوز أحداث Kubernetes القياسية. إن Sealed Secrets هو أحد حلول تخزين Git، وليس منصة كاملة لإدارة الأسرار. إذا تغيرت كلمة المرور الخاصة بك، فيمكنك إعادة التشفير والالتزام مرة أخرى.

النسخ الاحتياطي للمفتاح الخاص أمر بالغ الأهمية. إذا فقدت المفتاح الخاص لوحدة التحكم، فستفقد القدرة على فك تشفير أسرارك المختومة. قم بعمل نسخة احتياطية من سر “مفتاح الأسرار المختومة” في مكان منفصل وآمن.

التسعير: مجاني بالكامل ومفتوح المصدر (Apache 2.0).

4. مدير أسرار AWS مع Kubernetes

إذا كانت أعباء العمل الخاصة بك تعمل بشكل أساسي على EKS (أو تتصل بشكل كبير بخدمات AWS)، فإن AWS Secrets Manager المقترن بـ Secrets Store CSI Driver أو مشغل الأسرار الخارجية يكون مناسبًا بشكل طبيعي. يمكنك الاحتفاظ بالأسرار في متجر AWS المُدار والمشفر والمسجل بالتدقيق وسحبها إلى Kubernetes عند الحاجة.

Secrets Store CSI Driver (SSCSID) هو النهج الذي يتم الحفاظ عليه من قبل CNCF: يتم تثبيت الأسرار مباشرة في القرون كملفات عبر وحدة تخزين CSI، ولا تتم كتابتها أبدًا إلى إلخ ككائنات Kubernetes Secret. هذا هو المسار الأكثر أمانًا - الأسرار موجودة في ذاكرة الكبسولة ولكن ليس في متجر Kubernetes Secret.

volumes:
  - name: secrets-store
    csi:
      driver: secrets-store.csi.k8s.io
      readOnly: true
      volumeAttributes:
        secretProviderClass: aws-secrets

تتضمن إمكانيات AWS Secrets Manager الأصلية التدوير التلقائي للخدمات المدعومة (RDS وRedshift وDocumentDB وعبر Lambda للتدوير المخصص)، والوصول عبر الحسابات، والتكامل العميق مع CloudTrail لمسارات تدقيق الامتثال.

النظر في التكلفة: يتقاضى AWS Secrets Manager رسومًا لكل سر شهريًا ولكل استدعاء لواجهة برمجة التطبيقات. بالنسبة للأساطيل الكبيرة التي تحتوي على العديد من الأسرار الصغيرة، يمكن أن تزيد التكاليف. راجع دليل تحسين تكلفة السحابة للتعرف على إستراتيجيات إدارة إنفاق AWS المتعلق بالسرية.

الأفضل لـ: فرق EKS الأصلية التي استثمرت بالفعل في نظام AWS البيئي والتي ترغب في تكامل IAM المحكم وتناوب بيانات اعتماد RDS الأصلية.

5. دوبلر — أول منصة لأسرار SaaS للمطورين

يتبع Doppler نهج SaaS أولاً الذي يعطي الأولوية لتجربة المطور على التعقيد التشغيلي. يمكنك تحديد الأسرار في واجهة مستخدم Doppler (أو عبر CLI/API)، وتنظيمها حسب البيئة (التطوير، والتدريج، والإنتاج)، ويقوم مشغل Doppler Kubernetes بمزامنتها في Kubernetes Secrets تلقائيًا.

يقوم المشغل باستطلاع Doppler بحثًا عن التغييرات ويقوم بتحديث Kubernetes Secret المقابل، مما يؤدي بشكل اختياري إلى إعادة تشغيل الكبسولة عند تغيير الأسرار. الإعداد عبارة عن تثبيت مخطط Helm واحد:

helm repo add doppler https://helm.doppler.com
helm install --generate-name doppler/doppler-kubernetes-operator

حيث يتألق دوبلر: التنمية المحلية وتكامل CI/CD جنبًا إلى جنب مع Kubernetes. يستبدل Doppler CLI ملفات البيئة بالكامل (“doppler run – your-command”)، مما يوفر نفس الأسرار عبر البيئات المحلية وCI وبيئات الإنتاج. بالنسبة إلى خطوط أنابيب CI/CD، فإن عمليات تكامل Doppler الأصلية مع GitHub Actions وCircleCI وغيرها تلغي الحاجة إلى نسخ الأسرار إلى متغيرات بيئة خطوط الأنابيب.

** ما لا يغطيه دوبلر: ** بيانات اعتماد قاعدة البيانات الديناميكية. Doppler عبارة عن مخزن أسرار ثابت يحتوي على سجل الإصدارات وتسجيل التدقيق - وهو ليس محرك توليد سري مثل Vault.

السعر: تقدم دوبلر طبقة مجانية للفرق الصغيرة. تضيف الخطط المدفوعة تسجيل الدخول الموحّد (SSO) وطلبات الوصول وميزات الامتثال. تحقق من صفحة تسعير Doppler لمعرفة المستويات الحالية (تغييرات التسعير؛ تحقق قبل وضع الميزانية).

6. Infisical — بديل Vault مفتوح المصدر

Infisical هو أقوى منافس مفتوح المصدر لاحتكار Vault/Doppler الثنائي. فهو يوفر واجهة مستخدم ويب، وCLI، وSDK، ومشغل Kubernetes - يمكن نشره أو استضافته ذاتيًا أو استهلاكه كخدمة سحابية.

أضاف Infisical دعم الأسرار الديناميكية في عام 2024، مستهدفًا إنشاء بيانات اعتماد قاعدة البيانات المشابهة لمحرك أسرار قاعدة بيانات Vault. يقوم مشغل Infisical Kubernetes بمزامنة CRDs InfisicalSecret مع Kubernetes Secrets الأصلية، مع فترات تحديث قابلة للتكوين.

بالنسبة للفرق التي تريد تجربة مستخدم على مستوى SaaS (لوحة تحكم الويب، وسير عمل طلب الوصول، وسجلات التدقيق) ولكن لا يمكنها استخدام SaaS خارجي بسبب متطلبات الامتثال، فإن الاستضافة الذاتية Infisical مقنعة. يعد تشغيله أسهل بكثير من Vault ويتمتع بتجربة إعداد أكثر ملاءمة للمطورين.

التسعير: النواة مفتوحة المصدر مجانية. يحتوي الإصدار المستضاف على السحابة على طبقة مجانية وخطط مدفوعة للميزات المتقدمة. يتوفر ترخيص المؤسسة ذاتية الاستضافة للبيئات شديدة الامتثال.

📚 للتعمق أكثر في بنية أمان Kubernetes: Kubernetes Security and Observability على Amazon يغطي الأسرار وRBAC وسياسة الشبكة وأمن وقت التشغيل في إطار عمل واحد متماسك.

نصائح التنفيذ

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

اعتماد RBAC الأقل امتيازًا للأسرار. قم بمراجعة حسابات الخدمة التي تتمتع بأذونات “الحصول على”، أو “القائمة”، أو “المراقبة” على الكائنات السرية. يتم توفير حسابات الخدمة الافتراضية في العديد من مخططات Helm بشكل زائد. قم بتشديد RBAC قبل التبديل إلى متجر خارجي.

** خطط لاصطلاحات التسمية السرية مبكرًا. ** تتكاثر الأسرار بسرعة. يعمل التسلسل الهرمي المتسق ({env}/{service}/{credential-type}) على جعل التشغيل الآلي وسياسات RBAC وسير عمل التناوب أكثر بساطة بشكل كبير عبر جميع الأدوات.

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

مراقبة الزحف السري. مع نمو منصتك، تتراكم الأسرار. قم بدمج تقارير إدارة الأسرار في لوحات معلومات هندسة النظام الأساسي لديك. راجع دليل أدوات مراقبة Kubernetes للتعرف على أدوات المراقبة التي يمكنها تتبع أنماط الوصول السرية.

ما هي الأداة المناسبة لأي فريق؟

فريق صغير، سحابي أصلي (AWS/GCP/Azure): ابدأ مع مشغل الأسرار الخارجية الذي يتصل بالمتجر السري الأصلي لموفر السحابة الخاص بك. الحد الأدنى من النفقات التشغيلية، وتكامل التدقيق القوي، مجانًا.

** فريق GitOps الأول (Argo CD / Flux): ** الأسرار المختومة للتكوين المخزن على GitOps، جنبًا إلى جنب مع ESO لبيانات اعتماد وقت التشغيل الحساسة التي لا ينبغي حتى أن تكون مشفرة في Git.

مؤسسة ذات متطلبات الامتثال (SOC 2، PCI، HIPAA): HashiCorp Vault — إما مجموعة Raft المستضافة ذاتيًا أو HCP Vault المدارة. من الصعب تكرار سجل التدقيق وبيانات الاعتماد الديناميكية ومحرك السياسات الدقيق في أي مكان آخر.

** بيئة مختلطة تركز على تجربة المطورين (K8s + local + CI/CD): ** Doppler لـ DX الموحد عبر البيئات، أو الاستضافة غير المالية ذاتيًا إذا كانت إقامة البيانات مهمة.

** فريق منصة كبير يدير بيئات متعددة المجموعات: ** مشغل الأسرار الخارجية كطبقة تجريد من جانب K8s، مدعومة بـ Vault أو متجر سحابي أصلي. يعد مركزية مصدر الحقيقة في متجر واحد أثناء استخدام ESO كمحول عالمي عبر المجموعات نمطًا مثبتًا جيدًا في عام 2026.

ذات صلة: بالنسبة للمخاطر الأمنية التي تقدمها أدوات تشفير الذكاء الاصطناعي في بيانات Kubernetes ومسارات CI/CD، راجع دليلنا حول مخاطر أمان vibe coding في 2026.

التعليمات

هل أسرار Kubernetes مشفرة افتراضيًا؟

لا، أسرار Kubernetes يتم ترميزها باستخدام base64 افتراضيًا، وهي تشفير وليس تشفير. يتم تخزين البيانات في إلخ بدون تشفير ما لم تقم بتمكين التشفير أثناء الراحة بشكل صريح. تحقق دائمًا من تكوين المجموعة الخاصة بك وفكر في أدوات إدارة الأسرار الخارجية لأحمال عمل الإنتاج.

ما الفرق بين الأسرار المختومة ومشغل الأسرار الخارجية؟

تقوم شركة Sealed Secrets بتشفير البيانات السرية لتخزين Git بشكل آمن - إنه أحد حلول GitOps. يقوم مشغل الأسرار الخارجية بجلب الأسرار المباشرة من المتاجر الخارجية (Vault، AWS Secrets Manager، وما إلى ذلك) ويقوم بإنشاء أسرار Kubernetes الأصلية منها. إنها تحل مشكلات مختلفة وغالبًا ما يتم استخدامها معًا.

ما هي الأسرار الديناميكية وما سبب أهميتها؟

الأسرار الديناميكية هي بيانات اعتماد يتم إنشاؤها عند الطلب مع انتهاء الصلاحية التلقائي - بدلاً من كلمات المرور الثابتة المخزنة إلى أجل غير مسمى. يعد HashiCorp Vault المصدر الأساسي للأسرار الديناميكية لـ Kubernetes. إذا تم اختراق بيانات الاعتماد الديناميكية، فستنتهي صلاحيتها وفقًا للجدول الزمني الخاص بها. وهذا يحد بشكل كبير من نصف قطر انفجار الاختراق مقارنة بالأسرار الثابتة طويلة العمر.

هل يجب أن أستخدم Doppler أو HashiCorp Vault لـ Kubernetes؟

يفوز دوبلر بتجربة المطورين والاعتماد السريع. يفوز Vault بفضل امتثال المؤسسة - بيانات الاعتماد الديناميكية، وسجلات التدقيق الدقيقة، والسياسة الدقيقة. بالنسبة للفرق الصغيرة والمتوسطة الحجم، غالبًا ما يكون دوبلر هو المسار الأسرع. بالنسبة لبيئات SOC 2 أو PCI DSS أو HIPAA، عادةً ما يكون Vault هو الخيار الأكثر قابلية للدفاع.

كيف يمكنني منع تسرب الأسرار إلى سجلات الحاوية؟

قم بتحميل الأسرار كملفات بدلاً من متغيرات البيئة (يمكن كشف متغيرات البيئة من خلال /proc ونقاط نهاية التصحيح). استخدم برنامج تشغيل Secrets Store CSI لتجاوز etcd بالكامل. قم بالبحث عن الالتزامات السرية غير المقصودة في مسار CI/CD الخاص بك باستخدام أدوات مثل الماسح الضوئي السري الخاص بـ Trivy - راجع دليل أدوات فحص الثغرات الأمنية للحصول على تفاصيل الإعداد.

ما هي أفضل أداة لإدارة الأسرار لفريق Kubernetes الصغير؟

ابدأ باستخدام مشغل الأسرار الخارجية المدعوم من المتجر السري الأصلي لموفر الخدمة السحابية لديك. الحد الأدنى من النفقات العامة للعمليات، وسجلات التدقيق القوية، مجانًا. أضف طبقة Doppler المجانية إذا كنت تريد أيضًا تجربة أسرار تطوير/CI/إنتاج موحدة.

كيف يمكنني دمج AWS Secrets Manager مع Kubernetes؟

استخدم عامل الأسرار الخارجية مع ClusterSecretStore الذي يشير إلى AWS Secrets Manager. في EKS، استخدم IRSA (أدوار IAM لحسابات الخدمة) لمصادقة IAM على مستوى الحاوية - لا حاجة إلى بيانات اعتماد ثابتة. في المجموعات غير التابعة لـ EKS، استخدم مستخدم IAM مع Secretsmanager:GetSecretValue الذي تم تحديد نطاقه لأسماء ARN السرية الخاصة بك.