Skip to main content
본 한국어 번역은 사용자 편의를 위해 제공되는 기계 번역입니다. 영어 버전과 한국어 버전이 서로 어긋나는 경우에는 언제나 영어 버전이 우선합니다.

Trident Protect 권한 및 액세스 제어 관리

기여자 netapp-aruldeepa

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 서비스 계정 문서" .

예: 두 그룹의 사용자에 대한 액세스 관리

예를 들어, 어떤 조직에 클러스터 관리자, 엔지니어링 사용자 그룹, 마케팅 사용자 그룹이 있다고 가정해 보겠습니다. 클러스터 관리자는 엔지니어링 그룹과 마케팅 그룹이 각자의 네임스페이스에 할당된 리소스에만 액세스할 수 있는 환경을 만들기 위해 다음 작업을 완료합니다.

1단계: 각 그룹의 리소스를 포함할 네임스페이스 만들기

네임스페이스를 만들면 리소스를 논리적으로 분리하고 해당 리소스에 누가 액세스할 수 있는지 더 효과적으로 제어할 수 있습니다.

단계
  1. 엔지니어링 그룹에 대한 네임스페이스를 만듭니다.

    kubectl create ns engineering-ns
  2. 마케팅 그룹을 위한 네임스페이스를 만듭니다.

    kubectl create ns marketing-ns

2단계: 각 네임스페이스의 리소스와 상호 작용하기 위한 새 서비스 계정 만들기

새로 만든 네임스페이스마다 기본 서비스 계정이 제공되지만, 나중에 필요한 경우 그룹 간에 권한을 더욱 세분화할 수 있도록 각 사용자 그룹에 대한 서비스 계정을 만들어야 합니다.

단계
  1. 엔지니어링 그룹에 대한 서비스 계정을 만듭니다.

    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단계: ClusterRole 객체를 각각의 새 서비스 계정에 바인딩하기 위해 RoleBinding 객체를 만듭니다.

Trident Protect를 설치하면 기본 ClusterRole 개체가 생성됩니다. RoleBinding 객체를 생성하고 적용하여 이 ClusterRole을 서비스 계정에 바인딩할 수 있습니다.

단계
  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 및 비밀번호 조합 YAML 파일을 만들고 적용하여 사용자에게 AppVault에 대한 액세스 권한을 부여합니다. 예를 들어, 다음 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 개체를 사용할 수 있어야 하며, 할당된 네임스페이스 외부의 리소스에 액세스하거나 액세스 권한이 없는 새 리소스를 만들 수 없습니다.