Terraform المتقدم وأنماط البنية ككود

السياسة كرمز لـ IaC

18 دقيقة الدرس 8 من 28

السياسة كرمز لـ IaC

تمنح البنية التحتية كرمز الفرق قوة توفير أي شيء — وهذا هو المشكلة بالضبط. بدون حواجز حماية، يمكن للمطور فتح المنفذ 22 للعالم، أو تشغيل نسخة RDS غير مشفرة، أو نشر دلو S3 عام يحتوي على بيانات العملاء الشخصية، وكل ذلك عبر terraform apply نظيف. السياسة كرمز (PaC) هي ممارسة ترميز تلك الحواجز كملفات سياسة قابلة للقراءة آليًا وخاضعة للتحكم بالإصدار، وفرضها تلقائيًا داخل خط أنابيب CI/CD — قبل أن تصل أي استدعاءات API إلى مزود الحوسبة السحابية. في Google وMeta وAmazon، تخضع كل تغييرات البنية التحتية لبوابة PaC. الخطة التي تنتهك السياسة يتم حجبها، لا مجرد تحذيرها؛ ويحصل المهندس على رفض منظم مع مرجع القاعدة الدقيق وخطوات المعالجة.

الأدوات الثلاثة الرئيسية

ثلاثة أدوات تهيمن على مساحة PaC لـ Terraform، وتشغل مواضع مختلفة في نموذج الثقة:

Open Policy Agent (OPA) + Conftest — محرك سياسة متعدد الأغراض من CNCF. تُكتب السياسات بلغة Rego. تُغذّيه بخطة Terraform بصيغة JSON وتُقيّمها مقابل قواعد Rego. مفتوح المصدر، مستقل عن السحابة، ومُتبنّى على نطاق واسع في التحكم بالقبول في Kubernetes أيضًا.
Sentinel — إطار السياسات الخاص بـ HashiCorp، مدمج مباشرة في Terraform Cloud/Enterprise. تُكتب السياسات بلغة Sentinel وتعمل كبوابة أصلية بين plan وapply. أفضل تكامل مع منصة HCP لكنه يتطلب TFC/TFE.
Checkov — ماسح تحليل ثابت من Bridgecrew (تم الاستحواذ عليه من Palo Alto). يُحلّل HCL لـ Terraform مباشرة (لا حاجة للخطة) ويتحقق من أكثر من 1000 سياسة مدمجة للأخطاء في AWS وAzure وGCP. سريع، لا يحتاج إعدادًا، ويتكامل في أي خط أنابيب CI كخطوة لاكتشاف الأخطاء.

استخدم الثلاثة، في مراحل مختلفة. يعمل Checkov في ثوانٍ على HCL الخام أثناء فحص PR المحلي للمطور (الإزاحة لليسار). يُقيّم OPA/Conftest خطة JSON الكاملة بعد terraform plan (بوابة ما قبل التطبيق). يفرض Sentinel السياسة الصارمة على مستوى المؤسسة في Terraform Enterprise. إن طبّق الأدوات معًا يُجسّد الدفاع المتعمق ويكتشف فئات مختلفة من الانتهاكات في أرخص نقطة في خط الأنابيب.

معمارية خط الأنابيب المسوّر بالسياسات

يوضح الرسم التالي كيفية وضع بوابات السياسة داخل خط أنابيب Terraform CI لمستوى الإنتاج. كل بوابة تُعدّ فشلًا صارمًا — رمز خروج غير صفري يُخفق خط الأنابيب ويمنع الدمج أو التطبيق.

خط أنابيب Terraform CI المسوّر بالسياسات: Checkov يحجب على HCL الخام؛ OPA/Conftest يحجب على خطة JSON؛ الخطة النظيفة فقط تصل إلى التطبيق.

Checkov: المسح الثابت المُزاح لليسار

Checkov هو أسرع حلقة تغذية راجعة. شغّله محليًا قبل فتح PR، ومرة أخرى في CI على كل دفعة. لا يحتاج خطة — يقرأ ملفات .tf مباشرة.

# التثبيت (pipx يعزله عن Python النظام)
pipx install checkov

# فحص مجلد — حجب خط الأنابيب عند نتائج HIGH أو CRITICAL
checkov -d ./modules/vpc \
  --check CKV_AWS_25,CKV_AWS_23 \
  --compact \
  --output cli \
  --hard-fail-on HIGH

# في CI (مقتطف من GitHub Actions):
# - name: Checkov scan
#   uses: bridgecrewio/checkov-action@master
#   with:
#     directory: .
#     framework: terraform
#     soft_fail: false          # خروج غير صفري عند أي فحص فاشل
#     skip_check: CKV2_AWS_6   # تجاوز خطر مقبول معروف (وثّق السبب)

# توليد خط أساسي لتجاوز النتائج الموجودة أثناء الإصلاح التدريجي:
checkov -d . --create-baseline    # يكتب .checkov.baseline
checkov -d . --baseline .checkov.baseline  # الأجولة المستقبلية تتجاهل المسائل المُضمّنة

احرص على تسليم ملف .checkov.baseline. يوثّق المخاطر المقبولة ويمنع الإرهاق من النتائج الموروثة. كل تجاوز في الخط الأساسي ينبغي أن يكون له مرجع Jira/GitHub مقابل في تعليق حتى يُتابع الدَّين ولا يُخفى.

OPA + Conftest: سياسة على مستوى الخطة

يفوّت Checkov قرارات وقت التشغيل التي تظهر فقط في الخطة: ما إذا كانت قاعدة مجموعة الأمان هي 0.0.0.0/0، أو نوع النسخة على قائمة الموافقة، أو غياب وسم. يُقيّم OPA خطة terraform show -json الكاملة، مما يمنحك وصولًا إلى كل تغيير في الموارد بما فيها القيم المحسوبة.

# 1. توليد خطة JSON (خطوة معيارية في كل خطوط الأنابيب المسوّرة)
terraform plan -out=tfplan.binary
terraform show -json tfplan.binary > tfplan.json

# 2. كتابة سياسة Rego — policy/deny_public_sg.rego
# package main
#
# import future.keywords.if
# import future.keywords.in
#
# deny[msg] if {
#   rc := input.resource_changes[_]
#   rc.type == "aws_security_group_rule"
#   rc.change.after.cidr_blocks[_] == "0.0.0.0/0"
#   rc.change.after.type == "ingress"
#   msg := sprintf(
#     "DENY: %s opens ingress 0.0.0.0/0 — use a specific CIDR",
#     [rc.address]
#   )
# }

# 3. التقييم مع Conftest (يُغلّف OPA لإخراج CI)
conftest test tfplan.json \
  --policy policy/ \
  --namespace main \
  --output table   # إخراج منظم؛ يخرج برمز 1 عند أي حجب

# Conftest يُعيد رمز خروج 1 إذا أُطلق أي قاعدة رفض.
# في GitHub Actions، يُخفق هذا الرمز غير الصفري الخطوة ويوقف سير العمل.

احتفظ بالسياسات في مجلد policy/ مخصص داخل مستودع infra-live، مُعدَّل إصداره بجانب كود البنية التحتية. تنشر الفرق الكبيرة السياسات إلى خادم حزم OPA مشترك (S3 + OPA bundle API) حتى تستهلك جميع الفِرق نفس مجموعة القواعد المركزية دون نسخ الملفات.

Sentinel: السياسة الصارمة في Terraform Enterprise

إذا كانت مؤسستك تستخدم Terraform Cloud أو Enterprise، فإن Sentinel هو الجواب الأصلي. يعمل تلقائيًا بعد كل خطة في مساحة عمل، قبل أن يتمكن المشغلون من الموافقة على التطبيق. لسياسات Sentinel ثلاثة مستويات إنفاذ: advisory (تسجيل فقط)، وsoft-mandatory (قابل للتجاوز بشري)، وhard-mandatory (لا يمكن تجاوزه — أبدًا). فِرق الامتثال تحب hard-mandatory لقواعد مثل "لا يمكن إنشاء أي مورد بدون وسم Owner" أو "يجب تمكين التعيين على جميع دلاء S3."

# sentinel.hcl — ملف بيان مجموعة السياسات (مُسلَّم في مستودع السياسات)
# policy "require-owner-tag" {
#   source = "./policies/require_owner_tag.sentinel"
#   enforcement_level = "hard-mandatory"
# }
#
# policy "approved-instance-types" {
#   source = "./policies/approved_instance_types.sentinel"
#   enforcement_level = "soft-mandatory"
# }

# require_owner_tag.sentinel
# import "tfplan/v2" as tfplan
#
# all_resources = filter tfplan.resource_changes as _, rc {
#   rc.mode is "managed" and
#   (rc.change.actions contains "create" or
#    rc.change.actions contains "update")
# }
#
# main = rule {
#   all all_resources as _, rc {
#     rc.change.after.tags["Owner"] is not null
#   }
# }

سياسات Sentinel ذات الإنفاذ الصارم تحجب كل تطبيق في كل مساحة عمل في مجموعة السياسات — بما فيها التعافي من الكوارث والحوادث الطارئة. احرص دائمًا على وجود عملية: إما مساحة عمل طارئة منفصلة معفاة من مجموعة السياسات، أو مهندس مناوب بحقوق TFE admin يمكنه تعطيل مجموعة السياسات مؤقتًا (مُسجَّل ومُدقَّق). بدون مخرج طوارئ، يمكن لخلل في السياسة أن يعيق الاستجابة للحوادث.

هيكلة السياسات على نطاق واسع

على نطاق big-tech، تعيش السياسات في مستودع خاص بها (infra-policies) مع CI خاص به وإصدار ومراجعة. الممارسات الرئيسية:

اختبر سياساتك. يأتي OPA مع opa test؛ Sentinel لديه إطار اختبار. سياسة معطوبة تنطلق على تكوينات صالحة تضر بقدر غياب أي سياسة — تدرّب المهندسين على تجاوز البوابات.
افصل WARN عن BLOCK. السياسات الجديدة يجب أن تبدأ كتحذيرات لأسبوعين. هذا يمنح الفرق وقتًا لإصلاح الانتهاكات الموجودة قبل أن تصبح القاعدة فشلًا صارمًا. تتبع فترة التحذير في رأس ملف السياسة كتعليق.
ضع وسمًا لكل سياسة بمعرف تحكم. اربط كل قاعدة Rego/Sentinel برقم SOC 2 أو CIS أو معرف تحكم داخلي. هذا يجعل جمع أدلة المراجعة أمرًا بسيطًا مثل conftest test --output json بدلًا من جدول بيانات يدوي.
نسّق حزم السياسات. المستهلكون (مساحات العمل، خطوط الأنابيب) يُثبّتون إصدارًا محددًا من الحزمة. تمر تغييرات السياسة عبر PRs مع مراجعة CODEOWNERS من فريق الأمان قبل الإصدار.

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

مع Checkov يكتشف الأخطاء على مستوى HCL، وOPA يُقيّم الخطة الكاملة، وSentinel يفرض القواعد الصارمة على مستوى المؤسسة في المنصة — لديك دفاع متعمق لسلسلة توريد بنيتك التحتية. النتيجة: المهندسون يتحركون بسرعة، وفِرق الامتثال تنام مرتاحة، وأدلة المراجعة في متناول أمر git log.