اتصال وسيط MQTT الآمن باستخدام BrokerListener

مقالة
١٨‏/٠٥‏/١٤٤٦ هـ

هام

تتضمن هذه الصفحة إرشادات لإدارة مكونات عمليات Azure IoT باستخدام بيانات توزيع Kubernetes، وهي قيد المعاينة. يتم توفير هذه الميزة مع العديد من القيود، ولا يجب استخدامها لأحمال عمل الإنتاج.

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

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

يمكن أن يكون لكل منفذ BrokerListener قواعد المصادقة والتخويل الخاصة به التي تحدد من يمكنه الاتصال على منفذ وحدة الاستماع هذا والإجراءات التي يمكنهم تنفيذها على الوسيط. يمكنك استخدام موارد BrokerAuthentication و BrokerAuthorization لتحديد نهج التحكم في الوصول لكل منفذ وحدة استماع. تتيح لك هذه المرونة ضبط الأذونات والأدوار لعملاء MQTT بناء على احتياجاتهم وحالات الاستخدام الخاصة بهم.

تلميح

توزيع وسيط MQTT الافتراضي هو خدمة IP للمجموعة تتطلب من العملاء الاتصال ببروتوكول أمان طبقة النقل (TLS) والمصادقة باستخدام رموز حساب الخدمة المميزة. يحتاج العملاء الذين يتصلون من خارج المجموعة إلى تكوين إضافي قبل أن يتمكنوا من الاتصال.

لدى مستمعي الوسيط الخصائص التالية:

الاسم: اسم وحدة الاستماع. هذا الاسم هو أيضا اسم خدمة Kubernetes ما لم يتم تجاوزه.
نوع الخدمة: يمكن أن يكون لديك ما يصل إلى ثلاثة مستمعين، واحد لكل نوع خدمة. وحدة الاستماع الافتراضية هي نوع ClusterIpالخدمة .
المنافذ: يدعم كل وحدة استماع منافذ متعددة. لا يمكن أن تتعارض المنافذ مع المستمعين المختلفين.
مراجع المصادقة والتخويل: يتم تكوين BrokerAuthentication و BrokerAuthorization لكل منفذ.
TLS: يتم تطبيق تكوين TLS اليدوي أو التلقائي لكل منفذ.
البروتوكول: يمكن تمكين MQTT عبر WebSockets لكل منفذ.

للحصول على قائمة بجميع الإعدادات المتوفرة، راجع مرجع Broker Listener API.

BrokerListener الافتراضي

عند نشر عمليات Azure IoT، ينشئ النشر مورد BrokerListener يسمى default. يتم استخدام وحدة الاستماع هذه للاتصال الداخلي المشفر بين مكونات عمليات IoT. وحدة الاستماع الافتراضية هي جزء من الوسيط الافتراضي.

يعرض خدمة ClusterIp على المنفذ 18883.
يتطلب من العملاء استخدام مصادقة حساب خدمة Kubernetes.
لديها شهادة TLS مدارة تلقائيا.
لا يقوم بتكوين أي نهج تخويل للعميل.

تنبيه

لتجنب تعطيل اتصال عمليات IoT الداخلية، احتفظ بالمستمع الافتراضي دون تغيير ومخصص للاستخدام الداخلي. للاتصال الخارجي، قم بإنشاء وحدة استماع جديدة. إذا كنت بحاجة إلى استخدام الخدمة، أضف المزيد من المنافذ ClusterIp إلى وحدة الاستماع الافتراضية دون تغيير أي من الإعدادات الموجودة.

لعرض وحدة الاستماع الافتراضية أو تحريرها، اتبع هذه الخطوات.

في مدخل Microsoft Azure، انتقل إلى مثيل عمليات IoT.
ضمن Components، حدد MQTT Broker.
من قائمة مستمع الوسيط، حدد وحدة الإصغاء الافتراضية .
راجع إعدادات وحدة الاستماع، ولكن تجنب تعديل أي من الإعدادات الموجودة. بدلا من ذلك، قم بإنشاء منفذ جديد وتكوينه حسب الحاجة.

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

param aioInstanceName string = '<AIO_INSTANCE_NAME>'
param customLocationName string = '<CUSTOM_LOCATION_NAME>'

resource aioInstance 'Microsoft.IoTOperations/instances@2024-11-01' existing = {
  name: aioInstanceName
}

resource customLocation 'Microsoft.ExtendedLocation/customLocations@2021-08-31-preview' existing = {
  name: customLocationName
}

resource defaultBroker 'Microsoft.IoTOperations/instances/brokers@2024-11-01' existing = {
  parent: aioInstance
  name: 'default'
}

resource defaultListener 'Microsoft.IoTOperations/instances/brokers/listeners@2024-11-01' = {
  parent: defaultBroker
  name: 'default'
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }
  properties: {
    // Don't change the service name or service type
    serviceType: 'ClusterIp'
    serviceName: 'aio-broker'
    ports: [
      // Don't modify the default port 18883 settings
      {
        port: 18883
        authenticationRef: 'default'
        protocol: 'Mqtt'
        tls: {
          mode: 'Automatic'
          certManagerCertificateSpec: {
            issuerRef: {
              name: 'azure-iot-operations-aio-certificate-issuer'
              kind: 'ClusterIssuer'
              group: 'cert-manager.io'
            }
            privateKey: {
              algorithm: 'Ec256'
              rotationPolicy: 'Always'
            }
          }
        }
      }
      // Add more ports here, like the following example
      {
        port: 1884
        protocol: 'Mqtt'
      }
    ]
  }
}

انشر ملف Bicep باستخدام Azure CLI:

az deployment group create --resource-group <RESOURCE_GROUP> --template-file <FILE>.bicep

لعرض مورد BrokerListener الافتراضي، استخدم الأمر التالي:

kubectl get brokerlistener default -n azure-iot-operations -o yaml

يجب أن يبدو الإخراج مشابها لهذا المثال، مع إزالة معظم بيانات التعريف للإيجاز:

apiVersion: mqttbroker.iotoperations.azure.com/v1
kind: BrokerListener
metadata:
  name: default
  namespace: azure-iot-operations
  ownerReferences:
  - apiVersion: mqttbroker.iotoperations.azure.com/v1
    kind: Broker
    name: default
spec:
  serviceType: ClusterIp
  serviceName: aio-broker
  ports:
  - port: 18883
    authenticationRef: default
    protocol: Mqtt
    tls:
      mode: Automatic
      certManagerCertificateSpec:
        issuerRef:
          name: azure-iot-operations-aio-certificate-issuer
          kind: ClusterIssuer
          group: cert-manager.io
        privateKey:
          algorithm: Ec256
          rotationPolicy: Always

لإضافة منفذ جديد 1883، بدون إيقاف تشغيل TLS والمصادقة، إلى وحدة الاستماع الافتراضية kubectl patch ، استخدم الأمر :

kubectl patch brokerlistener default -n azure-iot-operations --type='json' -p='[{"op": "add", "path": "/spec/ports/-", "value": {"port": 1883, "protocol": "Mqtt"}}]'

تجنب تعديل وحدة إصغاء الوسيط الافتراضية

لمنع تعطيل اتصال عمليات IoT الداخلية، احتفظ بالمستمع الافتراضي دون تغيير ومخصص للاستخدام الداخلي. للاتصال الخارجي، قم بإنشاء وحدة استماع جديدة.

نظرا لأن مستمع الوسيط الافتراضي يستخدم نوع ClusterIpالخدمة ، ويمكن أن يكون لديك وحدة استماع واحدة فقط لكل نوع خدمة، أضف المزيد من المنافذ إلى وحدة الاستماع الافتراضية دون تغيير أي من الإعدادات الموجودة إذا كنت بحاجة إلى استخدام ClusterIp الخدمة.

إنشاء مستمعين وسيط جديدين

لإنشاء وحدة استماع جديدة، حدد الإعدادات التالية:

الاسم: اسم وحدة الاستماع. هذا الاسم هو أيضا اسم خدمة Kubernetes ما لم يتم تجاوزه.
نوع الخدمة: نوع خدمة Kubernetes. راجع نوع الخدمة.
المنافذ: قائمة المنافذ التي يجب الاستماع إليها. راجع المنافذ.
اسم الخدمة (اختياري): تجاوز اسم خدمة Kubernetes. راجع اسم الخدمة.

مثال: إنشاء وحدة استماع جديدة مع منفذين

يوضح هذا المثال كيفية إنشاء وحدة استماع جديدة باستخدام LoadBalancer نوع الخدمة. يعرف مورد BrokerListener منفذين يقبلان اتصالات MQTT من العملاء.

يستمع المنفذ الأول على المنفذ 1883 دون TLS والمصادقة. هذا الإعداد مناسب للاختبار فقط. لا تستخدم هذا التكوين في الإنتاج.
يستمع المنفذ الثاني على المنفذ 8883 مع تمكين TLS والمصادقة. يمكن فقط للعملاء المصادق عليهم مع رمز مميز لحساب خدمة Kubernetes الاتصال. يتم تعيين TLS إلى الوضع التلقائي، باستخدام cert-manager لإدارة شهادة الخادم من المصدر الافتراضي. هذا الإعداد أقرب إلى تكوين الإنتاج.

في مدخل Microsoft Azure، انتقل إلى مثيل عمليات IoT.
ضمن Components، حدد MQTT Broker.

حدد مستمع وسيط MQTT لإنشاء LoadBalancer>.

أدخل الإعدادات التالية:

الإعدادات	الوصف
الاسم	اسم مورد BrokerListener.
اسم الخدمة	اسم خدمة Kubernetes. اتركه فارغا لاستخدام اسم وحدة الاستماع كاسم خدمة.
نوع الخدمة	LoadBalancer محدد بالفعل.

ضمن المنافذ، أدخل الإعدادات التالية للمنفذ الأول:

الإعدادات	‏‏الوصف
المنفذ	أدخل 1883.
المصادقة	اختر بلا.
التصريح	اختر بلا.
البروتوكول	اختر MQTT.
TLS	لا تقم بإضافة.

حدد Add port entry لإضافة منفذ ثان وأدخل الإعدادات التالية:

الإعدادات	‏‏الوصف
المنفذ	أدخل 8883.
المصادقة	اختر الإعداد الافتراضي.
التصريح	اختر بلا.
البروتوكول	اختر MQTT.
TLS	حدد إضافة.

في جزء تكوين TLS، أدخل الإعدادات التالية:

الإعدادات	‏‏الوصف
وضع TLS	اختر تلقائي.
اسم المصدر	أدخل `azure-iot-operations-aio-certificate-issuer`.
نوع المصدر	اختر ClusterIssuer.

اترك الإعدادات الأخرى افتراضية، وحدد تطبيق.

حدد إنشاء وحدة استماع.

param aioInstanceName string = '<AIO_INSTANCE_NAME>'
param customLocationName string = '<CUSTOM_LOCATION_NAME>'
param listenerName string = '<LISTENER_NAME>'

resource aioInstance 'Microsoft.IoTOperations/instances@2024-11-01' existing = {
  name: aioInstanceName
}

resource customLocation 'Microsoft.ExtendedLocation/customLocations@2021-08-31-preview' existing = {
  name: customLocationName
}

resource defaultBroker 'Microsoft.IoTOperations/instances/brokers@2024-11-01' existing = {
  parent: aioInstance
  name: 'default'
}

resource loadBalancerListener 'Microsoft.IoTOperations/instances/brokers/listeners@2024-11-01' = {
  parent: defaultBroker
  name: listenerName
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }

  properties: {
    serviceType: 'LoadBalancer'
    ports: [
      {
        port: 1883
        protocol: 'Mqtt'
      }
      {
        authenticationRef: 'default'
        port: 8883
        protocol: 'Mqtt'
        tls: {
          mode: 'Automatic'
          certManagerCertificateSpec: {
            issuerRef: {
              name: 'azure-iot-operations-aio-certificate-issuer'
              kind: 'ClusterIssuer'
              group: 'cert-manager.io'
            }
          }
        }
      }
    ]
  }
}

انشر ملف Bicep باستخدام Azure CLI:

az deployment group create --resource-group <RESOURCE_GROUP> --template-file <FILE>.bicep

apiVersion: mqttbroker.iotoperations.azure.com/v1
kind: BrokerListener
metadata:
  name: <LISTENER_NAME>
  namespace: azure-iot-operations
spec:
  brokerRef: default
  serviceType: LoadBalancer
  ports:
  - port: 1883
    protocol: Mqtt
  - port: 8883
    authenticationRef: default
    protocol: Mqtt
    tls:
      mode: Automatic
      certManagerCertificateSpec:
        issuerRef:
            name: azure-iot-operations-aio-certificate-issuer
            kind: ClusterIssuer
            group: cert-manager.io

نوع الخدمة

يتم تعيين كل مورد BrokerListener إلى خدمة Kubernetes. يحدد نوع الخدمة كيفية تعرض الوسيط للشبكة. أنواع الخدمة المدعومة هي:

ClusterIp: يعرض الوسيط على عنوان IP داخلي لنظام المجموعة. يمكن للعملاء الاتصال بالوسيط من داخل المجموعة. نوع الخدمة الافتراضي هذا مخصص للمستمع الافتراضي.
NodePort: يعرض الوسيط على عنوان IP لكل عقدة في منفذ ثابت. يمكن للعملاء الاتصال بالوسيط من خارج المجموعة. يعد نوع الخدمة هذا مفيدا للتطوير والاختبار.
LoadBalancer: يعرض الوسيط خارجيا. يتم تعيين عنوان IP خارجي للخدمة يمكن للعملاء استخدامه للاتصال بالوسيط. نوع الخدمة هذا هو الأكثر شيوعا في عمليات توزيع الإنتاج.

وحدة استماع واحدة فقط لكل نوع خدمة

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

اسم الخدمة

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

تلميح

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

منافذ

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

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

لاستخدام TLS، راجع قسم تكوين TLS مع الإدارة التلقائية للشهادات أو تكوين TLS باستخدام إدارة الشهادات اليدوية.

استخدام نفس المنفذ عبر المستمعين

استخدام نفس رقم المنفذ عبر وحدات الاستماع المختلفة غير مدعوم. يجب أن يكون كل رقم منفذ فريدا داخل وسيط IoT Operations MQTT.

على سبيل المثال، إذا كان لديك وحدة استماع تستخدم المنفذ 1883، فلا يمكنك إنشاء وحدة استماع أخرى باستخدام المنفذ 1883. وبالمثل، يستخدم وحدة الاستماع الافتراضية المنفذ 18883، لذلك لا يمكنك إنشاء وحدة استماع أخرى مع المنفذ 18883.

دعم WebSockets

يدعم وسيط IoT Operations MQTT MQTT عبر WebSockets. لتمكين WebSockets، قم بتعيين البروتوكول إلى WebSockets للمنفذ.

تكوين TLS مع الإدارة التلقائية للشهادات

لتمكين TLS مع الإدارة التلقائية للشهادات، حدد إعدادات TLS على منفذ وحدة الاستماع.

التحقق من تثبيت مدير الشهادات

باستخدام الإدارة التلقائية للشهادات، يمكنك استخدام مدير الشهادات لإدارة شهادة خادم TLS. بشكل افتراضي، يتم تثبيت cert-manager جنبا إلى جنب مع عمليات IoT في cert-manager مساحة الاسم بالفعل. تحقق من التثبيت قبل المتابعة.

استخدم kubectl للتحقق من pods التي تطابق تسميات تطبيق cert-manager.

kubectl get pods --namespace cert-manager -l 'app in (cert-manager,cainjector,webhook)'

NAME                                           READY   STATUS    RESTARTS       AGE
aio-cert-manager-64f9548744-5fwdd              1/1     Running   4 (145m ago)   4d20h
aio-cert-manager-cainjector-6c7c546578-p6vgv   1/1     Running   4 (145m ago)   4d20h
aio-cert-manager-webhook-7f676965dd-8xs28      1/1     Running   4 (145m ago)   4d20h

إذا رأيت pods تظهر على أنها جاهزة ومشغلة، يتم تثبيت cert-manager وجاهز للاستخدام.

تلميح

لمزيد من التحقق من التثبيت، تحقق من وثائق cert-manager للتحقق من التثبيت. تذكر استخدام cert-manager مساحة الاسم.

إنشاء مصدر لشهادة خادم TLS

يحدد مورد مصدر إدارة الشهادات كيفية إصدار الشهادات تلقائيا. يدعم مدير الشهادات العديد من أنواع المصدرين في الأصل. كما أنه يدعم نوعا خارجيا issuer لتوسيع الوظائف خارج المصدرين المدعومين أصلا. يمكنك استخدام وسيط MQTT مع أي نوع من مصدري الشهادات.

هام

أثناء النشر الأولي، يتم تثبيت عمليات IoT مع مصدر افتراضي لشهادات خادم TLS. يمكنك استخدام مصدر البيانات هذا للتطوير والاختبار. لمزيد من المعلومات، راجع المرجع المصدق الجذر الافتراضي (CA) والمصدر مع عمليات Azure IoT. الخطوات التالية مطلوبة فقط إذا كنت تريد استخدام مصدر آخر.

يختلف نهج إنشاء المصدر وفقا للسيناريو الخاص بك. تسرد الأقسام التالية أمثلة لمساعدتك على البدء.

التطوير أو الاختبار
إنتاج

مصدر CA مفيد للتطوير والاختبار. يجب تكوينه بشهادة ومفتاح خاص مخزن في سر Kubernetes.

إعداد الشهادة الجذر كبيانات سرية ل Kubernetes

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

kubectl create secret tls test-ca --cert tls.crt --key tls.key -n azure-iot-operations

إذا لم يكن لديك شهادة CA، يمكن لمدير الشهادات إنشاء شهادة CA لك. يعرف استخدام مدير الشهادات لإنشاء شهادة CA باسم تمهيد تشغيل مصدر CA بشهادة موقعة ذاتيا.

ابدأ بإنشاء ca.yaml:

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: selfsigned-ca-issuer
  namespace: azure-iot-operations
spec:
  selfSigned: {}
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: selfsigned-ca-cert
  namespace: azure-iot-operations
spec:
  isCA: true
  commonName: test-ca
  secretName: test-ca
  issuerRef:
    # Must match Issuer name above
    name: selfsigned-ca-issuer
    # Must match Issuer kind above
    kind: Issuer
    group: cert-manager.io
  # Override default private key config to use an EC key
  privateKey:
    rotationPolicy: Always
    algorithm: ECDSA
    size: 256

إنشاء شهادة CA الموقعة ذاتيا باستخدام الأمر التالي:
```
kubectl apply -f ca.yaml
```

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

توزيع الشهادة الجذر

يخزن المثال السابق شهادة المرجع المصدق في سر Kubernetes يسمى test-ca. يمكنك استرداد الشهادة بتنسيق PEM من السر وتخزينها في الملف ca.crt باستخدام الأمر التالي:

kubectl get secret test-ca -n azure-iot-operations -o json | jq -r '.data["tls.crt"]' | base64 -d > ca.crt

يجب توزيع هذه الشهادة والوثوق بها من قبل جميع العملاء. على سبيل المثال، استخدم العلامة --cafile لعميل Mosquitto.

إنشاء مصدر الشهادة استنادا إلى شهادة المرجع المصدق

يحتاج مدير الشهادات إلى مصدر استنادا إلى شهادة المرجع المصدق التي تم إنشاؤها أو استيرادها في الخطوة السابقة. قم بإنشاء الملف التالي ك issuer-ca.yaml:

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: my-issuer
  namespace: azure-iot-operations
spec:
  ca:
    # Must match secretName of generated or imported CA cert
    secretName: test-ca

إنشاء المصدر باستخدام الأمر التالي:

kubectl apply -f issuer-ca.yaml

يقوم الأمر السابق بإنشاء مصدر لإصدار شهادات خادم TLS. لاحظ اسم المصدر ونوعه. في المثال، الاسم هو my-issuer والنوع هو Issuer. يتم تعيين هذه القيم في مورد BrokerListener لاحقا.

للإنتاج، تحقق من وثائق cert-manager لمعرفة المصدر الذي يعمل بشكل أفضل لك. على سبيل المثال، مع مصدر Vault:

انشر HashiCorp Vault في بيئة من اختيارك، مثل Kubernetes. تهيئة المخزن وإلغاء تنظيمه وفقا لذلك.
إنشاء وتكوين محرك أسرار PKI عن طريق استيراد شهادة المرجع المصدق.
تكوين Vault بدور ونهج لإصدار شهادات الخادم.

الدور التالي مثال على ذلك. لاحظ أن ExtKeyUsageServerAuth يجعل شهادة الخادم تعمل:
```
vault write pki/roles/my-issuer \
  allow_any_name=true \
  client_flag=false \
  ext_key_usage=ExtKeyUsageServerAuth \
  no_store=true \
  max_ttl=240h
```
مثال على نهج الدور:
```
path "pki/sign/my-issuer" {
  capabilities = ["create", "update"]
}
```
إعداد المصادقة بين cert-manager و Vault باستخدام طريقة اختيار، مثل SAT.
تكوين مصدر مخزن إدارة الشهادات.

تمكين إدارة شهادات TLS التلقائية لمنفذ

المثال التالي هو مورد BrokerListener الذي يمكن TLS على المنفذ 8884 مع إدارة الشهادات التلقائية.

في مدخل Microsoft Azure، انتقل إلى مثيل عمليات IoT.
ضمن Components، حدد MQTT Broker.
حدد وحدة استماع أو أنشئها. يمكنك إنشاء وحدة استماع واحدة فقط لكل نوع خدمة. إذا كان لديك وحدة استماع من نفس نوع الخدمة، يمكنك إضافة المزيد من المنافذ إلى وحدة الاستماع الموجودة.

يمكنك إضافة إعدادات TLS إلى وحدة الاستماع عن طريق تحديد TLS على منفذ موجود أو عن طريق إضافة منفذ جديد.

أدخل الإعدادات التالية:

الإعدادات	الوصف
الاسم	اسم مورد BrokerListener. أدخل `aio-broker-loadbalancer-tls`.
المنفذ	رقم المنفذ الذي يستمع إليه BrokerListener لاتصالات MQTT. أدخل 8884.
المصادقة	مرجع مورد المصادقة.
التصريح	مرجع مورد التخويل.
TLS	حدد الزر إضافة.
اسم المصدر	اسم مصدر مدير الشهادات. مطلوب.
نوع المصدر	نوع مصدر مدير الشهادات. مطلوب.
مجموعة المصدر	مجموعة من مصدر مدير الشهادات. مطلوب.
خوارزمية المفتاح الخاص	خوارزمية المفتاح الخاص.
نهج تدوير المفتاح الخاص	نهج تدوير المفتاح الخاص.
أسماء DNS	أسماء بديلة لموضوع DNS للشهادة.
عناوين IP	عناوين IP للأسماء البديلة للموضوع للشهادة.
اسم السر	بيانات Kubernetes السرية التي تحتوي على شهادة عميل X.509.
المدة	إجمالي مدة بقاء شهادة خادم TLS افتراضيا إلى 90 يوما.
التجديد قبل	متى تبدأ تجديد الشهادة.

حدد تطبيق لحفظ إعدادات TLS.

param aioInstanceName string = '<AIO_INSTANCE_NAME>'
param customLocationName string = '<CUSTOM_LOCATION_NAME>'
param listenerName string = 'aio-broker-loadbalancer-tls'

resource aioInstance 'Microsoft.IoTOperations/instances@2024-11-01' existing = {
  name: aioInstanceName
}

resource customLocation 'Microsoft.ExtendedLocation/customLocations@2021-08-31-preview' existing = {
  name: customLocationName
}

resource defaultBroker 'Microsoft.IoTOperations/instances/brokers@2024-11-01' existing = {
  parent: aioInstance
  name: 'default'
}

resource loadBalancerListener 'Microsoft.IoTOperations/instances/brokers/listeners@2024-11-01' = {
  parent: defaultBroker
  name: listenerName
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }

  properties: {
    serviceType: 'LoadBalancer'
    ports: [
      {
        authenticationRef: 'default'
        port: 8884
        tls: {
          mode: 'Automatic'
          certManagerCertificateSpec: {
            issuerRef: {
              name: 'my-issuer'
              kind: 'Issuer'
            }
          }
        }
      }
    ]
  }
}

انشر ملف Bicep باستخدام Azure CLI:

az deployment group create --resource-group <RESOURCE_GROUP> --template-file <FILE>.bicep

tls تعديل الإعداد في مورد BrokerListener لتحديد منفذ TLS وللواجهات Issuer الأمامية.

apiVersion: mqttbroker.iotoperations.azure.com/v1
kind: BrokerListener
metadata:
  name: aio-broker-loadbalancer-tls # Avoid conflicts with default service name 'aio-broker'
  namespace: azure-iot-operations
spec:
  brokerRef: default
  serviceType: loadBalancer
  ports:
  - port: 8884 # Avoid conflicts with default port 18883
    tls:
      mode: Automatic
      certManagerCertificateSpec:
        issuerRef:
          name: my-issuer
          kind: Issuer

بعد تكوين مورد BrokerListener، ينشئ وسيط MQTT تلقائيا خدمة جديدة مع المنفذ المحدد وتمكين TLS.

اختياري: تكوين معلمات شهادة الخادم

المعلمات المطلوبة الوحيدة هي Issuer الاسم والنوع Issuer . يتم اختيار جميع الخصائص الأخرى لشهادات خادم TLS التي تم إنشاؤها تلقائيا. ومع ذلك، يسمح وسيط MQTT بتخصيص خصائص معينة باتباع نفس بناء الجملة مثل شهادات مدير الشهادات. على سبيل المثال، يمكنك تحديد خوارزمية المفتاح الخاص ونهج التدوير. توجد هذه الإعدادات ضمن tls.certManagerCertificateSpec أو في جزء تكوين TLS في مدخل Microsoft Azure.

للحصول على قائمة كاملة بهذه الإعدادات، راجع مرجع واجهة برمجة تطبيقات Broker Listener CertManagerCertificateSpec.

تحقق من النشر

استخدم kubectl للتحقق من تشغيل الخدمة المقترنة بمورد BrokerListener. من المثال السابق، اسم الخدمة هو aio-broker-loadbalancer-tls ومساحة الاسم هي azure-iot-operations. يتحقق الأمر التالي من حالة الخدمة:

$ kubectl get service my-new-tls-listener -n azure-iot-operations
NAME                           TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
aio-broker-loadbalancer-tls    LoadBalancer   10.X.X.X        172.X.X.X     8884:32457/TCP   33s

الاتصال بالوسيط باستخدام TLS

بعد تكوين شهادة الخادم، يتم تمكين TLS. للاختبار باستخدام Mosquitto:

mosquitto_pub -h $HOST -p 8884 -V mqttv5 -i "test" -t "test" -m "test" --cafile ca.crt

--cafile تمكن الوسيطة TLS على عميل Mosquitto وتحدد أن العميل يجب أن يثق في جميع شهادات الخادم الصادرة عن الملف المحدد. يجب تحديد ملف يحتوي على مصدر شهادة خادم TLS المكونة.

استبدل $HOST بالمضيف المناسب:

إذا كنت تتصل من داخل نفس المجموعة، فاستبدل باسم الخدمة المحدد (my-new-tls-listener على سبيل المثال) أو الخدمة CLUSTER-IP.
إذا كنت تتصل من خارج نظام المجموعة، فاستخدم الخدمة EXTERNAL-IP.

تذكر تحديد أساليب المصادقة إذا لزم الأمر.

المرجع المصدق الجذري الافتراضي ومصدر الشهادة

لمساعدتك في البدء، يتم نشر عمليات IoT بشهادة CA "التشغيل السريع" الافتراضية ومصدر شهادات خادم TLS. يمكنك استخدام مصدر البيانات هذا للتطوير والاختبار. لمزيد من المعلومات، راجع المرجع المصدق الجذري الافتراضي ومصدر شهادات خادم TLS.

للإنتاج، يجب تكوين مصدر CA بشهادة من مرجع مصدق موثوق به، كما هو موضح في الأقسام السابقة.

تكوين TLS مع إدارة الشهادات اليدوية

لتكوين وسيط MQTT يدويا لاستخدام شهادة TLS معينة، حددها في مورد BrokerListener مع الإشارة إلى سر Kubernetes ونشره باستخدام kubectl. تعرض هذه المقالة مثالا يقوم بتكوين TLS مع شهادات موقعة ذاتيا للاختبار.

إنشاء مرجع مصدق باستخدام Step CLI

Step هو مدير شهادات يمكنه الحصول عليك وتشغيله بسرعة عند إنشاء المرجع المصدق الخاص بك وإدارته.

تثبيت Step CLI وإنشاء شهادة ومفتاح المرجع المصدق الجذر.
```
step certificate create --profile root-ca "Example Root CA" root_ca.crt root_ca.key
```

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

step certificate create --profile intermediate-ca "Example Intermediate CA" intermediate_ca.crt intermediate_ca.key \
--ca root_ca.crt --ca-key root_ca.key

إنشاء شهادة خادم

استخدم Step CLI لإنشاء شهادة خادم من شهادة CA الوسيطة والمفتاح.

step certificate create mqtts-endpoint mqtts-endpoint.crt mqtts-endpoint.key \
--profile leaf \
--not-after 8760h \
--san mqtts-endpoint \
--san localhost \
--ca intermediate_ca.crt --ca-key intermediate_ca.key \
--no-password --insecure

هنا، mqtts-endpoint و localhost هي الأسماء البديلة للموضوع (SANs) للواجهة الأمامية للوسيط MQTT في Kubernetes والعملاء المحليين، على التوالي. للاتصال عبر الإنترنت، أضف --san مع عنوان IP خارجي. --no-password --insecure يتم استخدام العلامات للاختبار لتخطي مطالبات كلمة المرور وتعطيل حماية كلمة المرور للمفتاح الخاص لأنه مخزن في سر Kubernetes. للإنتاج، استخدم كلمة مرور وقم بتخزين المفتاح الخاص في موقع آمن مثل Azure Key Vault.

متطلبات خوارزمية مفتاح الشهادة

يتم دعم كل من مفاتيح EC وRSA، ولكن يجب أن تستخدم جميع الشهادات في السلسلة نفس خوارزمية المفتاح. إذا قمت باستيراد شهادات المرجع المصدق الخاصة بك، فتأكد من أن شهادة الخادم تستخدم نفس خوارزمية المفتاح مثل CAs.

استيراد سلسلة شهادات الخادم كبيانات سرية ل Kubernetes

إنشاء سلسلة شهادات خادم كاملة، حيث يكون ترتيب الشهادات مهما. شهادة الخادم هي الأولى في الملف، والمتوسطة هي الثانية.
```
cat  mqtts-endpoint.crt intermediate_ca.crt  > server_chain.crt
```

إنشاء سر Kubernetes مع سلسلة شهادات الخادم ومفتاح الخادم باستخدام kubectl.

kubectl create secret tls server-cert-secret -n azure-iot-operations \
--cert server_chain.crt \
--key mqtts-endpoint.key

تمكين إدارة شهادات TLS اليدوية لمنفذ

يوضح المثال التالي مورد BrokerListener الذي يمكن TLS على المنفذ 8884 مع إدارة الشهادات اليدوية.

في مدخل Microsoft Azure، انتقل إلى مثيل عمليات IoT.
ضمن Components، حدد MQTT Broker.
حدد وحدة استماع أو أنشئها. يمكنك إنشاء وحدة استماع واحدة فقط لكل نوع خدمة. إذا كان لديك وحدة استماع من نفس نوع الخدمة، يمكنك إضافة المزيد من المنافذ إلى وحدة الاستماع الموجودة. لمتابعة المثال، حدد اسم خدمة وحدة الاستماع ك mqtts-endpoint.

يمكنك إضافة إعدادات TLS إلى وحدة الاستماع عن طريق تحديد TLS على منفذ موجود أو عن طريق إضافة منفذ جديد.

أدخل الإعدادات التالية:

الإعدادات	‏‏الوصف
المنفذ	رقم المنفذ الذي يستمع إليه BrokerListener لاتصالات MQTT. مطلوب.
المصادقة	مرجع مورد المصادقة.
التصريح	مرجع مورد التخويل.
TLS	حدد الزر إضافة.
اسم السر	بيانات Kubernetes السرية التي تحتوي على شهادة عميل X.509.

حدد تطبيق لحفظ إعدادات TLS.

tls تعديل الإعداد في مورد BrokerListener لتحديد تكوين TLS اليدوي الذي يشير إلى سر Kubernetes. لاحظ اسم السر المستخدم لشهادة خادم TLS (server-cert-secret في المثال السابق).

param aioInstanceName string = '<AIO_INSTANCE_NAME>'
param customLocationName string = '<CUSTOM_LOCATION_NAME>'
param listenerServiceName string = 'mqtts-endpoint'
param listenerName string = '<LISTENER_NAME>' // Match the SAN in the server certificate

resource aioInstance 'Microsoft.IoTOperations/instances@2024-11-01' existing = {
  name: aioInstanceName
}

resource customLocation 'Microsoft.ExtendedLocation/customLocations@2021-08-31-preview' existing = {
  name: customLocationName
}

resource defaultBroker 'Microsoft.IoTOperations/instances/brokers@2024-11-01' existing = {
  parent: aioInstance
  name: 'default'
}

resource loadBalancerListener 'Microsoft.IoTOperations/instances/brokers/listeners@2024-11-01' = {
  parent: defaultBroker
  name: listenerName
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }

  properties: {
    serviceName: listenerServiceName
    serviceType: 'LoadBalancer'
    ports: [
      {
        authenticationRef: 'default'
        port: 8885 // Avoid port conflict with default listener at 18883
        tls: {
          mode: 'Manual'
          manual: {
            secretRef: 'server-cert-secret'
          }
        }
      }
    ]
  }
}

انشر ملف Bicep باستخدام Azure CLI:

az deployment group create --resource-group <RESOURCE_GROUP> --template-file <FILE>.bicep

apiVersion: mqttbroker.iotoperations.azure.com/v1
kind: BrokerListener
metadata:
  name: loadbalancer-tls
  namespace: azure-iot-operations
spec:
  brokerRef: default
  serviceType: loadBalancer # Optional, defaults to clusterIP
  serviceName: mqtts-endpoint # Match the SAN in the server certificate
  ports:
  - port: 8885 # Avoid port conflict with default listener at 18883
    tls:
      mode: Manual
      manual:
        secretRef: server-cert-secret

بعد إنشاء مورد BrokerListener، يقوم المشغل تلقائيا بإنشاء خدمة Kubernetes ونشر وحدة الاستماع. يمكنك التحقق من حالة الخدمة عن طريق تشغيل kubectl get svc.

الاتصال بالوسيط باستخدام TLS

لاختبار اتصال TLS مع عميل Mosquitto، انشر رسالة ومرر شهادة المرجع المصدق الجذر في المعلمة --cafile.

mosquitto_pub -d -h localhost -p 8885 -i "my-client" -t "test-topic" -m "Hello" --cafile root_ca.crt

تذكر تحديد عناصر مثل اسم المستخدم وكلمة المرور إذا تم تمكين مصادقة وسيط MQTT.

Client my-client sending CONNECT
Client my-client received CONNACK (0)
Client my-client sending PUBLISH (d0, q0, r0, m1, 'test-topic', ... (5 bytes))
Client my-client sending DISCONNECT

تلميح

لاستخدام localhost، يجب أن يكون المنفذ متوفرا على الجهاز المضيف. مثال على ذلك kubectl port-forward svc/mqtts-endpoint 8885:8885 -n azure-iot-operations . مع بعض توزيعات Kubernetes مثل K3d، يمكنك إضافة منفذ معاد توجيهه باستخدام k3d cluster edit $CLUSTER_NAME --port-add 8885:8885@loadbalancer.

للاتصال بالوسيط، تحتاج إلى توزيع جذر الثقة، المعروف أيضا باسم حزمة الثقة، لجميع العملاء. في هذه الحالة، جذر الثقة هو المرجع المصدق الجذر الموقع ذاتيا الذي تم إنشاؤه بواسطة Step CLI. توزيع جذر الثقة مطلوب للعميل للتحقق من سلسلة شهادات الخادم. إذا كان عملاء MQTT هم أحمال العمل على مجموعة Kubernetes، تحتاج أيضا إلى إنشاء ConfigMap مع المرجع المصدق الجذر وتركيبه في جراب الخاص بك.

استخدام IP خارجي لشهادة الخادم

للاتصال ب TLS عبر الإنترنت، يجب أن يكون لشهادة خادم وسيط MQTT اسم المضيف الخارجي أو عنوان IP ك SAN. في الإنتاج، عادة ما تكون هذه المعلومات اسم DNS أو عنوان IP معروف. أثناء التطوير/الاختبار، قد لا تعرف اسم المضيف أو IP الخارجي الذي تم تعيينه قبل النشر. لحل هذه المشكلة، انشر وحدة الإصغاء بدون شهادة الخادم أولا، وأنشئ شهادة الخادم والبيانات السرية باستخدام عنوان IP الخارجي، واستورد السر إلى وحدة الاستماع.

إذا حاولت نشر مثال وحدة إصغاء manual-tls-listener TLS ولكن سر server-cert-secret Kubernetes المشار إليه غير موجود، يتم إنشاء الخدمة المقترنة، ولكن لا تبدأ وحدات الجراب. يتم إنشاء الخدمة لأن المشغل يحتاج إلى حجز IP الخارجي للمستمع.

kubectl get svc mqtts-endpoint -n azure-iot-operations

NAME                   TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
mqtts-endpoint         LoadBalancer   10.X.X.X        172.X.X.X     8885:30674/TCP      1m15s

هذا السلوك متوقع أثناء استيراد شهادة الخادم. تشير سجلات إدارة الصحة إلى أن وسيط MQTT ينتظر شهادة الخادم.

kubectl logs -l app=health-manager -n azure-iot-operations

...
<6>2023-11-06T21:36:13.634Z [INFO] [1] - Server certificate server-cert-secret not found. Awaiting creation of secret.

ملاحظة

بشكل عام، في نظام موزع، سجلات pods ليست محددة ويجب استخدامها بحذر. الطريقة الصحيحة لعرض معلومات مثل هذه هي من خلال أحداث Kubernetes وحالة الموارد المخصصة، وهي في التراكم. ضع في اعتبارك الخطوة السابقة كحل بديل مؤقت.

على الرغم من أن القرون الأمامية ليست أعلى، فإن IP الخارجي متاح بالفعل.

kubectl get svc mqtts-endpoint -n azure-iot-operations

NAME                   TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
mqtts-endpoint         LoadBalancer   10.X.X.X        172.X.X.X     8885:30674/TCP      1m15s

من هنا، اتبع نفس الخطوات كما هو موضح سابقا لإنشاء شهادة خادم باستخدام عنوان IP الخارجي هذا في --san وإنشاء سر Kubernetes بنفس الطريقة. بعد إنشاء السر، يتم استيراده تلقائيا إلى وحدة الاستماع.

مشاركة عبر

اتصال وسيط MQTT الآمن باستخدام BrokerListener

BrokerListener الافتراضي

تجنب تعديل وحدة إصغاء الوسيط الافتراضية

إنشاء مستمعين وسيط جديدين

مثال: إنشاء وحدة استماع جديدة مع منفذين

نوع الخدمة

وحدة استماع واحدة فقط لكل نوع خدمة

اسم الخدمة

منافذ

استخدام نفس المنفذ عبر المستمعين

دعم WebSockets

تكوين TLS مع الإدارة التلقائية للشهادات

التحقق من تثبيت مدير الشهادات

إنشاء مصدر لشهادة خادم TLS

إعداد الشهادة الجذر كبيانات سرية ل Kubernetes

توزيع الشهادة الجذر

إنشاء مصدر الشهادة استنادا إلى شهادة المرجع المصدق

تمكين إدارة شهادات TLS التلقائية لمنفذ

اختياري: تكوين معلمات شهادة الخادم

تحقق من النشر

الاتصال بالوسيط باستخدام TLS

المرجع المصدق الجذري الافتراضي ومصدر الشهادة

تكوين TLS مع إدارة الشهادات اليدوية

إنشاء مرجع مصدق باستخدام Step CLI

إنشاء شهادة خادم

متطلبات خوارزمية مفتاح الشهادة

استيراد سلسلة شهادات الخادم كبيانات سرية ل Kubernetes

تمكين إدارة شهادات TLS اليدوية لمنفذ

الاتصال بالوسيط باستخدام TLS

استخدام IP خارجي لشهادة الخادم

الملاحظات

الموارد الإضافية

مشاركة عبر

اتصال وسيط MQTT الآمن باستخدام BrokerListener

BrokerListener الافتراضي

تجنب تعديل وحدة إصغاء الوسيط الافتراضية

إنشاء مستمعين وسيط جديدين

مثال: إنشاء وحدة استماع جديدة مع منفذين

نوع الخدمة

وحدة استماع واحدة فقط لكل نوع خدمة

اسم الخدمة

منافذ

استخدام نفس المنفذ عبر المستمعين

دعم WebSockets

تكوين TLS مع الإدارة التلقائية للشهادات

التحقق من تثبيت مدير الشهادات

إنشاء مصدر لشهادة خادم TLS

إعداد الشهادة الجذر كبيانات سرية ل Kubernetes

توزيع الشهادة الجذر

إنشاء مصدر الشهادة استنادا إلى شهادة المرجع المصدق

تمكين إدارة شهادات TLS التلقائية لمنفذ

اختياري: تكوين معلمات شهادة الخادم

تحقق من النشر

الاتصال بالوسيط باستخدام TLS

المرجع المصدق الجذري الافتراضي ومصدر الشهادة

تكوين TLS مع إدارة الشهادات اليدوية

إنشاء مرجع مصدق باستخدام Step CLI

إنشاء شهادة خادم

متطلبات خوارزمية مفتاح الشهادة

استيراد سلسلة شهادات الخادم كبيانات سرية ل Kubernetes

تمكين إدارة شهادات TLS اليدوية لمنفذ

الاتصال بالوسيط باستخدام TLS

استخدام IP خارجي لشهادة الخادم

المحتوى ذو الصلة

الملاحظات

الموارد الإضافية