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

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

배포에 필요한 역할

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

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

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

따라서 배포하는 사용자에게 다음을 수행할 수 있는 권한이 있어야 합니다.

• 클러스터의 네임스페이스를 나열합니다(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 및 노드 메트릭이 수집되는 데 몇 분 정도 지연됩니다.

배포 구성 파일의 보안 섹션에서 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 사용자 지정 구성 파일에서 이 설정을 업데이트합니다.

azdata bdc config replace -c custom-bdc/control.json -j "$.security.automountServiceAccountToken=true"

Related content

• RBAC 권한 부여 사용 - Kubernetes
• RBAC를 사용하여 권한 정의 및 적용 - OpenShift