Konfigurowanie autoryzacji brokera MQTT

Ważne

Ta strona zawiera instrukcje dotyczące zarządzania składnikami operacji usługi Azure IoT przy użyciu manifestów wdrażania platformy Kubernetes, które są w wersji zapoznawczej. Ta funkcja jest udostępniana z kilkoma ograniczeniami i nie powinna być używana w przypadku obciążeń produkcyjnych.

Zobacz Dodatkowe warunki użytkowania wersji zapoznawczych platformy Microsoft Azure, aby zapoznać się z postanowieniami prawnymi dotyczącymi funkcji platformy Azure, które są w wersji beta lub wersji zapoznawczej albo w inny sposób nie zostały jeszcze wydane jako ogólnie dostępne.

Zasady autoryzacji określają, jakie akcje mogą wykonywać klienci na brokerze, takie jak łączenie, publikowanie lub subskrybowanie tematów. Skonfiguruj brokerA MQTT tak, aby używał jednego lub wielu zasad autoryzacji za pomocą zasobu BrokerAuthorization . Każdy zasób BrokerAuthorization zawiera listę reguł określających podmioty zabezpieczeń i zasoby zasad autoryzacji.

Łączenie elementu BrokerAuthorization z elementem BrokerListener

Aby połączyć element BrokerListener z zasobem BrokerAuthorization, określ authorizationRef pole w ports ustawieniu zasobu BrokerListener. Podobnie jak w przypadku brokeraAuthentication, zasób BrokerAuthorization może być połączony z wieloma portami BrokerListener . Zasady autoryzacji dotyczą wszystkich połączonych portów odbiornika. Istnieje jednak jedna kluczowa różnica w porównaniu z elementem BrokerAuthentication:

Ważne

Aby konfiguracja BrokerAuthorization miała zastosowanie do portu odbiornika, co najmniej jeden brokerAuthentication musi być również połączony z tym portem odbiornika.

Aby dowiedzieć się więcej o brokerlistener, zobacz Zasób BrokerListener.

Reguły autoryzacji

Aby skonfigurować autoryzację , utwórz zasób BrokerAuthorization w klastrze Kubernetes. W poniższych sekcjach przedstawiono przykłady konfigurowania autoryzacji dla klientów korzystających z nazw użytkowników, atrybutów, certyfikatów X.509 i tokenów kont usługi Kubernetes Service (SATs). Aby uzyskać listę dostępnych ustawień, zobacz dokumentację interfejsu API autoryzacji brokera .

W poniższym przykładzie pokazano, jak utworzyć zasób BrokerAuthorization przy użyciu nazw użytkowników i atrybutów:

Portal

1. W witrynie Azure Portal przejdź do wystąpienia operacji IoT.

2. W obszarze Składniki wybierz pozycję Broker MQTT.

3. Wybierz kartę Autoryzacja.

4. Wybierz istniejące zasady uwierzytelniania lub utwórz nowe, wybierając pozycję Utwórz zasady autoryzacji.

   

Bicep

Aby edytować zasady autoryzacji, utwórz plik Bicep .bicep z następującą zawartością. Zaktualizuj ustawienia zgodnie z potrzebami i zastąp wartości symboli zastępczych, na przykład <AIO_INSTANCE_NAME> własnymi.

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 brokerAuthorization 'Microsoft.IoTOperations/instances/brokers/authorizations@2024-11-01' = {
  parent: defaultBroker
  name: policyName
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }
  properties: {
    authorizationPolicies: {
      cache: 'Enabled'
      rules: [
        {
          principals: {
            clientIds: [
              'temperature-sensor'
              'humidity-sensor'
            ]
            attributes: [
              {
                city: 'seattle'
                organization: 'contoso'
              }
            ]
          }
          brokerResources: [
            {
              method: 'Connect'
            }
            {
              method: 'Publish'
              topics: [
                '/telemetry/{principal.clientId}'
                '/telemetry/{principal.attributes.organization}'
              ]
            }
            {
              method: 'Subscribe'
              topics: [
                '/commands/{principal.attributes.organization}'
              ]
            }
          ]
        }
      ]
    }
  }
}

Wdróż plik Bicep przy użyciu interfejsu wiersza polecenia platformy Azure.

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

Kubernetes (wersja zapoznawcza)

apiVersion: mqttbroker.iotoperations.azure.com/v1
kind: BrokerAuthorization
metadata:
  name: "my-authz-policies"
  namespace: azure-iot-operations
spec:
  authorizationPolicies:
    cache: Enabled
    rules:
      - principals:
          clientIds:
            - "temperature-sensor"
            - "humidity-sensor"
          attributes:
            - city: "seattle"
              organization: "contoso"
        brokerResources:
          - method: Connect
          - method: Publish
            topics:
              - "/telemetry/{principal.clientId}"
              - "/telemetry/{principal.attributes.organization}"
          - method: Subscribe
            topics:
              - "/commands/{principal.attributes.organization}"

Aby utworzyć ten zasób BrokerAuthorization , zastosuj manifest YAML do klastra Kubernetes.

Ta autoryzacja brokera umożliwia klientom z identyfikatorami temperature-sensor klienta lub humidity-sensor, lub klientów z atrybutami organization z wartością contoso i city wartością seattle, do:

• Nawiąż połączenie z brokerem.
• Publikowanie komunikatów w tematach telemetrii o określonym zakresie przy użyciu identyfikatorów klientów i organizacji. Na przykład: .
  • temperature-sensor program może publikować w plikach /telemetry/temperature-sensor i /telemetry/contoso.
  • humidity-sensor program może publikować w plikach /telemetry/humidity-sensor i /telemetry/contoso.
  • some-other-username program może publikować w programie /telemetry/contoso.
• Subskrybowanie tematów poleceń objętych zakresem ich organizacji. Na przykład: .
  • temperature-sensor program może subskrybować usługę /commands/contoso.
  • some-other-username program może subskrybować usługę /commands/contoso.

Używanie nazwy użytkownika do autoryzacji

Aby użyć nazwy użytkownika MQTT do autoryzacji, określ je jako tablicę w obszarze principals.usernames. Jednak w zależności od metody uwierzytelniania nazwa użytkownika może nie zostać zweryfikowana:

• Kubernetes SAT — nazwa użytkownika nie powinna być używana do autoryzacji, ponieważ nie jest weryfikowana pod kątem MQTTv5 z rozszerzonym uwierzytelnianiem.
• X.509 — nazwa użytkownika pasuje do nazwy CN z certyfikatu i może służyć do reguł autoryzacji.
• Niestandardowe — nazwa użytkownika powinna być używana tylko dla reguł autoryzacji, jeśli uwierzytelnianie niestandardowe weryfikuje nazwę użytkownika.

Aby zapobiec problemom z zabezpieczeniami, użyj nazwy użytkownika MQTT tylko do autoryzacji brokera, gdy można go zweryfikować.

Dalsze ograniczanie dostępu na podstawie identyfikatora klienta

principals Ponieważ pole jest logiczne LUB, można dodatkowo ograniczyć dostęp na podstawie identyfikatora klienta, dodając clientIds pole do brokerResources pola. Aby na przykład umożliwić klientom z identyfikatorami klientów rozpoczynającymi się od numeru konstrukcyjnego, aby połączyć się i opublikować dane telemetryczne w tematach o określonym zakresie w budynku, użyj następującej konfiguracji:

Portal

W regułach autoryzacji brokera dla zasad autoryzacji użyj następującej konfiguracji:

[
  {
    "brokerResources": [
      {
        "clientIds": [
          "{principal.attributes.building}*"
        ],
        "method": "Connect",
        "topics": []
      },
      {
        "clientIds": [],
        "method": "Publish",
        "topics": [
          "sensors/{principal.attributes.building}/{principal.clientId}/telemetry"
        ]
      }
    ],
    "principals": {
      "attributes": [
        {
          "building": "building22"
        },
        {
          "building": "building23"
        }
      ]
    }
  }
]

Bicep

Aby edytować zasady autoryzacji, utwórz plik Bicep .bicep z następującą zawartością. Zaktualizuj ustawienia zgodnie z potrzebami i zastąp wartości symboli zastępczych, na przykład <AIO_INSTANCE_NAME> własnymi.

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 brokerAuthorization 'Microsoft.IoTOperations/instances/brokers/authorizations@2024-11-01' = {
  parent: defaultBroker
  name: policyName
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }
  properties: {
    authorizationPolicies: {
      cache: 'Enabled'
      rules: [
        {
          principals: {
            attributes: [
              {
                building: 'building22'
              }
              {
                building: 'building23'
              }
            ]
          }
          brokerResources: [
            {
              method: 'Connect'
              clientIds: [
                '{principal.attributes.building}*' // client IDs must start with building22
              ]
            }
            {
              method: 'Publish'
              topics: [
                'sensors/{principal.attributes.building}/{principal.clientId}/telemetry'
              ]
            }
          ]
        }
      ]
    }
  }
}

Wdróż plik Bicep przy użyciu interfejsu wiersza polecenia platformy Azure.

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

Kubernetes (wersja zapoznawcza)

apiVersion: mqttbroker.iotoperations.azure.com/v1
kind: BrokerAuthorization
metadata:
  name: "my-authz-policies"
  namespace: azure-iot-operations
spec:
  authorizationPolicies:
    cache: Enabled
    rules:
    - principals:
        attributes:
          - building: "building22"
          - building: "building23"
      brokerResources:
      - method: Connect
        clientIds:
          - "{principal.attributes.building}*" # client IDs must start with building22
      - method: Publish
        topics:
          - "sensors/{principal.attributes.building}/{principal.clientId}/telemetry"

W tym miejscu, jeśli parametr clientIds nie został ustawiony w metodzie Connect , klient z dowolnym identyfikatorem klienta może nawiązać połączenie, building o ile atrybut ma ustawiony na building22 wartość lub building23. clientIds Dodając pole, tylko klienci z identyfikatorami klientów rozpoczynającymi się od building22 lub building23 mogą się łączyć. Gwarantuje to nie tylko, że klient ma prawidłowy atrybut, ale także, że identyfikator klienta jest zgodny z oczekiwanym wzorcem.

Autoryzowanie klientów korzystających z uwierzytelniania X.509

Klienci korzystający z certyfikatów X.509 do uwierzytelniania mogą mieć autoryzację dostępu do zasobów na podstawie właściwości X.509 znajdujących się w ich certyfikacie lub certyfikatów wystawiających łańcuch.

Używanie atrybutów

Aby utworzyć reguły na podstawie właściwości na podstawie certyfikatu klienta, jego głównego urzędu certyfikacji lub pośredniego urzędu certyfikacji, zdefiniuj atrybuty X.509 w zasobie BrokerAuthorization . Aby uzyskać więcej informacji, zobacz Atrybuty certyfikatu.

W przypadku nazwy pospolitej podmiotu certyfikatu klienta jako nazwy użytkownika

Aby utworzyć zasady autoryzacji na podstawie nazwy pospolitej podmiotu certyfikatu klienta (CN), utwórz reguły na podstawie nazwy CN.

Jeśli na przykład klient ma certyfikat z podmiotem CN = smart-lock, jego nazwa użytkownika to smart-lock. Z tego miejsca utwórz zasady autoryzacji w zwykły sposób.

Autoryzowanie klientów korzystających z tokenów konta usługi Kubernetes Service

Atrybuty autoryzacji dla sieci SAN są ustawiane jako część adnotacji konta usługi. Aby na przykład dodać atrybut autoryzacji o nazwie group z wartością authz-sat, uruchom polecenie:

kubectl annotate serviceaccount mqtt-client aio-broker-auth/group=authz-sat

Adnotacje atrybutów muszą zaczynać się od aio-broker-auth/ , aby odróżnić je od innych adnotacji.

Ponieważ aplikacja ma atrybut autoryzacji o nazwie authz-sat, nie ma potrzeby podawania elementu clientId lub username. Odpowiedni zasób BrokerAuthorization używa tego atrybutu jako podmiotu zabezpieczeń, na przykład:

Portal

W regułach autoryzacji brokera dla zasad autoryzacji użyj następującej konfiguracji:

[
  {
    "brokerResources": [
      {
        "clientIds": [],
        "method": "Connect",
        "topics": []
      },
      {
        "clientIds": [],
        "method": "Publish",
        "topics": [
          "odd-numbered-orders"
        ]
      },
      {
        "clientIds": [],
        "method": "Subscribe",
        "topics": [
          "orders"
        ]
      }
    ],
    "principals": {
      "attributes": [
        {
          "group": "authz-sat"
        }
      ]
    }
  }
]

Bicep

Aby edytować zasady autoryzacji, utwórz plik Bicep .bicep z następującą zawartością. Zaktualizuj ustawienia zgodnie z potrzebami i zastąp wartości symboli zastępczych, na przykład <AIO_INSTANCE_NAME> własnymi.

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 brokerAuthorization 'Microsoft.IoTOperations/instances/brokers/authorizations@2024-11-01' = {
  parent: defaultBroker
  name: policyName
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }
  properties: {
    authorizationPolicies: {
      rules: [
        {
          principals: {
            attributes: [
              {
                group: 'authz-sat'
              }
            ]
          }
          brokerResources: [
            {
              method: 'Connect'
            }
            {
              method: 'Publish'
              topics: [
                'odd-numbered-orders'
              ]
            }
            {
              method: 'Subscribe'
              topics: [
                'orders'
              ]
            }
          ]
        }
      ]
    }
  }
}

Wdróż plik Bicep przy użyciu interfejsu wiersza polecenia platformy Azure.

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

Kubernetes (wersja zapoznawcza)

apiVersion: mqttbroker.iotoperations.azure.com/v1
kind: BrokerAuthorization
metadata:
  name: "my-authz-policies"
  namespace: azure-iot-operations
spec:
  authorizationPolicies:
    cache: Enabled
    rules:
      - principals:
          attributes:
            - group: "authz-sat"
        brokerResources:
          - method: Connect
          - method: Publish
            topics:
              - "odd-numbered-orders"
          - method: Subscribe
            topics:
              - "orders"

Aby dowiedzieć się więcej na przykładzie, zobacz Konfigurowanie zasad autoryzacji za pomocą klienta dapr.

Magazyn stanów

Broker MQTT udostępnia magazyn stanów, którego klienci mogą używać do przechowywania stanu. Magazyn stanów można również skonfigurować tak, aby był wysoce dostępny.

Aby skonfigurować autoryzację dla klientów korzystających z magazynu stanów, podaj następujące uprawnienia:

• Uprawnienie do publikowania w temacie magazynu $services/statestore/_any_/command/invoke/request wartości klucza systemu
• Uprawnienie do subskrybowania tematu odpowiedzi (ustawionego podczas początkowego publikowania jako parametru) <response_topic>/#

Klucze magazynu stanów

Dostęp do magazynu stanów jest uzyskiwany za pośrednictwem brokera MQTT w temacie statestore/v1/FA9AE35F-2F64-47CD-9BFF-08E2B32A0FE8/command/invoke. Ponieważ klienci mają dostęp do tematu, można określić klucze i poziomy dostępu w stateStoreResources sekcji konfiguracji brokera brokerResources MQTT.

Format stateStoreResources sekcji składa się z poziomu dostępu, wskaźnika wzorca i wzorca.

Portal

Uwzględnij sekcję stateStoreResources w regułach zasad autoryzacji.

"stateStoreResources": [
  {
    "method": "", // Values: read, write, readwrite 
    "keyType": "", //Values: string, pattern, binary. Default is pattern
    "keys": [
      // List of patterns to match
    ]
  },
]

Bicep

W aplikacji Bicep dołącz sekcję stateStoreResources w zasadach autoryzacji.

stateStoreResources: [
  {
    method: '' // Values: read, write, readwrite 
    keyType: '' //Values: string, pattern, binary. Default is pattern
    keys: [
      // List of patterns to match
    ]
  }
  {
    method: 'ReadWrite'
    keyType: 'Binary'
    keys: [
      'xxxxxxxxxxxxxxxxxxxx'
    ]
  }
]

Kubernetes

W definicji zasobu niestandardowego uwzględnij sekcję stateStoreResources w zasadach autoryzacji.

stateStoreResources:
  - method:  # Values: read, write, readwrite 
    keyType: # Values: string, pattern, binary. Default is pattern
    keys:
      - # List of patterns to match

Pole method określa poziom dostępu.

• Dostęp do odczytu jest określony za pomocą readfunkcji , dostępu do zapisu za pomocą writepolecenia i obu z parametrami readwrite.
• Wymagany jest poziom dostępu.
• Poziom dostępu do odczytu oznacza akcje i get keynotify.
• Poziom dostępu do zapisu oznacza akcje set, deli vdel.

Pole keyType określa typ dopasowania klucza.

• patternaby używać dopasowania do wzorca stylu globu
• string aby dokładnie dopasować, na przykład, gdy klucz zawiera znaki, które mogą być w inny sposób dopasowane jako wzorzec (*, ?, [0-9])
• binary aby dopasować klucz binarny

Pole keys określa klucze, które mają być zgodne. Klucze można określić jako wzorce stylów globu , podstawienia tokenu lub dokładne ciągi.

• Przykłady stylu globu :
  • colors/*: Wszystkie klucze pod prefiksem "kolory/"
  • number[0-9]: Dowolny klucz z "number0" do "number9"
  • char?: dowolny klucz z prefiksem "char" i sufiksem pojedynczej cyfry, na przykład "charA"
  • *: Pełny dostęp do wszystkich kluczy.
• Klucze magazynu stanów obsługują również podstawianie tokenów, gdy typ klucza to pattern i nawiasy klamrowe są zarezerwowane do tego celu. Przykłady podstawiania tokenów:
  • clients/{principal.clientId}/*
  • usernames/{principal.username}/*
  • rooms/{principal.attributes.room}/*

Oto przykład tworzenia zasobów magazynu stanów:

Portal

W regułach autoryzacji brokera dla zasad autoryzacji dodaj podobną konfigurację:

[
  {
    "brokerResources": [
      {
        "clientIds": [
          "{principal.attributes.building}*"
        ],
        "method": "Connect"
      },
      {
        "method": "Publish",
        "topics": [
          "sensors/{principal.attributes.building}/{principal.clientId}/telemetry/*"
        ]
      },
      {
        "method": "Subscribe",
        "topics": [
          "commands/{principal.attributes.organization}"
        ]
      }
    ],
    "principals": {
      "attributes": [
        {
          "building": "17",
          "organization": "contoso"
        }
      ],
      "usernames": [
        "temperature-sensor",
        "humidity-sensor"
      ]
    },
    "stateStoreResources": [
      {
        "method": "Read",
        "keyType": "Pattern",
        "keys": [
          "myreadkey",
          "myotherkey?",
          "mynumerickeysuffix[0-9]",
          "clients/{principal.clientId}/*"
        ]
      },
      {
        "method": "ReadWrite",
        "keyType": "Binary",
        "keys": [
          "xxxxxxxxxxxxxxxxxxxx"
        ]
      }
    ]
  }
]

Bicep

Aby edytować zasady autoryzacji, utwórz plik Bicep .bicep z następującą zawartością. Zaktualizuj ustawienia zgodnie z potrzebami i zastąp wartości symboli zastępczych, na przykład <AIO_INSTANCE_NAME> własnymi.

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 brokerAuthorization 'Microsoft.IoTOperations/instances/brokers/authorizations@2024-11-01' = {
  parent: defaultBroker
  name: policyName
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }
  properties: {
    authorizationPolicies: {
      cache: 'Enabled'
      rules: [
        {
          principals: {
            usernames: [
              'temperature-sensor'
              'humidity-sensor'
            ]
            attributes: [
              {
                city: 'seattle'
                organization: 'contoso'
              }
            ]
          }
          brokerResources: [
            {
              method: 'Connect'
            }
            {
              method: 'Publish'
              topics: [
                '/telemetry/{principal.username}'
                '/telemetry/{principal.attributes.organization}'
              ]
            }
            {
              method: 'Subscribe'
              topics: [
                '/commands/{principal.attributes.organization}'
              ]
            }
          ]
          stateStoreResources: [
            {
              method: 'Read'
              keyType: 'Pattern'
              keys: [
                'myreadkey'
                'myotherkey?'
                'mynumerickeysuffix[0-9]'
                'clients/{principal.clientId}/*'
              ]
            }
            {
              method: 'ReadWrite'
              keyType: 'Binary'
              keys: [
                'xxxxxxxxxxxxxxxxxxxx'
              ]
            }
          ]
        }
      ]
    }
  }
}

Wdróż plik Bicep przy użyciu interfejsu wiersza polecenia platformy Azure.

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

Kubernetes

stateStoreResources:
  - method: Read # Read includes Get, Notify
    keyType: "pattern" # string, pattern, binary
    keys:
      - "myreadkey" # explicit read access on key: myreadkey
      - "myotherkey?" # single digit wildcard
      - "mynumerickeysuffix[0-9]" # single digit number range
      - "clients/{principal.clientId}/*" # use token substitution and a wildcard for per-client sandboxing
  - method: ReadWrite  # ReadWrite access includes Get, Notify, Set, Del
    keyType: "binary" # binary keys have exact match, no patterns
    keys:
      - "xxxxxxxxxxxxxxxxxxxx"  # base-64 encoded binary key.

Aktualizowanie autoryzacji

Zasoby autoryzacji brokera można aktualizować w czasie wykonywania bez ponownego uruchamiania. Wszyscy klienci połączeni w momencie aktualizacji zasad są rozłączone. Zmiana typu zasad jest również obsługiwana.

kubectl edit brokerauthorization my-authz-policies

Wyłączanie autoryzacji

Portal

1. W witrynie Azure Portal przejdź do wystąpienia operacji IoT.
2. W obszarze Składniki wybierz pozycję Broker MQTT.
3. Wybierz odbiornik brokera, który chcesz edytować z listy.
4. Na porcie, który chcesz wyłączyć autoryzację, wybierz pozycję Brak z listy rozwijanej autoryzacji.

Bicep

Aby wyłączyć autoryzację, pomiń ports authorizationRef ustawienie zasobu BrokerListener.

Kubernetes (wersja zapoznawcza)

Aby wyłączyć autoryzację, pomiń ports authorizationRef ustawienie zasobu BrokerListener.

Nieautoryzowane publikowanie w MQTT 3.1.1

W przypadku protokołu MQTT 3.1.1 po odmowie publikowania klient otrzymuje puBACK bez błędu, ponieważ wersja protokołu nie obsługuje zwracania kodu błędu. MQTTv5 zwraca puBACK z kodem przyczyny 135 (nieautoryzowanym) podczas odmowy publikowania.

Powiązana zawartość

• Informacje o zasobie BrokerListener
• Konfigurowanie uwierzytelniania dla elementu BrokerListener
• Samouczek: uwierzytelnianie klienta TLS, X.509 i autoryzacja kontroli dostępu opartej na atrybutach (ABAC)