MQTT aracısı kimlik doğrulamasını yapılandırma

MQTT aracısı, istemciler için birden çok kimlik doğrulama yöntemini destekler. Bir BrokerAuthentication kaynağıyla her dinleyici bağlantı noktasını kendi kimlik doğrulama ayarlarına sahip olacak şekilde yapılandırabilirsiniz. Kullanılabilir ayarların listesi için bkz. Aracı Kimlik Doğrulaması API başvurusu.

Ortam değişkenlerinizi ayarlama

Bu makaledeki Azure CLI örnek, her değeri bir kez ayarlayabilmeniz ve ardından komutları kopyalayıp yapıştırmanız için ortam değişkenlerini kullanır as-is. Eğer hızlı başlangıçta Azure IoT İşlemleri Codespaces ortamını kullanıyorsanız, bu değişkenler zaten sizin için ayarlanmış ve bu adımı atlayabilirsiniz. Aksi takdirde, komutları çalıştırmadan önce shell'inizde aşağıdaki ortam değişkenlerini ayarlayın.

Aşağıdaki betikler en sık kullanılan ortam değişkenlerini ayarlar:

Ortam değişkeni	Description
SUBSCRIPTION_ID	Azure IoT İşlemleri örneğini içeren aboneliğin kimliği.
RESOURCE_GROUP	Azure IoT İşlemleri örneğini içeren kaynak grubunun adı.
AIO_INSTANCE_NAME	Azure IoT İşlemleri örneğinizin adı. Örneklerinizi listelemek için çalıştırın az iot ops list -o table.
CLUSTER_NAME	Azure Arc özellikli Kubernetes kümesinin adı, örneğini barındırıyor.
LOCATION	Yeni kaynaklar için kullanılacak Azure bölgesi, örneğin eastus.

Bash

SUBSCRIPTION_ID=<subscription-id>
RESOURCE_GROUP=<resource-group-name>
AIO_INSTANCE_NAME=<instance-name>
CLUSTER_NAME=<cluster-name>
LOCATION=<region>

PowerShell

$SUBSCRIPTION_ID = "<subscription-id>"
$RESOURCE_GROUP = "<resource-group-name>"
$AIO_INSTANCE_NAME = "<instance-name>"
$CLUSTER_NAME = "<cluster-name>"
$LOCATION = "<region>"

Sadece bu makalenin kullandığı değişkenleri ayarlamanız yeterlidir. Bu makale, seçtiğiniz kaynak adları için ek ortam değişkenleri kullanabilir. Makale, tanıtıldıkları yere nasıl yerleştirileceğini açıklıyor.

Bu makale ayrıca seçtiğiniz değerler için aşağıdaki ortam değişkenlerini kullanır: (genellikle BROKERMQTT aracısının adı), default (broker dinleyicinin adı), LISTENER (broker kimlik doğrulama kaynağının adı), AUTHN (dinleyici portu), LISTENER_PORT, BROKER_HOST, SERVICE_ACCOUNT_NAME, ATTRIBUTEATTRIBUTE_VALUE, , ve TOKEN. AUDIENCE İlgili komutları çalıştırmadan önce her birini ayarlayın.

BrokerListener ve BrokerAuthentication'ı bağlama

Aşağıdaki kurallar BrokerListener ile BrokerAuthentication kaynakları arasındaki ilişki için geçerlidir:

• Her BrokerListener kaynağının birden çok bağlantı noktası olabilir. Her bağlantı noktasını bir BrokerAuthentication kaynağına bağlayabilirsiniz.
• Her BrokerAuthentication kaynağı aynı anda birden çok kimlik doğrulama yöntemini destekleyebilir.
• BrokerAuthentication kaynağına bağlanmamış bağlantı noktalarının kimlik doğrulaması devre dışıdır.

BrokerListener bağlantı noktasını bir BrokerAuthentication kaynağına bağlamak için, BrokerListener kaynağının ayarında authenticationRef alanını belirtin ports. Daha fazla bilgi için bkz. BrokerListener kaynağı.

Varsayılan BrokerAuthentication kaynağı

Azure IoT İşlemleri, ad alanında default, varsayılan dinleyici ile bağlantılı azure-iot-operations adlı varsayılan BrokerAuthentication kaynağını dağıtır. Kimlik doğrulaması için yalnızca Kubernetes hizmet hesabı belirteçlerini (STS) kullanır.

Önemli

IoT İşlemlerindeki bileşenlerin düzgün çalışması için varsayılan BrokerAuthentication kaynağındaki SAT kimlik doğrulama yöntemi gereklidir. Varsayılan BrokerAuthentication kaynağını güncelleştirmekten veya silmekten kaçının.

Portal

1. Azure portalında varsayılan BrokerAuthentication kaynağını görmek için IoT Operasyonları örneğinize gidin.

2. Bileşenler'in altında MQTT Aracısı'ni seçin.

3. Kimlik Doğrulaması sekmesini seçin.

4. Kimlik doğrulama ilkesi listesinden varsayılan ilke adını seçin.

   

Azure CLI

Yerel MQTT aracısı varsayılan kimlik doğrulama ilkesini görüntülemek için az iot ops broker authn show komutunu kullanın.

az iot ops broker authn show --resource-group $RESOURCE_GROUP --instance $AIO_INSTANCE_NAME --broker default --name default 

Pazı

Varsayılan BrokerAuthentication kaynağını görmek için aşağıdaki içerikle bir Bicep .bicep dosyası oluşturun. Ayarları gerektiği gibi güncelleştirin. Yer tutucu değerleri, örneğin <AIO_INSTANCE_NAME>, kendi değerlerinizle değiştirin.

param aioInstanceName string = '<AIO_INSTANCE_NAME>'

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

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

resource defaultBrokerAuthentication 'Microsoft.IoTOperations/instances/brokers/authentications@2026-03-01' existing = {
  parent: defaultBroker
  name: 'default'
}

output defaultBrokerAuthenticationDetails object = {
  id: defaultBrokerAuthentication.id
  name: defaultBrokerAuthentication.name
  authenticationMethods: defaultBrokerAuthentication.properties.authenticationMethods
}

Azure CLI kullanarak Bicep dosyasını dağıtın:

az deployment group create --resource-group $RESOURCE_GROUP --template-file main.bicep --query properties.outputs.defaultBrokerAuthenticationDetails.value

Kubernetes (yalnızca hata ayıklama)

Önemli

Kubernetes dağıtım bildirimlerinin kullanımı üretim ortamlarında desteklenmez ve yalnızca hata ayıklama ve test için kullanılmalıdır.

Varsayılan aracı kimlik doğrulama kaynağını incelemek için şunu çalıştırın:

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

Çıktıda varsayılan BrokerAuthentication kaynağı gösterilir ve meta veriler kısa süre için kaldırılır:

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

Kimlik doğrulamayı özelleştirmek için, benzersiz bir isimle bir BrokerAuthentication kaynağı oluşturun ve bunu kendi BrokerListener'ınızla ilişkilendirin. Varsayılan BrokerAuthentication kaynağını değiştirmeyin.

Kimlik doğrulama akışı

Belirtilen kimlik doğrulama yöntemlerinin sırası, MQTT aracısının istemcilerin kimliğini nasıl doğruladığını belirler. MQTT aracısı, belirtilen ilk yöntemi kullanarak istemcinin kimlik bilgilerini doğrulamaya çalışır ve bir eşleşme bulana veya sona ulaşana kadar belirtilen yöntemler arasında yinelenir.

Her yöntem için, MQTT aracısı önce istemcinin kimlik bilgilerinin bu yöntemle ilgili olup olmadığını denetler. Örneğin, SAT kimlik doğrulaması için kullanıcı adı K8S-SATve X.509 kimlik doğrulaması için bir istemci sertifikası gerekir. İstemcinin kimlik bilgileri ilgiliyse, MQTT aracısı geçerli olup olmadığını doğrular. Daha fazla bilgi için Kimlik doğrulama yöntemini yapılandırma bölümüne bakın.

Özel kimlik doğrulaması için, MQTT aracısı özel kimlik doğrulama sunucusuyla iletişim kuramama durumunu kimlik bilgilerine güvenilemez olarak değerlendirir. Bu davranış, özel kimlik doğrulama sunucusuna ulaşılamıyorsa MQTT aracısının diğer yöntemlere geri dönmesini sağlar.

Kimlik doğrulama akışı şu durumlarda sona erer:

• Bu koşullardan biri doğrudur:
  • İstemcinin kimlik bilgileri, yöntemlerden biri için ilgili ve geçerlidir.
  • İstemcinin kimlik bilgileri hiçbir yöntemle ilgili değildir.
  • İstemcinin kimlik bilgileri ilgili ancak yöntemlerden herhangi biri için geçersiz.
• MQTT aracısı, kimlik doğrulama akışının sonucuna göre istemciye erişim verir veya erişimi reddeder.

Örneğin:

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

Önceki örnek custom ve SAT belirtir. bir istemci bağlandığında, MQTT aracısı belirtilen yöntemleri sırayla custom ve ardından SATkullanarak istemcinin kimliğini doğrulamayı dener.

1. MQTT aracısı, istemci kimlik bilgilerinin özel kimlik doğrulaması için geçerli olup olmadığını denetler. Özel kimlik doğrulaması, kimlik bilgilerinin geçerliliğini belirlemek için bir dış sunucuya dayandığından, aracı özel kimlik doğrulamasıyla ilgili tüm kimlik bilgilerini dikkate alır ve bunları özel kimlik doğrulama sunucusuna iletir.
2. Özel kimlik doğrulama sunucusu bir Pass veya Fail sonucuyla yanıt verirse, kimlik doğrulama akışı sona erer. Özel kimlik doğrulama sunucusu kullanılamıyorsa, MQTT aracısı kalan belirtilen yöntemlere geri döner; bu durumda bir sonraki adım SAT olacaktır.
3. MQTT aracısı kimlik bilgilerini SAT kimlik bilgileri olarak doğrulamayı dener.

Özel kimlik doğrulama sunucusu kullanılamıyorsa ve sonraki tüm yöntemler sağlanan kimlik bilgilerinin uygun olmadığını belirlerse, aracı istemci bağlantısını reddeder.

Kimlik doğrulama yöntemini yapılandırma

Kimlik doğrulama ilkelerine X.509, SAT veya özel gibi kimlik doğrulama yöntemleri ekleyebilirsiniz.

İlkeye kimlik doğrulama yöntemi eklemek için:

Portal

1. Azure portalında IoT İşlemleri örneğine gidin.

2. Bileşenler'in altında MQTT Aracısı'ni seçin.

3. Kimlik Doğrulaması sekmesini seçin.

4. Mevcut bir kimlik doğrulama ilkesini seçin veya yeni bir ilke oluşturun.

5. Yöntem ekle'yi seçerek yeni bir yöntem ekleyin.

6. Açılan listeden yöntem türünü seçin ve ardından Yöntemi yapılandırmak için Ayrıntı ekle'yi seçin.

   

Azure CLI

MQTT aracısı kimlik doğrulaması politikası oluşturmak veya değiştirmek için az iot ops broker authn apply komutunu kullanın.

az iot ops broker authn apply --resource-group $RESOURCE_GROUP --instance $AIO_INSTANCE_NAME --broker $BROKER --name $AUTHN --config-file config.json

--config-file parametresi, kaynak özelliklerini içeren bir JSON yapılandırma dosyasının yolu ve dosya adıdır.

Bu örnekte, kullanıcının giriş dizininde depolanan aşağıdaki içeriğe sahip adlı my-authn-policy.json bir yapılandırma dosyası varsayın:

{
    "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"
        }
      }
    ]
}

Aşağıdaki örnek adlı my-policyyeni bir kimlik doğrulama ilkesi oluşturur:

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

Pazı

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

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

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

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

resource myBrokerAuthentication 'Microsoft.IoTOperations/instances/brokers/authentications@2026-03-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'
            }
          }
        }
      }
    ]
  }
}

Azure CLI kullanarak Bicep dosyasını dağıtın:

az deployment group create --resource-group $RESOURCE_GROUP --template-file main.bicep

Kubernetes (yalnızca hata ayıklama)

Önemli

Kubernetes dağıtım bildirimlerinin kullanımı üretim ortamlarında desteklenmez ve yalnızca hata ayıklama ve test için kullanılmalıdır.

Kimlik doğrulama ilkesi için BrokerAuthentication kaynağını authenticationMethods bölümüne yeni metotlar ekleyerek değiştirin. Aşağıdaki örnekte, BrokerAuthentication kaynağı için birden çok kimlik doğrulama yöntemi gösterilmektedir:

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

Yapılandırmayı değiştirmek için bu BrokerAuthentication kaynağındaki ayarı değiştirin authenticationMethods . Ardından kubectl apply yardımıyla dağıtın.

Kimlik doğrulama seçeneklerinin her biri hakkında daha fazla bilgi edinmek için her yöntemin sonraki bölümlerine bakın.

Azure Key Vault örneğini yapılandırarak ve iş yükü kimliklerini etkinleştirerek güvenli ayarları etkinleştirme hakkında daha fazla bilgi için bkz. Azure IoT İşlemleri dağıtımında güvenli ayarları etkinleştirme.

X.509

İpucu

X.509 kimlik doğrulamasını yapılandırma hakkında uçtan uca bir örnek için bkz . Öğretici: TLS, X.509 istemci kimlik doğrulaması ve öznitelik tabanlı erişim denetimi (ABAC) yetkilendirmesi.

X.509 kimlik doğrulamasıyla, MQTT aracısı istemci sertifikalarını doğrulamak için güvenilir bir Sertifika Yetkilisi (CA) sertifikası kullanır. Bu güvenilen CA bir kök veya ara CA olabilir. Aracı, istemci sertifika zincirini güvenilen CA sertifikası ile karşılaştırır. Zincir geçerliyse istemcinin kimliği doğrulanır.

X.509 kimlik doğrulamasını güvenilen bir CA sertifikasıyla kullanmak için aşağıdaki gereksinimleri karşılamanız gerekir:

• Aktarım Katmanı Güvenliği (TLS) protokolü: X.509 TLS istemci sertifikalarını kullandığından, X.509 kimlik doğrulaması kullanılarak bağlantı noktaları için TLS'nin etkinleştirilmesi gerekir.
• Anahtar algoritmaları: Hem EC hem de RSA anahtarları desteklenir, ancak zincirdeki tüm sertifikaların aynı anahtar algoritmasını kullanması gerekir.
• Biçim: CA sertifikası Privacy-Enhanced Posta (PEM) biçiminde olmalıdır.

İpucu

PEM biçimi, sertifikalar ve anahtarlar için ortak bir biçimdir. PEM dosyaları, ve -----BEGIN CERTIFICATE-----gibi -----BEGIN EC PRIVATE KEY----- üst bilgiler içeren Base64 kodlu ASCII dosyalarıdır.

Başka bir biçimde bir sertifikanız varsa, OpenSSL kullanarak sertifikayı PEM'ye dönüştürebilirsiniz. Daha fazla bilgi için bkz. Sertifikayı uygun biçime dönüştürme.

Güvenilen CA sertifikası alma

Bir üretim kurulumunda, CA sertifikası bir kuruluşun ortak anahtar altyapısı (PKI) veya ortak sertifika yetkilisi tarafından sağlanır.

Test için OpenSSL ile otomatik olarak imzalanan bir CA sertifikası oluşturun. Örneğin, RSA anahtarı, ayırt edici bir ad CN=Contoso Root CA Certve 365 günlük geçerlilik ile otomatik olarak imzalanan bir CA sertifikası oluşturmak için aşağıdaki komutu çalıştırın:

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

Sertifikaları yönetmek için kullanışlı bir araç olan Step CLI ile aynı komut şu şekildedir:

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

Bu komutlar, ca.pemPEM biçiminde bir CA sertifikası ve özel anahtar ca-key.pemoluşturur. CA sertifikasını ca.pem X.509 kimlik doğrulaması için MQTT aracısına aktarabilirsiniz.

Güvenilen CA sertifikalarını içeri aktarma

X.509 kimlik doğrulamasını kullanmaya başlamak için, güvenilir CA sertifikasını azure-iot-operations isim alanındaki bir ConfigMap'e içe aktarın. Güvenilen CA sertifikasını ca.pem adlı client-cabir ConfigMap'e aktarmak için şunu çalıştırın:

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

Önemli

ConfigMap adı, aracı işleci tarafından dahili olarak Kubernetes birim adı olarak kullanılır. Birim adları RFC 1123 etiket kurallarına uymalıdır; bu da yalnızca küçük harf alfasayısal karakterler ve kısa çizgiler içerebileceği anlamına gelir. Örneğin, client-ca ve my-root-ca geçerli adlardır, ancak my-root-ca.crt değildir. ConfigMap adında noktalar veya başka geçersiz karakterler varsa, aracı uzlaşma işlemi sessizce başarısız olur ve dinleyiciler doğru şekilde yapılandırılmaz.

Bu örnekte, CA sertifikası anahtarı ca.pemaltında içeri aktarılır. MQTT aracısı ConfigMap'teki tüm CA sertifikalarına güvenir, böylece anahtarın adı için her şeyi kullanabilirsiniz.

Kök CA sertifikasının düzgün içeri aktarıldığından emin olmak için komutunu çalıştırın kubectl describe configmap. Sonuç, PEM sertifika dosyasının aynı Base64 kodlamasını gösterir.

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
====

X.509 kimlik doğrulama yöntemini yapılandırma

Güvenilen CA sertifikası içeri aktarıldıktan sonra, Bir BrokerAuthentication kaynağına kimlik doğrulama yöntemi olarak ekleyerek X.509 istemci kimlik doğrulamasını etkinleştirin. Bu kaynağın TLS özellikli bir dinleyici bağlantı noktasına bağlı olduğundan emin olun.

Portal

1. Azure portalında IoT İşlemleri örneğine gidin.

2. Bileşenler'in altında MQTT Aracısı'ni seçin.

3. Kimlik Doğrulaması sekmesini seçin.

4. Mevcut bir kimlik doğrulama ilkesini seçin veya yeni bir ilke oluşturun.

5. Yöntem ekle'yi seçerek yeni bir yöntem ekleyin.

6. Açılan listeden X.509 yöntem türünü seçin. Ardından yöntemi yapılandırmak için Ayrıntılar ekle'yi seçin.

7. X.509 kimlik doğrulama ayrıntıları bölmesinde, JSON biçimini kullanarak güvenilen CA sertifikası ConfigMap adını belirtin.

   {
       "trustedClientCaCert": "<TRUSTED_CA_CONFIGMAP>"
   }
   

   <TRUSTED_CA_CONFIGMAP> ifadesini, güvenilen CA sertifikasını içeren ConfigMap adıyla değiştirin. Örneğin, kullanın "trustedClientCaCert": "client-ca".

   

8. İsteğe bağlı olarak, X.509 sertifikalarını kullanarak istemciler için yetkilendirme öznitelikleri ekleyin. Daha fazla bilgi edinmek için bkz. Yetkilendirme için sertifika öznitelikleri.

9. Değişiklikleri kaydetmek için Uygula'yı seçin.

Azure CLI

MQTT aracısı kimlik doğrulaması politikası oluşturmak veya değiştirmek için az iot ops broker authn apply komutunu kullanın.

az iot ops broker authn apply --resource-group $RESOURCE_GROUP --instance $AIO_INSTANCE_NAME --broker $BROKER --name $AUTHN --config-file config.json

--config-file parametresi, kaynak özelliklerini içeren bir JSON yapılandırma dosyasının yolu ve dosya adıdır.

Bu örnekte, X.509 yöntemiyle adlı my-authn-policy.json bir yapılandırma dosyasının kullanıcının giriş dizininde depolandığını varsayalım:

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

X.509 yöntemiyle adlı my-policy yeni bir kimlik doğrulama ilkesi oluşturmaya yönelik örnek komut aşağıdaki gibidir:

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

Pazı

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@2026-03-01' existing = {
  name: aioInstanceName
}

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

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

resource myBrokerAuthentication 'Microsoft.IoTOperations/instances/brokers/authentications@2026-03-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
          // }
        }
      }
    ]
  }
}

<TRUSTED_CA_CONFIGMAP> ifadesini, güvenilen CA sertifikasını içeren ConfigMap adıyla değiştirin. Örneğin, kullanın client-ca.

Azure CLI kullanarak Bicep dosyasını dağıtın:

az deployment group create --resource-group $RESOURCE_GROUP --template-file main.bicep

Kubernetes (yalnızca hata ayıklama)

Önemli

Kubernetes dağıtım bildirimlerinin kullanımı üretim ortamlarında desteklenmez ve yalnızca hata ayıklama ve test için kullanılmalıdır.

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

<TRUSTED_CA_CONFIGMAP> ifadesini, güvenilen CA sertifikasını içeren ConfigMap adıyla değiştirin. Örneğin, kullanın client-ca.

İsteğe bağlı: Yetkilendirme için sertifika öznitelikleri

İstemcileri sertifika özelliklerine göre yetkilendirmek için BrokerAuthentication kaynağında X.509 özniteliklerini belirtebilirsiniz. Öznitelikler alanında authorizationAttributes tanımlanır.

Örneğin:

Portal

Azure portalında X.509 kimlik doğrulama yöntemini yapılandırdığınızda, X.509 kimlik doğrulama ayrıntıları bölmesine JSON biçiminde yetkilendirme özniteliklerini ekleyin.

{
  "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

MQTT aracısı kimlik doğrulaması politikası oluşturmak veya değiştirmek için az iot ops broker authn apply komutunu kullanın.

az iot ops broker authn apply --resource-group $RESOURCE_GROUP --instance $AIO_INSTANCE_NAME --broker $BROKER --name $AUTHN --config-file config.json

--config-file parametresi, kaynak özelliklerini içeren bir JSON yapılandırma dosyasının yolu ve dosya adıdır.

Bu örnekte, X.509 yöntemiyle adlı my-authn-policy.json bir yapılandırma dosyasının ve sertifika özelliklerinin kullanıcının giriş dizininde depolandığını varsayalım

{
  "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"
      }
    }
  ]
}

adlı my-policy yeni bir kimlik doğrulama ilkesi oluşturmaya yönelik örnek komut aşağıdaki gibidir:

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

Pazı

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 (yalnızca hata ayıklama)

Önemli

Kubernetes dağıtım bildirimlerinin kullanımı üretim ortamlarında desteklenmez ve yalnızca hata ayıklama ve test için kullanılmalıdır.

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

Bu örnekte, ayırt edici adı CN = Contoso Root CA Cert, OU = Engineering, C = US olan kök CA veya ayırt edici adı CN = Contoso Intermediate CA olan ara CA tarafından verilen bir sertifikaya sahip her istemci, listelenen öznitelikleri alır. Buna ek olarak, akıllı fan istemci sertifikası ona özgü öznitelikleri alır.

Öznitelikler için eşleştirme her zaman yaprak istemci sertifikasından başlar ve ardından zincir boyunca gider. Öznitelik ataması ilk eşleşmeden sonra durur. Önceki örnekte, ara sertifikaya smart-fansahip olsa CN = Contoso Intermediate CA bile ilişkili öznitelikleri almaz.

Bu özniteliklere sahip X.509 sertifikalarını kullanarak istemcilere yetkilendirme kuralları uygulayabilirsiniz. Daha fazla bilgi edinmek için bkz. X.509 kimlik doğrulamasını kullanan istemcileri yetkilendirme.

İsteğe göre: X.509 authentication için Azure Device Registry entegrasyonu

Cihaz düzeyinde sertifika doğrulamayı ve iptali zorunlu kılmak için X.509 kimlik doğrulamasıyla Azure Cihaz Kayıt Defteri tümleştirmesini etkinleştirebilirsiniz. Bu özellik etkinleştirildiğinde, X.509 istemcilerinin cihaz kayıt defterinde eşleşen cihazlara sahip olmasını gerektirir ve ilgili cihazı devre dışı bırakarak istemcileri devre dışı bırakmanıza olanak tanır.

Azure Cihaz Kayıt Defteri tümleştirmesi etkinken:

• İstemci sertifikaları, Azure Cihaz Kayıt Defteri'ndeki bir cihaz adıyla eşleşen bir Ortak Ad'a (CN) sahip olmalıdır.
• Yalnızca kayıt defterindeki etkin cihazlar başarıyla kimlik doğrulaması yapabilir.
• Cihaz durumu istemci kimlik doğrulamasında ve bundan sonra her 10 dakikada bir denetlenmektedir.
• Devre dışı bırakılan veya kaldırılan cihazların erişimi otomatik olarak reddedilir.

Bu özelliği etkinleştirmeden önce, her istemci sertifikası için Azure Cihaz Kayıt Defteri'nde ilgili cihazı oluşturun. Cihaz adı sertifikanın Ortak Adı (CN) ile eşleşmelidir. Azure Cihaz Kayıt Defteri'nde cihaz oluşturmak ve yönetmek için bkz:

• Varlıklar, cihazlar ve veri akışları gibi kaynakları yönetmek için işlem deneyimini kullanın
• Varlıkları ve cihazları anlama

Azure Cihaz Kaydı tümleştirmesini etkinleştirmek için, X.509 ayarlarındaki additionalValidation alanını AzureDeviceRegistry olarak ayarlayın. additionalValidation alanı, belirtilen yöntemi kullanarak istemci sertifikasının ek doğrulamasını gerçekleştirir; desteklenen değerler AzureDeviceRegistry veya None (varsayılan) olarak belirtilmiştir:

Portal

Azure portalında, X.509 kimlik doğrulama yöntemini yapılandırdığınızda, X.509 kimlik doğrulama ayrıntıları bölmesine JSON biçiminde Azure Cihaz Kayıt Defteri doğrulamasını ekleyin:

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

Azure CLI

Azure Cihaz Kayıt Defteri doğrulamasıyla bir MQTT aracısı kimlik doğrulama ilkesi oluşturmak veya değiştirmek için az iot ops broker authn apply komutunu kullanın.

Azure Cihaz Kayıt Defteri tümleştirmesi ile örnek yapılandırma dosyası:

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

Pazı

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

Kubernetes (yalnızca hata ayıklama)

Önemli

Kubernetes dağıtım bildirimlerinin kullanımı üretim ortamlarında desteklenmez ve yalnızca hata ayıklama ve test için kullanılmalıdır.

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

Azure Cihaz Kayıt Defteri tümleştirmesini etkinleştirdikten sonra, Azure Cihaz Kayıt Defteri'nde her istemci sertifikası için ilgili cihazı oluşturun. Cihaz adı sertifikanın Ortak Adı (CN) ile eşleşmelidir. İstemci kayıt defterinde eşleşen bir etkin cihaza sahip olmayan bir sertifikayla kimlik doğrulaması yapmaya çalışırsa, kimlik doğrulaması başarısız olur.

Dinleyici bağlantı noktası için X.509 kimlik doğrulamasını etkinleştirme

Güvenilen CA sertifikasını içeri aktardıktan ve BrokerAuthentication kaynağını yapılandırdıktan sonra tls özellikli dinleyici bağlantı noktasına bağlayın. X.509 kimlik doğrulaması istemci sertifikası doğrulaması için TLS'ye bağlı olduğundan bu adım önemlidir.

TLS etkin dinleyici bağlantı noktasını almak için, Bağlantı noktası için TLS el ile sertifika yönetimini etkinleştirme ve Bağlantı noktası için TLS otomatik sertifika yönetimini etkinleştirme başlıklı belgeleri inceleyin.

Not

Aracı dinleyici bağlantı noktasında TLS'nin etkinleştirilmesi, aracının TLS şifrelemesi için bir sunucu sertifikası kullandığı anlamına gelir. İstemciler bu bağlantı noktasına bağlandığında, güven depolarında imzalanmış olan CA sertifikasına ihtiyaç duyarlar ve böylece sunucu sertifikasına güvenmelidirler. Bu işlem , güven dağıtımı veya güven paketleme olarak bilinir. İstemci doğrulaması ile sunucu doğrulaması arasındaki farkı anlamak önemlidir:

• İstemci doğrulaması: MQTT aracısı (sunucu), X.509 istemci kimlik doğrulaması için alanında belirtilen güvenilen CA sertifikasına karşı istemci sertifikasını trustedClientCaCert denetler.
• Sunucu doğrulaması: İstemciler (Mosquitto veya MQTTX gibi), MQTT aracısının sunucu sertifikasını güven depolarındaki güvenilen CA sertifikasına karşı denetler. Mosquitto istemcileri için, CA sertifika dosyasını belirtmek için parametresini kullanın --cafile . MQTTX için ca sertifikasını ayarlardaki güven deposuna ekleyin.

X.509 kimlik doğrulamasını etkinleştirdikten sonra, istemcilerin, sunucu tarafı CA sertifikasını güven depolarında bulundurarak aracının sunucu sertifikasına güvendiğinden emin olun. Sunucu tarafı CA sertifikasına güvenmeyi, alanda belirtilen istemci kimlik doğrulaması için kullanılan istemci trustedClientCaCert CA sertifikasıyla karıştırmayın.

Tam bir örnek için bkz . Öğretici: TLS, X.509 istemci kimlik doğrulaması ve öznitelik tabanlı erişim denetimi (ABAC) yetkilendirmesi.

Mosquitto istemcisini X.509 istemci sertifikasıyla MQTT aracısına bağlama

Mosquitto gibi bir istemcinin TLS ve X.509 istemci kimlik doğrulaması ile MQTT aracısına bağlanabilmesi için iki dosyaya ihtiyacı vardır:

• --cert parametresi, istemci sertifikası PEM dosyasını belirtir. Bu dosya, MQTT aracısının tam sertifika zincirini oluşturmasına yardımcı olacak ara sertifikaları da içermelidir.
• --key parametresi istemci özel anahtar PEM dosyasını belirtir.

MQTT aracısının TLS sunucu sertifikasını vermek için otomatik olarak imzalanan bir CA sertifikası kullandığı durumlarda parametresi --cafile gereklidir. Bu dosya, Mosquitto istemcisinin TLS üzerinden bağlandığında aracının sunucu sertifikasını doğrulamak için kullandığı CA sertifikasını ( güven paketi olarak da bilinir) içerir. MQTT aracısının sunucu sertifikasının vereni, iyi bilinen genel Sertifika Yetkilisi (CA) gibi sistem kök deposunun bir parçasıysa, --cafile parametresi atlanabilir.

Örneğin:

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

MQTT aracısı X.509 istemci kimlik doğrulama akışını anlama

İstemci kimlik doğrulaması için şu adımları izleyin:

1. X.509 istemci kimlik doğrulaması açık olduğunda, bağlanan istemcilerin MQTT aracısının yapılandırılmış güvenilen sertifikalarından birine dayalı bir sertifika zinciri oluşturmasına izin vermek için bir istemci sertifikası ve herhangi bir ara sertifika sunması gerekir.
2. Yük dengeleyici, iletişimi ön uç brokerlerinden birine yönlendirir.
3. Ön uç aracısı istemci sertifikasını aldıktan sonra, yapılandırılan sertifikalardan birine kök salmış bir sertifika zinciri oluşturmaya çalışır. Ön uç aracısı başarıyla bir zincir oluşturursa ve sunulan zincir doğrulanırsa TLS el sıkışması tamamlanır. Bağlanan istemci, TLS kanalı üzerinden ön uçta MQTT paketleri gönderebilir.
4. TLS kanalı açık, ancak istemci kimlik doğrulaması veya yetkilendirmesi henüz tamamlanmadı.
5. İstemci daha sonra MQTT aracısına bir CONNECT paketi gönderir.
6. CONNECT paketi tekrar bir ön uca yönlendirilir.
7. Ön uç, CONNECT paketinden gelen kimlik doğrulama verileri ve TLS el sıkışması sırasında sunulan istemci sertifika zinciri gibi istemcinin şu ana kadar sunduğu tüm kimlik bilgilerini toplar.
8. Ön uç bu kimlik bilgilerini kimlik doğrulama hizmetine gönderir. Kimlik doğrulama hizmeti sertifika zincirini bir kez daha denetler ve zincirdeki tüm sertifikaların konu adlarını toplar.
9. Kimlik doğrulama hizmeti, bağlanan istemcilerin sahip olduğu öznitelikleri belirlemek için yapılandırılmış yetkilendirme kurallarını kullanır. Bu öznitelikler, CONNECT paketinin kendisi de dahil olmak üzere istemcinin çalıştırabileceği işlemleri belirler.
10. Kimlik doğrulama hizmeti, kararı ön uç aracısına döndürür.
11. Ön uç aracısı istemci özniteliklerini ve bağlanmasına izin verilip verilmediğini bilir. Bu durumda MQTT bağlantısı tamamlanır ve istemci, yetkilendirme kuralları tarafından belirlenen MQTT paketlerini gönderip almaya devam edebilir.

Kubernetes hizmet hesabı belirteçleri

Kubernetes SATs, Kubernetes hizmet hesaplarıyla ilişkilendirilmiş JSON web belirteçleridir. İstemciler, kimliklerini doğrulamak için MQTT aracısına SATs sunar.

MQTT aracısı, GKE kullanıcılarının Kubernetes'in yeni hizmet hesabı belirteçleri hakkında bilmesi gerekenler gönderisinde açıklanan bağlı hizmet hesabı belirteçlerini kullanır. Gönderinin ana özellikleri şunlardır:

Bağlı belirteçler Kubernetes 1.13'te başlatıldı ve 1.21'de varsayılan biçim oldu. Bağlı belirteçler, eski belirteçlerin sınırlı işlevlerinin tamamını ve daha fazlasını kapsar.

• Belirteçleri çalmak ve kötüye kullanmak zordur. Bunlar zamana bağlı, izleyiciye bağlı ve nesneye bağlı.
• Standartlaştırılmış bir biçimi benimserler. Tam OIDC Bulma özelliğine sahip OpenID Connect (OIDC), hizmet sağlayıcılarının bunları kabul etmelerini kolaylaştırır.
• Yeni bir Kubelet tarafından yansıtılan birim türü kullanılarak podlara daha güvenli bir şekilde dağıtılıyorlar.

Aracı, Kubernetes Token Review API'sini kullanarak belirteçleri doğrular. Kubernetes TokenRequestProjection özelliğini etkinleştirerek audiences belirtin (1.21'den bu yana varsayılan). Bu özellik etkinleştirilmediyse, SAT'leri kullanamazsınız.

Servis hesabı oluşturma

SATs oluşturmak için önce bir hizmet hesabı oluşturun. Aşağıdaki komut adlı mqtt-clientbir hizmet hesabı oluşturur:

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

İsteğe bağlı: Yetkilendirme için öznitelik ekleme

SAT aracılığıyla kimlik doğrulaması yapan istemcilerin hizmet hesapları, isteğe bağlı olarak yetkilendirme ilkeleriyle kullanılacak özniteliklerle anote edilebilir. Bu açıklamaları diğerlerinden ayırt etmek için aio-broker-auth/ ön ekiyle başlarlar.

kullanarak kubectl annotatebir hizmet hesabına açıklama ekleyebilirsiniz:

kubectl annotate serviceaccount $SERVICE_ACCOUNT_NAME aio-broker-auth/$ATTRIBUTE=$ATTRIBUTE_VALUE -n azure-iot-operations

Ek açıklamaları hizmet hesabı bildirim dosyasına da ekleyebilirsiniz:

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>

Daha fazla bilgi edinmek için bkz. Kubernetes hizmet hesabı belirteçlerini kullanan istemcileri yetkilendirme.

SAT kimlik doğrulamasını etkinleştirme

BrokerAuthentication kaynağındaki ayarı geçerli bir kimlik doğrulama yöntemi olarak authenticationMethods belirlemek için değiştirin. audiences parametresi belirteçler için geçerli izleyicilerin listesini belirtir. MQTT aracı hizmetini tanımlayan benzersiz değerler seçin. En az bir hedef kitle belirtmeniz ve tüm SAT'lerin belirtilen hedef kitlelerden biriyle eşleşmesi gerekir.

Portal

1. Azure portalında IoT İşlemleri örneğine gidin.
2. Bileşenler'in altında MQTT Aracısı'ni seçin.
3. Kimlik Doğrulaması sekmesini seçin.
4. Mevcut bir kimlik doğrulama ilkesini seçin veya yeni bir ilke oluşturun.
5. Yöntem ekle'yi seçerek yeni bir yöntem ekleyin.
6. Açılan listeden Kubernetes SAT yöntemini seçin. Ardından yöntemi yapılandırmak için Ayrıntılar ekle'yi seçin.

Azure CLI

MQTT aracısı kimlik doğrulaması politikası oluşturmak veya değiştirmek için az iot ops broker authn apply komutunu kullanın.

az iot ops broker authn apply --resource-group $RESOURCE_GROUP --instance $AIO_INSTANCE_NAME --broker $BROKER --name $AUTHN --config-file config.json

--config-file parametresi, kaynak özelliklerini içeren bir JSON yapılandırma dosyasının yolu ve dosya adıdır.

Bu örnekte Kubernetes SAT yöntemiyle adlı my-authn-policy.json bir yapılandırma dosyasının kullanıcının giriş dizininde depolandığını varsayalım:

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

Kubernetes SAT yöntemiyle adlı my-policy yeni bir kimlik doğrulama ilkesi oluşturmaya yönelik örnek bir komut aşağıdaki gibidir:

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

Pazı

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

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

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

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

resource myBrokerAuthentication 'Microsoft.IoTOperations/instances/brokers/authentications@2026-03-01' = {
  parent: defaultBroker
  name: policyName
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }
  properties: {
    authenticationMethods: [
      {
        method: 'ServiceAccountToken'
        serviceAccountTokenSettings: {
          audiences: [
            'aio-internal'
            'my-audience'
          ]
        }
      }
    ]
  }
}

Azure CLI kullanarak Bicep dosyasını dağıtın:

az deployment group create --resource-group $RESOURCE_GROUP --template-file main.bicep

Kubernetes (yalnızca hata ayıklama)

Önemli

Kubernetes dağıtım bildirimlerinin kullanımı üretim ortamlarında desteklenmez ve yalnızca hata ayıklama ve test için kullanılmalıdır.

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

Değişikliklerinizi kubectl apply ile uygulayın. Değişikliklerin geçerlilik kazanması birkaç dakika sürebilir.

SAT kimlik doğrulamayı test edin

SAT kimlik doğrulaması, MQTT v5 gelişmiş kimlik doğrulama alanlarını kullanır. İstemcinin gelişmiş kimlik doğrulama yöntemini K8S-SAT olarak ve gelişmiş kimlik doğrulama verilerini belirteç olarak ayarlaması gerekir.

Örneğin, Mosquitto kullanın (kısa süre için atlanan bazı alanlar):

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

Burada <TOKEN> servis hesabı belirteci yer alır. Test belirteci almak için şunu çalıştırın:

kubectl create token $SERVICE_ACCOUNT_NAME -n azure-iot-operations --audience $AUDIENCE

Burada, <SERVICE_ACCOUNT> oluşturduğunuz hizmet hesabının adıdır ve <AUDIENCE> BrokerAuthentication kaynağında yapılandırılan hedef kitlelerden biridir.

Kubernetes podunu SAT kimlik doğrulamasını kullanacak şekilde yapılandırma örneği için bkz. Küme içindeki varsayılan dinleyiciye bağlanma.

Pod yapılandırmasında, serviceAccountName alanın kullanılan belirteçle ilişkili hizmet hesabıyla eşleşmesi gerekir. Alan serviceAccountToken.audience, BrokerAuthentication kaynağında yapılandırılan audiences seçeneklerinden biri olmalıdır.

Hizmet hesabı belirteçlerini yenileme

Hizmet hesabı belirteçleri sınırlı bir süre için geçerlidir ve expirationSeconds ile yapılandırılır. Ancak Kubernetes , süresi dolmadan önce belirteci otomatik olarak yeniler. Belirteç arka planda yenilenir ve istemcinin yapması gereken tek şey onu yeniden getirmektir.

Örneğin, istemci, test SAT kimlik doğrulaması örneğinde olduğu gibi birim olarak bağlanmış belirteci kullanan bir pod ise, en son belirteç aynı yolda /var/run/secrets/tokens/broker-satkullanılabilir. İstemci yeni bir bağlantı yaptığında, istemci en son belirteci getirebilir ve kimlik doğrulaması için kullanabilir. İstemci ayrıca en son belirteci getirerek ve bağlantıyı yeniden deneyerek MQTT yetkisiz hatalarını işlemek için bir mekanizmaya sahip olmalıdır.

Özel kimlik doğrulaması

Özel kimlik doğrulaması ile istemci kimlik doğrulamasını sağlanan kimlik doğrulama yöntemlerinin ötesine genişletin. Api'ye bağlı olduğu sürece hizmet herhangi bir şey olabileceğinden eklenebilir .

Bir istemci özel kimlik doğrulaması etkinken MQTT aracısına bağlandığında, aracı istemcinin kimlik bilgileriyle özel bir kimlik doğrulama sunucusuna bir HTTPS isteği gönderir. Ardından sunucu, istemcinin yetkilendirme öznitelikleri de dahil olmak üzere onay veya reddetme ile yanıt verir.

Özel kimlik doğrulama hizmeti oluşturma

Özel kimlik doğrulama sunucusu, MQTT aracısından ayrı olarak uygulanır ve dağıtılır.

GitHub'da örnek bir özel kimlik doğrulama sunucusu ve yönergeler bulunur. Bu örneği şablon olarak ve kendi özel kimlik doğrulama mantığınızı uygulamak için bir başlangıç noktası olarak kullanın.

Uygulama Programlama Arayüzü (API)

MQTT aracısı ile özel kimlik doğrulama sunucusu arasındaki API, özel kimlik doğrulaması için API belirtimini izler. OpenAPI belirtimi GitHub'da mevcuttur.

TLS şifrelemesi ile HTTPS gereklidir

MQTT aracısı, hassas istemci kimlik bilgilerini içeren istekleri özel kimlik doğrulama sunucusuna gönderir. Bu kimlik bilgilerini korumak için, MQTT aracısı ile özel kimlik doğrulama sunucusu arasındaki iletişim TLS ile şifrelenmelidir.

Özel kimlik doğrulama sunucusunun bir sunucu sertifikası sunması ve MQTT aracısının sunucu sertifikasını doğrulamak için güvenilen bir kök CA sertifikasına sahip olması gerekir. İsteğe bağlı olarak, özel kimlik doğrulama sunucusu, MQTT aracısının kimliğini doğrulamak için bir istemci sertifikası sunmayı gerektirebilir.

Dinleyici için özel kimlik doğrulamasını etkinleştirme

Bir BrokerAuthentication kaynağındaki Kimlik doğrulama yöntemleri ayarını, geçerli bir kimlik doğrulama yöntemi olarak Özel olarak belirtmek üzere değiştirin. Ardından, özel bir kimlik doğrulama sunucusuyla iletişim kurmak için gereken parametreleri belirtin.

Portal

1. Azure portalında IoT İşlemleri örneğine gidin.

2. Bileşenler'in altında MQTT Aracısı'ni seçin.

3. Kimlik Doğrulaması sekmesini seçin.

4. Mevcut bir kimlik doğrulama ilkesini seçin veya yeni bir ilke oluşturun.

5. Yöntem ekle'yi seçerek yeni bir yöntem ekleyin.

6. Açılan listeden Özel yöntem türünü seçin. Ardından yöntemi yapılandırmak için Ayrıntılar ekle'yi seçin.

   

Azure CLI

MQTT aracısı kimlik doğrulaması politikası oluşturmak veya değiştirmek için az iot ops broker authn apply komutunu kullanın.

az iot ops broker authn apply --resource-group $RESOURCE_GROUP --instance $AIO_INSTANCE_NAME --broker $BROKER --name $AUTHN --config-file config.json

--config-file parametresi, kaynak özelliklerini içeren bir JSON yapılandırma dosyasının yolu ve dosya adıdır.

Bu örnekte, özel bir yöntemle adlı my-authn-policy.json bir yapılandırma dosyasının kullanıcının giriş dizininde depolandığını varsayalım:

{
  "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"
        ]
      }
    }
  ]
}

Kubernetes SAT yöntemiyle adlı my-policy yeni bir kimlik doğrulama ilkesi oluşturmaya yönelik örnek bir komut aşağıdaki gibidir:

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

Pazı

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

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

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

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

resource myBrokerAuthentication 'Microsoft.IoTOperations/instances/brokers/authentications@2026-03-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'
          }
        }
      }
    ]
  }
}

Azure CLI kullanarak Bicep dosyasını dağıtın:

az deployment group create --resource-group $RESOURCE_GROUP --template-file main.bicep

Kubernetes (yalnızca hata ayıklama)

Önemli

Kubernetes dağıtım bildirimlerinin kullanımı üretim ortamlarında desteklenmez ve yalnızca hata ayıklama ve test için kullanılmalıdır.

Bu örnekte tüm olası parametreler gösterilir. Tam olarak gerekli parametreler her özel sunucunun gereksinimlerine bağlıdır.

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

Kullanıcı adı ve parola kimlik doğrulaması için özel kimlik doğrulaması kullanma

Kullanıcı adı ve parola kimlik doğrulaması uygulamak için özel kimlik doğrulaması kullanabilirsiniz. Test için örnek bir özel kimlik doğrulama sunucusu örneği kullanılabilir. GitHub'da Azure IoT İşlemleri MQTT kullanıcı adı ve parola kimlik doğrulaması örneğine bakın.

Kimlik doğrulamayı devre dışı bırakma

Test için, aracı dinleyici bağlantı noktası için kimlik doğrulamasını devre dışı bırakabilirsiniz. Üretim ortamları için kimlik doğrulamasını devre dışı bırakmanızı önermiyoruz.

Portal

1. Azure portalında IoT İşlemleri örneğine gidin.
2. Bileşenler'in altında MQTT Aracısı'ni seçin.
3. Listeden düzenlemek istediğiniz aracı dinleyicisini seçin.
4. Kimlik doğrulamasını devre dışı bırakmak istediğiniz bağlantı noktasında, kimlik doğrulaması açılan listesinde Hiçbiri'ni seçin.

Azure CLI

Bir bağlantı noktası için kimlik doğrulamasını devre dışı bırakmak için az iot ops broker listener port add komutunu kullanın. Kimlik doğrulamasını devre dışı bırakmak için --authn-ref parametresini eklemeyin.

az iot ops broker listener port add --resource-group $RESOURCE_GROUP --instance $AIO_INSTANCE_NAME --broker default --listener $LISTENER --port $LISTENER_PORT

Aşağıdaki örnek, adlı aio-broker-loadbalancerdinleyiciye 8884 numaralı bağlantı noktası için kimlik doğrulamasını devre dışı bırakır:

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

Pazı

Kimlik doğrulamayı devre dışı bırakmak için BrokerListener kaynağınızın ayarındaki authenticationRefports'yi dahil etmeyin.

Kubernetes (yalnızca hata ayıklama)

Önemli

Kubernetes dağıtım bildirimlerinin kullanımı üretim ortamlarında desteklenmez ve yalnızca hata ayıklama ve test için kullanılmalıdır.

Kimlik doğrulamayı devre dışı bırakmak için BrokerListener kaynağınızın ayarındaki authenticationRefports'yi dahil etmeyin.

Kimlik bilgilerinin süresi dolduktan sonra istemcilerin bağlantısı kesilir

Kimlik bilgilerinin süresi dolduğunda MQTT aracısı istemcilerin bağlantısını keser. Kimlik bilgisi süresinin dolması, MQTT aracısı ön uçlarına bağlanan tüm istemciler için geçerli olur, bağlantıyı keser, örneğin:

• SAT'ler ile kimlikleri doğrulanmış istemcilerin bağlantısı, SAT'leri sona erdiğinde kesilir.
• X.509 ile kimlik doğrulaması yapılan istemcilerin, istemci sertifikasının süresi dolduğunda bağlantısı kesilir.
• Özel kimlik doğrulaması ile kimlik doğrulaması yapılan istemciler, özel kimlik doğrulama sunucusundan döndürülen süre sonu süresine göre bağlantıyı keser.

Bağlantı kesildiğinde istemcinin ağ bağlantısı kapatılır. İstemci bir MQTT DISCONNECT paketi almaz, ancak sunucu istemcinin bağlantısını kestiğini belirten bir mesajı günlüğe kaydeder.

SAT'ler ve özel kimlik doğrulamasıyla kimliği doğrulanmış MQTT v5 istemcileri, ilk kimlik bilgilerinin süresi dolmadan önce yeni bir kimlik bilgileriyle yeniden kimlik doğrulaması yapabilir. Kimlik doğrulaması TLS katmanında yapıldığından X.509 istemcileri yeniden kimlik doğrulaması yapamaz ve bağlantıyı yeniden kurmalıdır.

İstemciler, nedeni ReAuthile bir MQTT v5 AUTH paketi göndererek yeniden kimlik doğrulaması yapabilir.

SAT istemcileri, method: K8S-SAT ve data: <token> alanlarını içeren bir AUTH paketi gönderir. Özel kimlik doğrulama istemcileri, yöntemi ve veri alanını özel kimlik doğrulama sunucusunun gerektirdiği şekilde ayarlar.

Başarılı bir yeniden kimlik doğrulama, istemcinin kimlik bilgisi süresini, yeni kimlik bilgileriyle güncellenmiş son kullanım tarihiyle değiştirir. Aracı bir Success AUTH paketiyle yanıt verir. Özel kimlik doğrulama sunucusunun kullanılamaması gibi geçici sorunlar nedeniyle kimlik doğrulaması başarısız olduğunda, bu durum aracının bir ContinueAuthentication AUTH paketiyle yanıt vermesine neden olur. İstemci daha sonra yeniden deneyebilir. Diğer kimlik doğrulama hataları, aracının bir DISCONNECT paketi göndermesine ve istemcinin ağ bağlantısını kapatmasına neden olur.

İlgili içerik

• BrokerListener kaynağı
• BrokerListener için yetkilendirmeyi yapılandırma
• Öğretici: TLS, X.509 istemci kimlik doğrulaması ve öznitelik tabanlı erişim denetimi (ABAC) yetkilendirmesi