وجّه سياق TLS الصاعد في Envoy إلى حزمة CA داخل الحاوية

بالنسبة إلى TLS الذي يبدأه عنقود وكيل إعادة توجيه ديناميكي، اضبط trusted_ca على ذلك العنقود مع الإبقاء على التحقق من SAN للوجهة.

transport_socket:
  name: envoy.transport_sockets.tls
  typed_config:
    "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.UpstreamTlsContext
    common_tls_context:
      validation_context:
        trusted_ca:
          filename: /etc/envoy/trust/upstream-ca.pem

ادمج هذا مع إعداد عنقود وكيل إعادة التوجيه الديناميكي. يجب أن تكون حزمة المسار المعتمدة قابلة للقراءة من عملية Envoy العاملة. في Kubernetes، افحص الملف المثبّت داخل الحاوية؛ فالشهادة المثبّتة على عقدة العامل فقط لا توفّره.

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

يوفّر إعداد TLS الديناميكي الموثّق لوكيل إعادة التوجيه تحقق SNI و SAN لاسم المضيف المضيف المحلول. أبقِ فحص الهوية هذا إلى جانب التحقق من السلسلة.

يمكن لطلب wget ناجح أن يستخدم مصدر ثقة آخر. يغطي هذا المدخل TLS الصادر من Envoy؛ وفي مرحّل CONNECT العادي يبقى التطبيق هو عميل TLS الذي يتحقق من الوجهة.

مقالات ذات صلة