RBAC 역할에는 어떤 유형이 있나요?

• Kubernetes _역할_의 범위는 배치 또는 서비스와 같은 특정 네임스페이스 내의 리소스로 지정됩니다.
• Kubernetes _클러스터 역할_의 범위는 작업자 노드와 같은 클러스터 전체 리소스 또는 팟(Pod)과 같이 각 네임스페이스에서 찾을 수 있는 네임스페이스 범위 리소스로 지정됩니다.

RBAC 역할 바인딩과 클러스터 역할 바인딩이란 무엇인가요?

역할 바인딩은 RBAC 역할 또는 클러스터 역할을 특정 네임스페이스에 적용합니다. 역할을 적용하기 위해 역할 바인딩을 사용하면 사용자에게 특정 네임스페이스의 특정 리소스에 대한 액세스 권한을 부여하게 됩니다. 클러스터 역할을 적용하기 위해 역할 바인딩을 사용하면 사용자에게 특정 네임스페이스 한정으로, 각 네임스페이스에서 찾을 수 있는 네임스페이스 범위 리소스(팟(Pod) 등)에 대한 액세스 권한을 부여하게 됩니다.

클러스터 역할 바인딩은 클러스터의 모든 네임스페이스에 RBAC 클러스터 역할을 적용합니다. 클러스터 역할을 적용하기 위해 클러스터 역할 바인딩을 사용하면 사용자에게 클러스터 전체 리소스(작업자 노드 등) 또는 모든 네임스페이스의 네임스페이스 범위 리소스(팟(Pod) 등)에 대한 액세스 권한을 부여하게 됩니다.

내 클러스터에서 이러한 역할들은 어떻게 구성되어 있나요?

사용자가 클러스터 내 Kubernetes 리소스와 상호작용할 수 있도록 하려면 IBM Cloud IAM 서비스 액세스 역할을 통해 하나 이상의 네임스페이스에 대한 액세스 권한을 사용자에게 지정해야 합니다. 서비스 액세스 역할이 지정된 사용자에게는 모두 자동으로 해당 RBAC 클러스터 역할이 지정됩니다. 이러한 RBAC 클러스터 역할은 사전 정의되며 사용자가 클러스터 내의 Kubernetes 리소스와 상호작용할 수 있도록 해 줍니다. 또한, 역할 바인딩은 특정 네임스페이스에 클러스터 역할을 적용하기 위해 작성되고, 클러스터 역할 바인딩은 모든 네임스페이스에 클러스터 역할을 적용하기 위해 작성됩니다.

각 RBAC 역할에서 허용되는 작업에 대해 자세히 알아보려면, ‘ IBM Cloud ’의 IAM 서비스 액세스 역할 참조 항목을 확인해 보세요. 개별 Kubernetes 리소스에 각 RBAC 역할에 의해 부여된 권한을 보려면 RBAC 역할별 Kubernetes 리소스 권한을 확인하십시오.

사용자 정의 역할이나 클러스터 역할을 생성할 수 있나요?

자체 사용자 정의 RBAC 정책을 작성하는 경우 클러스터에 있는 기존 IBM 역할 바인딩을 편집하지 않거나 기존 IBM 바인딩과 동일한 이름으로 사용자 정의 역할 바인딩을 작성하지 마십시오. IBM제공 RBAC 역할 바인딩에 대한 변경사항은 업데이트 시 유지되지 않습니다.

view, edit, admin 및 cluster-admin 클러스터 역할은 사용자에게 해당 IBM Cloud IAM 서비스 액세스 역할을 지정할 때 자동으로 작성되는 사전 정의된 역할입니다. 그 외의 Kubernetes 권한을 부여하려는 경우에는 사용자 정의 RBAC 권한을 작성할 수 있습니다. 사용자 정의 RBAC 역할은 서비스 액세스 역할에 포함된 기존 RBAC 역할에 추가되는 것이며, 이러한 기존 RBAC 역할을 변경하거나 재정의하지 않습니다. 참고: 사용자 지정 RBAC 권한을 생성하려면, ‘ cluster-admin ’ Kubernetes RBAC 역할을 부여하는 IAM Manager 서비스 액세스 역할 또는 관리자 플랫폼 역할을 보유하고 있어야 합니다. 그러나 자신의 사용자 정의 Kubernetes RBAC 역할을 관리하는 경우 다른 사용자에는 IAM 서비스 액세스 역할이 필요하지 않습니다.

언제 사용자 정의 클러스터 역할 바인딩 및 역할 바인딩을 사용해야 합니까?

클러스터에서 팟(Pod)을 작성하고 업데이트할 수 있도록 사용자에게 권한을 부여하고자 하는 경우가 있을 수 있습니다. Pod 보안 정책(PSP)을 사용하면 클러스터에 기본으로 포함된 기존 클러스터 역할 바인딩을 사용하거나, 직접 바인딩을 생성할 수 있습니다.

클러스터에 추가 기능을 통합하려는 경우도 있을 수 있습니다. 예를 들어, 클러스터에서 Helm 을 설정할 때.

사용자, 그룹 또는 서비스 계정에 대한 사용자 정의 RBAC 권한 작성

view, edit, admin 및 cluster-admin 클러스터 역할은 해당 IBM Cloud IAM 서비스 액세스 역할을 지정할 때 자동으로 작성됩니다. 클러스터 액세스 정책이 이러한 사전 정의된 권한보다 더 세부적으로 권한을 부여하도록 하려 하십니까? 걱정하지 마십시오! 이러한 경우에는 사용자 정의 RBAC 역할 및 클러스터 역할을 작성할 수 있습니다.

사용자 정의 RBAC 역할 및 클러스터 역할을 개별 사용자, 사용자 그룹 또는 서비스 계정에 지정할 수 있습니다. 그룹에 대해 바인딩이 작성되면 이는 해당 그룹에서 추가 또는 제거된 사용자에게 영향을 줍니다. 사용자를 그룹에 추가하면 이들은 자신에게 부여된 개별 액세스 권한 외에 해당 그룹의 액세스 권한 또한 얻습니다. 이를 제거하면 해당 액세스 권한이 취소됩니다. 서비스 계정은 액세스 그룹에 추가할 수 없다는 점에 유의하십시오.

지속적 배포 툴체인과 같이 포드 내에서 실행되는 컨테이너 프로세스에 액세스 권한을 부여하려면 다음을 사용할 수 있습니다. Kubernetes ServiceAccounts를 사용할 수 있습니다. Travis 및 Jenkins 용 서비스 계정을 설정하고, 해당 서비스 계정에 사용자 정의 RBAC 역할을 할당하는 방법을 보여주는 튜토리얼을 보려면 블로그 게시물 Kubernetes ServiceAccounts 자동화 시스템에서 사용하기 위한 을 참조하세요.

이전 버전과 호환되지 않는 변경사항을 방지하기 위해 사전 정의된 view, edit, admin 및 cluster-admin 클러스터 역할을 변경하지 마십시오. 사용자 정의 RBAC 역할은 IBM Cloud IAM 서비스 액세스 역할에 포함된 기존 RBAC 역할에 추가되는 것이며, 이러한 기존 역할을 변경하거나 재정의하지 않습니다.

• 네임스페이스 액세스: 사용자, 액세스 그룹 또는 서비스 계정이 특정 네임스페이스 내의 리소스에 액세스할 수 있도록 하려는 경우에는 다음 조합 중 하나를 선택하십시오.

  • 역할을 작성하고 역할 바인딩을 사용하여 이를 적용합니다. 이 선택사항은 앱 배치와 같이 하나의 네임스페이스만 있는 고유 리소스에 대한 액세스를 제어하는 데 유용합니다.
  • 클러스터 역할을 작성하고 역할 바인딩을 사용하여 이를 적용합니다. 이 선택사항은 팟(Pod)과 같이 하나의 네임스페이스에 있는 일반 리소스에 대한 액세스를 제어하는 데 유용합니다.

• 클러스터 전체 액세스: 사용자 또는 액세스 그룹이 클러스터 전체 리소스 또는 모든 네임스페이스의 리소스에 액세스할 수 있도록 하려는 경우에는 클러스터 역할을 작성하고 클러스터 역할 바인딩을 사용하여 이를 적용하십시오. 이 선택사항은 작업자 노드와 같이 네임스페이스보다 범위가 큰 리소스, 또는 각 네임스페이스에 있는 팟(Pod)과 같이 클러스터의 모든 네임스페이스에 있는 리소스에 대한 액세스를 제어하는 데 유용합니다.

• 계정에 로그인하십시오. If applicable, target the appropriate resource group. 클러스터에 대한 컨텍스트를 설정하십시오.

• 모든 네임스페이스에 대한 관리자 IAM 서비스 액세스 역할 또는 관리자 플랫폼 역할이 있는지 확인하세요.

• 개별 사용자 또는 액세스 그룹에 속한 사용자에게 액세스 권한을 할당하려면, 해당 사용자나 그룹에 ‘ IBM Cloud Kubernetes Service ’ 서비스 수준에서 최소 한 개의 IAM 플랫폼 액세스 역할이 할당되어 있는지 확인하십시오.

사용자 정의 RBAC 권한을 작성하려는 경우

1. 다음과 유사한 .yaml 파일을 작성하여 role 또는 cluster role 를 정의하십시오.

   kind: Role
   apiVersion: rbac.authorization.k8s.io/v1
   metadata:
       namespace: default
       name: my_role
   rules:
   - apiGroups: [""]
       resources: ["pods"]
       verbs: ["get", "watch", "list"]
   - apiGroups: ["apps", "extensions"]
       resources: ["daemonsets", "deployments"]
       verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
   

   YAML 매개변수 이해

   매개변수	설명
   kind	특정 네임스페이스 내의 리소스에 대한 액세스 권한을 부여하려면 Role을 사용하십시오. 작업자 노드와 같은 클러스터 전체 리소스, 또는 모든 네임스페이스의 팟(Pod)과 같은 네임스페이스 범위 리소스에 대한 액세스 권한을 부여하려면 ClusterRole을 사용하십시오.
   metadata.namespace	Role 유형 한정: 액세스 권한이 부여되는 Kubernetes 네임스페이스를 지정하십시오.
   rules.apiGroups	사용자가 상호 작용할 수 있도록 허용할 Kubernetes API 그룹 (예: "apps", "batch" 또는 "extensions" 등)을 지정하십시오. REST 경로 api/v1의 코어 API 그룹에 액세스하려면 그룹을 [""]와 같이 공백으로 두십시오.
   rules.resources	"daemonsets", "deployments", "events", "ingresses" 등과 같이 액세스 권한을 부여할 Kubernetes 리소스 유형을 지정하십시오. "nodes"를 지정하는 경우 유형은 ClusterRole이어야 합니다.
   rules.verbs	사용자가 수행할 수 있도록 허용할 작업 유형을 지정하십시오. 예를 들어, "get", "list", "describe", "create" 또는 "delete" 등이 있습니다.

2. 클러스터에 역할 또는 클러스터 역할을 작성하십시오.

   kubectl apply -f my_role.yaml
   

3. 역할 또는 클러스터 역할이 작성되었는지 확인하십시오.

   • 역할:

       kubectl get roles -n <namespace>
       ```
   * 클러스터 역할:
   ```sh {: pre}
       kubectl get clusterroles
       ```
   

4. .yaml 파일을 작성하여 역할 또는 클러스터 역할에 사용자를 바인드하십시오. 각 주제의 이름에 사용할 고유한 URL을 기록해 두십시오.

   kind: RoleBinding
   apiVersion: rbac.authorization.k8s.io/v1
   metadata:
       name: my_role_binding
       namespace: default
   subjects:
   - kind: User
       name: IAM#user1@example.com
       apiGroup: rbac.authorization.k8s.io
   - kind: Group
       name: team1
       apiGroup: rbac.authorization.k8s.io
   - kind: ServiceAccount
       name: <service_account_name>
       namespace: <kubernetes_namespace>
   roleRef:
       kind: Role
       name: my_role
       apiGroup: rbac.authorization.k8s.io
   

   YAML 매개변수 이해

   매개변수	설명
   kind	네임스페이스 특정 Role 또는 ClusterRole에 대해 RoleBinding을 지정하십시오. 클러스터 전체 ClusterRoleBinding에 대해 ClusterRole을 지정하십시오.
   apiVersion	rbac.authorization.k8s.io/v1을(를) 사용하십시오.
   metadata.namespace	RoleBinding 유형의 경우: 액세스 권한이 부여되는 Kubernetes 네임스페이스를 지정하십시오. ClusterRoleBinding 유형의 경우: namespace 필드를 사용하지 마십시오.
   metadata.name	역할 바인딩 또는 클러스터 역할 바인딩의 이름을 지정하십시오.
   subjects.kind	유형을 다음 중 하나로 지정하십시오. User: RBAC 역할 또는 클러스터 역할을 계정 내의 개별 사용자에 바인드하십시오. Group: RBAC 역할 또는 클러스터 역할을 계정 내의 IBM Cloud IAM 액세스 그룹에 바인드하십시오. ServiceAccount: RBAC 역할 또는 클러스터 역할을 클러스터 내의 네임스페이스에 있는 서비스 계정에 바인드하십시오.
   subjects.name	User: 개별 사용자의 이메일 주소를 IAM# 에 다음과 같이 추가합니다: IAM#user@email.com. Group: 계정에 IBM Cloud IAM 액세스 그룹의 이름을 지정합니다. ServiceAccount의 경우: 서비스 계정 이름을 지정하십시오.
   subjects.apiGroup	User 또는 Group: rbac.authorization.k8s.io 을 사용합니다. ServiceAccount의 경우: 이 필드를 포함하지 마십시오.
   subjects.namespace	ServiceAccount only: 서비스 계정이 배포된 Kubernetes 네임스페이스의 이름을 지정합니다.
   roleRef.kind	역할 kind 파일(.yaml 또는 Role)에서 ClusterRole와 동일한 값을 입력하십시오.
   roleRef.name	역할 .yaml 파일의 이름을 입력하십시오.
   roleRef.apiGroup	rbac.authorization.k8s.io을(를) 사용하십시오.

5. 클러스터에 역할 바인딩 또는 클러스터 역할 바인딩 리소스를 작성하십시오.

   kubectl apply -f my_role_binding.yaml
   

6. 바인딩이 작성되었는지 확인하십시오.

   kubectl get rolebinding -n <namespace>
   

7. 선택사항: 다른 네임스페이스에서 동일한 사용자 액세스 권한 레벨을 적용하려는 경우에는 해당 역할 또는 클러스터 역할에 대한 역할 바인딩을 다른 네임스페이스로 복사할 수 있습니다.

   1. 역할 바인딩을 한 네임스페이스에서 다른 네임스페이스로 복사하십시오.

       kubectl get rolebinding <role_binding_name> -o yaml | sed 's/<namespace_1>/<namespace_2>/g' | kubectl -n <namespace_2> create -f -
       ```
       예를 들어, `custom-role` 네임스페이스의 `default` 역할 바인딩을 `testns` 네임스페이스에 복사하십시오.
       ```sh {: pre}
       kubectl get rolebinding custom-role -o yaml | sed 's/default/testns/g' | kubectl -n testns create -f -
       ```
   2. 역할 바인딩이 복사되었는지 확인하십시오. IBM Cloud IAM 액세스 그룹을 역할 바인딩에 추가한 경우 해당 그룹의 각 사용자는 액세스 그룹 ID로 추가되는 것이 아니라 개별적으로 추가됩니다.
   ```sh {: pre}
       kubectl get rolebinding -n <namespace_2>
       ```
   

사용자 정의 Kubernetes RBAC 역할 또는 클러스터 역할의 작성 및 바인드가 완료되었습니다. 사용자에게 후속 조치를 취하십시오. 팟(Pod) 삭제와 같은 역할로 인해 완료할 권한이 있는 조치를 테스트하도록 사용자에게 요청하십시오.

클러스터 역할을 집계하여 기존 권한 확장

다른 클러스터 역할과 클러스터 역할을 결합하거나 집계하여 사용자의 기존 권한을 확장할 수 있습니다. 사용자에게 IBM Cloud 서비스 액세스 역할을 지정하면 사용자는 해당 Kubernetes RBAC 클러스터 역할에 추가됩니다. 하지만 특정 사용자에게는 더 많은 작업을 수행할 수 있도록 허용하고 싶을 수도 있습니다.

예를 들어, 네임스페이스 범위의 admin 클러스터 역할이 있는 사용자는 kubectl top pods 명령을 사용하여 네임스페이스의 모든 팟(Pod)에 대한 팟(Pod) 메트릭을 볼 수 없습니다. admin 클러스터 역할의 사용자에게 top pods 명령을 실행할 수 있는 권한이 부여되도록 클러스터 역할을 집계할 수 있습니다. 자세한 내용은 Kubernetes 문서를 참조하십시오.

Error from server (Forbidden): pods.metrics.k8s.io is forbidden: User "IAM#myname@example.com" can't list resource "pods" in API group "metrics.k8s.io" in the namespace "mynamespace"

RBAC 역할 확인

IBM Cloud Kubernetes Service 클러스터에서 사용자 정의 RBAC, 또는 RBAC 역할에 동기화된 IAM 서비스 액세스 권한을 확인하십시오.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  creationTimestamp: 2018-05-23T14:34:24Z
  name: ibm-view
  namespace: default
  resourceVersion: "8192510"
  selfLink: /apis/rbac.authorization.k8s.io/v1/namespaces/default/rolebindings/ibm-view
  uid: 63f62887-5e96-11e8-8a75-b229c11ba64a
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: view
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: IAM#user@email.com
- apiGroup: rbac.authorization.k8s.io
  kind: group
  name: team1

Kubernetes 서비스 액세스 역할 및 해당 RBAC 역할

다음 표는 각 서비스 액세스 역할 및 해당 RBAC 역할에 따라 부여되는 Kubernetes 리소스 권한을 보여줍니다.