أصبح الآن مطلوبًا أن تعمل الكتلة على Kubernetes >=1.19.

سيتم إهمال التسميات (labels) المتجاوزة التي تحتوي على تعليقات توضيحية (annotations) غير مسجلة من kubernetes.io. سيكون من الضروري قريبًا استخدام kubeaudit.io بدلاً من ذلك. يرجى الرجوع إلى هذه المناقشة لمزيد من السياق.

🚨 إشعار الإهمال 🚨

من المقرر إهمال Kubeaudit بحلول أكتوبر 2024.

نحن نبحث بنشاط عن مطورين مهتمين بتولي مسؤولية هذا المشروع. إذا كنت شغوفًا بمواصلة تطويره وصيانته، فيرجى التواصل معنا.

للمستخدمين الذين يبحثون عن بدائل، نوصي بالانتقال إلى Kubebench، الذي يوفر وظائف مماثلة ويتم صيانته بنشاط.

نشكر المجتمع على مساهماتكم ودعمكم.

kubeaudit ☁️ 🔒 💪

kubeaudit هي أداة سطر أوامر وحزمة Go لتدقيق مجموعات Kubernetes لمخاوف أمنية متنوعة، مثل:

• التشغيل كمستخدم غير root
• استخدام نظام ملفات جذري للقراءة فقط
• إسقاط القدرات المخيفة، وعدم إضافة قدرات جديدة
• عدم التشغيل بامتيازات
• والمزيد!

باختصار. kubeaudit يضمن لك نشر حاويات آمنة!

الحزمة

لاستخدام kubeaudit كحزمة Go، راجع وثائق الحزمة.

سيركز باقي ملف README هذا على كيفية استخدام kubeaudit كأداة سطر أوامر.

واجهة سطر الأوامر (CLI)

• التثبيت
• البدء السريع
• نتائج التدقيق
• الأوامر
• ملف التكوين
• تجاوز الأخطاء
• المساهمة

التثبيت

Brew

brew install kubeaudit

تنزيل نسخة ثنائية

لدى Kubeaudit إصدارات رسمية مباركة ومستقرة: الإصدارات الرسمية

بناء DIY

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

go get -v github.com/Shopify/kubeaudit

ابدأ استخدام kubeaudit من خلال البدء السريع أو اعرض جميع الأوامر المدعومة.

إضافة Kubectl

المتطلب الأساسي: kubectl v1.12.0 أو أحدث

مع إصدار kubectl v1.12.0 الذي يقدم قابلية الإضافة بسهولة للوظائف الخارجية، يمكن استدعاء kubeaudit كـ kubectl audit عن طريق:

• تشغيل make plugin وجعل $GOPATH/bin متاحًا في مسارك.

أو

• إعادة تسمية الملف الثنائي إلى kubectl-audit وجعله متاحًا في مسارك.

Docker

لم نعد ننشر الصور إلى Docker Hub (منذ أن أوقفت Docker Hub خطط المؤسسات المجانية). في الوقت الحالي، الصور القديمة لا تزال متاحة ولكن قد تتوقف عن التوفر في أي وقت. سنبدأ في نشر الصور إلى سجل حاويات Github قريبًا.

لتشغيل kubeaudit كوظيفة في مجموعتك، راجع تشغيل kubeaudit في مجموعة.

البدء السريع

لدى kubeaudit ثلاثة أوضاع:

1. وضع المانيفست
2. الوضع المحلي
3. وضع الكتلة

وضع المانيفست

إذا تم توفير ملف مانيفست Kubernetes باستخدام العلامة -f/--manifest، سيقوم kubeaudit بتدقيق ملف المانيفست.

مثال الأمر:

kubeaudit all -f "/path/to/manifest.yml"

مثال الإخراج:

$ kubeaudit all -f "internal/test/fixtures/all_resources/deployment-apps-v1.yml"

---------------- النتائج لـ ---------------

  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: deployment
    namespace: deployment-apps-v1

--------------------------------------------

-- [خطأ] AppArmorAnnotationMissing
   الرسالة: التعليق التوضيحي لـ AppArmor مفقود. يجب إضافة التعليق التوضيحي 'container.apparmor.security.beta.kubernetes.io/container'.
   البيانات الوصفية:
      الحاوية: container
      التعليق التوضيحي المفقود: container.apparmor.security.beta.kubernetes.io/container

-- [خطأ] AutomountServiceAccountTokenTrueAndDefaultSA
   الرسالة: حساب الخدمة الافتراضي مع الرمز المميز مركب. يجب تعيين automountServiceAccountToken إلى 'false' أو يجب استخدام حساب خدمة غير افتراضي.

-- [خطأ] CapabilityShouldDropAll
   الرسالة: لم يتم تعيين القدرة إلى ALL. من الأفضل إسقاط جميع القدرات وإضافة القدرات المحددة التي تحتاجها إلى قائمة الإضافة.
   البيانات الوصفية:
      الحاوية: container
      القدرة: AUDIT_WRITE
...

إذا لم يتم العثور على أي أخطاء ذات خطورة دنيا معينة، يتم إرجاع ما يلي:

تم الانتهاء من جميع الفحوصات. تم العثور على 0 ثغرات عالية الخطورة.

الإصلاح التلقائي

يدعم وضع المانيفست أيضًا الإصلاح التلقائي لجميع المشكلات الأمنية باستخدام الأمر autofix:

kubeaudit autofix -f "/path/to/manifest.yml"

لكتابة المانيفست المُصلَح إلى ملف جديد بدلاً من تعديل الملف المصدر، استخدم العلامة -o/--output.

kubeaudit autofix -f "/path/to/manifest.yml" -o "/path/to/fixed"

لإصلاح مانيفست بناءً على قواعد مخصصة محددة في ملف تكوين kubeaudit، استخدم العلامة -k/--kconfig.

kubeaudit autofix -k "/path/to/kubeaudit-config.yml" -f "/path/to/manifest.yml" -o "/path/to/fixed"

وضع الكتلة

يمكن لـ Kubeaudit اكتشاف ما إذا كان يعمل داخل حاوية في الكتلة. إذا كان الأمر كذلك، فسيحاول تدقيق جميع موارد Kubernetes في تلك الكتلة:

kubeaudit all

الوضع المحلي

سيحاول Kubeaudit الاتصال بكتلة باستخدام ملف kubeconfig المحلي ($HOME/.kube/config). يمكن تحديد موقع kubeconfig مختلف باستخدام العلامة --kubeconfig. لتحديد سياق kubeconfig، استخدم العلامة -c/--context.

kubeaudit all --kubeconfig "/path/to/config" --context my_cluster

لمزيد من المعلومات حول ملفات تكوين kubernetes، راجع https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/

نتائج التدقيق

ينتج Kubeaudit نتائج بثلاث مستويات من الخطورة:

• خطأ: مشكلة أمنية أو تكوين Kubernetes غير صحيح
• تحذير: توصية بأفضل الممارسات
• معلومات: إعلامي، لا يتطلب إجراءً. يتضمن ذلك النتائج التي تم تجاوزها

يمكن تعيين الحد الأدنى لمستوى الخطورة باستخدام العلامة --minSeverity/-m.

بشكل افتراضي، سيقوم kubeaudit بإخراج النتائج بطريقة قابلة للقراءة البشرية. إذا كان الإخراج مخصصًا لمزيد من المعالجة، يمكن ضبطه لإخراج JSON باستخدام العلامة --format json. لإخراج النتائج كسجلات (الافتراضي السابق) استخدم --format logrus. تتضمن بعض تنسيقات الإخراج ألوانًا لتسهيل قراءة النتائج في الطرفية. لتعطيل الألوان (على سبيل المثال، إذا كنت ترسل الإخراج إلى ملف نصي)، يمكنك استخدام العلامة --no-color.

يمكنك إنشاء تقرير kubeaudit بتنسيق SARIF باستخدام العلامة --format sarif. لكتابة نتائج SARIF إلى ملف، يمكنك إعادة توجيه الإخراج باستخدام >. على سبيل المثال:

kubeaudit all -f path-to-my-file.yaml --format="sarif" > example.sarif

إذا كانت هناك نتائج بمستوى خطورة error، فسيخرج kubeaudit برمز خروج 2. يمكن تغيير ذلك باستخدام العلامة --exitcode/-e.

لجميع طرق تخصيص kubeaudit، راجع العلامات العامة.

الأوامر

المدققون

يمكن أيضًا تشغيل المدققين بشكل فردي.

العلامات العامة

ملف التكوين

يمكن استخدام تكوين kubeaudit لشيئين:

1. تمكين بعض المدققين فقط
2. تحديد تكوين للمدققين

يمكن تمثيل أي تكوين يمكن تحديده باستخدام علامات للمدققين الفرديين باستخدام التكوين.

التكوين له التنسيق التالي:

enabledAuditors:
  # المدققون ممكّنون افتراضيًا إذا لم يتم تعيينهم صراحةً إلى "false"
  apparmor: false
  asat: false
  capabilities: true
  deprecatedapis: true
  hostns: true
  image: true
  limits: true
  mounts: true
  netpols: true
  nonroot: true
  privesc: true
  privileged: true
  rootfs: true
  seccomp: true
auditors:
  capabilities:
    # أضف القدرات المطلوبة إلى قائمة الإضافة، حتى لا يبلغ kubeaudit عن أخطاء
    allowAddList: ['AUDIT_WRITE', 'CHOWN']
  deprecatedapis:
    # إذا لم يتم تحديد إصدارات وتم تمكين مدقق 'deprecatedapis'، سيتم إنشاء نتائج WARN
    # للموارد المحددة بإصدار API مهمل.
    currentVersion: '1.22'
    targetedVersion: '1.25'
  image:
    # إذا لم يتم تحديد صورة وتم تمكين مدقق 'image'، سيتم إنشاء نتائج WARN
    # للحاويات التي تستخدم صورة بدون علامة
    image: 'myimage:mytag'
  limits:
    # إذا لم يتم تحديد حدود وتم تمكين مدقق 'limits'، سيتم إنشاء نتائج WARN
    # للحاويات التي لا تحتوي على حدود cpu أو memory محددة
    cpu: '750m'
    memory: '500m'

لمزيد من التفاصيل حول كل مدقق، بما في ذلك وصف التكوين الخاص بالمدقق في التكوين، راجع وثائق المدقق.

ملاحظة: تكوين kubeaudit ليس هو نفسه ملف kubeconfig المحدد بالعلامة --kubeconfig، والذي يشير إلى ملف تكوين Kubernetes (راجع الوضع المحلي). لاحظ أيضًا أن أمرى all و autofix فقط هما اللذان يدعمان استخدام تكوين kubeaudit. لن يعمل مع الأوامر الأخرى.

ملاحظة: إذا تم استخدام العلامات مع ملف التكوين، فستكون العلامات لها الأولوية.

تجاوز الأخطاء

يمكن تجاهل المشكلات الأمنية لحاويات أو بودات محددة عن طريق إضافة تسميات تجاوز (override labels). وهذا يعني أن المدقق سينتج نتائج info بدلاً من نتائج error وسيتم إلحاق اسم نتيجة التدقيق بـ Allowed. يتم توثيق التسميات في وثائق كل مدقق، ولكن التنسيق العام للمدققين الذين يدعمون التجاوزات هو كما يلي:

تتكون تسمية التجاوز من مفتاح و قيمة.

المفتاح هو مزيج من نوع التجاوز (حاوية أو بود) و معرف التجاوز الفريد لكل مدقق (راجع الوثائق للمدقق المحدد). يمكن أن يأخذ المفتاح أحد شكلين اعتمادًا على نوع التجاوز:

1. تجاوزات الحاوية، التي تتجاوز المدقق لتلك الحاوية المحددة، تكون منسقة على النحو التالي:

container.kubeaudit.io/[اسم الحاوية].[معرف التجاوز]

2. تجاوزات البود، التي تتجاوز المدقق لجميع الحاويات داخل البود، تكون منسقة على النحو التالي:

kubeaudit.io/[معرف التجاوز]

إذا تم تعيين القيمة إلى سلسلة غير فارغة، فسيتم عرضها في نتيجة info كـ OverrideReason:

$ kubeaudit asat -f "auditors/asat/fixtures/service-account-token-true-allowed.yml"

---------------- النتائج لـ ---------------

  apiVersion: v1
  kind: ReplicationController
  metadata:
    name: replicationcontroller
    namespace: service-account-token-true-allowed

--------------------------------------------

-- [معلومات] AutomountServiceAccountTokenTrueAndDefaultSAAllowed
   الرسالة: تم تجاوز نتيجة التدقيق: حساب الخدمة الافتراضي مع الرمز المميز مركب. يجب تعيين automountServiceAccountToken إلى 'false' أو يجب استخدام حساب خدمة غير افتراضي.
   البيانات الوصفية:
      سبب التجاوز: SomeReason

وفقًا لمواصفات Kubernetes، يجب ألا يزيد value عن 63 حرفًا ويجب أن يكون فارغًا أو يبدأ وينتهي بحرف أبجدي رقمي ([a-z0-9A-Z]) مع شرطات (-)، وشرطات سفلية (_)، ونقاط (.)، وأحرف أبجدية رقمية بينها.

يمكن إضافة تسميات تجاوز متعددة (لعدة مدققين) إلى نفس المورد.

راجع وثائق المدقق المحددة للمدقق الذي ترغب في تجاوزه للحصول على أمثلة.

لمعرفة المزيد عن التسميات، راجع https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/

المساهمة

إذا كنت ترغب في إصلاح خطأ، أو المساهمة بميزة، أو مجرد تصحيح خطأ إملائي، فلا تتردد في القيام بذلك طالما تتبعت قواعد السلوك الخاصة بنا.

1. قم بإنشاء fork خاص بك!
2. احصل على المصدر: go get github.com/Shopify/kubeaudit
3. انتقل إلى المصدر: cd $GOPATH/src/github.com/Shopify/kubeaudit
4. أضف المستودع المfork الخاص بك كـ fork: git remote add fork https://github.com/you-are-awesome/kubeaudit
5. أنشئ فرع الميزات الخاص بك: git checkout -b awesome-new-feature
6. قم بتثبيت Kind
7. قم بتشغيل الاختبارات لترى أن كل شيء يعمل كما هو متوقع: USE_KIND=true make test (لتشغيل الاختبارات بدون Kind: make test)
8. أضف تغييراتك: git commit -am 'يضيف ميزة رائعة'
9. ادفع إلى الفرع: git push fork
10. قم بتوقيع اتفاقية ترخيص المساهم
11. أرسل طلب سحب PR (يجب تسمية جميع طلبات السحب بـ 🐛 (إصلاح خطأ)، ✨ (ميزة جديدة)، 📖 (تحديث وثائق)، أو ⚠️ (تغييرات جذرية) )
12. ???
13. استفد

لاحظ أنه إذا لم تقم بتوقيع CLA قبل فتح طلب السحب الخاص بك، يمكنك إعادة تشغيل الفحص عن طريق إضافة تعليق إلى طلب السحب يقول "I've signed the CLA!"!