Kubernetes RBAC モデルと、SQL Server 2019 ビッグ データ クラスターを管理するユーザーとサービス アカウントへの影響
重要
Microsoft SQL Server 2019 ビッグ データ クラスターのアドオンは廃止されます。 SQL Server 2019 ビッグ データ クラスターのサポートは、2025 年 2 月 28 日に終了します。 ソフトウェア アシュアランス付きの SQL Server 2019 を使用する既存の全ユーザーはプラットフォームで完全にサポートされ、ソフトウェアはその時点まで SQL Server の累積更新プログラムによって引き続きメンテナンスされます。 詳細については、お知らせのブログ記事と「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 など) を使用して、クラスター ポッド、サービス、高可用性、監視などのプロビジョニングを調整します。ビッグ データ クラスターのデプロイが開始されると (azdata bdc create など)、Azure Data CLI (azdata) が次のことを行います。
- 指定された名前空間が存在するかどうかが確認されます。
- 存在しない場合は作成され、
MSSQL_CLUSTERラベルが適用されます。 sa-mssql-controllerサービス アカウントが作成されます。- クラスター レベルのアクセス許可ではなく、名前空間またはプロジェクトに対する完全なアクセス許可を持つ
<namespaced>-adminロールが作成されます。 - そのロールに対して、そのサービス アカウントのロールの割り当てが作成されます。
これらの手順が完了すると、コントロール プレーン ポッドがプロビジョニングされ、サービス アカウントによって残りのビッグ データ クラスターがデプロイされます。
そのため、デプロイするユーザーには次のアクセス許可が必要です。
- クラスター内の名前空間を一覧表示する (1)。
- 新規または既存の名前空間にラベルを適用する (2)。
- サービス アカウント
sa-mssql-controller、<namespaced>-adminロールおよびロール バインディングを作成する (3-5)。
既定の admin ロールにはこれらのアクセス許可がないため、ビッグ データ クラスターをデプロイするユーザーには、少なくとも名前空間レベルの管理者アクセス許可が必要です。
ポッドとノードのメトリック コレクションに必要なクラスターのロール
SQL Server 2019 CU5 以降、ポッドとノードのメトリックを収集するには、Telegraf にクラスター全体のロール アクセス許可を持つサービス アカウントが必要です。 デプロイ (または既存のデプロイのアップグレード) 時に、必要なサービス アカウントとクラスターのロールの作成が試行されます。ただし、クラスターをデプロイしたり、アップグレードを実行したりするユーザーに十分なアクセス許可がない場合でも、デプロイまたはアップグレードは警告は生成されますが続行され、成功します。 この場合、ポッドとノードのメトリックは収集されません。 クラスターをデプロイするユーザーは、(デプロイまたはアップグレードの前または後に) クラスター管理者にロールとサービス アカウントの作成を依頼する必要があります。 それらが作成されると、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 サービス アカウントのアクセス許可が自動的に更新されます。 これらがポッドのデプロイとして作成されている場合、ポッドとノードのメトリックが収集されるまでに数分の遅延が発生します。
注意
SQL Server 2019 CU5 では、ポッドとノードのメトリックのコレクションを制御する 2 つの機能スイッチが導入されました。 既定では、これらのパラメーターは、既定値がオーバーライドされている OpenShift を除き、すべての環境ターゲットで true に設定されています。
これらの設定は、control.json デプロイ構成ファイルのセキュリティ セクションでカスタマイズできます。
"security": {
...
"allowNodeMetricsCollection": false,
"allowPodMetricsCollection": false
}
これらの設定が false に設定されている場合、BDC デプロイのワークフローでは、サービス アカウント、クラスター ロール、および Telegraf のバインディングの作成が試行されます。
ビッグ データ クラスター ポッド内からの既定のサービス アカウントの使用
より厳密なセキュリティ モデルのために、SQL Server 2019 CU5 では、BDC ポッド内における既定の Kubernetes サービス アカウント用の既定の資格情報によるマウントが無効になりました。 これは、CU5 以降のバージョンで、新しいデプロイとアップデートされたデプロイの両方に適用されます。
ポッド内の資格情報トークンを使用し、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"
関連するコンテンツ
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示