MQTT 브로커 인증 구성

Important

이 페이지에는 미리 보기 상태인 Kubernetes 배포 매니페스트를 사용하여 Azure IoT Operations 구성 요소를 관리하기 위한 지침이 포함되어 있습니다. 이 기능은 몇 가지 제한 사항을 제공하며 프로덕션 워크로드에 사용하면 안 됩니다.

베타, 미리 보기로 제공되거나 아직 일반 공급으로 릴리스되지 않은 Azure 기능에 적용되는 약관은 Microsoft Azure 미리 보기에 대한 추가 사용 약관을 참조하세요.

MQTT broker는 클라이언트에 대해 여러 인증 방법을 지원하며 BrokerAuthentication 리소스를 사용하여 자체 인증 설정을 갖도록 각 수신기 포트를 구성할 수 있습니다. 사용 가능한 설정 목록은 Broker 인증 API 참조를 참조하세요.

BrokerListener 및 BrokerAuthentication 연결

BrokerListener와 BrokerAuthentication 리소스 간의 관계에는 다음 규칙이 적용됩니다.

• 각 BrokerListener에는 여러 포트가 있을 수 있습니다. 각 포트는 BrokerAuthentication 리소스에 연결할 수 있습니다.
• 각 BrokerAuthentication 은 한 번에 여러 인증 방법을 지원할 수 있습니다.
• BrokerAuthentication 리소스를 연결하지 않는 포트에는 인증을 사용할 수 없습니다.

BrokerListener 포트를 BrokerAuthentication 리소스에 연결하려면 BrokerListener 리소스 설정에서 ports 필드를 지정 authenticationRef 합니다. 자세한 내용은 BrokerListener 리소스를 참조 하세요.

기본 BrokerAuthentication 리소스

Azure IoT Operations는 네임스페이스의 기본 수신기와 연결된 명명된 default 기본 BrokerAuthentication 리소스를 azure-iot-operations 배포합니다. 인증에 Kubernetes 서비스 계정 토큰(SAT)만 사용합니다.

Important

Azure IoT Operations의 구성 요소가 올바르게 작동하려면 기본 BrokerAuthentication 리소스의 SAT(서비스 계정 토큰) 인증 방법이 필요합니다. 기본 BrokerAuthentication 리소스를 업데이트하거나 삭제하지 않습니다.

포털

1. Azure Portal에서 IoT Operations 인스턴스로 이동합니다.

2. 구성 요소 아래에서 MQTT Broker를 선택합니다.

3. 인증 탭을 선택합니다.

4. 인증 정책 목록에서 기본 정책 이름을 선택합니다.

   

새 인증 방법을 추가하려면 메서드 추가를 선택합니다.

Bicep

기본 엔드포인트를 편집하려면 다음 콘텐츠가 포함된 Bicep .bicep 파일을 만듭니다. 필요에 따라 설정을 업데이트하고 자리 표시자 값을 사용자 고유의 값 <AIO_INSTANCE_NAME> 으로 바꿉니다.

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'
          ]
        }
      }
    ]
  }
}

Azure CLI를 사용하여 Bicep 파일을 배포합니다.

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

Kubernetes(미리 보기)

기본 broker 인증 리소스를 검사하려면 다음을 실행합니다.

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

출력은 간결하게 하기 위해 메타데이터가 제거된 기본 BrokerAuthentication 리소스를 보여줍니다.

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

변경해야 하는 경우 대상 그룹과 함께 SAT 인증 방법을 유지하면서 이 리소스의 aio-internal 필드를 수정 authenticationMethods 합니다. 그런 다음 kubectl apply를 사용하여 배포합니다.

인증 흐름

지정된 인증 방법의 순서에 따라 MQTT Broker가 클라이언트를 인증하는 방법이 결정됩니다. MQTT broker는 첫 번째 지정된 메서드를 사용하여 클라이언트의 자격 증명을 인증하려고 시도하고 일치 항목을 찾거나 끝에 도달할 때까지 지정된 메서드를 반복합니다.

각 메서드에 대해 MQTT 브로커는 먼저 클라이언트의 자격 증명이 해당 메서드에 관련이 있는지 확인합니다. 예를 들어 SAT 인증에는 K8S-SAT으로 시작하는 사용자 이름이 필요하며 X.509 인증에는 클라이언트 인증서가 필요합니다. 클라이언트의 자격 증명이 관련된 경우 MQTT 브로커는 자격 증명이 유효한지 확인합니다. 자세한 내용은 인증 방법 구성 섹션을 참조하세요.

사용자 지정 인증의 경우 MQTT 브로커는 사용자 지정 인증 서버와의 통신 실패를 관련 없는 자격 증명으로 처리합니다. 이 동작을 사용하면 사용자 지정 인증 서버에 연결할 수 없는 경우 MQTT broker가 다른 방법으로 대체됩니다.

인증 흐름은 다음 경우에 종료됩니다.

• 다음 조건 중 하나가 true:
  • 클라이언트의 자격 증명은 메서드 중 하나에 대해 관련되고 유효합니다.
  • 클라이언트의 자격 증명은 아무 메서드와도 관련이 없습니다.
  • 클라이언트의 자격 증명은 메서드 중 하나에 대해 관련이 있지만 유효하지 않습니다.
• MQTT 브로커는 인증 흐름의 결과에 따라 클라이언트에 대한 액세스를 부여하거나 거부합니다.

예시:

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

앞의 예제에서는 사용자 지정 및 SAT를 지정합니다. 클라이언트가 연결되면 MQTT broker는 지정된 메서드 를 순서대로 사용자 지정한 다음 SAT를 사용하여 클라이언트를 인증하려고 시도합니다.

1. MQTT 브로커는 클라이언트의 자격 증명이 사용자 지정 인증에 유효한지 확인합니다. 사용자 지정 인증은 외부 서버에 의존하여 자격 증명의 유효성을 확인하므로 broker는 사용자 지정 인증과 관련된 모든 자격 증명을 고려하고 사용자 지정 인증 서버에 전달합니다.
2. 사용자 지정 인증 서버가 Pass 또는 Fail 결과로 응답하면 인증 흐름이 종료됩니다. 그러나 사용자 지정 인증 서버를 사용할 수 없는 경우 MQTT 브로커는 SAT가 다음인 지정된 나머지 메서드로 되돌아갑니다.
3. MQTT 브로커는 자격 증명을 SAT 자격 증명으로 인증하려고 합니다.

사용자 지정 인증 서버를 사용할 수 없고 모든 후속 메서드가 제공된 자격 증명과 관련이 없다고 판단하는 경우 broker는 클라이언트 연결을 거부합니다.

인증 방법 구성

X.509, SAT 또는 사용자 지정과 같은 인증 방법을 인증 정책에 추가할 수 있습니다.

정책에 인증 방법을 추가하려면 다음을 수행합니다.

포털

1. Azure Portal에서 IoT Operations 인스턴스로 이동합니다.

2. 구성 요소 아래에서 MQTT Broker를 선택합니다.

3. 인증 탭을 선택합니다.

4. 기존 인증 정책을 선택하거나 새 인증 정책을 만듭니다.

5. 메서드 추가를 선택하여 새 메서드를 추가합니다.

6. 드롭다운 목록에서 메서드 유형을 선택한 다음 세부 정보 추가를 선택하여 메서드를 구성합니다.

   

Bicep

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'
            }
          }
        }
      }
    ]
  }
}

Azure CLI를 사용하여 Bicep 파일을 배포합니다.

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

Kubernetes(미리 보기)

섹션에 새 메서드를 추가하여 인증 정책에 대한 BrokerAuthentication 리소스를 authenticationMethods 수정합니다. 다음 예제에서는 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

구성을 변경하려면 이 BrokerAuthentication 리소스의 설정을 수정 authenticationMethods 한 다음 , 를 사용하여 kubectl apply배포합니다.

각 인증 옵션에 대한 자세한 내용은 각 방법에 대한 다음 섹션을 참조하세요.

Azure Key Vault를 구성하고 워크로드 ID를 사용하도록 설정하여 보안 설정을 사용하도록 설정하는 방법에 대한 자세한 내용은 Azure IoT Operations 배포에서 보안 설정 사용을 참조하세요.

X.509

팁

X.509 인증을 구성하는 방법에 대한 엔드투엔드 예제는 자습서: TLS, X.509 클라이언트 인증 및 ABAC(특성 기반 액세스 제어) 권한 부여를 참조하세요.

X.509 인증을 사용하면 MQTT 브로커는 신뢰할 수 있는 CA 인증서를 사용하여 클라이언트 인증서 의 유효성을 검사합니다. 이 신뢰할 수 있는 CA는 루트 또는 중간 CA일 수 있습니다. 브로커는 신뢰할 수 있는 CA 인증서에 대해 클라이언트 인증서 체인을 확인합니다. 체인이 유효한 경우 클라이언트가 인증됩니다.

신뢰할 수 있는 CA 인증서로 X.509 인증을 사용하려면 다음 요구 사항을 충족해야 합니다.

• TLS: X.509는 TLS 클라이언트 인증서 를 사용하므로 X.509 인증을 사용하는 포트에 대해 TLS를 사용하도록 설정해야 합니다.
• 키 알고리즘: EC 및 RSA 키는 모두 지원되지만 체인의 모든 인증서는 동일한 키 알고리즘을 사용해야 합니다.
• 형식: CA 인증서는 PEM 형식이어야 합니다.

팁

PEM 형식은 인증서 및 키에 대한 일반적인 형식입니다. PEM 파일은 같은 -----BEGIN CERTIFICATE----- 헤더가 있는 base64로 인코딩된 ASCII 파일입니다 -----BEGIN EC PRIVATE KEY-----.

다른 형식의 인증서가 있는 경우 OpenSSL을 사용하여 PEM으로 변환할 수 있습니다. 자세한 내용은 인증서를 적절한 형식으로 변환하는 방법을 참조 하세요.

신뢰할 수 있는 CA 인증서 가져오기

프로덕션 설정에서 CA 인증서는 조직의 PKI(공개 키 인프라) 또는 공용 인증 기관에서 제공합니다.

테스트를 위해 OpenSSL을 사용하여 자체 서명된 CA 인증서를 만듭니다. 예를 들어 다음 명령을 실행하여 RSA 키, 고유 이름 CN=Contoso Root CA Cert및 365일의 유효성을 사용하여 자체 서명된 CA 인증서를 생성합니다.

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

인증서를 관리하는 편리한 도구인 Step CLI와 동일한 명령은 다음과 같습니다.

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

이러한 명령은 PEM 형식의 CA 인증서 ca.pem 및 프라이빗 키를 ca-key.pem 만듭니다. X.509 인증을 위해 CA 인증서 ca.pem 를 MQTT 브로커로 가져올 수 있습니다.

신뢰할 수 있는 CA 인증서 가져오기

X.509 인증을 시작하려면 신뢰할 수 있는 CA 인증서를 네임스페이스의 ConfigMap azure-iot-operations 으로 가져옵니다. 신뢰할 수 있는 CA 인증서 ca.pem 를 ConfigMap으로 client-ca가져오려면 다음을 실행합니다.

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

이 예제에서는 키 아래에 CA 인증서를 ca.pem가져옵니다. MQTT broker는 ConfigMap의 모든 CA 인증서를 신뢰하므로 키 이름은 무엇이든 될 수 있습니다.

루트 CA 인증서를 제대로 가져왔는지 확인하려면 kubectl describe configmap을 실행합니다. 결과는 PEM 인증서 파일의 동일한 base64 인코딩을 보여줍니다.

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 인증 방법 구성

신뢰할 수 있는 CA 인증서를 가져오면 BrokerAuthentication 리소스에 인증 방법으로 추가하여 X.509 클라이언트 인증을 사용하도록 설정합니다. 이 리소스가 TLS 사용 수신기 포트에 연결되어 있는지 확인합니다.

포털

1. Azure Portal에서 IoT Operations 인스턴스로 이동합니다.

2. 구성 요소 아래에서 MQTT Broker를 선택합니다.

3. 인증 탭을 선택합니다.

4. 기존 인증 정책을 선택하거나 새 인증 정책을 만듭니다.

5. 메서드 추가를 선택하여 새 메서드를 추가합니다.

6. 드롭다운 목록에서 X.509 메서드 유형을 선택한 다음, 세부 정보 추가를 선택하여 메서드를 구성합니다.

7. X.509 인증 세부 정보 창에서 JSON 형식을 사용하여 신뢰할 수 있는 CA 인증서 ConfigMap 이름을 지정합니다.

   {
       "trustedClientCaCert": "<TRUSTED_CA_CONFIGMAP>"
   }
   

   신뢰할 수 있는 CA 인증서를 포함하는 ConfigMap의 이름으로 바꿉 <TRUSTED_CA_CONFIGMAP> 니다. 예들 들어 "trustedClientCaCert": "client-ca"입니다.

   

8. 필요에 따라 X.509 인증서를 사용하여 클라이언트에 대한 권한 부여 특성을 추가합니다. 자세한 내용은 권한 부여에 대한 인증서 특성을 참조하세요.

9. 적용을 선택하여 변경 내용을 저장합니다.

Bicep

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
          // }
        }
      }
    ]
  }
}

신뢰할 수 있는 CA 인증서를 포함하는 ConfigMap의 이름으로 바꿉 <TRUSTED_CA_CONFIGMAP> 니다. 예들 들어 client-ca입니다.

Azure CLI를 사용하여 Bicep 파일을 배포합니다.

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

Kubernetes(미리 보기)

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

신뢰할 수 있는 CA 인증서를 포함하는 ConfigMap의 이름으로 바꿉 <TRUSTED_CA_CONFIGMAP> 니다. 예들 들어 client-ca입니다.

선택 사항: 권한 부여를 위한 인증서 특성

인증서 속성에 따라 클라이언트에 권한을 부여하기 위해 BrokerAuthentication 리소스에서 X.509 특성을 지정할 수 있습니다. 특성은 필드에 정의 authorizationAttributes 됩니다.

예시:

포털

Azure Portal에서 X.509 인증 방법을 구성할 때 X.509 인증 세부 정보 창에 권한 부여 특성을 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"
      }
    }
  }
}

Bicep

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(미리 보기)

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

이 예제에서는 고유 이름을 가진 루트 CA 또는 고유 이름의 CN = Contoso Root CA Cert, OU = Engineering, C = US 중간 CA에서 발급한 인증서가 있는 모든 클라이언트가 나열된 CN = Contoso Intermediate CA 특성을 받습니다. 또한 스마트 팬 클라이언트 인증서는 이와 관련된 특성을 받습니다.

특성에 대한 일치는 항상 리프 클라이언트 인증서에서 시작한 다음 체인을 따라 이동합니다. 특성 할당은 첫 번째 일치 후 중지됩니다. 이전 예제에서는 smart-fan에 중간 인증서 CN = Contoso Intermediate CA가 있더라도 연결된 특성을 얻지 못합니다.

X.509 인증서를 이러한 특성과 함께 사용하여 클라이언트에 권한 부여 규칙을 적용할 수 있습니다. 자세한 내용은 X.509 인증을 사용하는 클라이언트 권한 부여를 참조하세요.

수신기 포트에 X.509 인증 사용

신뢰할 수 있는 CA 인증서를 가져오고 BrokerAuthentication 리소스를 구성한 후 TLS 사용 수신기 포트에 연결합니다. X.509 인증은 클라이언트 인증서 유효성 검사를 위해 TLS를 사용하므로 이 단계는 중요합니다.

TLS 사용 수신기 포트를 얻으려면 포트에 대해 TLS 수동 인증서 관리 사용 및 포트에 대한 TLS 자동 인증서 관리 사용을 참조하세요.

참고 항목

브로커 수신기 포트에서 TLS를 사용하도록 설정한다는 것은 브로커가 TLS 암호화에 서버 인증서를 사용한다는 것을 의미합니다. 클라이언트는 이 포트에 연결할 때 해당 보안 저장소에 서명된 CA 인증서를 사용하여 서버 인증서를 신뢰해야 합니다. 이 프로세스를 신뢰 배포 또는 트러스트 묶음이라고 합니다. 서버 유효성 검사와 클라이언트 유효성 검사의 차이점을 이해하는 것이 중요합니다.

• 클라이언트 유효성 검사: MQTT broker(서버)는 X.509 클라이언트 인증을 위해 필드에 지정된 신뢰할 수 있는 CA 인증서에 trustedClientCaCert 대해 클라이언트 인증서를 확인합니다.
• 서버 유효성 검사: 클라이언트(예: mosquitto 또는 MQTTX)는 신뢰 저장소의 신뢰할 수 있는 CA 인증서에 대해 MQTT broker의 서버 인증서를 확인합니다. mosquitto 클라이언트의 경우 매개 변수를 --cafile 사용하여 CA 인증서 파일을 지정합니다. MQTTX의 경우 설정에서 신뢰 저장소에 CA 인증서를 추가합니다.

X.509 인증을 사용하도록 설정한 후 클라이언트가 해당 신뢰 저장소에 서버 쪽 CA 인증서를 사용하여 브로커의 서버 인증서를 신뢰하는지 확인합니다. 서버 쪽 CA 인증서 신뢰와 필드에 지정된 trustedClientCaCert 클라이언트 인증에 사용되는 클라이언트 쪽 CA 인증서를 혼동하지 마세요.

전체 예제 는 자습서: TLS, X.509 클라이언트 인증 및 ABAC(특성 기반 액세스 제어) 권한 부여를 참조하세요.

X.509 클라이언트 인증서를 사용하여 MQTT 브로커에 mosquitto 클라이언트 연결

mosquitto와 같은 클라이언트는 TLS 및 X.509 클라이언트 인증을 사용하여 MQTT broker에 연결할 수 있는 두 개의 파일이 필요합니다.

• --cert 매개 변수는 클라이언트 인증서 PEM 파일을 지정합니다. 이 파일에는 MQTT 브로커가 전체 인증서 체인을 빌드하는 데 도움이 되는 중간 인증서도 포함되어야 합니다.
• --key 매개 변수는 클라이언트 프라이빗 키 PEM 파일을 지정합니다.

MQTT broker가 자체 서명된 CA 인증서를 사용하여 TLS 서버 인증서 --cafile 를 발급하는 경우 매개 변수가 필요합니다. 이 파일에는 mosquitto 클라이언트가 TLS를 통해 연결할 때 broker의 서버 인증서의 유효성을 검사하는 데 사용하는 CA 인증서(신뢰 번들이라고도 함)가 포함되어 있습니다. MQTT broker의 서버 인증서 발급자를 시스템 루트 저장소(예: 잘 알려진 공용 CA)의 일부인 경우 매개 변수를 --cafile 생략할 수 있습니다.

예시:

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 브로커 X.509 클라이언트 인증 흐름 이해

클라이언트 인증 단계는 다음과 같습니다.

1. X.509 클라이언트 인증이 켜지면 연결 클라이언트는 클라이언트 인증서와 중간 인증서를 제공해야 MQTT broker가 구성된 신뢰할 수 있는 인증서 중 하나에 루트된 인증서 체인을 빌드할 수 있습니다.
2. 부하 분산 장치는 프런트 엔드 broker 중 하나에 통신을 보냅니다.
3. 프런트 엔드 broker가 클라이언트 인증서를 받으면 구성된 인증서 중 하나에 루트가 되는 인증서 체인을 빌드하려고 합니다. 프런트 엔드 broker가 체인을 성공적으로 빌드하고 제공된 체인이 확인되면 TLS 핸드셰이크가 완료됩니다. 연결 클라이언트는 TLS 채널을 통해 프런트 엔드에 MQTT 패킷을 보낼 수 있습니다.
4. TLS 채널이 열려 있지만 클라이언트 인증 또는 권한 부여가 아직 완료되지 않았습니다.
5. 그런 다음 클라이언트는 CONNECT 패킷을 MQTT 브로커로 보냅니다.
6. CONNECT 패킷은 프런트 엔드로 다시 라우팅됩니다.
7. 프런트 엔드는 CONNECT 패킷의 인증 데이터 및 TLS 핸드셰이크 중에 제공된 클라이언트 인증서 체인과 같이 클라이언트가 지금까지 제시한 모든 자격 증명을 수집합니다.
8. 프런트 엔드는 이러한 자격 증명을 인증 서비스로 보냅니다. 인증 서비스는 인증서 체인을 다시 한 번 확인하고 체인에 있는 모든 인증서의 주체 이름을 수집합니다.
9. 인증 서비스는 구성된 권한 부여 규칙을 사용하여 연결 클라이언트에 어떤 특성이 있는지 확인합니다. 이러한 특성은 CONNECT 패킷 자체를 포함하여 클라이언트에서 실행할 수 있는 작업을 결정합니다.
10. 인증 서비스는 프런트 엔드 broker에 대한 결정을 반환합니다.
11. 프런트 엔드 broker는 클라이언트 특성과 연결할 수 있는지를 알고 있습니다. 이 경우 MQTT 연결이 완료되고 클라이언트는 권한 부여 규칙에 따라 MQTT 패킷을 계속 보내고 받을 수 있습니다.

Kubernetes 서비스 계정 토큰

Kubernetes SAT(서비스 계정 토큰)는 Kubernetes 서비스 계정과 연결된 JSON 웹 토큰입니다. 클라이언트는 자체 인증을 위해 MQTT 브로커에 SAT를 제공합니다.

MQTT 브로커는 GKE 사용자가 Kubernetes의 새 서비스 계정 토큰에 대해 알아야 하는 바인딩된 서비스 계정 토큰을 사용합니다. 게시물의 눈에 띄는 기능은 다음과 같습니다.

Kubernetes 1.13에서 시작되고 1.21의 기본 형식이 되는 바인딩된 토큰은 레거시 토큰의 제한된 기능 등을 모두 처리합니다.

• 토큰 자체는 훔치고 오용하기가 더 어렵습니다. 시간이 제한되고, 대상 그룹에 바인딩되고, 개체에 바인딩됩니다.
• 표준화된 형식인 OIDC(OpenID Connect)를 전체 OIDC 검색과 함께 채택하므로 서비스 공급자가 이를 더 쉽게 수락할 수 있습니다.
• 새 Kubelet 프로젝션된 볼륨 유형을 사용하여 Pod에 보다 안전하게 배포됩니다.

broker는 Kubernetes 토큰 검토 API를 사용하여 토큰을 확인합니다. Kubernetes TokenRequestProjection 기능을 사용하도록 설정하여 지정 audiences 합니다(1.21 이후 기본값). 이 기능을 사용하도록 설정하지 않으면 SAT를 사용할 수 없습니다.

서비스 계정 만들기

SAT를 만들려면 먼저 서비스 계정을 만듭니다. 다음 명령은 mqtt-client라는 서비스 계정을 만듭니다.

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

선택 사항: 권한 부여를 위한 특성 추가

SAT를 통해 인증하는 클라이언트는 필요에 따라 권한 부여 정책에 사용할 특성으로 주석이 추가된 서비스 계정을 가질 수 있습니다. 이러한 주석을 다른 주석과 구분하기 위해 접두사로 aio-broker-auth/ 시작합니다.

다음을 사용하여 kubectl annotate서비스 계정에 주석을 달 수 있습니다.

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

또는 서비스 계정 매니페스트 파일에 주석을 추가할 수 있습니다.

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>

자세한 내용은 Kubernetes 서비스 계정 토큰을 사용하는 클라이언트 권한 부여를 참조하세요.

SAT(서비스 계정 토큰) 인증 사용

authenticationMethods BrokerAuthentication 리소스의 설정을 수정하여 유효한 인증 방법으로 지정 ServiceAccountToken 합니다. audiences는 토큰에 대한 유효한 대상 그룹 목록을 지정합니다. MQTT 브로커 서비스를 식별하는 고윳값을 선택합니다. 하나 이상의 대상 그룹을 지정해야 하며 모든 SAT는 지정된 대상 그룹 중 하나와 일치해야 합니다.

포털

1. Azure Portal에서 IoT Operations 인스턴스로 이동합니다.
2. 구성 요소 아래에서 MQTT Broker를 선택합니다.
3. 인증 탭을 선택합니다.
4. 기존 인증 정책을 선택하거나 새 인증 정책을 만듭니다.
5. 메서드 추가를 선택하여 새 메서드를 추가합니다.
6. 드롭다운 목록에서 Kubernetes SAT 메서드 유형을 선택한 다음 세부 정보 추가를 선택하여 메서드를 구성합니다.

Bicep

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'
          ]
        }
      }
    ]
  }
}

Azure CLI를 사용하여 Bicep 파일을 배포합니다.

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

Kubernetes(미리 보기)

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

kubectl apply를 사용하여 변경 내용을 적용합니다. 변경 내용을 적용하는 데 몇 분 정도 걸릴 수 있습니다.

SAT 인증 테스트

SAT 인증은 MQTT v5 향상된 인증 필드를 사용합니다. 클라이언트는 향상된 인증 방법과 K8S-SAT 향상된 인증 데이터를 토큰으로 설정해야 합니다.

예를 들어 mosquitto를 사용하는 경우(간결하게 하기 위해 생략된 일부 필드):

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

<TOKEN> 서비스 계정 토큰은 다음과 같습니다. 테스트 토큰을 가져오려면 다음을 실행합니다.

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

<SERVICE_ACCOUNT> 다음은 만든 서비스 계정의 이름이며 <AUDIENCE> BrokerAuthentication 리소스에 구성된 대상 그룹 중 하나입니다.

SAT 인증을 사용하도록 Kubernetes Pod를 구성하는 방법에 대한 예제는 클러스터 내의 기본 수신기에 연결을 참조하세요.

Pod 구성 serviceAccountName 에서 필드는 사용 중인 토큰과 연결된 서비스 계정과 일치해야 하며 serviceAccountToken.audience 필드는 BrokerAuthentication 리소스에 구성된 필드 중 audiences 하나여야 합니다.

서비스 계정 토큰 새로 고침

서비스 계정 토큰은 제한된 시간 동안 유효하며 expirationSeconds로 구성됩니다. 그러나 Kubernetes는 만료되기 전에 토큰을 자동으로 새로 고칩니다. 토큰은 백그라운드에서 새로 고쳐지고 클라이언트는 토큰을 다시 가져오는 것 이외의 다른 작업을 수행할 필요가 없습니다.

예를 들어 클라이언트가 테스트 SAT 인증 예제와 같이 볼륨으로 탑재된 토큰을 사용하는 Pod인 경우 동일한 경로 /var/run/secrets/tokens/broker-sat에서 최신 토큰을 사용할 수 있습니다. 새 연결을 만들 때 클라이언트는 최신 토큰을 가져와서 인증하는 데 사용할 수 있습니다. 또한 클라이언트에는 최신 토큰을 가져오고 연결을 다시 시도하여 MQTT 무단 오류를 처리하는 메커니즘이 있어야 합니다.

사용자 지정 인증

사용자 지정 인증을 사용하여 제공된 인증 방법 이상으로 클라이언트 인증을 확장합니다. 서비스는 API를 준수하는 한 무엇이든 될 수 있으므로 플러그 가능합니다.

클라이언트가 사용자 지정 인증을 사용하도록 설정된 MQTT Broker에 연결하면 broker는 클라이언트의 자격 증명을 사용하여 사용자 지정 인증 서버에 HTTPS 요청을 보냅니다. 그런 다음 서버는 클라이언트의 권한 부여 특성을 포함하여 승인 또는 거부로 응답합니다.

사용자 지정 인증 서비스 만들기

사용자 지정 인증 서버는 MQTT 브로커와 별도로 구현되고 배포됩니다.

샘플 사용자 지정 인증 서버 및 지침은 GitHub에서 확인할 수 있습니다. 이 샘플을 템플릿으로 사용하고 사용자 지정 인증 논리를 구현하기 위한 시작 지점으로 사용합니다.

API

MQTT 브로커와 사용자 지정 인증 서버 간의 API는 사용자 지정 인증에 대한 API 사양을 따릅니다. OpenAPI 사양은 GitHub에서 확인할 수 있습니다.

TLS 암호화를 사용하는 HTTPS가 필요합니다.

MQTT 브로커는 중요한 클라이언트 자격 증명이 포함된 요청을 사용자 지정 인증 서버로 보냅니다. 이러한 자격 증명을 보호하려면 MQTT 브로커와 사용자 지정 인증 서버 간의 통신을 TLS로 암호화해야 합니다.

사용자 지정 인증 서버는 서버 인증서를 제공해야 하며 MQTT 브로커에는 서버 인증서의 유효성을 검사하기 위한 신뢰할 수 있는 루트 CA 인증서가 있어야 합니다. 필요에 따라 사용자 지정 인증 서버에서 자체 인증을 위해 클라이언트 인증서를 제시하려면 MQTT 브로커가 필요할 수 있습니다.

수신기에 대한 사용자 지정 인증 사용

authenticationMethods BrokerAuthentication 리소스의 설정을 수정하여 유효한 인증 방법으로 지정 Custom 합니다. 그런 다음 사용자 지정 인증 서버와 통신하는 데 필요한 매개 변수를 지정합니다.

이 예제에서는 가능한 모든 매개 변수를 보여줍니다. 필요한 정확한 매개 변수는 각 사용자 지정 서버의 요구 사항에 따라 달라집니다.

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

인증 사용 중지

테스트를 위해 broker 수신기 포트에 대한 인증을 사용하지 않도록 설정할 수 있습니다. 프로덕션 환경에는 인증을 사용하지 않도록 설정하는 것이 좋습니다.

포털

1. Azure Portal에서 IoT Operations 인스턴스로 이동합니다.
2. 구성 요소 아래에서 MQTT Broker를 선택합니다.
3. 목록에서 편집할 broker 수신기를 선택합니다.
4. 인증을 사용하지 않도록 설정하려는 포트에서 인증 드롭다운에서 없음을 선택합니다.

Bicep

인증을 사용하지 않도록 설정하려면 BrokerListener 리소스 설정에서 ports 생략 authenticationRef 합니다.

Kubernetes(미리 보기)

인증을 사용하지 않도록 설정하려면 BrokerListener 리소스 설정에서 ports 생략 authenticationRef 합니다.

자격 증명이 만료된 후 클라이언트 연결 끊기

MQTT 브로커는 자격 증명이 만료된 클라이언트의 연결을 해제합니다. 자격 증명이 만료된 후에는 다음을 포함하여 MQTT 브로커 프런트 엔드에 연결하는 모든 클라이언트의 연결이 해제됩니다.

• SAT가 만료되면 SAT를 통해 인증된 클라이언트의 연결이 해제됩니다.
• 클라이언트 인증서가 만료되면 X.509를 통해 인증된 클라이언트의 연결이 해제됩니다.
• 사용자 지정 인증 서버에서 반환된 만료 시간에 따라 사용자 지정 인증을 통해 인증된 클라이언트의 연결이 해제됩니다.

연결이 해제되면 클라이언트의 네트워크 연결이 종료됩니다. 클라이언트는 MQTT DISCONNECT 패킷을 받지 않지만 브로커는 클라이언트의 연결을 끊었다는 메시지를 기록합니다.

SAT 및 사용자 지정 인증을 통해 인증된 MQTT v5 클라이언트는 초기 자격 증명이 만료되기 전에 새 자격 증명으로 다시 인증할 수 있습니다. X.509 클라이언트는 다시 인증할 수 없으며 TLS 계층에서 인증이 수행되므로 연결을 다시 설정해야 합니다.

클라이언트는 이유 ReAuth와 함께 MQTT v5 AUTH 패킷을 전송하여 다시 인증할 수 있습니다.

SAT 클라이언트는 method: K8S-SAT, data: <token> 필드가 있는 AUTH 클라이언트를 전송합니다. 사용자 지정 인증 클라이언트는 사용자 지정 인증 서버에서 요구하는 대로 메서드 및 데이터 필드를 설정합니다.

재인증에 성공하면 클라이언트의 자격 증명 만료 시간이 새 자격 증명의 만료 시간으로 업데이트되고 브로커가 Success AUTH 패킷으로 응답합니다. 사용자 지정 인증 서버를 사용할 수 없는 등의 일시적인 문제로 인해 인증에 실패하면 Broker가 ContinueAuthentication AUTH 패킷으로 응답합니다. 클라이언트는 나중에 다시 시도할 수 있습니다. 기타 인증에 실패하면 브로커는 DISCONNECT 패킷을 전송하고 클라이언트의 네트워크 연결을 종료합니다.

관련 콘텐츠

• BrokerListener 리소스 정보
• BrokerListener에 대한 권한 부여 구성
• 자습서: TLS, X.509 클라이언트 인증 및 ABAC(특성 기반 액세스 제어) 권한 부여