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

許可とアクセス制御の管理

共同作成者

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

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

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

メモ

管理者のみが、次のような特権Trident保護カスタムリソースオブジェクトへのアクセス権を持つ必要があります。

  • * AppVault *:バケット資格情報データが必要です。

  • * AutoSupportBundle *:指標、ログ、その他の機密性の高いTridentデータを収集します。

  • * AutoSupportBundleSchedule *:ログ収集スケジュールを管理します。

RBACを使用して、権限付きオブジェクトへのアクセスを管理者に制限することを推奨します。

RBACでリソースおよびネームスペースへのアクセスを制御する方法の詳細については、を参照して "Kubernetes RBACのドキュメント"ください。

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

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

たとえば、ある組織に、クラスタ管理者、エンジニアリングユーザのグループ、およびマーケティングユーザのグループがあるとします。クラスタ管理者は次のタスクを実行して、engineeringグループとmarketingグループがそれぞれのネームスペースに割り当てられたリソースのみにアクセスできる環境を作成します。

手順1:各グループのリソースを含むネームスペースを作成する

ネームスペースを作成すると、リソースを論理的に分離し、それらのリソースにアクセスできるユーザをより細かく制御できます。

手順
  1. engineeringグループの名前空間を作成します。

    kubectl create ns engineering-ns
  2. marketingグループの名前空間を作成します。

    kubectl create ns marketing-ns

ステップ2:各ネームスペースのリソースとやり取りするための新しいサービスアカウントを作成する

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

手順
  1. engineeringグループのサービスアカウントを作成します。

    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: eng-user
      namespace: engineering-ns
  2. マーケティンググループのサービスアカウントを作成します。

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

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

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

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

    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
  2. マーケティングサービスアカウントのシークレットを作成します。

    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オブジェクトを作成して適用します。

手順
  1. 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
  2. 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:権限のテスト

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

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

    kubectl auth can-i --as=system:serviceaccount:engineering-ns:eng-user get applications.protect.trident.netapp.io -n engineering-ns
  2. エンジニアリングユーザーがマーケティングリソースにアクセスできないことを確認します。

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

手順6:AppVaultオブジェクトへのアクセスを許可する

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

手順
  1. 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
  2. 役割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
  3. 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
  4. 権限が正しいことを確認します。

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