Mengonfigurasi autentikasi broker MQTT

Penting

Halaman ini mencakup instruksi untuk mengelola komponen Azure IoT Operations menggunakan manifes penyebaran Kubernetes, yang masih dalam tahap pratinjau. Fitur ini disediakan dengan beberapa batasan, dan tidak boleh digunakan untuk beban kerja produksi.

Lihat Ketentuan Penggunaan Tambahan untuk Pratinjau Microsoft Azure untuk mengetahui ketentuan hukum yang berlaku untuk fitur Azure yang dalam tahap beta, pratinjau, atau belum dirilis ke ketersediaan umum.

Broker MQTT mendukung beberapa metode autentikasi untuk klien. Anda dapat mengonfigurasi setiap port pendengar untuk memiliki pengaturan autentikasinya sendiri dengan sumber daya BrokerAuthentication. Untuk daftar pengaturan yang tersedia, lihat referensi API Autentikasi Broker .

Menautkan BrokerListener dan BrokerAuthentication

Aturan berikut berlaku untuk hubungan antara sumber daya BrokerListener dan BrokerAuthentication:

• Setiap sumber daya BrokerListener dapat memiliki beberapa port. Anda dapat menautkan setiap port ke sumber daya BrokerAuthentication.
• Setiap sumber daya BrokerAuthentication dapat mendukung beberapa metode autentikasi sekaligus.
• Port yang tidak menautkan sumber daya BrokerAuthentication telah menonaktifkan autentikasi.

Untuk menautkan port BrokerListener ke sumber daya BrokerAuthentication, tentukan authenticationRef bidang di ports pengaturan sumber daya BrokerListener. Untuk mempelajari lebih lanjut, lihat Sumber daya BrokerListener.

Sumber daya default BrokerAuthentication

Azure IoT Operations menyebarkan sumber daya default BrokerAuthentication bernama default yang ditautkan dengan listener default di azure-iot-operations namespace. Ini hanya menggunakan token akun layanan Kubernetes (SAT) untuk autentikasi.

Penting

Metode autentikasi SAT dalam sumber daya BrokerAuthentication default diperlukan agar komponen dalam Operasi IoT berfungsi dengan benar. Hindari memperbarui atau menghapus sumber daya BrokerAuthentication default.

Portal

1. Di portal Azure, buka instans Operasi IoT Anda.

2. Di bawah Komponen, pilih MQTT Broker.

3. Pilih tab Autentikasi .

4. Dari daftar kebijakan autentikasi, pilih nama kebijakan default .

   

Untuk menambahkan metode autentikasi baru, pilih Tambahkan metode.

Azure CLI

Gunakan perintah authn show broker az iot ops untuk melihat kebijakan autentikasi default broker MQTT lokal.

az iot ops broker authn show --resource-group <ResourceGroupName> --instance <AioInstanceName> --broker default --name default 

Bisep

Untuk mengedit titik akhir default, buat file Bicep .bicep dengan konten berikut. Perbarui pengaturan sesuai kebutuhan. Ganti placeholder seperti <AIO_INSTANCE_NAME> dengan nilai Anda.

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 defaultBrokerAuthentication 'Microsoft.IoTOperations/instances/brokers/authentications@2024-11-01' = {
  parent: defaultBroker
  name: 'default'
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }
  properties: {
    authenticationMethods: [
      {
        method: 'ServiceAccountToken'
        serviceAccountTokenSettings: {
          audiences: [
            'aio-internal'
          ]
        }
      }
    ]
  }
}

Sebarkan file Bicep dengan menggunakan Azure CLI:

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

Kubernetes (versi pratinjau)

Untuk memeriksa sumber daya autentikasi broker default, jalankan:

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

Output menunjukkan sumber daya BrokerAuthentication default, dengan metadata dihapus untuk kejelasan:

apiVersion: mqttbroker.iotoperations.azure.com/v1
kind: BrokerAuthentication
metadata:
  name: default
  namespace: azure-iot-operations
spec:
  authenticationMethods:
    - method: ServiceAccountToken
      serviceAccountTokenSettings:
        audiences:
          - aio-internal

Jika Anda perlu membuat perubahan, ubah authenticationMethods bidang di sumber daya ini saat Anda mempertahankan metode autentikasi SAT dengan aio-internal audiens. Kemudian, sebarkan dengan menggunakan kubectl apply.

Proses autentikasi

Urutan metode autentikasi yang ditentukan menentukan bagaimana broker MQTT mengautentikasi klien. Broker MQTT mencoba mengautentikasi kredensial klien dengan menggunakan metode pertama yang ditentukan dan melakukan iterasi melalui metode yang ditentukan sampai menemukan kecocokan atau mencapai akhir.

Untuk setiap metode, broker MQTT terlebih dahulu memeriksa apakah kredensial klien relevan untuk metode tersebut. Misalnya, autentikasi SAT memerlukan nama pengguna yang dimulai dengan K8S-SAT, dan autentikasi X.509 memerlukan sertifikat klien. Jika kredensial klien relevan, broker MQTT kemudian memverifikasi apakah kredensial tersebut valid. Untuk informasi selengkapnya, lihat bagian Mengonfigurasi metode autentikasi .

Untuk autentikasi kustom, broker MQTT memperlakukan kegagalan untuk berkomunikasi dengan server autentikasi kustom karena kredensial tidak relevan. Perilaku ini memungkinkan broker MQTT kembali ke metode lain jika server autentikasi kustom tidak dapat dijangkau.

Alur autentikasi berakhir ketika:

• Salah satu kondisi ini benar:
  • Kredensial klien relevan dan valid untuk salah satu dari metode yang ada.
  • Kredensial klien tidak relevan untuk metode apa pun.
  • Kredensial klien relevan tetapi tidak valid dengan metode mana pun.
• Broker MQTT memberikan atau menolak akses ke klien berdasarkan hasil alur autentikasi.

Contohnya:

apiVersion: mqttbroker.iotoperations.azure.com/v1
kind: BrokerAuthentication
metadata: 
  name: default
  namespace: azure-iot-operations
spec:
  authenticationMethods:
    - method: Custom
      customSettings:
        # ...
    - method: ServiceAccountToken
      serviceAccountTokenSettings:
        # ...

Contoh sebelumnya menentukan custom dan SAT. Ketika klien terhubung, broker MQTT mencoba mengautentikasi klien dengan menggunakan metode yang ditentukan dalam urutan custom lalu SAT.

1. Broker MQTT memeriksa apakah kredensial klien valid untuk autentikasi kustom. Karena autentikasi kustom bergantung pada server eksternal untuk menentukan validitas kredensial, broker mempertimbangkan semua kredensial yang relevan dengan autentikasi kustom dan meneruskannya ke server autentikasi kustom.
2. Jika server autentikasi kustom merespons dengan hasil Pass atau Fail , alur autentikasi berakhir. Jika server autentikasi kustom tidak tersedia, broker MQTT kembali ke metode yang ditentukan yang tersisa, dengan SAT menjadi berikutnya.
3. Broker MQTT mencoba mengautentikasi kredensial sebagai kredensial SAT.

Jika server autentikasi kustom tidak tersedia dan semua metode berikutnya menentukan bahwa kredensial yang disediakan tidak relevan, broker menolak koneksi klien.

Mengonfigurasi metode autentikasi

Anda dapat menambahkan metode autentikasi seperti X.509, SAT, atau kustom untuk kebijakan autentikasi.

Untuk menambahkan metode autentikasi ke kebijakan:

Portal

1. Di portal Azure, buka instans Operasi IoT Anda.

2. Di bawah Komponen, pilih MQTT Broker.

3. Pilih tab Autentikasi .

4. Pilih kebijakan autentikasi yang sudah ada atau buat yang baru.

5. Tambahkan metode baru dengan memilih Tambahkan metode.

6. Pilih jenis metode dari daftar dropdown, lalu pilih Tambahkan detail untuk mengonfigurasi metode.

   

Azure CLI

Gunakan perintah az iot ops broker authn apply untuk membuat atau mengubah kebijakan autentikasi broker MQTT.

az iot ops broker authn apply --resource-group <ResourceGroupName> --instance <AioInstanceName> --broker <BrokerName> --name <AuthenticationResourceName> --config-file <ConfigFilePathAndName>

Parameter --config-file adalah jalur dan nama file file konfigurasi JSON yang berisi properti sumber daya.

Dalam contoh ini, asumsikan file konfigurasi bernama my-authn-policy.json dengan konten berikut yang disimpan di direktori beranda pengguna:

{
    "authenticationMethods": [
      {
        "customSettings": {
          "auth": {
            "x509": {
              "secretRef": "custom-auth-client-cert"
            }
          },
          "caCertConfigMap": "custom-auth-ca",
          "endpoint": "https://auth-server-template",
          "headers": {
            "header_key": "header_value"
          }
        },
        "method": "Custom"
      },
      {
        "method": "ServiceAccountToken",
        "serviceAccountTokenSettings": {
          "audiences": [
            "my-audience"
          ]
        }
      },
      {
        "method": "X509",
        "x509Settings": {
          "authorizationAttributes": {
            "intermediate": {
              "attributes": {
                "city": "seattle",
                "foo": "bar"
              },
              "subject": "CN = Contoso Intermediate CA"
            },
            "root": {
              "attributes": {
                "organization": "contoso"
              },
              "subject": "CN = Contoso Root CA Cert, OU = Engineering, C = US"
            },
            "smartfan": {
              "attributes": {
                "building": "17"
              },
              "subject": "CN = smart-fan"
            }
          },
          "trustedClientCaCert": "client-ca"
        }
      }
    ]
}

Contoh perintah untuk membuat kebijakan autentikasi baru bernama my-policy adalah sebagai berikut:

az iot ops broker authn apply --resource-group myResourceGroupName --instance myAioInstanceName --broker default --name my-policy --config-file ~/my-authn-policy.json

Bisep

param aioInstanceName string = '<AIO_INSTANCE_NAME>'
param customLocationName string = '<CUSTOM_LOCATION_NAME>'
param policyName string = '<POLICY_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 myBrokerAuthentication 'Microsoft.IoTOperations/instances/brokers/authentications@2024-11-01' = {
  parent: defaultBroker
  name: policyName
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }
  properties: {
    authenticationMethods: [
      {
        method: 'Custom'
        customSettings: {
          endpoint: 'https://auth-server-template'
          caCertConfigMap: 'custom-auth-ca'
          auth: {
            x509: {
              secretRef: 'custom-auth-client-cert'
            }
          }
          headers: {
            header_key: 'header_value'
          }
        }
      }
      {
        method: 'ServiceAccountToken'
        serviceAccountTokenSettings: {
          audiences: [
            'aio-internal'
            'my-audience'
          ]
        }
      }
      {
        method: 'X509'
        x509Settings: {
          trustedClientCaCert: 'client-ca'
          authorizationAttributes: {
            root: {
              attributes: {
                organization: 'contoso'
              }
              subject: 'CN = Contoso Root CA Cert, OU = Engineering, C = US'
            }
            intermediate: {
              attributes: {
                city: 'seattle'
                foo: 'bar'
              }
              subject: 'CN = Contoso Intermediate CA'
            }
            smartfan: {
              attributes: {
                building: '17'
              }
              subject: 'CN = smart-fan'
            }
          }
        }
      }
    ]
  }
}

Sebarkan file Bicep dengan menggunakan Azure CLI:

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

Kubernetes (versi pratinjau)

Ubah sumber daya BrokerAuthentication untuk kebijakan autentikasi dengan menambahkan metode baru ke bagian .authenticationMethods Contoh berikut menunjukkan beberapa metode autentikasi untuk sumber daya BrokerAuthentication:

apiVersion: mqttbroker.iotoperations.azure.com/v1
kind: BrokerAuthentication
metadata:
  name: my-policy
  namespace: azure-iot-operations
spec:
  authenticationMethods:
  - method: Custom
    customSettings:
      endpoint: https://auth-server-template
      caCertConfigMap: custom-auth-ca
      auth:
        x509:
          secretRef: custom-auth-client-cert
      headers:
        header_key: header_value
    - method: ServiceAccountToken
      serviceAccountTokenSettings:
        audiences:
        - aio-internal
        - my-audience
    - method: X509
      x509Settings:
        trustedClientCaCert: client-ca
        authorizationAttributes:
          root:
            attributes:
              organization: contoso
            subject: CN = Contoso Root CA Cert, OU = Engineering, C = US
          intermediate:
            attributes:
              city: seattle
              foo: bar
            subject: CN = Contoso Intermediate CA
          smart-fan:
            attributes:
              building: "17"
            subject: CN = smart-fan

Untuk mengubah konfigurasi, modifikasi pengaturan authenticationMethods dalam sumber daya BrokerAuthentication ini. Kemudian sebarkan dengan menggunakan kubectl apply.

Untuk mempelajari selengkapnya tentang setiap opsi autentikasi, lihat bagian berikutnya untuk setiap metode.

Untuk informasi selengkapnya tentang cara mengaktifkan pengaturan aman dengan mengonfigurasi instans Azure Key Vault dan mengaktifkan identitas beban kerja, lihat Mengaktifkan pengaturan aman dalam penyebaran Operasi Azure IoT.

X.509

Petunjuk / Saran

Untuk contoh end-to-end tentang cara mengonfigurasi autentikasi X.509, lihat Tutorial: TLS, autentikasi klien X.509, dan otorisasi kontrol akses berbasis atribut (ABAC).

Dengan autentikasi X.509, broker MQTT menggunakan sertifikat Otoritas Sertifikat (CA) tepercaya untuk memvalidasi sertifikat klien. CA tepercaya ini dapat menjadi CA akar atau menengah. Broker memeriksa rantai sertifikat klien terhadap sertifikat CA tepercaya. Jika rantai valid, klien diautentikasi.

Untuk menggunakan autentikasi X.509 dengan sertifikat CA tepercaya, Anda harus memenuhi persyaratan berikut:

• Protokol Keamanan Lapisan Transportasi (TLS): Karena X.509 bergantung pada sertifikat klien TLS, TLS harus diaktifkan untuk port dengan menggunakan autentikasi X.509.
• Algoritma kunci: Kunci EC dan RSA didukung, tetapi semua sertifikat dalam rantai harus menggunakan algoritma kunci yang sama.
• Format: Sertifikat CA harus dalam format Privacy-Enhanced Mail (PEM).

Petunjuk / Saran

Format PEM adalah format umum untuk sertifikat dan kunci. File PEM adalah file ASCII yang dikodekan Base64 dengan header seperti -----BEGIN CERTIFICATE----- dan -----BEGIN EC PRIVATE KEY-----.

Jika Anda memiliki sertifikat dalam format lain, Anda dapat mengonversinya ke PEM dengan menggunakan OpenSSL. Untuk informasi selengkapnya, lihat Mengonversi sertifikat ke dalam format yang sesuai.

Mendapatkan sertifikat CA tepercaya

Dalam penyiapan produksi, sertifikat CA disediakan oleh infrastruktur kunci publik (PKI) organisasi atau otoritas sertifikat publik.

Untuk pengujian, buat sertifikat CA yang ditandatangani sendiri dengan OpenSSL. Misalnya, jalankan perintah berikut untuk menghasilkan sertifikat CA yang ditandatangani sendiri dengan kunci RSA, nama CN=Contoso Root CA Certkhusus , dan validitas 365 hari:

openssl req -x509 -newkey rsa:4096 -keyout ca-key.pem -out ca.pem -days 365 -nodes -subj "/CN=Contoso Root CA Cert"

Perintah yang sama dengan Langkah CLI, yang merupakan alat yang nyaman untuk mengelola sertifikat, adalah:

step certificate create "Contoso Root CA Cert" ca.pem ca-key.pem --profile root-ca --kty RSA --size 4096 --no-password --insecure
 --not-after 8760h

Perintah ini membuat sertifikat CA, ca.pem, dan kunci privat, ca-key.pem, dalam format PEM. Anda dapat mengimpor sertifikat ca.pem CA ke broker MQTT untuk autentikasi X.509.

Mengimpor sertifikat CA tepercaya

Untuk mulai menggunakan autentikasi X.509, impor sertifikat CA tepercaya ke dalam ConfigMap di namespace azure-iot-operations. Untuk mengimpor sertifikat ca.pem CA tepercaya ke dalam ConfigMap bernama client-ca, jalankan:

kubectl create configmap client-ca --from-file=ca.pem -n azure-iot-operations

Dalam contoh ini, sertifikat CA diimpor di bawah kunci ca.pem. Broker MQTT mempercayai semua sertifikat CA di ConfigMap, sehingga Anda dapat menggunakan apa pun untuk nama kunci.

Untuk memeriksa apakah sertifikat CA akar diimpor dengan benar, jalankan kubectl describe configmap. Hasilnya menunjukkan pengodean Base64 yang sama dari file sertifikat PEM.

kubectl describe configmap client-ca -n azure-iot-operations

Name:         client-ca
Namespace:    azure-iot-operations

Data
====
ca.pem:
----
-----BEGIN CERTIFICATE-----
MIIFDjCCAvagAwIBAgIRAKQWo1+S13GTwqZSUYLPemswDQYJKoZIhvcNAQELBQAw
...
-----END CERTIFICATE-----


BinaryData
====

Mengonfigurasi metode autentikasi X.509

Setelah sertifikat CA tepercaya diimpor, aktifkan autentikasi klien X.509 dengan menambahkannya sebagai metode autentikasi dalam sumber daya BrokerAuthentication. Pastikan bahwa sumber daya ini ditautkan ke port pendengar yang mendukung TLS.

Portal

1. Di portal Azure, buka instans Operasi IoT Anda.

2. Di bawah Komponen, pilih MQTT Broker.

3. Pilih tab Autentikasi .

4. Pilih kebijakan autentikasi yang sudah ada atau buat yang baru.

5. Tambahkan metode baru dengan memilih Tambahkan metode.

6. Pilih jenis metode X.509 dari daftar dropdown. Lalu pilih Tambahkan detail untuk mengonfigurasi metode .

7. Pada panel detail autentikasi X.509 , tentukan nama ConfigMap sertifikat CA tepercaya dengan menggunakan format JSON.

   {
       "trustedClientCaCert": "<TRUSTED_CA_CONFIGMAP>"
   }
   

   Ganti <TRUSTED_CA_CONFIGMAP> dengan nama ConfigMap yang berisi sertifikat CA tepercaya. Misalnya, gunakan "trustedClientCaCert": "client-ca".

   

8. Secara opsional, tambahkan atribut otorisasi untuk klien dengan menggunakan sertifikat X.509. Untuk mempelajari selengkapnya, lihat Atribut sertifikat untuk otorisasi.

9. Pilih Terapkan untuk menyimpan perubahan.

Azure CLI

Gunakan perintah az iot ops broker authn apply untuk membuat atau mengubah kebijakan autentikasi broker MQTT.

az iot ops broker authn apply --resource-group <ResourceGroupName> --instance <AioInstanceName> --broker <BrokerName> --name <AuthenticationResourceName> --config-file <ConfigFilePathAndName>

Parameter --config-file adalah jalur dan nama file file konfigurasi JSON yang berisi properti sumber daya.

Dalam contoh ini, asumsikan file konfigurasi bernama my-authn-policy.json dengan metode X.509 disimpan di direktori beranda pengguna:

{
    "authenticationMethods": [
      {
        "method": "X509",
        "x509Settings": {
          "trustedClientCaCert": "client-ca"
        }
      }
    ]
}

Contoh perintah untuk membuat kebijakan autentikasi baru bernama my-policy dengan metode X.509 adalah sebagai berikut:

az iot ops broker authn apply --resource-group myResourceGroupName --instance myAioInstanceName --broker default --name my-policy --config-file ~/my-authn-policy.json

Bisep

param aioInstanceName string = '<AIO_INSTANCE_NAME>'
param customLocationName string = '<CUSTOM_LOCATION_NAME>'
param policyName string = '<POLICY_NAME>'
param trustedCaConfigMap string = '<TRUSTED_CA_CONFIGMAP>'

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 myBrokerAuthentication 'Microsoft.IoTOperations/instances/brokers/authentications@2024-11-01' = {
  parent: defaultBroker
  name: policyName
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }
  properties: {
    authenticationMethods: [
      {
        method: 'X509'
        x509Settings: {
          trustedClientCaCert: trustedCaConfigMap
          // authorizationAttributes: {
            //// Optional authorization attributes
            //// See the next section for more information
          // }
        }
      }
    ]
  }
}

Ganti <TRUSTED_CA_CONFIGMAP> dengan nama ConfigMap yang berisi sertifikat CA tepercaya. Misalnya, gunakan client-ca.

Sebarkan file Bicep dengan menggunakan Azure CLI:

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

Kubernetes (versi pratinjau)

spec:
  authenticationMethods:
    - method: X509
      x509Settings:
        trustedClientCaCert: <TRUSTED_CA_CONFIGMAP>
        # authorizationAttributes:
          ## Optional authorization attributes
          ## See the next section for more information

Ganti <TRUSTED_CA_CONFIGMAP> dengan nama ConfigMap yang berisi sertifikat CA tepercaya. Misalnya, gunakan client-ca.

Opsional: Atribut sertifikat untuk otorisasi

Anda dapat menentukan atribut X.509 di sumber daya BrokerAuthentication untuk mengotorisasi klien berdasarkan properti sertifikat mereka. Atribut didefinisikan di authorizationAttributes bidang .

Contohnya:

Portal

Di portal Microsoft Azure, saat Anda mengonfigurasi metode autentikasi X.509, tambahkan atribut otorisasi di panel detail autentikasi X.509 dalam format JSON.

{
  "trustedClientCaCert": "<TRUSTED_CA_CONFIGMAP>",
  "authorizationAttributes": {
    "root": {
      "subject": "CN = Contoso Root CA Cert, OU = Engineering, C = US",
      "attributes": {
        "organization": "contoso"
      }
    },
    "intermediate": {
      "subject": "CN = Contoso Intermediate CA",
      "attributes": {
        "city": "seattle",
        "foo": "bar"
      }
    },
    "smartfan": {
      "subject": "CN = smart-fan",
      "attributes": {
        "building": "17"
      }
    }
  }
}

Azure CLI

Gunakan perintah az iot ops broker authn apply untuk membuat atau mengubah kebijakan autentikasi broker MQTT.

az iot ops broker authn apply --resource-group <ResourceGroupName> --instance <AioInstanceName> --broker <BrokerName> --name <AuthenticationResourceName> --config-file <ConfigFilePathAndName>

Parameter --config-file adalah jalur dan nama file file konfigurasi JSON yang berisi properti sumber daya.

Dalam contoh ini, asumsikan file konfigurasi bernama my-authn-policy.json dengan metode X.509 dan properti sertifikat disimpan di direktori beranda pengguna

{
  "authenticationMethods": [
    {
      "method": "X509",
      "x509Settings": {
        "authorizationAttributes": {
          "intermediate": {
            "attributes": {
              "city": "seattle",
              "foo": "bar"
            },
            "subject": "CN = Contoso Intermediate CA"
          },
          "root": {
            "attributes": {
              "organization": "contoso"
            },
            "subject": "CN = Contoso Root CA Cert, OU = Engineering, C = US"
          },
          "smartfan": {
            "attributes": {
              "building": "17"
            },
            "subject": "CN = smart-fan"
          }
        },
        "trustedClientCaCert": "client-ca"
      }
    }
  ]
}

Contoh perintah untuk membuat kebijakan autentikasi baru bernama my-policy adalah sebagai berikut:

az iot ops broker authn apply --resource-group myResourceGroupName --instance myAioInstanceName --broker default --name my-policy --config-file ~/my-authn-policy.json

Bisep

x509Settings: {
  trustedClientCaCert: '<TRUSTED_CA_CONFIGMAP>'
  authorizationAttributes: {
    root: {
      subject: 'CN = Contoso Root CA Cert, OU = Engineering, C = US'
      attributes: {
        organization: 'contoso'
      }
    }
    intermediate: {
      subject: 'CN = Contoso Intermediate CA'
      attributes: {
        city: 'seattle'
        foo: 'bar'
      }
    }
    smartfan: {
      subject: 'CN = smart-fan'
      attributes: {
        building: '17'
      }
    }
  }
}

Kubernetes (versi pratinjau)

x509Settings:
  trustedClientCaCert: <TRUSTED_CA_CONFIGMAP>
  authorizationAttributes:
    root:
      subject = "CN = Contoso Root CA Cert, OU = Engineering, C = US"
      attributes:
        organization = contoso
    intermediate:
      subject = "CN = Contoso Intermediate CA"
      attributes:
        city = seattle
        foo = bar
    smart-fan:
      subject = "CN = smart-fan"
      attributes:
        building = 17

Dalam contoh ini, setiap klien yang memiliki sertifikat yang dikeluarkan oleh CA akar dengan nama CN = Contoso Root CA Cert, OU = Engineering, C = US khusus atau CA perantara dengan nama CN = Contoso Intermediate CA khusus menerima atribut yang tercantum. Selain itu, sertifikat klien smart-fan menerima atribut khusus untuk itu.

Pencocokan untuk atribut selalu dimulai dari sertifikat klien daun dan kemudian mengikuti rantai. Penetapan atribut berhenti setelah kecocokan pertama. Dalam contoh sebelumnya, bahkan jika smart-fan memiliki sertifikat CN = Contoso Intermediate CAperantara , sertifikat tersebut tidak mendapatkan atribut terkait.

Anda dapat menerapkan aturan otorisasi ke klien dengan menggunakan sertifikat X.509 dengan atribut ini. Untuk mempelajari selengkapnya, lihat Mengotorisasi klien yang menggunakan autentikasi X.509.

Opsional: Integrasi Azure Device Registry untuk autentikasi X.509 (pratinjau)

Penting

Integrasi Azure Device Registry untuk autentikasi X.509 saat ini dalam pratinjau. Fitur ini tunduk pada batasan tertentu dan tidak disarankan untuk beban kerja produksi. Untuk informasi lebih lanjut, lihat Supplemental Terms of Use for Microsoft Azure Previews.

Anda dapat mengaktifkan integrasi Azure Device Registry dengan autentikasi X.509 untuk memberlakukan validasi dan pencabutan sertifikat tingkat perangkat. Saat diaktifkan, fitur ini mengharuskan klien X.509 memiliki perangkat yang cocok di registri perangkat dan memungkinkan Anda menonaktifkan klien dengan menonaktifkan perangkat yang sesuai.

Dengan integrasi Azure Device Registry diaktifkan:

• Sertifikat klien harus memiliki Nama Umum (CN) yang cocok dengan nama perangkat di Azure Device Registry.
• Hanya perangkat yang diaktifkan dalam registri yang berhasil diautentikasi.
• Status perangkat diperiksa pada autentikasi klien dan setiap 10 menit setelahnya.
• Perangkat yang dinonaktifkan atau dihapus secara otomatis ditolak aksesnya.

Sebelum Anda mengaktifkan fitur ini, buat perangkat yang sesuai di Azure Device Registry untuk setiap sertifikat klien. Nama perangkat harus cocok dengan Nama Umum (CN) sertifikat. Untuk membuat dan mengelola perangkat di Azure Device Registry, lihat:

• Gunakan pengalaman operasi untuk mengelola sumber daya seperti aset, perangkat, dan aliran data
• Memahami aset dan perangkat

Untuk mengaktifkan integrasi Azure Device Registry, atur bidang ke additionalValidationAzureDeviceRegistry di pengaturan X.509 Anda. Bidang additionalValidation melakukan validasi tambahan sertifikat klien menggunakan metode yang ditentukan, dengan nilai AzureDeviceRegistry atau None (default) yang didukung:

Portal

Di portal Microsoft Azure, saat Anda mengonfigurasi metode autentikasi X.509, tambahkan validasi Azure Device Registry di panel detail autentikasi X.509 dalam format JSON:

{
  "trustedClientCaCert": "<TRUSTED_CA_CONFIGMAP>",
  "additionalValidation": "AzureDeviceRegistry"
}

Azure CLI

Gunakan perintah authn apply az iot ops broker untuk membuat atau mengubah kebijakan autentikasi broker MQTT dengan validasi Azure Device Registry.

Contoh file konfigurasi dengan integrasi Azure Device Registry:

{
  "authenticationMethods": [
    {
      "method": "X509",
      "x509Settings": {
        "trustedClientCaCert": "<TRUSTED_CA_CONFIGMAP>",
        "additionalValidation": "AzureDeviceRegistry"
      }
    }
  ]
}

Bisep

x509Settings: {
  trustedClientCaCert: '<TRUSTED_CA_CONFIGMAP>'
  additionalValidation: 'AzureDeviceRegistry'
  // authorizationAttributes: {
    //// Optional authorization attributes can still be used
  // }
}

Kubernetes (versi pratinjau)

apiVersion: mqttbroker.iotoperations.azure.com/v1beta1
kind: BrokerAuthentication
metadata:
  name: aio-broker-authn
  namespace: azure-iot-operations
spec:
  authenticationMethods:
  - method: X509
    x509Settings:
      trustedClientCaCert: <TRUSTED_CA_CONFIGMAP>
      additionalValidation: AzureDeviceRegistry

Nota

Perhatikan bahwa versi v1beta1 API diperlukan saat menggunakan additionalValidation bidang .

Setelah Anda mengaktifkan integrasi Azure Device Registry, buat perangkat yang sesuai di Azure Device Registry untuk setiap sertifikat klien. Nama perangkat harus cocok dengan Nama Umum (CN) sertifikat. Jika klien mencoba mengautentikasi dengan sertifikat yang tidak memiliki perangkat yang diaktifkan pencocokan di registri, autentikasi gagal.

Mengaktifkan autentikasi X.509 untuk port pendengar

Setelah Anda mengimpor sertifikat CA tepercaya dan mengonfigurasi sumber daya BrokerAuthentication, tautkan ke port pendengar yang mendukung TLS. Langkah ini penting karena autentikasi X.509 bergantung pada TLS untuk validasi sertifikat klien.

Untuk mendapatkan port listener yang didukung TLS, lihat Mengaktifkan manajemen sertifikat manual TLS untuk port dan Mengaktifkan manajemen sertifikat otomatis TLS untuk port.

Nota

Mengaktifkan TLS pada port pendengar broker berarti bahwa broker menggunakan sertifikat server untuk enkripsi TLS. Ketika klien terhubung ke port ini, mereka harus mempercayai sertifikat server dengan memiliki sertifikat CA yang menandatanganinya di penyimpanan kepercayaan mereka. Proses ini dikenal sebagai distribusi kepercayaan atau bundel kepercayaan. Penting untuk memahami perbedaan antara validasi klien dan validasi server:

• Validasi klien: Broker MQTT (server) memeriksa sertifikat klien terhadap sertifikat CA tepercaya yang ditentukan di trustedClientCaCert bidang untuk autentikasi klien X.509.
• Validasi server: Klien (seperti Mosquitto atau MQTTX) memeriksa sertifikat server broker MQTT terhadap sertifikat CA tepercaya di penyimpanan sertifikat tepercaya mereka. Untuk klien Mosquitto, gunakan --cafile parameter untuk menentukan file sertifikat CA. Untuk MQTTX, tambahkan sertifikat CA ke penyimpanan kepercayaan di pengaturan.

Setelah Anda mengaktifkan autentikasi X.509, pastikan bahwa klien mempercayai sertifikat server broker dengan memiliki sertifikat CA sisi server di penyimpanan kepercayaan mereka. Jangan salah mengira sertifikat CA sisi server dengan sertifikat CA sisi klien yang digunakan untuk autentikasi klien yang ditentukan di bidang trustedClientCaCert.

Untuk contoh lengkapnya, lihat Tutorial: TLS, autentikasi klien X.509, dan otorisasi kontrol akses berbasis atribut (ABAC).

Sambungkan klien Mosquitto ke broker MQTT dengan sertifikat klien X.509

Klien seperti Mosquitto membutuhkan dua file untuk dapat terhubung ke broker MQTT dengan Autentikasi klien TLS dan X.509:

• Parameter --cert menentukan file PEM sertifikat klien. File ini juga harus menyertakan sertifikat perantara apa pun untuk membantu broker MQTT membangun rantai sertifikat lengkap.
• Parameter --key menentukan file PEM kunci privat klien.

Dalam kasus di mana broker MQTT menggunakan sertifikat CA yang ditandatangani sendiri untuk mengeluarkan sertifikat server TLS-nya, --cafile parameter diperlukan. File ini berisi sertifikat CA (juga dikenal sebagai bundel kepercayaan), yang digunakan klien Mosquitto untuk memvalidasi sertifikat server broker ketika terhubung melalui TLS. Jika penerbit sertifikat server broker MQTT adalah bagian dari penyimpanan root sistem (seperti CA publik terkenal), parameter --cafile dapat dihilangkan.

Contohnya:

mosquitto_pub -q 1 -t hello -d -V mqttv5 -m world -i thermostat \
-h "<BROKER_HOST>" \
--cert thermostat_cert.pem \
--key thermostat_key.pem \
--cafile ca.pem

Memahami alur autentikasi klien broker MQTT X.509

Ikuti langkah-langkah berikut untuk autentikasi klien:

1. Ketika autentikasi klien X.509 diaktifkan, menghubungkan klien harus menunjukkan sertifikat klien dan sertifikat perantara apa pun untuk memungkinkan broker MQTT membangun rantai sertifikat yang berakar ke salah satu sertifikat tepercaya yang dikonfigurasi.
2. Load balancer mengarahkan komunikasi ke salah satu broker frontend.
3. Setelah broker frontend menerima sertifikat klien, broker tersebut mencoba membangun rantai sertifikat yang berakar ke salah satu sertifikat yang dikonfigurasi. Jika broker frontend berhasil membangun rantai dan rantai yang disajikan diverifikasi, ia menyelesaikan jabat tangan TLS. Klien yang terhubung dapat mengirim paket MQTT ke frontend melalui saluran TLS.
4. Saluran TLS terbuka, tetapi autentikasi atau otorisasi klien belum selesai.
5. Klien kemudian mengirim paket CONNECT ke broker MQTT.
6. Paket CONNECT dirutekan lagi ke bagian frontend.
7. Frontend mengumpulkan semua kredensial yang disajikan klien sejauh ini, seperti data autentikasi dari paket CONNECT, dan rantai sertifikat klien yang disajikan selama jabat tangan TLS.
8. Frontend mengirimkan kredensial ini ke layanan autentikasi. Layanan autentikasi memeriksa rantai sertifikat sekali lagi dan mengumpulkan nama subjek semua sertifikat dalam rantai.
9. Layanan autentikasi menggunakan aturan otorisasi yang dikonfigurasi untuk menentukan atribut apa yang dimiliki klien yang terhubung. Atribut ini menentukan operasi apa yang dapat dijalankan klien, termasuk paket CONNECT itu sendiri.
10. Layanan autentikasi mengembalikan keputusan ke broker frontend.
11. Broker frontend mengetahui atribut klien dan apakah diizinkan untuk terhubung. Jika demikian, maka koneksi MQTT selesai dan klien dapat terus mengirim dan menerima paket MQTT seperti yang ditentukan oleh aturan otorisasinya.

Token akun layanan Kubernetes

SATs Kubernetes adalah token web JSON yang terkait dengan akun layanan Kubernetes. Klien menyajikan SATs kepada broker MQTT untuk mengautentikasi diri mereka sendiri.

Broker MQTT menggunakan token akun layanan terikat yang dijelaskan dalam postingan Yang Perlu Diketahui Pengguna GKE Tentang Token Akun Layanan Baru Kubernetes. Berikut adalah fitur utama dari posting:

Token terikat yang diluncurkan di Kubernetes 1.13 dan menjadi format default dalam 1.21. Token terikat membahas semua fungsionalitas terbatas token warisan, dan banyak lagi:

• Token sulit dicuri dan disalahgunakan. Mereka terikat waktu, terikat audiens, dan terikat objek.
• Mereka mengadopsi format standar. OpenID Connect (OIDC), dengan fitur OIDC Discovery lengkap, memudahkan penyedia layanan untuk menerima penggunaan OpenID Connect.
• Mereka didistribusikan ke pod dengan lebih aman dengan menggunakan jenis proyeksi volume Kubelet yang baru.

Broker memverifikasi token dengan menggunakan API Ulasan Token Kubernetes. Aktifkan fitur Kubernetes TokenRequestProjection untuk menentukan audiences (default sejak 1.21). Jika fitur ini tidak diaktifkan, Anda tidak dapat menggunakan SAT.

Membuat akun layanan

Untuk membuat SAT, pertama-tama buat akun layanan. Perintah berikut membuat akun layanan yang disebut mqtt-client:

kubectl create serviceaccount mqtt-client -n azure-iot-operations

Opsional: Menambahkan atribut untuk otorisasi

Klien yang mengautentikasi melalui SAT dapat secara opsional membuat akun layanan mereka dianotasi dengan atribut yang akan digunakan dengan kebijakan otorisasi. Untuk membedakan anotasi-anotasi ini dari yang lain, anotasi-anotasi ini dimulai dengan awalan aio-broker-auth/.

Anda dapat membuat anotasi akun layanan dengan menggunakan kubectl annotate:

kubectl annotate serviceaccount <SERVICE_ACCOUNT_NAME> aio-broker-auth/<ATTRIBUTE>=<VALUE> -n azure-iot-operations

Atau Anda dapat menambahkan anotasi ke file manifes akun layanan:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: <SERVICE_ACCOUNT_NAME>
  namespace: azure-iot-operations
  annotations:
    aio-broker-auth/<ATTRIBUTE_1>: <VALUE_1>
    aio-broker-auth/<ATTRIBUTE_2>: <VALUE_2>

Untuk mempelajari lebih lanjut, lihat Mengotorisasi klien yang menggunakan token akun layanan Kubernetes.

Mengaktifkan autentikasi SAT

authenticationMethods Ubah pengaturan dalam sumber daya BrokerAuthentication untuk menentukan ServiceAccountToken sebagai metode autentikasi yang valid. Parameter audiences menentukan daftar audiens yang valid untuk token. Pilih nilai unik yang mengidentifikasi layanan broker MQTT. Anda harus menentukan setidaknya satu audiens, dan semua SAT harus cocok dengan salah satu audiens yang ditentukan.

Portal

1. Di portal Azure, buka instans Operasi IoT Anda.
2. Di bawah Komponen, pilih MQTT Broker.
3. Pilih tab Autentikasi .
4. Pilih kebijakan autentikasi yang sudah ada atau buat yang baru.
5. Tambahkan metode baru dengan memilih Tambahkan metode.
6. Pilih jenis metode Kubernetes SAT dari daftar dropdown. Lalu pilih Tambahkan detail untuk mengonfigurasi metode .

Azure CLI

Gunakan perintah az iot ops broker authn apply untuk membuat atau mengubah kebijakan autentikasi broker MQTT.

az iot ops broker authn apply --resource-group <ResourceGroupName> --instance <AioInstanceName> --broker <BrokerName> --name <AuthenticationResourceName> --config-file <ConfigFilePathAndName>

Parameter --config-file adalah jalur dan nama file file konfigurasi JSON yang berisi properti sumber daya.

Dalam contoh ini, asumsikan file konfigurasi bernama my-authn-policy.json dengan metode Kubernetes SAT disimpan di direktori beranda pengguna:

{
  "authenticationMethods": [
    {
      "method": "ServiceAccountToken",
      "serviceAccountTokenSettings": {
        "audiences": [
          "my-audience"
        ]
      }
    }
  ]
}

Contoh perintah untuk membuat kebijakan autentikasi baru bernama my-policy dengan metode Kubernetes SAT adalah sebagai berikut:

az iot ops broker authn apply --resource-group myResourceGroupName --instance myAioInstanceName --broker default --name my-policy --config-file ~/my-authn-policy.json

Bisep

param aioInstanceName string = '<AIO_INSTANCE_NAME>'
param customLocationName string = '<CUSTOM_LOCATION_NAME>'
param policyName string = '<POLICY_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 myBrokerAuthentication 'Microsoft.IoTOperations/instances/brokers/authentications@2024-11-01' = {
  parent: defaultBroker
  name: policyName
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }
  properties: {
    authenticationMethods: [
      {
        method: 'ServiceAccountToken'
        serviceAccountTokenSettings: {
          audiences: [
            'aio-internal'
            'my-audience'
          ]
        }
      }
    ]
  }
}

Sebarkan file Bicep dengan menggunakan Azure CLI:

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

Kubernetes (versi pratinjau)

spec:
  authenticationMethods:
    - method: ServiceAccountToken
      serviceAccountTokenSettings:
        audiences:
        - aio-internal
        - my-audience

Terapkan perubahan Anda dengan kubectl apply. Mungkin perlu waktu beberapa menit agar perubahan diterapkan.

Menguji autentikasi SAT

Autentikasi SAT menggunakan bidang autentikasi MQTT v5 yang ditingkatkan. Klien harus mengatur metode autentikasi yang ditingkatkan ke K8S-SAT dan data autentikasi yang ditingkatkan ke token.

Misalnya, gunakan Mosquitto (beberapa bidang dihilangkan untuk keringkasan):

mosquitto_pub ... -D CONNECT authentication-method 'K8S-SAT' -D CONNECT authentication-data <TOKEN>

Di sini, <TOKEN> adalah token akun layanan. Untuk mendapatkan token pengujian, jalankan:

kubectl create token <SERVICE_ACCOUNT> -n azure-iot-operations --audience <AUDIENCE>

Di sini, <SERVICE_ACCOUNT> adalah nama akun layanan yang Anda buat, dan <AUDIENCE> merupakan salah satu audiens yang dikonfigurasi dalam sumber daya BrokerAuthentication.

Untuk contoh tentang cara mengonfigurasi pod Kubernetes untuk menggunakan autentikasi SAT, lihat Menyambungkan ke pendengar default di dalam kluster.

Dalam konfigurasi pod, serviceAccountName bidang harus cocok dengan akun layanan yang terkait dengan token yang digunakan. Bidang serviceAccountToken.audience harus menjadi salah satu yang dikonfigurasi dalam entitas BrokerAuthentication audiences.

Segarkan token akun layanan

Token akun layanan berlaku untuk waktu terbatas dan dikonfigurasi dengan expirationSeconds. Namun, Kubernetes secara otomatis me-refresh token sebelum kedaluwarsa. Token disegarkan di latar belakang, dan klien tidak perlu melakukan apa pun selain mengambilnya lagi.

Misalnya, jika klien adalah pod yang menggunakan token yang dipasang sebagai volume, seperti dalam contoh pengujian autentikasi SAT, token terbaru tersedia di jalur yang sama /var/run/secrets/tokens/broker-sat. Ketika klien membuat koneksi baru, klien dapat mengambil token terbaru dan menggunakannya untuk mengautentikasi. Klien juga harus memiliki mekanisme untuk menangani kesalahan MQTT yang tidak sah dengan mengambil token terbaru dan mencoba kembali koneksi.

Autentikasi kustom

Perluas autentikasi klien di luar metode autentikasi yang disediakan dengan autentikasi kustom. Ini dapat dicolokkan karena layanan bisa apa saja selama mematuhi API.

Ketika klien terhubung ke broker MQTT dengan autentikasi kustom diaktifkan, broker mengirim permintaan HTTPS ke server autentikasi kustom dengan kredensial klien. Server kemudian merespons dengan persetujuan atau penolakan, termasuk atribut otorisasi klien.

Membuat layanan autentikasi kustom

Server autentikasi kustom diimplementasikan dan disebarkan secara terpisah dari broker MQTT.

Contoh server autentikasi kustom dan instruksi tersedia di GitHub. Gunakan sampel ini sebagai templat dan titik awal untuk menerapkan logika autentikasi kustom Anda sendiri.

API

API antara broker MQTT dan server autentikasi kustom mengikuti spesifikasi API untuk autentikasi kustom. Spesifikasi OpenAPI tersedia di GitHub.

HTTPS dengan enkripsi TLS diperlukan

Broker MQTT mengirimkan permintaan yang berisi kredensial klien sensitif ke server autentikasi kustom. Untuk melindungi kredensial ini, komunikasi antara broker MQTT dan server autentikasi kustom harus dienkripsi dengan TLS.

Server autentikasi kustom harus menunjukkan sertifikat server, dan broker MQTT harus memiliki sertifikat OS akar tepercaya untuk memvalidasi sertifikat server. Secara opsional, server autentikasi kustom mungkin mengharuskan broker MQTT untuk menyajikan sertifikat klien untuk mengautentikasi dirinya sendiri.

Mengaktifkan autentikasi kustom untuk pendengar

Ubah pengaturan metode Autentikasi di sumber daya BrokerAuthentication untuk menentukan Kustom sebagai metode autentikasi yang valid. Kemudian, tentukan parameter yang diperlukan untuk berkomunikasi dengan server autentikasi kustom.

Portal

1. Di portal Azure, buka instans Operasi IoT Anda.

2. Di bawah Komponen, pilih MQTT Broker.

3. Pilih tab Autentikasi .

4. Pilih kebijakan autentikasi yang sudah ada atau buat yang baru.

5. Tambahkan metode baru dengan memilih Tambahkan metode.

6. Pilih jenis metode Kustom dari daftar dropdown. Lalu pilih Tambahkan detail untuk mengonfigurasi metode .

   

Azure CLI

Gunakan perintah az iot ops broker authn apply untuk membuat atau mengubah kebijakan autentikasi broker MQTT.

az iot ops broker authn apply --resource-group <ResourceGroupName> --instance <AioInstanceName> --broker <BrokerName> --name <AuthenticationResourceName> --config-file <ConfigFilePathAndName>

Parameter --config-file adalah jalur dan nama file file konfigurasi JSON yang berisi properti sumber daya.

Dalam contoh ini, asumsikan file konfigurasi bernama my-authn-policy.json dengan metode kustom disimpan di direktori beranda pengguna:

{
  "authenticationMethods": [
    {
      "method": "Custom",
      "customSettings": {
        "auth": {
          "x509": {
            "secretRef": "custom-auth-client-cert"
          }
        },
        "caCertConfigMap": "custom-auth-ca",
        "endpoint": "https://auth-server-template",
        "headers": {
          "header_key": "header_value"
        }
      }
    },
    {
      "method": "ServiceAccountToken",
      "serviceAccountTokenSettings": {
        "audiences": [
          "my-audience"
        ]
      }
    }
  ]
}

Contoh perintah untuk membuat kebijakan autentikasi baru bernama my-policy dengan metode Kubernetes SAT adalah sebagai berikut:

az iot ops broker authn apply --resource-group myResourceGroupName --instance myAioInstanceName --broker default --name my-policy --config-file ~/my-authn-policy.json

Bisep

param aioInstanceName string = '<AIO_INSTANCE_NAME>'
param customLocationName string = '<CUSTOM_LOCATION_NAME>'
param policyName string = '<POLICY_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 myBrokerAuthentication 'Microsoft.IoTOperations/instances/brokers/authentications@2024-11-01' = {
  parent: defaultBroker
  name: policyName
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }
  properties: {
    authenticationMethods: [
      {
        method: 'Custom'
        serviceAccountTokenSettings: {
          audiences: [
            'aio-internal'
            'my-audience'
          ]
        }
      }
    ]
  }
}

Sebarkan file Bicep dengan menggunakan Azure CLI:

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

Kubernetes (versi pratinjau)

Contoh ini menunjukkan semua parameter yang mungkin. Parameter yang tepat yang diperlukan bergantung pada persyaratan setiap server kustom.

spec:
  authenticationMethods:
    - method: Custom
      customSettings:
        # Endpoint for custom authentication requests. Required.
        endpoint: https://auth-server-template
        # Optional CA certificate for validating the custom authentication server's certificate.
        caCertConfigMap: custom-auth-ca
        # Authentication between MQTT broker with the custom authentication server.
        # The broker may present X.509 credentials or no credentials to the server.
        auth:
          x509:
            secretRef: custom-auth-client-cert
            namespace: azure-iot-operations
        # Optional additional HTTP headers that the broker will send to the
        # custom authentication server.
        headers:
          header_key: header_value

Menggunakan autentikasi kustom untuk autentikasi nama pengguna dan kata sandi

Anda dapat menggunakan autentikasi kustom untuk menerapkan autentikasi nama pengguna dan kata sandi. Sampel server autentikasi kustom tersedia untuk pengujian. Lihat sampel autentikasi kata sandi dan nama pengguna Azure IoT Operations MQTT di GitHub.

Menonaktifkan autentikasi

Untuk pengujian, Anda dapat menonaktifkan autentikasi untuk port penerima broker. Kami tidak menyarankan Agar Anda menonaktifkan autentikasi untuk lingkungan produksi.

Portal

1. Di portal Azure, buka instans Operasi IoT Anda.
2. Di bawah Komponen, pilih MQTT Broker.
3. Pilih pendengar broker yang ingin Anda edit dari daftar.
4. Pada port tempat Anda ingin menonaktifkan autentikasi, pilih Tidak Ada di menu dropdown autentikasi.

Azure CLI

Gunakan perintah az iot ops broker listener port add untuk menonaktifkan autentikasi untuk port. Untuk menonaktifkan autentikasi, jangan sertakan --authn-ref parameter .

az iot ops broker listener port add --resource-group <ResourceGroupName> --instance <AioInstanceName> --broker default --listener <ListenerName> --port <ListenerServicePort>

Contoh berikut menonaktifkan autentikasi untuk port 8884 ke pendengar bernama aio-broker-loadbalancer:

az iot ops broker listener port add --resource-group myResourceGroupName --instance myAioInstanceName --broker default --listener aio-broker-loadbalancer --port 8884

Bisep

Untuk menonaktifkan autentikasi, hilangkan authenticationRefports dalam pengaturan sumber daya BrokerListener Anda.

Kubernetes (versi pratinjau)

Untuk menonaktifkan autentikasi, hilangkan authenticationRefports dalam pengaturan sumber daya BrokerListener Anda.

Klien memutuskan sambungan setelah kredensial kedaluwarsa

Broker MQTT memutuskan koneksi klien ketika kredensial mereka kedaluwarsa. Pemutusan sambungan setelah kredensial kedaluwarsa berlaku untuk semua klien yang terhubung ke antarmuka depan broker MQTT, seperti:

• Klien yang diautentikasi dengan SAT terputus saat SAT mereka kedaluwarsa.
• Klien yang diautentikasi dengan X.509 terputus saat sertifikat klien mereka kedaluwarsa.
• Klien yang diautentikasi dengan autentikasi kustom terputus sesuai waktu kedaluwarsa yang diterima dari server autentikasi kustom.

Saat sambungan terputus, koneksi jaringan klien ditutup. Klien tidak menerima paket MQTT DISCONNECT, tetapi broker mencatat pesan bahwa klien tersebut terputus.

Klien MQTT v5 yang diautentikasi dengan SAT dan autentikasi kustom dapat mengautentikasi ulang dengan kredensial baru sebelum kredensial awal mereka kedaluwarsa. Klien X.509 tidak dapat mengautentikasi ulang dan harus membangun kembali koneksi karena autentikasi dilakukan di lapisan TLS.

Klien dapat mengautentikasi ulang dengan mengirim paket AUTH MQTT v5 dengan alasan ReAuth.

Klien SAT mengirimkan AUTH client yang memiliki bidang method: K8S-SAT dan data: <token>. Klien autentikasi kustom mengatur metode dan bidang data sebagaimana diperlukan oleh server autentikasi kustom.

Autentikasi ulang yang berhasil memperbarui waktu kedaluwarsa kredensial klien dengan waktu kedaluwarsa dari kredensial barunya. Broker menanggapi dengan sebuah paket AUTH Success. Autentikasi yang gagal karena masalah sementara, seperti server autentikasi kustom yang tidak tersedia, menyebabkan broker merespons dengan ContinueAuthentication paket AUTH. Klien dapat mencoba lagi nanti. Kegagalan autentikasi lainnya menyebabkan broker mengirim paket DISCONNECT dan menutup koneksi jaringan klien.

Konten terkait

• Sumber daya BrokerListener
• Mengonfigurasi otorisasi untuk BrokerListener
• Tutorial: TLS, autentikasi klien X.509, dan otorisasi kontrol akses berbasis atribut (ABAC)