تدوير TLS في Kubernetes: جدّد الشهادات دون Pods قديمة

لا يكون تدوير شهادات TLS في Kubernetes آمنًا إلا عندما تفصل بين ثلاث مراحل: إصدار الشهادة، ووصول Secret، وتفعيلها داخل العملية التي تنهي TLS. يستطيع cert-manager تجديد الشهادة واستبدال Secret بصورة صحيحة، لكن انعدام التوقف يعتمد على اكتشاف المستهلك للملفات الجديدة أوإعادة تشغيله تدريجيًا. اربط Secret كاملة لا subPath، وعرّف سلوك Reload صراحة، وتحقق من الشهادة المقدمة من خارج العنقود، ونبّه على قرب الانتهاء وتأخر التفعيل. يفيد هذا فرق المنصات التي تشغل Ingress أوGateway أوTLS داخل التطبيق.

يعتمد هذا الدليل على وثائق cert-manager وKubernetes وingress-nginx الرسمية التي راجعتها في 21 أكتوبر 2026. الأمثلة وميزانيات الوقت ليست قيمًا عامة؛ تحقق من حدود Issuer وسلوك Controller وعمر الشهادة في بيئتك.

افصل الإصدار عن التوصيل والتفعيل

تعني حالة Certificate الخضراء أن cert-manager حصل على المادة وكتب Secret المستهدفة. لا تثبت أن Load Balancer أوIngress Controller أوالتطبيق يقدمها للعميل. لمسار الإنتاج ثلاثة عقود:

1. الإصدار: يوقع Issuer شهادة قبل مهلة التجديد؛
2. التوصيل: يسقط Kubernetes Secret المحدثة داخل المستهلك أويراقب Controller تحديث API؛
3. التفعيل: تعيد عملية TLS تحميل الزوج دون إسقاط المرور المفيد.

قس كل حد مستقلًا. سجّل Certificate Ready وNot After وSecret resourceVersion ورقم Serial أوبصمة الشهادة التي رآها المستهلك، ثم الرقم الذي يقدمه External Probe. تخفي لوحة “الشهادة صالحة” الواحدة أكثر حالات التعطل شيوعًا: Secret حديثة والعملاء ما زالوا يتلقون الشهادة القديمة.

إذا كان TLS ينتهي في Managed Load Balancer، فقد تملك خدمة الشهادات المرحلتين الثانية والثالثة. لا تضف cert-manager لمجرد نسخ Control Plane لا تستخدمها. أما إذا كان TLS ينتهي في ingress-nginx أوApplication Pod فأنت تملك عقد Reload وعليك اختباره.

صرّح بسياسة التدوير ولا تعتمد على الذاكرة

غيّر cert-manager القيمة الافتراضية لتدوير المفتاح الخاص في v1.18: الإصدار v1.18 فأحدث يستخدم Always افتراضيًا، والأقدم يستخدم Never. صرّح بالقيمة حتى لا يغير Downgrade أوCluster Migration أوبيئة مختلطة العقد الأمني بصمت. مع Always يولد cert-manager مفتاحًا خاصًا جديدًا أثناء Reissuance وينتظر توقيع الشهادة قبل استبدال tls.key في Secret.

استخدم renewBefore أوrenewBeforePercentage لتترك وقتًا لإعادة محاولة Issuer والإصلاح التشغيلي. لا تنسخ نافذة من عنقود آخر؛ الهامش يعتمد على مدة الشهادة وRate Limits وزمن DNS أوHTTP Challenge وChange Freeze ووقت استجابة الفريق.

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: checkout-api
  namespace: edge
spec:
  secretName: checkout-api-tls
  dnsNames:
    - api.example.com
  issuerRef:
    kind: ClusterIssuer
    name: production-acme
  privateKey:
    algorithm: ECDSA
    size: 256
    rotationPolicy: Always
  renewBefore: 360h

عامل Certificate كالحالة المطلوبة وSecret كمخرج مولد. لا تعدل tls.crt أوtls.key يدويًا تحت secretName نفسها؛ قد تصنع عدم تطابق بين المفتاح والشهادة وسيعيد Controller تسويته. للتدوير المبكر المقصود يوصي cert-manager بأمر cmctl renew بدل حذف Secret.

اختر عقد Reload للمستهلك الحقيقي

يحدث Kubernetes المجلدات المدعومة بـSecret باتساق نهائي لا لحظي. يراقب kubelet أويسأل بحسب Change Detection Strategy، وقد يحتاج الإسقاط Sync Period مع Propagation Delay. لا تتلقى Secret المربوطة عبر subPath تحديثًا آليًا أبدًا. كذلك تبقى Secret المستخدمة كEnvironment Variable قديمة حتى Restart.

لذلك توجد ثلاثة أنماط صحيحة:

• Controller يراقب Kubernetes API: شائع في Ingress وGateway؛ تحقق أن Controller المحدد يراقب Secret ويعيد التحميل بأمان؛
• التطبيق يراقب المجلد: يقرأ الزوج معًا ويتحقق من التطابق ثم يبدل إعداد TLS في الذاكرة Atomically؛
• التطبيق يقرأ عند Startup فقط: فعّل Deployment Rollout مضبوطًا عند تغير Secret واحفظ السعة عبر Readiness وSurge وDraining.

لا تفترض أن تغير الملف يغير العملية؛ كثير من الخوادم تقرأ الشهادة مرة واحدة. وفي المقابل لا تعِد تشغيل كل Workload عند كل تغيير إذا كان Controller يستطيع Reload داخل العملية. القرار قدرة موثقة لدى TLS Terminator، لا تخمينًا داخل Helm Chart.

راقب المجلد لا Inode واحدة؛ يحدث Kubernetes الإسقاط بتغيير الروابط، وقد يفوت File Watcher المرتبط بالملف الأصلي الاستبدال. بعد استقرار التحديث اقرأ tls.crt وtls.key وحللهما وتأكد من تطابق Public Keys ثم فعّل الجديد. أبقِ الزوج الأخير السليم إذا فشل التحليل أوالتطابق.

صمّم مسار تفعيل بلا توقف

التسلسل الآمن هو Prepare ثم Observe ثم Activate ثم Verify. يجهز cert-manager الزوج الموقع قبل الكتابة فوق Secret مع rotationPolicy: Always. يلاحظ Kubernetes أوController التغيير. لا يفعّل المستهلك إلا زوجًا كاملًا ومتطابقًا. وأخيرًا يؤكد External Probe ما يراه العميل.

للتطبيق الذي يقرأ عند البداية فقط، يستطيع Restart Controller تعديل Pod Template عند تغير Secret. لكنه ليس بديلًا عن أمان Deployment. استخدم نسختين جاهزتين على الأقل عندما تتطلب الخدمة توفرًا، واضبط maxUnavailable: 0 وmaxSurge موجبة عندما تسمح السعة، ولا تجعل Readiness صحيحة قبل تحميل الشهادة الجديدة. أعد استخدام نمط الإغلاق السليم في Kubernetes حتى تصرّف Pods القديمة الاتصالات بدل قطعها.

Certificate Ready بالنسخة N
  -> تغير Secret resourceVersion
  -> لاحظ المستهلك زوجًا كاملًا
  -> Reload في الذاكرة أوRollout مضبوط
  -> بقيت Readiness سليمة
  -> قدم External TLS Probe النسخة N
  -> قبلت الشهادة القديمة خلال نافذة انتشار محدودة فقط

تدرج معمارية ingress-nginx الرسمية تحديث Secret ضمن أحداث المزامنة التي تحتاج إعادة تحميل الإعداد. هذا دليل لذلك Controller، وليس وعدًا لكل تطبيق Ingress. ثبّت الإصدار وشغّل اختبار تدوير بعد التحديثات.

تحقق من الشهادة التي يتلقاها المستخدم

لا تنه Runbook عند kubectl describe certificate. اختبر من خارج كل Network Path: الإنترنت العام والحافة الخاصة وRegional Load Balancer وService Mesh إذا كان كل منها ينهي TLS. قارن SANs وIssuer وNot Before وNot After والبصمة بالنسخة المطلوبة.

اختبر جميع Hostnames لا Apex فقط. قد يتجه Wildcard واسم صريح إلى Listeners مختلفة. اختبر SNI صراحة؛ فقد تكون Default Certificate سليمة بينما Virtual Host المحددة تقدم مادة قديمة. وفي البيئات متعددة المناطق أوAnycast خذ عينة من كل Region حتى يتحقق Convergence Objective.

تتبع وقت بدء التجديد ووقت Ready ووقت تغير Secret وAcknowledgement كل مستهلك ووقت رؤية External Probe للبصمة الجديدة. الفروق تكشف هل التأخير في Issuer أوتوصيل Kubernetes أوتفعيل التطبيق.

نبّه قبل الانتهاء بهامش يسمح بالإصلاح. نبّه كذلك عندما تكون Certificate Ready=false، وعندما يبقى Challenge أوOrder معلقًا، وعندما تتقدم Secret Revision من دون تغير البصمة المقدمة، وعندما تقدم Replicas أرقام Serial مختلفة بعد نافذة التداخل المتوقعة. مراقبة الانتهاء وحدها لا تكشف شهادة جديدة عالقة خلف عملية قديمة.

تمرّن على التجديد العادي وتدوير الطوارئ

يختبر التجديد الآلي المسار العادي، لكن تسرب Private Key يحتاج تدويرًا عاجلًا. تمرّن على cmctl renew في Namespace غير إنتاجية، وتأكد أن Always تنتج مفتاحًا جديدًا، وأن المستهلك يعيد التحميل، وقس External Convergence. ثم اختبر الإنتاج ضمن Change Window قبل أن يفرض الحادث ذلك.

لا تحذف Secret لإجبار التدوير. يوصي cert-manager صراحة باستخدام cmctl؛ حذف الكائن يزيل اعتمادًا تستخدمه مكونات أخرى ويجعل زمن الاستعادة أقل توقعًا. ضع Rate Limits الخاصة بالـIssuer في Runbook حتى لا يصنع تدوير الأسطول Renewal Storm.

للتعافي من الكوارث ترتيب مختلف. توثق cert-manager استعادة Secrets قبل Certificate Resources لمنع Reissuance غير الضرورية، واستعادة Secrets قبل Ingresses المعلّمة عند استخدام ingress-shim. استبعد Order وChallenge وCertificateRequest غالبًا من النسخ الاحتياطي وفق الإرشادات الرسمية. اختبر الترتيب في عنقودك؛ وجود Archive لا يثبت قابلية الاستعادة.

أفضل الممارسات والأنماط الخاطئة والقيود

استخدم Least-Privilege RBAC بحيث لا يقرأ Secret إلا TLS Controller والـWorkloads اللازمة. أبقِ Secret في Namespace المستهلك عندما يتطلب API ذلك، ولا تنسخ المفاتيح بين Namespaces إلا عبر Controller خضع للمراجعة. Kubernetes Secret ليست مشفرة لمجرد اسمها؛ فعّل Encryption at Rest واحمِ نسخ etcd.

الممارسات المفيدة: rotationPolicy صريحة، وهامش تجديد محسوب، وربط مجلد كامل، وفحص ذري للزوج، وExternal Probe، واختبارات Rollout، وأمر طوارئ موثق. الأدلة المفيدة Resource Versions والبصمات، لا محتوى Private Keys.

الأنماط الخاطئة: subPath لمادة متغيرة، وEnvironment Variables لمفاتيح TLS الحية، وحذف Secret للتجديد، وإعادة تشغيل كل الأحمال بلا Readiness أوSurge، والثقة في Ready داخل Control Plane فقط، وتسجيل المفاتيح لأغراض Debug. ولا تستخدم Temporary Certificates كاستراتيجية توفر طبيعية؛ هي سلوك Bootstrap لتدفقات محددة وليست إثباتًا لثقة العملاء.

لا تلغي هذه البنية كل انقطاع. تستمر اتصالات TLS الطويلة بالشهادة التي تفاوضت عليها، وقد تتقارب Load Balancers لا تزامنيًا، وقد لا يدعم المستهلك Graceful Reload. عرّف نافذة التداخل وهدف التقارب وفقًا لذلك. وإذا كانت خدمة شهادات مُدارة تنهي TLS وتضمن التدوير، ففضّل دورة حياتها الأصلية ما لم يحتج Kubernetes امتلاك المفتاح.

عقد الإنتاج موجز: يصدر cert-manager زوجًا كاملًا، ويوصله Kubernetes بلا subPath، ويعيد TLS Terminator الحقيقي تحميله أوينفذ Rollout بأمان، وتثبت External Probes ما يصل إلى المستخدم. عندما تكون هذه الجمل الأربع قابلة للقياس ومختبرة يصبح التجديد الآلي قدرة تشغيلية لا مجرد حقل YAML.

إعداد: Noor Yasser