リクエストされたアーティクルはご利用いただけません。このバージョンの製品で扱われていないか、関連する情報がこのバージョンのドキュメントで別に扱われています。検索 / 参照しなおすか、別のバージョンに戻る場合は、こちらをクリックしてください.

日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。

Trident Protectの認証とアクセス制御を管理する

02/25/2026

PDF

Trident Protectは、Kubernetesモデルのロールベースアクセス制御（RBAC）を使用します。デフォルトでは、Trident Protectは、単一のシステムネームスペースとそれに関連付けられたデフォルトのサービスアカウントを提供します。多数のユーザーを抱える組織や特定のセキュリティニーズを持つ組織の場合は、Trident Protectのロールベースアクセス制御機能を使用して、リソースとネームスペースへのアクセスをより細かく制御できます。

クラスタ管理者は常にdefault `trident-protect`ネームスペース内のリソースにアクセスでき、他のすべてのネームスペース内のリソースにもアクセスできます。リソースとアプリケーションへのアクセスを制御するには、追加のネームスペースを作成し、それらのネームスペースにリソースとアプリケーションを追加する必要があります。

デフォルトの `trident-protect`ネームスペースでは、どのユーザーもアプリケーションデータ管理CRを作成できないことに注意してください。アプリケーションネームスペースにアプリケーションデータ管理CRを作成する必要があります（ベストプラクティスとして、関連付けられているアプリケーションと同じネームスペースにアプリケーションデータ管理CRを作成します）。

特権を持つTrident Protectカスタムリソースオブジェクトへのアクセスは、管理者のみが持つ必要があります。これには次のものが含まれます：

AppVault：バケット認証情報データが必要です
AutoSupportBundle：メトリクス、ログ、およびその他の機密性の高いTrident Protectデータを収集します
AutoSupportBundleSchedule：ログ収集スケジュールを管理します

ベストプラクティスとして、RBAC を使用して、特権オブジェクトへのアクセスを管理者に制限します。

RBACがリソースと名前空間へのアクセスをどのように制御するかの詳細については、 "Kubernetes RBAC ドキュメント"を参照してください。

サービスアカウントの詳細については、 "Kubernetes サービスアカウントのドキュメント"を参照してください。

例：2つのユーザーグループのアクセスを管理する

たとえば、組織にはクラスタ管理者、エンジニアリングユーザーのグループ、マーケティングユーザーのグループがあります。クラスタ管理者は、エンジニアリンググループとマーケティンググループがそれぞれの名前空間に割り当てられたリソースのみにアクセスできる環境を作成するために、次のタスクを実行します（：）

ステップ1：各グループのリソースを格納する名前空間を作成する

名前空間を作成すると、リソースを論理的に分離し、それらのリソースにアクセスできるユーザーをより適切に制御できるようになります。

手順

エンジニアリンググループの名前空間を作成します：
```
kubectl create ns engineering-ns
```
マーケティンググループのネームスペースを作成します：
```
kubectl create ns marketing-ns
```

ステップ2：各名前空間内のリソースとやり取りするための新しいサービスアカウントを作成する

作成する新しいネームスペースにはそれぞれデフォルトのサービスアカウントが付属しますが、将来必要に応じてグループ間で権限をさらに分割できるように、ユーザーグループごとにサービスアカウントを作成する必要があります。

手順

エンジニアリンググループのサービスアカウントを作成します：

apiVersion: v1
kind: ServiceAccount
metadata:
  name: eng-user
  namespace: engineering-ns

マーケティンググループのサービスアカウントを作成します：

apiVersion: v1
kind: ServiceAccount
metadata:
  name: mkt-user
  namespace: marketing-ns

ステップ3：新しいサービスアカウントごとにシークレットを作成する

サービスアカウントシークレットは、サービスアカウントでの認証に使用され、侵害された場合には簡単に削除して再作成できます。

手順

エンジニアリングサービスアカウントのシークレットを作成します：

apiVersion: v1
kind: Secret
metadata:
  annotations:
    kubernetes.io/service-account.name: eng-user
  name: eng-user-secret
  namespace: engineering-ns
type: kubernetes.io/service-account-token

marketingサービスアカウントのシークレットを作成します：

apiVersion: v1
kind: Secret
metadata:
  annotations:
    kubernetes.io/service-account.name: mkt-user
  name: mkt-user-secret
  namespace: marketing-ns
type: kubernetes.io/service-account-token

ステップ4：RoleBindingオブジェクトを作成して、ClusterRoleオブジェクトを各新しいサービスアカウントにバインドします

Trident Protectをインストールすると、デフォルトのClusterRoleオブジェクトが作成されます。このClusterRoleをサービスアカウントにバインドするには、RoleBindingオブジェクトを作成して適用します。

手順

ClusterRoleをエンジニアリングサービスアカウントにバインドします：

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: engineering-ns-tenant-rolebinding
  namespace: engineering-ns
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: trident-protect-tenant-cluster-role
subjects:
- kind: ServiceAccount
  name: eng-user
  namespace: engineering-ns

ClusterRoleをマーケティングサービスアカウントにバインドします：

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: marketing-ns-tenant-rolebinding
  namespace: marketing-ns
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: trident-protect-tenant-cluster-role
subjects:
- kind: ServiceAccount
  name: mkt-user
  namespace: marketing-ns

ステップ5：権限をテストする

権限が正しいことをテストします。

手順

エンジニアリングユーザーがエンジニアリングリソースにアクセスできることを確認します：

kubectl auth can-i --as=system:serviceaccount:engineering-ns:eng-user get applications.protect.trident.netapp.io -n engineering-ns

エンジニアリングユーザーがマーケティングリソースにアクセスできないことを確認します：

kubectl auth can-i --as=system:serviceaccount:engineering-ns:eng-user get applications.protect.trident.netapp.io -n marketing-ns

ステップ6：AppVaultオブジェクトへのアクセスを許可する

バックアップやスナップショットなどのデータ管理タスクを実行するには、クラスタ管理者が個々のユーザーにAppVaultオブジェクトへのアクセスを許可する必要があります。

手順

AppVaultとシークレットの組み合わせYAMLファイルを作成して適用し、ユーザーにAppVaultへのアクセス権を付与します。たとえば、次のCRは、ユーザー `eng-user`にAppVaultへのアクセス権を付与します：

apiVersion: v1
data:
  accessKeyID: <ID_value>
  secretAccessKey: <key_value>
kind: Secret
metadata:
  name: appvault-for-eng-user-only-secret
  namespace: trident-protect
type: Opaque
---
apiVersion: protect.trident.netapp.io/v1
kind: AppVault
metadata:
  name: appvault-for-eng-user-only
  namespace: trident-protect # Trident Protect system namespace
spec:
  providerConfig:
    azure:
      accountName: ""
      bucketName: ""
      endpoint: ""
    gcp:
      bucketName: ""
      projectID: ""
    s3:
      bucketName: testbucket
      endpoint: 192.168.0.1:30000
      secure: "false"
      skipCertValidation: "true"
  providerCredentials:
    accessKeyID:
      valueFromSecret:
        key: accessKeyID
        name: appvault-for-eng-user-only-secret
    secretAccessKey:
      valueFromSecret:
        key: secretAccessKey
        name: appvault-for-eng-user-only-secret
  providerType: GenericS3

ロール CR を作成して適用し、クラスター管理者が名前空間内の特定のリソースへのアクセスを許可できるようにします。例：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: eng-user-appvault-reader
  namespace: trident-protect
rules:
- apiGroups:
  - protect.trident.netapp.io
  resourceNames:
  - appvault-for-enguser-only
  resources:
  - appvaults
  verbs:
  - get

RoleBinding CR を作成して適用し、ユーザー eng-user に権限をバインドします。例：

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: eng-user-read-appvault-binding
  namespace: trident-protect
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: eng-user-appvault-reader
subjects:
- kind: ServiceAccount
  name: eng-user
  namespace: engineering-ns

権限が正しいことを確認してください。

すべての名前空間のAppVaultオブジェクト情報の取得を試みます：

kubectl get appvaults -n trident-protect --as=system:serviceaccount:engineering-ns:eng-user

次のような出力が表示されます。

Error from server (Forbidden): appvaults.protect.trident.netapp.io is forbidden: User "system:serviceaccount:engineering-ns:eng-user" cannot list resource "appvaults" in API group "protect.trident.netapp.io" in the namespace "trident-protect"

ユーザーがアクセス権限を持つようになったAppVault情報を取得できるかどうかをテストします：
```
kubectl auth can-i --as=system:serviceaccount:engineering-ns:eng-user get appvaults.protect.trident.netapp.io/appvault-for-eng-user-only -n trident-protect
```
次のような出力が表示されます。

yes

結果

AppVault権限を付与したユーザーは、承認されたAppVaultオブジェクトをアプリケーションデータ管理操作に使用できる必要があり、割り当てられた名前空間外のリソースにアクセスしたり、アクセス権のない新しいリソースを作成したりすることはできません。