سير عمل النشر الآمن: من CI/CD Pipeline إلى بيئة الإنتاج

يمكن أن يتضمن CI/CD pipeline لديك ضوابط أمنية محكمة — commits موقعة، dependencies مثبتة، فحوصات SAST، توقيع container images — لكن كل ذلك لا قيمة له إذا كانت عملية النشر نفسها ضعيفة. النشر هو نقطة التقاطع الحرجة حيث يلتقي أمان pipeline بأمان بيئة الإنتاج. يمكن لسير عمل نشر مخترق أن يتجاوز كل ضابط أمني بنيته في المراحل السابقة، ويدفع بشفرة خبيثة مباشرة إلى البيئة التي يعتمد عليها عملاؤك.

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

نماذج النشر: Push-Based مقابل Pull-Based (GitOps)

القرار المعماري الأول الذي يشكل وضعك الأمني في النشر هو ما إذا كنت تستخدم نموذج push-based أو pull-based.

النشر Push-Based (المدفوع بـ CI)

في نموذج push-based التقليدي، يقوم CI/CD pipeline ببناء artifact ثم يدفعه مباشرة إلى البيئة المستهدفة. GitHub Actions ينشر إلى Kubernetes عبر kubectl apply، أو وظيفة GitLab CI تنفذ helm upgrade على cluster. يحتفظ pipeline نفسه ببيانات اعتماد بيئة الإنتاج.

هذا النموذج بسيط لكنه يحمل مخاطر متأصلة: runner الخاص بـ CI لديه وصول كتابة مباشر إلى بيئة الإنتاج. إذا اخترق مهاجم pipeline — من خلال dependency مسموم، أو pull request خبيث، أو secret مسروق — فإنه يرث وصول الإنتاج فوراً.

النشر Pull-Based (GitOps)

في نموذج pull-based أو GitOps، يقوم controller مخصص يعمل داخل البيئة المستهدفة — مثل Flux أو ArgoCD — بمراقبة مستودع Git للتغييرات في الحالة المطلوبة. عندما يتم commit لـ manifest جديد (عادةً بواسطة CI pipeline الذي يحدّث image tag)، يسحب controller التغيير ويوفق cluster ليطابق.

الميزة الأمنية كبيرة. لا يحتاج CI pipeline أبداً إلى بيانات اعتماد مباشرة لـ production cluster. ينكمش سطح الهجوم لأن وكيل النشر يعيش داخل cluster ويسحب فقط من مصدر معروف. اكتشاف الانحراف مدمج: إذا عدّل شخص ما مورداً يدوياً، يعيده controller ليطابق Git.

التوصية: لأعباء العمل الإنتاجية، فضّل نموذج GitOps pull-based. احتفظ بنشر push-based لبيئات التطوير والتجهيز حيث تهم السرعة أكثر من التحكم الصارم في الوصول. حتى في إعدادات push-based، طبّق مبدأ الحد الأدنى من الصلاحيات بصرامة على بيانات اعتماد النشر.

بوابات النشر: الموافقات اليدوية والبيئات المحمية

Pipelines المؤتمتة سريعة، لكن النشر إلى بيئة الإنتاج لا ينبغي أن يحدث دون تحقق بشري للتغييرات عالية التأثير. تقدم بوابات النشر نقاط تفتيش تتطلب موافقة صريحة قبل المضي قدماً في الإصدار.

GitHub Environments والمراجعون المطلوبون

يدعم GitHub Actions Environments مع قواعد حماية. يمكنك طلب مراجع واحد أو أكثر للموافقة على النشر قبل تشغيل الوظيفة. يتم تكوين ذلك في إعدادات المستودع ويُفرض على مستوى المنصة — لا يمكن لشفرة pipeline تجاوزه.

# .github/workflows/deploy.yml
jobs:
  deploy-production:
    runs-on: ubuntu-latest
    environment:
      name: production
      url: https://app.example.com
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Verify artifact signature
        run: |
          cosign verify \
            --key cosign.pub \
            ghcr.io/myorg/myapp:${{ github.sha }}

      - name: Deploy to production
        run: |
          helm upgrade --install myapp ./chart \
            --set image.tag=${{ github.sha }} \
            --namespace production

مع تكوين بيئة production لتتطلب مراجعين، ستتوقف هذه الوظيفة وتنتظر الموافقة قبل تنفيذ أي خطوات. يرى المُوافق بالضبط أي commit وتشغيل workflow أطلق النشر.

GitLab Protected Environments

يقدم GitLab protected environments التي تقيّد أي المستخدمين أو المجموعات يمكنها تشغيل عمليات النشر. بالدمج مع الوظائف اليدوية، ينشئ هذا سير عمل موافقة قوياً.

# .gitlab-ci.yml
deploy_production:
  stage: deploy
  environment:
    name: production
    url: https://app.example.com
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      when: manual
  script:
    - cosign verify --key cosign.pub $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
    - helm upgrade --install myapp ./chart
        --set image.tag=$CI_COMMIT_SHA
        --namespace production
  resource_group: production

يتطلب توجيه when: manual من المستخدم النقر على “Play” في واجهة GitLab. يضمن resource_group تشغيل نشر واحد فقط في كل مرة، مما يمنع حالات التسابق.

الموافقات عبر Slack و ChatOps

للفرق التي تعيش في Slack، يوفر دمج سير عمل الموافقة مع المحادثة رؤية وأوقات استجابة سريعة. أدوات مثل Opsgenie و PagerDuty أو روبوتات Slack مخصصة يمكنها نشر طلب نشر في قناة وانتظار مستخدم مخوّل للموافقة عبر زر أو تفاعل. المتطلب الأساسي هو أن تكون آلية الموافقة قابلة للتدقيق ولا يمكن تزويرها — استخدم رموز تطبيق Slack موثقة وسجّل كل قرار موافقة.

التحقق من Artifacts عند النشر

توقيع artifacts أثناء مرحلة البناء هو نصف المعادلة فقط. يجب أن تتحقق من تلك التواقيع عند النشر. وإلا، يمكن لمهاجم حصل على وصول إلى registry استبدال image موقعة بأخرى غير موقعة أو معاد توقيعها بشكل خبيث.

التحقق بـ Cosign قبل النشر

أضف خطوة تحقق صريحة في deployment pipeline تعمل قبل أي أمر نشر. إذا فشل التحقق، يجب أن يتوقف pipeline فوراً.

# Verify the image signature before deploying
cosign verify \
  --certificate-identity "https://github.com/myorg/myapp/.github/workflows/build.yml@refs/heads/main" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
  ghcr.io/myorg/myapp@sha256:abc123...

# Verify SLSA provenance
cosign verify-attestation \
  --type slsaprovenance \
  --certificate-identity "https://github.com/slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@refs/tags/v1.9.0" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
  ghcr.io/myorg/myapp@sha256:abc123...

Admission Controllers: Kyverno و Sigstore Policy Controller

التحقق على مستوى pipeline جيد، لكن يمكن تجاوزه إذا نشر شخص ما مباشرة إلى cluster باستخدام kubectl. تفرض admission controllers التحقق على مستوى Kubernetes API server — لا يمكن لأي image غير موقعة الدخول إلى cluster بغض النظر عن كيفية تقديمها.

Kyverno هو محرك سياسات أصلي لـ Kubernetes يمكنه التحقق من توقيعات images و attestations كجزء من admission webhook:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-signed-images
spec:
  validationFailureAction: Enforce
  background: false
  rules:
    - name: verify-signature
      match:
        any:
          - resources:
              kinds:
                - Pod
      verifyImages:
        - imageReferences:
            - "ghcr.io/myorg/*"
          attestors:
            - entries:
                - keyless:
                    subject: "https://github.com/myorg/*"
                    issuer: "https://token.actions.githubusercontent.com"
          attestations:
            - type: https://slsa.dev/provenance/v1
              conditions:
                - all:
                    - key: "{{ builder.id }}"
                      operator: Equals
                      value: "https://github.com/slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@refs/tags/v1.9.0"

يوفر Sigstore Policy Controller (المعروف سابقاً بـ cosigned) وظائف مماثلة ويُصان من قبل مشروع Sigstore. يتكامل بشكل وثيق مع سير عمل keyless signing وهو خيار قوي إذا وحّدت مؤسستك على نظام Sigstore البيئي.

الجمع بين التحقق على مستوى pipeline وتحكم القبول على مستوى cluster ينشئ دفاعاً عميقاً: حتى لو تم تجاوز طبقة واحدة، تلتقط الأخرى artifacts غير المصرح بها.

الطرح التدريجي: Canary و Blue-Green و Feature Flags

نشر إصدار جديد لـ 100% من حركة المرور فوراً يمثل خطراً أمنياً وخطراً على الموثوقية. تتيح لك استراتيجيات الطرح التدريجي اكتشاف المشاكل — بما في ذلك المشاكل الأمنية — قبل أن تؤثر على جميع المستخدمين.

نشر Canary

يوجه نشر canary نسبة صغيرة من حركة المرور (مثلاً 5%) إلى الإصدار الجديد بينما تستمر الأغلبية في الوصول إلى الإصدار المستقر. إذا تدهورت مقاييس مثل معدلات الأخطاء، أو زمن الاستجابة، أو إشارات أمنية (اتصالات صادرة غير متوقعة، تصعيدات صلاحيات مرتفعة)، يتم التراجع عن canary تلقائياً.

أدوات مثل Flagger (لـ Kubernetes) و AWS App Mesh و Istio تؤتمت تحليل canary. يمكن تكوين Flagger، على سبيل المثال، لمراقبة مقاييس Prometheus مخصصة والترقية أو التراجع تلقائياً:

apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
  name: myapp
  namespace: production
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp
  progressDeadlineSeconds: 600
  service:
    port: 8080
  analysis:
    interval: 1m
    threshold: 5
    maxWeight: 50
    stepWeight: 10
    metrics:
      - name: request-success-rate
        thresholdRange:
          min: 99
        interval: 1m
      - name: request-duration
        thresholdRange:
          max: 500
        interval: 1m

نشر Blue-Green

يحافظ نشر blue-green على بيئتين متطابقتين. بيئة “blue” تشغل الإصدار الحالي؛ و”green” تشغل الإصدار الجديد. يتم تحويل حركة المرور دفعة واحدة (عادةً عبر load balancer أو تغيير DNS) بعد أن تجتاز بيئة green فحوصات الصحة والتحقق الأمني. إذا حدث خطأ ما، فإن العودة إلى blue فورية.

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

Feature Flags كضوابط أمنية

تفصل feature flags بين النشر والإصدار. يُنشر الكود إلى بيئة الإنتاج لكنه يبقى غير نشط خلف flag. هذا يمنح فرق الأمن مفتاح إيقاف: إذا أدخلت ميزة صدرت حديثاً ثغرة أو تصرفت بشكل غير متوقع، يمكن تعطيلها فوراً دون rollback كامل. أدوات مثل LaunchDarkly و Unleash و OpenFeature توفر إدارة مركزية لـ flags مع سجلات تدقيق لمن بدّل ماذا ومتى.

استراتيجيات Rollback

يجب أن تتضمن كل خطة نشر خطة rollback. عندما تسوء الأمور — وستسوء — فإن سرعة وموثوقية rollback تحدد مباشرة نطاق الضرر.

Rollback تلقائي عند فشل Health Check

يدعم Kubernetes أصلاً rollback من خلال deployment controller. إذا فشلت pods الجديدة في readiness أو liveness probes، يتوقف الطرح ويمكن عكسه تلقائياً:

# Check rollout status and rollback if needed
kubectl rollout status deployment/myapp --namespace production --timeout=300s
if [ $? -ne 0 ]; then
  echo "Rollout failed, initiating rollback"
  kubectl rollout undo deployment/myapp --namespace production
  exit 1
fi

في نموذج GitOps، يعني rollback التراجع عن Git commit الذي أدخل التغيير. يكتشف controller التراجع ويوفق cluster إلى الحالة السابقة. هذا يحفظ سجل التدقيق الكامل في Git.

النشر غير القابل للتغيير (Immutable Deployments)

يعامل النشر غير القابل للتغيير كل إصدار كمثيل جديد قابل للتخلص منه. بدلاً من تحديث containers في مكانها، تنشر مجموعة جديدة بالكامل من الموارد وتلغي القديمة. هذا يزيل انحراف التكوين ويضمن أن ما تم اختباره هو بالضبط ما يعمل في بيئة الإنتاج. بالدمج مع image digests (بدلاً من tags قابلة للتغيير مثل latest)، يضمن النشر غير القابل للتغيير إعادة إنتاج ثنائية.

فصل هويات البناء والنشر

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

بيانات اعتماد مختلفة

يجب أن يمتلك build pipeline بيانات اعتماد لدفع images إلى registry وتوقيعها — لكن بدون وصول إلى بنية الإنتاج التحتية. يجب أن يمتلك deployment pipeline (أو GitOps controller) بيانات اعتماد لسحب images وتطبيق manifests — لكن بدون وصول إلى مستودعات الشفرة المصدرية أو مفاتيح التوقيع.

عملياً، يعني هذا استخدام service accounts منفصلة أو IAM roles أو OIDC claims لكل مرحلة. على AWS، قد يمتلك build role صلاحيات لـ ECR push و KMS signing، بينما يمتلك deploy role صلاحيات لـ EKS و Secrets Manager لكن ليس ECR push.

Runners مختلفة

خذ الفصل أبعد بتشغيل وظائف البناء والنشر على runners مختلفة فعلياً. وظائف البناء تعمل على runners مؤقتة متعددة الأغراض. وظائف النشر تعمل على runners مخصصة ومقواة تقع ضمن حدود شبكة أقرب إلى بيئة الإنتاج. هذا يمنع runner بناء مخترق من الانتقال إلى بيئة الإنتاج.

لمعالجة أعمق لفصل الهويات ومبادئ الحد الأدنى من الصلاحيات في CI/CD، راجع دليلنا حول فصل المهام والحد الأدنى من الصلاحيات في CI/CD Pipelines.

تجميد النشر ونوافذ التغيير

ليس كل وقت مناسباً للنشر. تجميد النشر — فترات يُمنع فيها تغيير بيئة الإنتاج — يقلل المخاطر أثناء أحداث حركة المرور العالية، والعطلات، وتحولات المناوبة، أو الاستجابة النشطة للحوادث.

نفّذ التجميد على مستوى المنصة، وليس فقط كاتفاق فريق. يدعم GitHub Environments deployment branch policies و wait timers. يسمح GitLab بـ deploy freezes المكونة عبر الواجهة أو API بجداول بنمط cron. لسير عمل Kubernetes، يمكنك فرض التجميد بسياسة OPA/Gatekeeper أو Kyverno ترفض عمليات النشر خلال نوافذ زمنية محددة.

# Kyverno policy to enforce deployment freeze
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: deployment-freeze
spec:
  validationFailureAction: Enforce
  background: false
  rules:
    - name: block-deployments-during-freeze
      match:
        any:
          - resources:
              kinds:
                - Deployment
              namespaces:
                - production
      preconditions:
        all:
          - key: "{{ time_now() }}"
            operator: GreaterThan
            value: "2026-03-27T00:00:00Z"  # Freeze start
          - key: "{{ time_now() }}"
            operator: LessThan
            value: "2026-03-30T00:00:00Z"  # Freeze end
      validate:
        message: "Production deployments are frozen until March 30. Contact platform-team for emergency exceptions."
        deny: {}

وثّق عملية استثناء لتصحيحات الأمان الطارئة التي تحتاج للنشر أثناء التجميد، بما في ذلك من يمكنه تفويض الاستثناء وكيف يتم تسجيله.

سجل التدقيق: ربط عمليات النشر بـ Commits والموافقين وتشغيلات Pipeline

ينتج سير عمل النشر الآمن سجل تدقيق كامل ومقاوم للتلاعب. لكل نشر في بيئة الإنتاج، يجب أن تتمكن من الإجابة: ماذا تم نشره؟ من وافق عليه؟ أي pipeline بناه؟ أي commit يرجع إليه؟

سجلات التدقيق على مستوى المنصة

يسجل AWS CloudTrail استدعاءات API إلى EKS و ECS و Lambda، بما في ذلك من بدأ النشر ومن أي مصدر. توفر GCP Audit Logs تغطية مماثلة لـ GKE و Cloud Run. تأكد من إرسال هذه السجلات إلى مخزن سجلات مركزي غير قابل للتغيير (مثل S3 bucket مخصص مع object lock أو SIEM) حيث لا يمكن للمهاجم الذي اخترق بيئة النشر التلاعب بها.

التتبع على مستوى Pipeline

أضف تعليقات توضيحية لموارد Kubernetes ببيانات وصفية للنشر حتى تتمكن من التتبع من pod قيد التشغيل إلى المصدر بالضبط:

# Include in your Helm chart or Kustomize overlay
metadata:
  labels:
    app.kubernetes.io/version: "{{ .Values.image.tag }}"
  annotations:
    deploy.example.com/commit-sha: "{{ .Values.commitSha }}"
    deploy.example.com/pipeline-url: "{{ .Values.pipelineUrl }}"
    deploy.example.com/approved-by: "{{ .Values.approvedBy }}"
    deploy.example.com/deployed-at: "{{ now | date \"2006-01-02T15:04:05Z\" }}"

في GitHub Actions، مرّر هذه القيم عبر deployment workflow:

- name: Deploy with traceability
  run: |
    helm upgrade --install myapp ./chart \
      --set image.tag=${{ github.sha }} \
      --set commitSha=${{ github.sha }} \
      --set pipelineUrl="https://github.com/${{ github.repository }}/actions/runs/${{ github.run_id }}" \
      --set approvedBy="${{ github.actor }}" \
      --namespace production

المراقبة بعد النشر

لا ينتهي النشر عندما يعمل الإصدار الجديد. تغلق المراقبة بعد النشر حلقة التغذية الراجعة وتلتقط المشاكل التي فاتتها فحوصات ما قبل النشر.

اكتشاف الشذوذ

حدد مقاييس أساسية لسلوك التطبيق الطبيعي: معدلات الطلبات، ومعدلات الأخطاء، ومئويات زمن الاستجابة، واستخدام CPU/الذاكرة، وأنماط اتصال الشبكة. بعد كل نشر، قارن المقاييس الحالية بالأساس. أدوات مثل Prometheus + Alertmanager و Datadog و Grafana Alerting يمكنها إطلاق تنبيهات عندما تنحرف مقاييس ما بعد النشر عن العتبات.

من منظور أمني، انتبه بشكل خاص لاتصالات الشبكة الصادرة غير المتوقعة، والعمليات الجديدة المنشأة داخل containers، واستدعاءات النظام المرتفعة، والزيادات المفاجئة في فشل المصادقة. يمكن أن تشير هذه إلى أن artifact مخترق مرّ عبر pipeline.

مقاييس DORA للأمن

مقاييس DORA الأربعة — تكرار النشر، وزمن التسليم للتغييرات، ومعدل فشل التغيير، ومتوسط وقت الاسترداد — تُستخدم عادةً لقياس أداء DevOps. وهي بنفس القيمة للأمن:

• تكرار النشر يشير إلى مدى تكرار إمكانية شحن تصحيحات الأمان. التكرار الأعلى يعني معالجة أسرع.
• زمن التسليم للتغييرات يقيس مدى سرعة وصول إصلاح أمني من commit إلى بيئة الإنتاج. أوقات التسليم الطويلة تعني نوافذ تعرض ممتدة.
• معدل فشل التغيير يتتبع مدى تكرار تسبب عمليات النشر في حوادث. معدل عالٍ يشير إلى اختبار أو تحقق غير كافٍ — وهو مصدر قلق أمني.
• متوسط وقت الاسترداد (MTTR) يقيس مدى سرعة إمكانية التراجع أو معالجة نشر سيء. MTTR منخفض يحد من نطاق الضرر لأي حادث، بما في ذلك الاختراق الأمني.

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

تجميع كل شيء: Pipeline نشر آمن متكامل

إليك سير عمل GitHub Actions كامل يتضمن الممارسات المذكورة أعلاه — التحقق من artifacts، والموافقات المبنية على البيئات، وتتبع النشر، و rollback التلقائي:

# .github/workflows/secure-deploy.yml
name: Secure Deployment

on:
  workflow_run:
    workflows: ["Build and Sign"]
    types: [completed]
    branches: [main]

jobs:
  verify-and-deploy:
    runs-on: ubuntu-latest
    if: ${{ github.event.workflow_run.conclusion == 'success' }}
    environment:
      name: production
      url: https://app.example.com
    permissions:
      id-token: write
      contents: read
    steps:
      - name: Checkout manifests
        uses: actions/checkout@v4

      - name: Install cosign
        uses: sigstore/cosign-installer@v3

      - name: Verify image signature (keyless)
        run: |
          IMAGE="ghcr.io/myorg/myapp@${{ github.event.workflow_run.head_sha }}"
          cosign verify \
            --certificate-identity "https://github.com/myorg/myapp/.github/workflows/build.yml@refs/heads/main" \
            --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
            "$IMAGE"

      - name: Verify SLSA provenance
        run: |
          IMAGE="ghcr.io/myorg/myapp@${{ github.event.workflow_run.head_sha }}"
          cosign verify-attestation \
            --type slsaprovenance \
            --certificate-identity "https://github.com/slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@refs/tags/v1.9.0" \
            --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
            "$IMAGE"

      - name: Configure AWS credentials (deploy role)
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/deploy-production
          aws-region: us-east-1

      - name: Deploy to EKS
        run: |
          aws eks update-kubeconfig --name production-cluster
          helm upgrade --install myapp ./chart \
            --set image.tag=${{ github.event.workflow_run.head_sha }} \
            --set commitSha=${{ github.event.workflow_run.head_sha }} \
            --set pipelineUrl="https://github.com/${{ github.repository }}/actions/runs/${{ github.run_id }}" \
            --set approvedBy="${{ github.actor }}" \
            --namespace production \
            --wait --timeout 300s

      - name: Verify rollout
        run: |
          kubectl rollout status deployment/myapp \
            --namespace production --timeout=300s

      - name: Rollback on failure
        if: failure()
        run: |
          echo "Deployment failed — initiating rollback"
          kubectl rollout undo deployment/myapp --namespace production
          echo "::error::Deployment rolled back due to failure"

و pipeline GitLab CI المكافئ بضوابط مماثلة:

# .gitlab-ci.yml
stages:
  - verify
  - deploy
  - validate

verify_artifact:
  stage: verify
  image: bitnami/cosign:latest
  script:
    - cosign verify
        --certificate-identity "https://gitlab.com/myorg/myapp//.gitlab-ci.yml@refs/heads/main"
        --certificate-oidc-issuer "https://gitlab.com"
        $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

deploy_production:
  stage: deploy
  environment:
    name: production
    url: https://app.example.com
  resource_group: production
  needs: [verify_artifact]
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      when: manual
  script:
    - aws eks update-kubeconfig --name production-cluster
    - helm upgrade --install myapp ./chart
        --set image.tag=$CI_COMMIT_SHA
        --set commitSha=$CI_COMMIT_SHA
        --set pipelineUrl=$CI_PIPELINE_URL
        --set approvedBy=$GITLAB_USER_LOGIN
        --namespace production
        --wait --timeout 300s

validate_deployment:
  stage: validate
  needs: [deploy_production]
  script:
    - kubectl rollout status deployment/myapp --namespace production --timeout=300s
  after_script:
    - |
      if [ "$CI_JOB_STATUS" == "failed" ]; then
        echo "Rolling back deployment"
        kubectl rollout undo deployment/myapp --namespace production
      fi
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

الملخص والأدلة ذات الصلة

تتطلب سير عمل النشر الآمن دفاعاً عميقاً عبر كل مرحلة: اختيار نموذج النشر المناسب، وفرض البوابات والموافقات، والتحقق من artifacts عند حدود cluster، وطرح التغييرات تدريجياً، والحفاظ على مسارات rollback نظيفة، وفصل هويات البناء والنشر، واحترام نوافذ التغيير، وتسجيل كل شيء. لا يكفي ضابط واحد بمفرده. الجمع بين التحقق على مستوى pipeline، وإنفاذ admission-controller، والطرح التدريجي، وتسجيل التدقيق الشامل ينشئ عملية نشر سريعة وآمنة في آن واحد.

تابع بناء معرفتك بـ CI/CD الآمن مع هذه الأدلة ذات الصلة:

• فصل المهام والحد الأدنى من الصلاحيات في CI/CD Pipelines — تعمق في فصل الهويات، وبيانات الاعتماد المحددة النطاق، ومبدأ الحد الأدنى من الصلاحيات عبر pipeline.
• أنماط الدفاع والتخفيف لهجمات CI/CD Pipeline — إجراءات مضادة عملية لأكثر متجهات الهجوم شيوعاً التي تستهدف أنظمة CI/CD.