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

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

10/29/2025 共同作成者

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

クラスタ管理者は常にデフォルトのリソースにアクセスできます。 `trident-protect`名前空間だけでなく、他のすべての名前空間のリソースにもアクセスできます。リソースとアプリケーションへのアクセスを制御するには、追加の名前空間を作成し、それらの名前空間にリソースとアプリケーションを追加する必要があります。

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

次のような特権Trident Protect カスタムリソースオブジェクトにアクセスできるのは管理者のみです。

AppVault: バケット認証情報データが必要
AutoSupportBundle: メトリック、ログ、その他の機密性の高いTrident保護データを収集します
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

マーケティングサービスアカウントのシークレットを作成します。

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: ClusterRoleオブジェクトを各新しいサービスアカウントにバインドするためのRoleBindingオブジェクトを作成する

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

手順

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 へのアクセスを許可する AppVault とシークレットの組み合わせ YAML ファイルを作成して適用します。たとえば、次のCRはユーザーにAppVaultへのアクセスを許可します。 eng-user :

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 オブジェクトを使用でき、割り当てられた名前空間外のリソースにアクセスしたり、アクセス権のない新しいリソースを作成したりすることはできません。