Trident 보호 인증 및 액세스 제어를 관리합니다
Trident Protect는 역할 기반 액세스 제어(RBAC)의 Kubernetes 모델을 사용합니다. 기본적으로 Trident Protect는 단일 시스템 네임스페이스 및 연결된 기본 서비스 계정을 제공합니다. 조직에 많은 사용자 또는 특정 보안 요구 사항이 있는 경우 Trident Protect의 RBAC 기능을 사용하여 리소스 및 네임스페이스에 대한 액세스를 보다 세부적으로 제어할 수 있습니다.
클러스터 관리자는 항상 기본 네임스페이스의 리소스에 액세스할 수 trident-protect
있으며 다른 모든 네임스페이스의 리소스에 액세스할 수도 있습니다. 리소스 및 응용 프로그램에 대한 액세스를 제어하려면 추가 네임스페이스를 만들고 해당 네임스페이스에 리소스 및 응용 프로그램을 추가해야 합니다.
사용자는 기본 네임스페이스에 응용 프로그램 데이터 관리 CRS를 만들 수 trident-protect
없습니다. 응용 프로그램 네임스페이스에 응용 프로그램 데이터 관리 CRS를 만들어야 합니다(모범 사례로서 연결된 응용 프로그램과 동일한 네임스페이스에 응용 프로그램 데이터 관리 CRS를 만듭니다).
|
관리자만 권한이 있는 Trident Protect 사용자 지정 리소스 객체에 액세스할 수 있어야 합니다. 여기에는 다음이 포함됩니다.
가장 좋은 방법은 RBAC를 사용하여 권한이 있는 객체에 대한 액세스를 관리자에게 제한하는 것입니다. |
RBAC가 리소스 및 네임스페이스에 대한 액세스를 규제하는 방법에 대한 자세한 내용은 를 "Kubernetes RBAC 설명서"참조하십시오.
서비스 계정에 대한 자세한 내용은 을 "Kubernetes 서비스 계정 설명서"참조하십시오.
예: 두 사용자 그룹에 대한 액세스를 관리합니다
예를 들어, 조직에는 클러스터 관리자, 엔지니어링 사용자 그룹 및 마케팅 사용자 그룹이 있습니다. 클러스터 관리자는 엔지니어링 그룹과 마케팅 그룹이 각각 해당 네임스페이스에 할당된 리소스에만 액세스할 수 있는 환경을 만들기 위해 다음 작업을 완료합니다.
1단계: 각 그룹의 리소스를 포함할 네임스페이스를 만듭니다
네임스페이스를 만들면 리소스를 논리적으로 분리하고 해당 리소스에 액세스할 수 있는 사용자를 보다 효율적으로 제어할 수 있습니다.
-
엔지니어링 그룹의 네임스페이스를 만듭니다.
kubectl create ns engineering-ns
-
마케팅 그룹의 네임스페이스를 만듭니다.
kubectl create ns marketing-ns
2단계: 각 네임스페이스의 리소스와 상호 작용할 새 서비스 계정을 만듭니다
새로 만드는 각 네임스페이스에는 기본 서비스 계정이 함께 제공되지만, 나중에 필요한 경우 그룹 간에 Privileges를 추가로 나눌 수 있도록 각 사용자 그룹에 대한 서비스 계정을 만들어야 합니다.
-
엔지니어링 그룹에 대한 서비스 계정을 생성합니다.
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 개체를 각 새 서비스 계정에 바인딩합니다
기본 ClusterRole 개체는 Trident Protect를 설치할 때 만들어집니다. 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 개체를 사용할 수 있어야 하며, 할당된 네임스페이스 외부의 리소스에 액세스하거나 액세스 권한이 없는 새 리소스를 생성할 수 없습니다.