Kubernetes RBAC 모델 및 SQL Server 2019 빅 데이터 클러스터를 관리하는 사용자 및 서비스 계정에 미치는 영향

  • 아티클

Important

Microsoft SQL Server 2019 빅 데이터 클러스터 추가 기능이 사용 중지됩니다. SQL Server 2019 빅 데이터 클러스터에 대한 지원은 2025년 2월 28일에 종료됩니다. Software Assurance를 사용하는 SQL Server 2019의 모든 기존 사용자는 플랫폼에서 완전히 지원되며, 소프트웨어는 지원 종료 시점까지 SQL Server 누적 업데이트를 통해 계속 유지 관리됩니다. 자세한 내용은 공지 블로그 게시물 및 Microsoft SQL Server 플랫폼의 빅 데이터 옵션을 참조하세요.

이 문서에서는 빅 데이터 클러스터를 관리하는 사용자에 대한 권한 요구 사항과 빅 데이터 클러스터 내에서의 기본 서비스 계정 및 Kubernetes 액세스와 관련된 의미 체계를 설명합니다.

참고 항목

Kubernetes RBAC 모델에 대한 추가 리소스를 확인하려면 RBAC 권한 부여 사용 - Kubernetes 및 RBAC를 사용하여 권한 정의 및 적용 - OpenShift를 참조하세요.

배포에 필요한 역할

SQL Server 2019 빅 데이터 클러스터는 서비스 계정(예: sa-mssql-controller 또는 master)을 사용하여 클러스터 Pod, 서비스, 고가용성, 모니터링 등의 프로비전을 오케스트레이션합니다. 빅 데이터 클러스터 배포가 시작되면(예: azdata bdc create), Azure Data CLI(azdata)가 다음 작업을 수행합니다.

  1. 제공된 네임스페이스가 존재하는지 확인합니다.
  2. 존재하지 않는 경우 하나를 만들고 MSSQL_CLUSTER 레이블을 적용합니다.
  3. sa-mssql-controller 서비스 계정을 만듭니다.
  4. 네임스페이스 또는 프로젝트에 대한 전체 권한이 있지만 클러스터 수준 권한은 없는 <namespaced>-admin 역할을 만듭니다.
  5. 역할에 대해 해당 서비스 계정의 역할 할당을 만듭니다.

이러한 단계가 완료되면 컨트롤 플레인 Pod가 프로비저닝되고 서비스 계정이 나머지 빅 데이터 클러스터를 배포합니다. 

결과적으로 배포하는 사용자에게는 다음과 같은 권한이 있어야 합니다.

  • 클러스터의 현재 네임스페이스를 나열합니다(1).
  • 레이블을 사용하여 신규 또는 기존 네임스페이스를 패치합니다(2).
  • 서비스 계정 sa-mssql-controller, <namespaced>-admin 역할 및 역할 바인딩을 만듭니다(3~5).

기본 admin 역할에는 이러한 권한이 없으므로 빅 데이터 클러스터를 배포하는 사용자에게는 최소한 네임스페이스 수준 관리자 권한이 있어야 합니다.

Pod 및 노드 메트릭 수집에 필요한 클러스터 역할

SQL Server 2019 CU5부터 Telegraf에서는 Pod 및 노드 메트릭을 수집하기 위해 클러스터 전체 역할 권한이 있는 서비스 계정이 필요합니다. 배포 중(또는 기존 배포 업그레이드)에는 배포에서 필요한 서비스 계정 및 클러스터 역할을 만들고자 시도하지만 클러스터를 배포하거나 업그레이드를 수행하는 사용자에게 충분한 권한이 없는 경우에는 경고와 함께 배포 또는 업그레이드가 계속 진행되며 결국 성공합니다. 이 경우 Pod 및 노드 메트릭이 수집되지 않습니다. 클러스터를 배포하는 사용자는 클러스터 관리자에게 역할 및 서비스 계정을 만들어 줄 것을 요청해야 합니다(배포 또는 업그레이드 이전이나 이후). 만들어진 후에는 BDC에서 이를 사용합니다.

필요한 아티팩트를 만드는 방법을 보여 주는 단계는 다음과 같습니다.

  1. 아래 콘텐츠로 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>

  2. 클러스터 역할과 클러스터 역할 바인딩을 만듭니다.

    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에 대한 바인딩을 만들고자 하는 시도를 하지 않습니다.

빅 데이터 클러스터 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"

관련 콘텐츠