Kubernetes RBAC 모델 및 SQL Server 2019 빅 데이터 클러스터를 관리하는 사용자 및 서비스 계정에 미치는 영향
중요
Microsoft SQL Server 2019 빅 데이터 클러스터 추가 기능이 사용 중지됩니다. SQL Server 2019 빅 데이터 클러스터에 대한 지원은 2025년 2월 28일에 종료됩니다. 자세한 내용은 Microsoft SQL Server 플랫폼의 빅 데이터 옵션을 참조하세요.
이 문서에서는 빅 데이터 클러스터를 관리하는 사용자의 권한 요구 사항과 빅 데이터 클러스터 내부로부터 기본 서비스 계정 및 Kubernetes 액세스에 관한 의미 체계를 설명합니다.
참고
Kubernetes RBAC 모델에 대한 추가 리소스는 Using RBAC Authorization - Kubernetes(RBAC 인증 사용 - Kubernetes) 및 Using RBAC to define and apply permissions - OpenShift(RBAC를 사용하여 권한 정의 및 적용 - OpenShift)를 참조하세요.
배포에 필요한 역할
SQL Server 2019 빅 데이터 클러스터는 서비스 계정(예: sa-mssql-controller
또는 master
)을 사용하여 클러스터 Pod, 서비스, 고가용성, 모니터링 등의 프로비전을 오케스트레이션합니다. BDC 배포가 시작되면(예: azdata bdc create
) Azure Data CLI(azdata
)가 다음 작업을 수행합니다.
- 제공된 네임스페이스가 존재하는지 확인합니다.
- 존재하지 않는 경우 네임스페이스를 만들고
MSSQL_CLUSTER
레이블을 적용합니다. sa-mssql-controller
서비스 계정을 만듭니다.- 네임스페이스 또는 프로젝트에 대한 모든 권한을 가지되 클러스터 수준 권한은 없는
<namespaced>-admin
역할을 만듭니다. - 역할에 대해 해당 서비스 계정의 역할 할당을 만듭니다.
위 단계가 완료되면 컨트롤 플레인 Pod이 프로비저닝되고 서비스 계정이 빅 데이터 클러스터의 나머지 부분을 배포합니다.
결과적으로 배포하는 사용자에게는 다음과 같은 권한이 있어야 합니다.
- 클러스터에 있는 네임스페이스를 나열합니다(1).
- 레이블을 사용하여 새 네임스페이스 또는 기존 네임스페이스를 패치합니다(2).
- 서비스 계정
sa-mssql-controller
,<namespaced>-admin
역할 및 역할 바인딩을 만듭니다(3~5).
기본 admin
역할에는 이러한 권한이 없으므로 빅 데이터 클러스터를 배포하는 사용자에게는 최소한 네임스페이스 수준 관리자 권한이 있어야 합니다.
Pod 및 노드 메트릭 수집에 필요한 클러스터 역할
SQL Server 2019 CU5부터, Telegraf에는 Pod 및 노드 메트릭을 수집하기 위해 클러스터 전체 역할 권한이 있는 서비스 계정이 필요합니다. 배포(또는 기존 배포의 업그레이드) 중에 필요한 서비스 계정 및 클러스터 역할을 만들려고 시도합니다. 단, 클러스터를 배포하거나 업그레이드를 수행하는 사용자에게 충분한 권한이 없는 경우에도 배포 또는 업그레이드는 경고와 함께 계속 진행되고 성공합니다. 이 경우 Pod 및 노드 메트릭이 수집되지 않습니다. 클러스터를 배포하는 사용자는 클러스터 관리자에게 배포 또는 업그레이드 전 또는 후에 역할 및 서비스 계정을 만들도록 요청해야 합니다. 이렇게 만든 역할 및 서비스 계정은 BDC가 사용합니다.
다음은 필요한 아티팩트를 만드는 방법을 보여 주는 단계입니다.
아래 내용이 포함된 metrics-role.yaml 파일을 만듭니다. <clusterName> 자리 표시자를 빅 데이터 클러스터의 이름으로 바꿔야 합니다.
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: <clusterName>:cr-mssql-metricsdc-reader rules: - apiGroups: - '*' resources: - pods - nodes/stats - nodes/proxy verbs: - get --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: <clusterName>:crb-mssql-metricsdc-reader roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: <clusterName>:cr-mssql-metricsdc-reader subjects: - kind: ServiceAccount name: sa-mssql-metricsdc-reader namespace: <clusterName>
클러스터 역할과 클러스터 역할 바인딩을 만듭니다.
kubectl create -f metrics-role.yaml
서비스 계정, 클러스터 역할 및 클러스터 역할 바인딩은 BDC 배포 전 또는 후에 만들 수 있습니다. Kubernetes는 Telegraf 서비스 계정의 권한을 자동으로 업데이트합니다. 이것이 Pod 배포로 생성된 경우 Pod 및 노드 메트릭이 수집되기 전까지 몇 분 정도 지연 시간이 발생합니다.
참고
SQL Server 2019 CU5부터 Pod 및 노드 메트릭의 수집을 제어하는 두 가지 기능 스위치가 도입되었습니다. 기본적으로 이 매개 변수는 기본값이 재정의되는 OpenShift를 제외하고 모든 환경 대상에서 true로 설정됩니다.
이러한 설정은 control.json
배포 구성 파일의 보안 섹션에서 사용자 지정할 수 있습니다.
"security": {
…
"allowNodeMetricsCollection": false,
"allowPodMetricsCollection": false
}
이러한 설정이 false
로 설정된 경우 BDC 배포 워크플로는 서비스 계정, 클러스터 역할 및 Telegraf에 대한 바인딩을 만들려고 시도하지 않습니다.
BDC Pod 내부로부터 기본 서비스 계정 사용
보안 모델을 강화하기 위해 SQL Server 2019 CU5에서는 BDC Pod 내 기본 Kubernetes 서비스 계정에 대한 자격 증명을 기본적으로 탑재하지 않도록 설정했습니다. 이는 CU5 이상 버전의 새 배포와 업그레이드된 배포 모두에 적용됩니다.
Pod 내부의 자격 증명 토큰을 사용하여 Kubernetes API 서버에 액세스할 수 있으며 권한 수준은 Kubernetes 권한 부여 정책 설정에 따라 달라집니다. 이전 CU5 동작으로 되돌려야 하는 특정 사용 사례가 있는 경우 CU6에서는 배포 시에만 자동 탑재를 켤 수 있도록 새 기능 스위치를 도입했습니다. 이렇게 하려면 control.json 구성 배포 파일을 사용하고 automountServiceAccountToken 을 true 로 설정합니다. Azure Data CLI(azdata
)를 사용하여 다음 명령을 실행해 control.json 사용자 지정 구성 파일에서 이 설정을 업데이트합니다.
azdata bdc config replace -c custom-bdc/control.json -j "$.security.automountServiceAccountToken=true"