最小限の特権で Azure Arc 対応データ サービスを操作する

Arc 対応データ サービスを最小限の特権で操作することは、セキュリティ上のベスト プラクティスです。 必要なタスクの実行に必要な特定のアクセス許可を、ユーザーとサービス アカウントに付与するだけです。 これらの特定のアクセス許可を付与するために使用できるロールベースのアクセス制御モデルが、Azure と Kubernetes の両方に用意されています。 この記事では、最小限の特権のセキュリティを適用する必要がある一般的なシナリオについて説明します。

Note

この記事では、arc という名前の名前空間を使用します。 別の名前を使用する場合は、全体で同じ名前を使用してください。 この記事では、例として kubectl CLI ユーティリティを使用します。 ただし、Kubernetes API を使用する任意のツールまたはシステムを使用できます。

Azure Arc データ コントローラーをデプロイする

Azure Arc データ コントローラーをデプロイするには、Kubernetes 名前空間の作成やクラスター ロールの作成など、高い特権と見なすことができる何らかのアクセス許可が必要です。 以下の手順に従って、データ コントローラーのデプロイを複数の手順に分けることができます。各手順は、必要なアクセス許可を持つユーザーまたはサービス アカウントによって実行できます。 この職務の分離により、プロセス内の各ユーザーまたはサービス アカウントには必要なアクセス許可のみがあり、それ以上の権限はないことが確実になります。

データ コントローラーが作成される名前空間をデプロイする

この手順では、Arc データ コントローラーがデプロイされる新しい専用 Kubernetes 名前空間を作成します。 この手順を最初に実行することが非常に重要です。以下の手順では、付与されるアクセス許可のスコープとしてこの新しい名前空間を使用するためです。

このアクションの実行に必要なアクセス許可:

• 名前空間
  • 作成
  • 編集 (OpenShift クラスターに必要な場合)

次のようなコマンドを実行して、データ コントローラーが作成される新しい専用の名前空間を作成します。

kubectl create namespace arc

OpenShift を使用している場合は、kubectl edit namespace <name of namespace> を使用して名前空間の openshift.io/sa.scc.supplemental-groups 注釈と openshift.io/sa.scc.uid-range 注釈を編集する必要があります。 これらの既存の注釈を、これらの特定の UID および fsGroup の ID または範囲に合わせて変更します。

openshift.io/sa.scc.supplemental-groups: 1000700001/10000
openshift.io/sa.scc.uid-range: 1000700001/10000

デプロイするサービス アカウントとユーザー/グループにアクセス許可を割り当てる

この手順では、サービス アカウントを作成し、そのサービス アカウントにロールとクラスター ロールを割り当てて、必要最小限の特権で Arc データ コントローラーをデプロイするジョブでサービス アカウントを使用できるようにします。

このアクションの実行に必要なアクセス許可:

• サービス アカウント
  • 作成
• Role
  • 作成
• ロール バインド
  • 作成
• クラスター ロール
  • 作成
• クラスター ロールのバインド
  • 作成
• サービス アカウントに付与されるすべてのアクセス許可 (詳細については、下の arcdata-deployer.yaml を参照)

arcdata-deployer.yaml のコピーを保存し、ファイル内のプレースホルダー {{NAMESPACE}} を前の手順で作成した名前空間 (たとえば、arc) に置き換えます。 次のコマンドを実行し、編集したファイルを使用してデプロイ担当者のサービス アカウントを作成します。

kubectl apply --namespace arc -f arcdata-deployer.yaml

ブートストラップ ジョブとデータ コントローラーを作成するためのアクセス許可をユーザーに付与する

このアクションの実行に必要なアクセス許可:

• Role
  • 作成
• ロール バインド
  • 作成

arcdata-installer.yaml のコピーを保存し、ファイル内のプレースホルダー {{INSTALLER_USERNAME}} を、アクセス許可を付与する先のユーザーの名前に置き換えます (例: john@contoso.com)。 必要に応じて、他のユーザーやグループなどのロール バインドの対象を追加します。 次のコマンドを実行して、編集済みのファイルを使用してインストール担当者のアクセス許可を作成します。

kubectl apply --namespace arc -f arcdata-installer.yaml

ブートストラップ ジョブをデプロイする

このアクションの実行に必要なアクセス許可:

• 前の手順で arcdata-installer-role ロールを割り当てられているユーザー

次のコマンドを実行して、データ コントローラーをデプロイするための準備手順を実行するブートストラップ ジョブを作成します。

kubectl apply --namespace arc -f https://raw.githubusercontent.com/microsoft/azure_arc/main/arc_data_services/deploy/yaml/bootstrapper.yaml

Arc データ コントローラーを作成する

これで、データ コントローラー自体を作成する準備が整いました。

まず、テンプレート ファイルのコピーをコンピューターのローカルに作成し、設定の一部を変更できるようにします。

メトリックとログ ダッシュボードのユーザー名とパスワードを作成する

ファイルの上部で、メトリックとログのダッシュボードに対する認証に使用するユーザー名とパスワードを管理者として指定できます。 安全なパスワードを選択し、これらの特権を必要とするユーザーとのみ共有します。

Kubernetes シークレットは base64 でエンコードされた文字列として格納されます。1 つはユーザー名、1 つはパスワード用です。

echo -n '<your string to encode here>' | base64
# echo -n 'example' | base64

必要に応じて、ログとメトリック ダッシュボードの SSL/TLS 証明書を作成できます。 「Kubernetes ネイティブ ツールのデプロイ時の SSL/TLS 証明書の指定」の手順に従ってください。

データ コントローラーの構成を編集する

必要に応じて、データ コントローラーの構成を編集します。

必須

• location: データ コントローラーに関する メタデータ が格納される Azure の場所に変更します。 利用可能なリージョンの一覧を参照してください。
• logsui-certificate-secret: ログ UI 証明書の Kubernetes クラスターで作成されたシークレットの名前。
• metricsui-certificate-secret: メトリック UI 証明書の Kubernetes クラスターで作成されたシークレットの名前。

推奨: 見直してできれば既定値を変更する

これらの値を見直し、デプロイを更新します。

• storage..className: データ コントローラーのデータ ファイルとログ ファイルに使用するストレージ クラス。 Kubernetes クラスターで使用できるストレージ クラスがわからない場合は、次のコマンドを実行します。kubectl get storageclass 既定値は default で、既定のストレージ クラスではなく、default という名前の既存のストレージ クラスがあることを前提としています。 注: 目的のストレージ クラスに設定する className 設定は 2 つあります - 1 つはデータ用、1 つはログ用です。

• serviceType: LoadBalancer を使用していない場合は、サービス タイプを NodePort に変更します。

• Security: Azure Red Hat OpenShift または Red Hat OpenShift コンテナー プラットフォームの場合は、データ コントローラーの yaml ファイルで、security: 設定を下記の値に置き換えます。

  security:
    allowDumps: false
    allowNodeMetricsCollection: false
    allowPodMetricsCollection: false
  

オプション

次の設定は省略可能です。

• name: データ コントローラーの既定の名前は arc ですが、必要に応じて変更できます。
• displayName: ファイルの先頭にある name 属性と同じ値に設定します。
• registry: Microsoft Container Registry が既定です。 Microsoft Container Registry からイメージを取得してプライベート コンテナー レジストリにプッシュしている場合は、ここでレジストリの IP アドレスまたは DNS 名を入力します。
• dockerRegistry: 必要に応じてプライベート コンテナー レジストリからイメージをプルするために使用するシークレット。
• repository: Microsoft Container Registry 上の既定のリポジトリは arcdata です。 プライベート コンテナー レジストリを使用している場合は、Azure Arc 対応データ サービスのコンテナー イメージが格納されているフォルダーまたはリポジトリのパスを入力します。
• imageTag: 現在の最新バージョンのタグはテンプレートに既定で設定されていますが、古いバージョンを使用する場合は変更できます。
• logsui-certificate-secret: ログ UI 証明書の Kubernetes クラスターで作成されたシークレットの名前。
• metricsui-certificate-secret: メトリック UI 証明書の Kubernetes クラスターで作成されたシークレットの名前。

次の例は、完成したデータ コントローラーの yaml を示しています。

apiVersion: v1
data:
  password: <your base64 encoded password>
  username: <your base64 encoded username>
kind: Secret
metadata:
  name: metricsui-admin-secret
type: Opaque

---

apiVersion: v1
data:
  password: <your base64 encoded password>
  username: <your base64 encoded username>
kind: Secret
metadata:
  name: logsui-admin-secret
type: Opaque

---

apiVersion: arcdata.microsoft.com/v5
kind: DataController
metadata:
  name: arc-dc
spec:
  credentials:
    dockerRegistry: arc-private-registry # Create a registry secret named 'arc-private-registry' if you are going to pull from a private registry instead of MCR.
    serviceAccount: sa-arc-controller
  docker:
    imagePullPolicy: Always
    imageTag: v1.29.0_2024-04-09
    registry: mcr.microsoft.com
    repository: arcdata
  infrastructure: other # Must be a value in the array [alibaba, aws, azure, gcp, onpremises, other]
  security:
    allowDumps: true # Set this to false if deploying on OpenShift
    allowNodeMetricsCollection: true # Set this to false if deploying on OpenShift
    allowPodMetricsCollection: true # Set this to false if deploying on OpenShift
  services:
  - name: controller
    port: 30080
    serviceType: LoadBalancer # Modify serviceType based on your Kubernetes environment
  settings:
    ElasticSearch:
      vm.max_map_count: "-1"
    azure:
      connectionMode: indirect # Only indirect is supported for Kubernetes-native deployment for now.
      location: eastus # Choose a different Azure location if you want
      resourceGroup: <your resource group>
      subscription: <your subscription GUID>
    controller:
      displayName: arc-dc
      enableBilling: true
      logs.rotation.days: "7"
      logs.rotation.size: "5000"
  storage:
    data:
      accessMode: ReadWriteOnce
      className: default # Use default configured storage class or modify storage class based on your Kubernetes environment
      size: 15Gi
    logs:
      accessMode: ReadWriteOnce
      className: default # Use default configured storage class or modify storage class based on your Kubernetes environment
      size: 10Gi

編集したファイルをローカル コンピューターに保存し、次のコマンドを実行してデータ コントローラーを作成します。

kubectl create --namespace arc -f <path to your data controller file>

#Example
kubectl create --namespace arc -f data-controller.yaml

作成状態の監視

コントローラーの作成が完了するまでに数分かかります。 次のコマンドを使用して、別のターミナル ウィンドウで進行状況を監視できます。

kubectl get datacontroller --namespace arc

kubectl get pods --namespace arc

次のようなコマンドを実行して、特定のポッドの作成状態やログを確認することもできます。 これは特に、何らの問題をトラブルシューティングするのに役立ちます。

kubectl describe pod/<pod name> --namespace arc
kubectl logs <pod name> --namespace arc

#Example:
#kubectl describe pod/control-2g7bl --namespace arc
#kubectl logs control-2g7b1 --namespace arc

関連するコンテンツ

Azure Arc データ コントローラーを作成するための追加オプションがいくつかあります。

試してみたい場合 AKS、Amazon EKS、または GKE 上、または Azure VM 内で Azure Arc Jumpstart をすぐに開始できます。

• Azure portal を使用して、直接接続モードでデータ コントローラーを作成する
• CLI を使用して、間接接続モードでデータ コントローラーを作成する
• Azure Data Studio を使用して、間接接続モードでデータ コントローラーを作成する
• Azure Data Studio で Jupyter ノートブックを使用して、Azure portal から間接接続モードでデータ コントローラーを作成する
• kubectl や oc などの Kubernetes ツールを使用して、間接接続モードでデータ コントローラーを作成する