MQTT 브로커 권한 부여 구성
Important
이 페이지에는 미리 보기 상태인 Kubernetes 배포 매니페스트를 사용하여 Azure IoT Operations 구성 요소를 관리하기 위한 지침이 포함되어 있습니다. 이 기능은 몇 가지 제한 사항을 제공하며 프로덕션 워크로드에 사용하면 안 됩니다.
베타, 미리 보기로 제공되거나 아직 일반 공급으로 릴리스되지 않은 Azure 기능에 적용되는 약관은 Microsoft Azure 미리 보기에 대한 추가 사용 약관을 참조하세요.
권한 부여 정책은 클라이언트가 브로커에서 수행할 수 있는 작업(예: 토픽 연결, 게시 또는 구독)을 결정합니다. BrokerAuthorization 리소스에서 하나 이상의 권한 부여 정책을 사용하도록 MQTT 브로커를 구성합니다. 각 ‘BrokerAuthorization’ 리소스에는 권한 부여 정책에 대한 보안 주체 및 리소스를 지정하는 규칙 목록이 포함되어 있습니다.
BrokerAuthorization을 BrokerListener에 연결
BrokerListener를 BrokerAuthorization 리소스에 연결하려면 BrokerListener 리소스 설정에서 ports
필드를 지정 authorizationRef
합니다. BrokerAuthentication 과 마찬가지로 BrokerAuthorization 리소스는 여러 BrokerListener 포트에 연결할 수 있습니다. 권한 부여 정책은 연결된 모든 수신기 포트에 적용됩니다. 그러나 BrokerAuthentication과 비교하면 한 가지 주요 차이점이 있습니다.
Important
BrokerAuthorization 구성을 수신기 포트에 적용하려면 하나 이상의 BrokerAuthentication도 해당 수신기 포트에 연결해야 합니다.
BrokerListener에 대한 자세한 내용은 BrokerListener 리소스를 참조하세요.
권한 부여 규칙
권한 부여를 구성하려면 Kubernetes 클러스터에서 BrokerAuthorization 리소스를 만듭니다. 다음 섹션에서는 사용자 이름, 특성, X.509 인증서 및 KUbernetes SAT(서비스 계정 토큰)를 사용하는 클라이언트에 대한 권한 부여를 구성하는 방법의 예를 제공합니다. 사용 가능한 설정 목록은 Broker 권한 부여 API 참조를 참조하세요.
다음 예제에서는 사용자 이름과 특성을 모두 사용하여 BrokerAuthorization 리소스를 만드는 방법을 보여줍니다.
Azure Portal에서 IoT Operations 인스턴스로 이동합니다.
구성 요소 아래에서 MQTT Broker를 선택합니다.
Authorization 탭을 선택합니다.
기존 인증 정책을 선택하거나 권한 부여 정책 만들기를 선택하여 새 인증 정책을 만듭니다.
이 broker 권한 부여를 사용하면 클라이언트 ID temperature-sensor
가 있는 클라이언트 또는 humidity-sensor
값 contoso
이 있는 특성 organization
이 city
seattle
있는 클라이언트에서 다음을 수행할 수 있습니다.
- 브로커에 연결합니다.
- 클라이언트 ID 및 조직으로 범위가 지정된 원격 분석 토픽에 메시지를 게시합니다. 예:
temperature-sensor
는/telemetry/temperature-sensor
및/telemetry/contoso
에 게시할 수 있습니다.humidity-sensor
는/telemetry/humidity-sensor
및/telemetry/contoso
에 게시할 수 있습니다.some-other-username
은/telemetry/contoso
에 게시할 수 있습니다.
- 소속 조직으로 범위가 지정된 명령 토픽을 구독합니다. 예:
temperature-sensor
는/commands/contoso
를 구독할 수 있습니다.some-other-username
은/commands/contoso
를 구독할 수 있습니다.
권한 부여에 사용자 이름 사용
권한 부여에 MQTT 사용자 이름을 사용하려면 아래 principals.usernames
의 배열로 지정합니다. 그러나 인증 방법에 따라 사용자 이름이 확인되지 않을 수 있습니다.
- Kubernetes SAT - 사용자 이름은 향상된 인증으로 MQTTv5에 대해 확인되지 않으므로 권한 부여에 사용하면 안 됩니다.
- X.509 - 사용자 이름은 인증서의 CN과 일치하며 권한 부여 규칙에 사용할 수 있습니다.
- 사용자 지정 - 사용자 지정 인증이 사용자 이름의 유효성을 검사하는 경우에만 사용자 이름을 권한 부여 규칙에 사용해야 합니다.
보안 문제를 방지하려면 확인할 수 있는 경우에만 브로커 권한 부여에 MQTT 사용자 이름을 사용합니다.
클라이언트 ID에 따라 액세스 제한 추가
principals
필드는 논리적 OR이므로 필드에 필드를 추가하여 clientIds
클라이언트 ID에 따라 액세스를 추가로 제한할 brokerResources
수 있습니다. 예를 들어 건물 번호로 시작하는 클라이언트 ID가 있는 클라이언트가 해당 건물로 범위가 지정된 토픽에 원격 분석을 연결하고 게시할 수 있도록 하려면 다음 구성을 사용합니다.
권한 부여 정책에 대한 broker 권한 부여 규칙에서 다음 구성을 사용합니다.
[
{
"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"
}
]
}
}
]
여기서 메서드에서 clientIds
Connect
설정되지 않은 경우 클라이언트 ID가 있는 클라이언트는 특성이 설정된 building22
경우 연결할 building
수 있습니다building23
. 필드를 추가 clientIds
하면 클라이언트 ID가 시작 building22
되거나 building23
연결할 수 있는 클라이언트만 있습니다. 이렇게 하면 클라이언트에 올바른 특성이 있는 것뿐만 아니라 클라이언트 ID가 예상된 패턴과 일치하게 됩니다.
X.509 인증을 사용하는 클라이언트에 권한 부여
인증에 X.509 인증서를 사용하는 클라이언트는 인증서 또는 체인의 발급 인증서에 있는 X.509 속성을 기반으로 리소스에 액세스할 수 있는 권한을 부여받을 수 있습니다.
특성 사용
클라이언트의 인증서, 루트 CA 또는 중간 CA의 속성을 기반으로 규칙을 만들려면 BrokerAuthorization 리소스에서 X.509 특성을 정의합니다. 자세한 내용은 인증서 특성을 참조하세요.
클라이언트 인증서 주체 일반 이름을 사용자 이름으로 사용
‘client’ 인증서 주체 CN(일반 이름)만을 기반으로 권한 부여 정책을 만들려면 CN을 기반으로 규칙을 만듭니다.
예를 들어 클라이언트에 주체가 CN = smart-lock
인 인증서가 있는 경우 해당 사용자 이름은 smart-lock
입니다. 여기에서 시작하여 일반적인 방법으로 권한 부여 정책을 만듭니다.
Kubernetes 서비스 계정 토큰을 사용하는 클라이언트에 권한 부여
SAT에 대한 권한 부여 특성은 서비스 계정 주석의 일부로 설정됩니다. 예를 들어 이름이 group
이고 값이 authz-sat
인 권한 부여 특성을 추가하려면 다음 명령을 실행합니다.
kubectl annotate serviceaccount mqtt-client aio-broker-auth/group=authz-sat
특성 주석은 aio-broker-auth/
로 시작하여 다른 주석과 구분되어야 합니다.
애플리케이션에 authz-sat
라는 권한 부여 특성이 있으므로 clientId
또는 username
을 제공할 필요가 없습니다. 해당 ‘BrokerAuthorization’ 리소스는 이 특성을 보안 주체로 사용합니다. 예를 들면 다음과 같습니다.
권한 부여 정책에 대한 Broker 권한 부여 규칙에서 다음 구성을 사용합니다.
[
{
"brokerResources": [
{
"clientIds": [],
"method": "Connect",
"topics": []
},
{
"clientIds": [],
"method": "Publish",
"topics": [
"odd-numbered-orders"
]
},
{
"clientIds": [],
"method": "Subscribe",
"topics": [
"orders"
]
}
],
"principals": {
"attributes": [
{
"group": "authz-sat"
}
]
}
}
]
예제를 통해 자세히 알아보려면 Dapr 클라이언트를 사용하여 권한 부여 정책 설정을 참조하세요.
상태 저장소
MQTT broker는 클라이언트가 상태를 저장하는 데 사용할 수 있는 상태 저장소 를 제공합니다. 상태 저장소를 고가용성으로 구성할 수도 있습니다.
상태 저장소를 사용하는 클라이언트에 대한 권한 부여를 설정하려면 다음 권한을 제공합니다.
- 시스템 키 값 저장소
$services/statestore/_any_/command/invoke/request
토픽에 게시할 수 있는 권한 - 응답 토픽(초기 게시 중에 매개 변수로 설정됨)
<response_topic>/#
을 구독할 수 있는 권한
상태 저장 키
상태 저장소는 토픽의 MQTT 브로커를 통해 액세스됩니다 statestore/v1/FA9AE35F-2F64-47CD-9BFF-08E2B32A0FE8/command/invoke
.
클라이언트는 토픽에 액세스할 수 있으므로 MQTT broker brokerResources
구성 섹션에서 키 및 액세스 수준을 stateStoreResources
지정할 수 있습니다.
섹션 형식은 stateStoreResources
액세스 수준, 패턴 표시기 및 패턴으로 구성됩니다.
stateStoreResources
권한 부여 정책에 대한 규칙에 섹션을 포함합니다.
"stateStoreResources": [
{
"method": "", // Values: read, write, readwrite
"keyType": "", //Values: string, pattern, binary. Default is pattern
"keys": [
// List of patterns to match
]
},
]
method
필드는 액세스 수준을 지정합니다.
- 읽기 액세스는 < a0/>를 사용하여
read
지정되고, 쓰기 액세스 권한과 함께write
지정readwrite
됩니다. - 액세스 수준이 필요합니다.
- 읽기 액세스 수준은 다음의
get
작업을 의미합니다keynotify
. - 쓰기 액세스 수준은 ,
del
및vdel
.의set
작업을 의미합니다.
keyType
필드는 키 일치 유형을 지정합니다.
pattern
glob 스타일 패턴 일치를 사용하려면string
정확히 일치하려면(예: 키에 패턴으로 일치시킬 수 있는 문자가 포함된 경우)*
?
[0-9]
binary
이진 키와 일치하려면
keys
필드는 일치시킬 키를 지정합니다. 키는 Glob 스타일 패턴, 토큰 대체 또는 정확한 문자열로 지정할 수 있습니다.
- Glob 스타일 예제:
colors/*
: "colors/" 접두사 아래의 모든 키number[0-9]
: "number0"에서 "number9"로의 모든 키char?
: 접두사 "char"와 한 자리 접미사가 있는 키(예: "charA")*
: 모든 키에 대한 모든 액세스 권한.
- 또한 상태 저장 키는 키 형식이고 중괄호가
pattern
이 목적을 위해 예약된 경우 토큰 대체를 지원합니다. 토큰 대체 예제:clients/{principal.clientId}/*
usernames/{principal.username}/*
rooms/{principal.attributes.room}/*
다음은 상태 저장소 리소스를 작성하는 방법의 예입니다.
권한 부여 정책에 대한 Broker 권한 부여 규칙에서 유사한 구성을 추가합니다.
[
{
"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"
]
}
]
}
]
권한 부여 업데이트
브로커 권한 부여 리소스는 런타임에 업데이트할 수 있으며 다시 시작할 필요가 없습니다. 정책 업데이트 시 연결된 모든 클라이언트의 연결이 끊어집니다. 정책 유형 변경도 지원됩니다.
kubectl edit brokerauthorization my-authz-policies
권한 부여 사용 안 함
- Azure Portal에서 IoT Operations 인스턴스로 이동합니다.
- 구성 요소 아래에서 MQTT Broker를 선택합니다.
- 목록에서 편집할 broker 수신기를 선택합니다.
- 권한 부여를 사용하지 않도록 설정하려는 포트에서 권한 부여 드롭다운에서 없음을 선택합니다.
MQTT 3.1.1에서 권한 없는 게시
MQTT 3.1.1에서는 게시가 거부되면 프로토콜 버전이 오류 코드 반환을 지원하지 않으므로 클라이언트가 오류 없이 PUBACK을 받습니다. MQTTv5는 게시가 거부되면 이유 코드 135(권한 없음)가 포함된 PUBACK을 반환합니다.