許可とアクセス制御の管理
Trident保護では、KubernetesモデルのRole-Based Access Control(RBAC;ロールベースアクセス制御)が使用されます。デフォルトでは、Trident保護は単一のシステムネームスペースとそれに関連付けられたデフォルトのサービスアカウントを提供します。多数のユーザがいる組織や、特定のセキュリティニーズがある組織では、Trident保護のRBAC機能を使用して、リソースやネームスペースへのアクセスをより細かく制御できます。
クラスタ管理者は、常にデフォルトのネームスペース内のリソースにアクセスできます trident-protect
。また、他のすべてのネームスペース内のリソースにもアクセスできます。リソースとアプリケーションへのアクセスを制御するには、追加の名前空間を作成し、それらの名前空間にリソースとアプリケーションを追加する必要があります。
デフォルトの名前空間にアプリケーションデータ管理CRSを作成することはできないことに注意して `trident-protect`ください。アプリケーションデータ管理CRSは、アプリケーションネームスペース内に作成する必要があります(ベストプラクティスとして、アプリケーションデータ管理CRSは、関連付けられているアプリケーションと同じネームスペースに作成します)。
管理者のみが、次のような特権Trident保護カスタムリソースオブジェクトへのアクセス権を持つ必要があります。
RBACを使用して、権限付きオブジェクトへのアクセスを管理者に制限することを推奨します。 |
RBACでリソースおよびネームスペースへのアクセスを制御する方法の詳細については、を参照して "Kubernetes RBACのドキュメント"ください。
サービスアカウントの詳細については、を参照して "Kubernetesサービスアカウントのドキュメント"ください。
例:2つのユーザグループのアクセスを管理する
たとえば、ある組織に、クラスタ管理者、エンジニアリングユーザのグループ、およびマーケティングユーザのグループがあるとします。クラスタ管理者は次のタスクを実行して、engineeringグループとmarketingグループがそれぞれのネームスペースに割り当てられたリソースのみにアクセスできる環境を作成します。
手順1:各グループのリソースを含むネームスペースを作成する
ネームスペースを作成すると、リソースを論理的に分離し、それらのリソースにアクセスできるユーザをより細かく制御できます。
-
engineeringグループの名前空間を作成します。
kubectl create ns engineering-ns
-
marketingグループの名前空間を作成します。
kubectl create ns marketing-ns
ステップ2:各ネームスペースのリソースとやり取りするための新しいサービスアカウントを作成する
作成する新しい名前空間にはそれぞれデフォルトのサービスアカウントが付属していますが、将来必要に応じてPrivilegesをグループ間でさらに分割できるように、ユーザーのグループごとにサービスアカウントを作成する必要があります。
-
engineeringグループのサービスアカウントを作成します。
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:RoleBindingオブジェクトを作成して、ClusterRoleオブジェクトを新しい各サービスアカウントにバインドする
Trident保護をインストールすると、デフォルトの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へのユーザーアクセスを許可する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オブジェクトを使用できる必要があります。また、割り当てられた名前空間以外のリソースにアクセスしたり、アクセスできない新しいリソースを作成したりすることはできません。