RBAC 권한 이해
IAM 서비스 액세스 역할은 IBM Cloud Kubernetes Service 클러스터 내에서 Kubernetes 역할 기반 액세스 제어(RBAC)에 해당합니다. RBAC 역할 및 클러스터 역할은 사용자가 클러스터에 있는 Kubernetes 리소스와 상호작용할 수 있는 방식에 대한 권한 세트를 정의합니다.
IBM Cloud IAM을 사용하면 IBM Cloud 에서 사용자에게 IAM 서비스 액세스 역할을 할당하여 RBAC을 자동으로 관리할 수 있습니다. 서비스 계정과 같이 클러스터 내 리소스에 대한 액세스를 사용자 정의하기 위해 RBAC를 자세히 이해하기를 원할 수 있습니다.
- IBM Cloud IAM 역할은 서비스 계정에 지정할 수 없습니다. 대신 직접 서비스 계정에 RBAC 역할을 지정할 수 있습니다.
- 역할 변경사항을 적용하려면 사용자가
ibmcloud ks cluster config
명령을 실행해야 합니다.
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 권한을 작성하려면 ** Kubernetes RBAC 역할을 제공하는 **관리자cluster-admin
서비스 액세스 역할이 있어야 합니다. 그러나 자신의 사용자 정의 Kubernetes RBAC 역할을 관리하는 경우 다른 사용자에는 IAM 서비스 액세스 역할이 필요하지
않습니다.
언제 사용자 정의 클러스터 역할 바인딩 및 역할 바인딩을 사용해야 합니까?
클러스터에서 팟(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 권한을 작성하려는 경우
-
다음과 유사한
.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
"apps"
,"batch"
, 또는"extensions"
과 같이 사용자가 상호 작용할 수 있도록 할 Kubernetes API 그룹을 지정합니다. REST 경로api/v1
의 코어 API 그룹에 액세스하려면 그룹을[""]
와 같이 공백으로 두십시오.rules.resources
"daemonsets"
,"deployments"
,"events"
또는"ingresses"
와 같이 액세스 권한을 부여할 Kubernetes 리소스 유형을 지정합니다."nodes"
를 지정하는 경우 유형은ClusterRole
이어야 합니다.rules.verbs
"get"
,"list"
,"describe"
,"create"
또는"delete"
과 같이 사용자가 수행할 수 있는 작업 유형을 지정합니다. -
클러스터에 역할 또는 클러스터 역할을 작성하십시오.
kubectl apply -f my_role.yaml
-
역할 또는 클러스터 역할이 작성되었는지 확인하십시오.
- 역할:
kubectl get roles -n <namespace>
- 클러스터 역할:
kubectl get clusterroles
- 역할:
-
.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
- Kubernetes 1.8 이상을 실행하는 클러스터의 경우
rbac.authorization.k8s.io/v1
을 사용하십시오. - 이전 버전의 경우
apiVersion: rbac.authorization.k8s.io/v1beta1
을 사용하십시오.
metadata.namespace
RoleBinding
유형의 경우: 액세스 권한이 부여되는 Kubernetes 네임스페이스를 지정하십시오.ClusterRoleBinding
유형의 경우:namespace
필드를 사용하지 마십시오.
metadata.name
역할 바인딩 또는 클러스터 역할 바인딩의 이름을 지정하십시오. subjects.kind
유형을 다음 중 하나로 지정하십시오.
User
: RBAC 역할 또는 클러스터 역할을 계정 내의 개별 사용자에 바인드하십시오.Group
: RBAC 역할 또는 클러스터 역할을 계정 내의 IBM Cloud IAM 액세스 그룹에 바인드하십시오.ServiceAccount
: RBAC 역할 또는 클러스터 역할을 클러스터 내의 네임스페이스에 있는 서비스 계정에 바인드하십시오.
subjects.name
User
의 경우:IAM#user@email.com
과 같은 개별 사용자의 이메일 주소를IAM#
에 추가하십시오.Group
의 경우: 계정에 있는 IBM Cloud IAM 액세스 그룹의 이름을 지정하십시오.ServiceAccount
의 경우: 서비스 계정 이름을 지정하십시오.
subjects.apiGroup
User
또는Group
의 경우:rbac.authorization.k8s.io
를 사용하십시오.ServiceAccount
의 경우: 이 필드를 포함하지 마십시오.
subjects.namespace
ServiceAccount
한정: 서비스 계정이 배치되는 Kubernetes 네임스페이스의 이름을 지정하십시오.roleRef.kind
역할 kind
파일(.yaml
또는Role
)에서ClusterRole
와 동일한 값을 입력하십시오.roleRef.name
역할 .yaml
파일의 이름을 입력하십시오.roleRef.apiGroup
rbac.authorization.k8s.io
을(를) 사용하십시오. - 네임스페이스 특정
-
클러스터에 역할 바인딩 또는 클러스터 역할 바인딩 리소스를 작성하십시오.
kubectl apply -f my_role_binding.yaml
-
바인딩이 작성되었는지 확인하십시오.
kubectl get rolebinding -n <namespace>
-
선택사항: 다른 네임스페이스에서 동일한 사용자 액세스 권한 레벨을 적용하려는 경우에는 해당 역할 또는 클러스터 역할에 대한 역할 바인딩을 다른 네임스페이스로 복사할 수 있습니다.
- 역할 바인딩을 한 네임스페이스에서 다른 네임스페이스로 복사하십시오.
예를 들어,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
네임스페이스에 복사하십시오.kubectl get rolebinding custom-role -o yaml | sed 's/default/testns/g' | kubectl -n testns create -f -
- 역할 바인딩이 복사되었는지 확인하십시오. IBM Cloud IAM 액세스 그룹을 역할 바인딩에 추가한 경우 해당 그룹의 각 사용자는 액세스 그룹 ID로 추가되는 것이 아니라 개별적으로 추가됩니다.
kubectl get rolebinding -n <namespace_2>
- 역할 바인딩을 한 네임스페이스에서 다른 네임스페이스로 복사하십시오.
사용자 정의 Kubernetes RBAC 역할 또는 클러스터 역할의 작성 및 바인드가 완료되었습니다. 사용자에게 후속 조치를 취하십시오. 팟(Pod) 삭제와 같은 역할로 인해 완료할 권한이 있는 조치를 테스트하도록 사용자에게 요청하십시오.
클러스터 역할을 집계하여 기존 권한 확장
다른 클러스터 역할과 클러스터 역할을 결합하거나 집계하여 사용자의 기존 권한을 확장할 수 있습니다. 사용자에게 IBM Cloud 서비스 액세스 역할을 지정하면 사용자는 해당 Kubernetes RBAC 클러스터 역할에 추가됩니다. 그러나 특정 사용자가 추가 오퍼레이션을 수행하도록 허용할 수 있습니다.
예를 들어, 네임스페이스 범위의 admin
클러스터 역할이 있는 사용자는 kubectl top pods
명령을 사용하여 네임스페이스의 모든 팟(Pod)에 대한 팟(Pod) 메트릭을 볼 수 없습니다. admin
클러스터 역할의 사용자에게 top pods
명령을 실행할 수 있는 권한이 부여되도록 클러스터 역할을 집계할 수 있습니다. 자세한
내용은 Kubernetes 문서를 참조하세요.
기본 클러스터 역할에 대한 권한을 확장할 수 있는 일반적인 작업에는 어떤 것이 있나요?
각 기본 RBAC 클러스터 역할에서 허용되는 오퍼레이션을 검토하여 사용자가 수행할 수 있는 오퍼레이션을 파악한 후 허용된 오퍼레이션과 수행 가능한 오퍼레이션을 비교하십시오.
동일한 클러스터 역할의 사용자에게 동일한 유형의 오퍼레이션에 대해 다음과 유사한 오류가 발생하는 경우 이 오퍼레이션을 포함하도록 클러스터 역할을 확장하려고 할 수 있습니다.
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"
시작하기 전에: 계정에 로그인하십시오. If applicable, target the appropriate resource group. 클러스터에 대한 컨텍스트를 설정하십시오.
-
클러스터 역할 YAML 파일을 작성하십시오.
labels
섹션에서 권한을 집계할 기존 클러스터 역할을 지정하십시오. 다음 예에서는 사용자가admin
를 실행할 수 있도록 사전 지정된kubectl top pods
클러스터 역할을 확장합니다. 더 많은 예제는 Kubernetes 문서를 참조하세요.apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: view-pod-metrics labels: rbac.authorization.k8s.io/aggregate-to-admin: "true" rules: - apiGroups: - "metrics.k8s.io" resources: - pods verbs: - list
YAML 매개변수 이해 매개변수 설명 metadata.name
클러스터 역할의 이름을 입력하십시오. 사전 지정된 클러스터 역할 이름 즉, view
,edit
,admin
및cluster-admin
을 사용하지 마십시오.metadata.labels
집계할 클러스터 역할과 일치하는
rbac.authorization.k8s.io/aggregate-to-<cluster_role>: "true"
형식의 레이블을 추가하십시오. 사전 정의된 클러스터 역할의 레이블은 다음과 같습니다.- 네임스페이스로 범위 지정된 IAM 관리자 서비스 액세스 역할:
rbac.authorization.k8s.io/aggregate-to-admin: "true"
- IAM 작성자 서비스 액세스 역할:
rbac.authorization.k8s.io/aggregate-to-edit: "true"
- IAM 독자 서비스 액세스 역할:
rbac.authorization.k8s.io/aggregate-to-view: "true"
rules.apiGroups
"apps"
,"batch"
, 또는"extensions"
과 같이 사용자가 상호 작용할 수 있도록 할 Kubernetes API 그룹을 지정합니다. REST 경로api/v1
의 코어 API 그룹에 액세스하려면 그룹을[""]
와 같이 공백으로 두십시오.rules.resources
"daemonsets"
,"deployments"
,"events"
또는"ingresses"
와 같이 액세스 권한을 부여할 Kubernetes 리소스 유형을 지정합니다.rules.verbs
"get"
,"list"
,"describe"
,"create"
또는"delete"
과 같이 사용자가 수행할 수 있는 작업 유형을 지정합니다. - 네임스페이스로 범위 지정된 IAM 관리자 서비스 액세스 역할:
-
클러스터에서 클러스터 역할을 작성하십시오.
admin
클러스터 역할에 대한 역할 바인딩이 있는 모든 사용자에게 이제view-pod-metrics
클러스터 역할로부터 추가 권한이 제공됩니다.kubectl apply -f <cluster_role_file.yaml>
-
admin
클러스터 역할이 있는 사용자에게 알리십시오. 해당 사용자에게 클러스터 구성을 새로 고치고kubectl top pods
와 같은 조치를 테스트하도록 요청하십시오.
RBAC 역할 확인
IBM Cloud Kubernetes Service 클러스터에서 사용자 정의 RBAC, 또는 RBAC 역할에 동기화된 IAM 서비스 액세스 권한을 확인하십시오.
UI에서 RBAC 역할 확인
-
콘솔에 로그인합니다.
-
확인할 RBAC 역할이 있는 클러스터를 클릭하십시오.
-
Kubernetes 대시보드를 클릭하십시오.
사설 네트워크 전용 클러스터가 있는 경우에는 VPN을 사용 중이 아니면 이 대시보드를 열지 못할 수 있습니다. 프라이빗 클라우드 서비스 엔드포인트를 통해 클러스터에 액세스를 참조하십시오.
-
클러스터 섹션에서 클러스터 역할 바인딩, 클러스터 역할, 역할 바인딩 및 역할을 검토하십시오.
CLI에서 RBAC 역할 확인
-
계정에 로그인하십시오. If applicable, target the appropriate resource group. 클러스터에 대한 컨텍스트를 설정하십시오.
-
사용자가 RBAC 역할에 추가되었는지 확인하십시오. 해당 사용자가 더 높은 권한을 보유한 경우 역할 바인딩에 추가되지 않습니다. 예를 들어, 사용자가 클러스터 역할을 갖고 있고 클러스터 역할 바인딩에 있는 경우 사용자는 각 개별 네임스페이스 역할 바인딩에도 추가되지 않습니다.
역할 바인딩 및 클러스터 역할 바인딩을 확인하려면 클러스터 관리자(모든 네임스페이스의 관리자 서비스 액세스 역할)여야 합니다.
- 독자:
kubectl get rolebinding ibm-view -o yaml -n <namespace>
- 작성자:
kubectl get rolebinding ibm-edit -o yaml -n <namespace>
- 관리자, 네임스페이스로 범위 지정됨:
kubectl get rolebinding ibm-operate -o yaml -n <namespace>
- 관리자, 모든 네임스페이스:
kubectl get clusterrolebinding ibm-admin -o yaml
- 독자:
출력 예
사용자 user@email.com
및 액세스 그룹 team1
에 독자 서비스 액세스 역할을 지정한 후 kubectl get rolebinding ibm-view -o yaml -n default
를 실행하면 다음 출력 예가 표시됩니다.
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 리소스 권한을 보여줍니다.
서비스 액세스 역할 | 해당 RBAC 역할, 바인딩 및 범위 | Kubernetes 리소스 권한 |
---|---|---|
독자 역할 |
하나의 네임스페이스로 범위 지정된 경우: 해당 네임스페이스의
|
|
작성자 역할 | 하나의 네임스페이스로 범위가 지정된 경우: edit 클러스터 역할은 해당 네임스페이스의 ibm-edit 역할 바인딩에 의해 적용된 클러스터 역할.
모든 네임스페이스로 범위가 지정된 경우: |
|
관리자 역할 | 하나의 네임스페이스로 범위 지정된 경우: 해당 네임스페이스의 ibm-operate 역할 바인딩으로 적용된 admin 클러스터 역할
모든 네임스페이스로 범위 지정된 경우: 모든 네임스페이스에 적용되는 |
하나의 네임스페이스로 범위 지정:
|
RBAC 역할별 Kubernetes 리소스 권한
IBM Cloud IAM 서비스 액세스 역할이 지정된 모든 사용자에게는 사전 정의된 해당 Kubernetes 역할 기반 액세스 제어(RBAC) 역할도 자동으로 지정됩니다. 자체 사용자 정의 Kubernetes RBAC 권한을 관리하려는 경우, 사용자, 그룹 또는 서비스 계정에 대한 사용자 정의 RBAC 권한 작성을 참조하십시오. 사용자 이름 세부사항은 RBAC 사용자에 대한 IBM Cloud IAM 발행자 세부사항을 참조하십시오.
네임스페이스의 리소스에서 특정 kubectl
명령을 실행할 수 있는 올바른 권한이 있는지 여부가 궁금하십니까? kubectl auth can-i
명령을
시도하십시오.
다음 표에는 개별 Kubernetes 리소스에 각 RBAC 역할에 의해 부여된 권한이 표시되어 있습니다. 권한은 해당 역할을 가진 사용자가 리소스에 대해 수행할 수 있는 verbs
(또는 작업)으로 표시됩니다(예: '가져오기', '목록', '설명', '만들기' 또는 '삭제').
Kubernetes 리소스 | view |
edit |
admin 및 cluster-admin |
---|---|---|---|
bindings |
가져오기, 나열, 감시 | 가져오기, 나열, 감시 | get, list, watch cluster-admin 전용: create, delete, update |
configmaps |
가져오기, 나열, 감시 | 생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
cronjobs.batch |
가져오기, 나열, 감시 | 생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
daemonsets.apps |
가져오기, 나열, 감시 | 생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
daemonsets.extensions |
가져오기, 나열, 감시 | 생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
deployments.apps |
가져오기, 나열, 감시 | 생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
deployments.apps/rollback |
|
생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
deployments.apps/scale |
가져오기, 나열, 감시 | 생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
deployments.extensions |
가져오기, 나열, 감시 | 생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
deployments.extensions/rollback |
|
생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
deployments.extensions/scale |
가져오기, 나열, 감시 | 생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
endpoints |
가져오기, 나열, 감시 | 생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
events |
가져오기, 나열, 감시 | 가져오기, 나열, 감시 | 가져오기, 나열, 감시 |
horizontalpodautoscalers.autoscaling |
가져오기, 나열, 감시 | 생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
ingresses.extensions |
가져오기, 나열, 감시 | 생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
jobs.batch |
가져오기, 나열, 감시 | 생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
limitranges |
가져오기, 나열, 감시 | 가져오기, 나열, 감시 | 가져오기, 나열, 감시 |
localsubjectaccessreviews |
|
|
create |
namespaces |
가져오기, 나열, 감시 | 가져오기, 나열, 감시 | get, list, watch cluster-admin 전용: create, delete |
namespaces/status |
가져오기, 나열, 감시 | 가져오기, 나열, 감시 | 가져오기, 나열, 감시 |
networkpolicies |
가져오기, 나열, 감시 | 생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
networkpolicies.extensions |
가져오기, 나열, 감시 | 생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
node |
없음 | 없음 | 네임스페이스로 범위 지정된 admin : 없음
모든 네임스페이스에 대한 |
persistentvolume |
없음 | 없음 | 생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
persistentvolumeclaims |
가져오기, 나열, 감시 | 생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
poddisruptionbudgets.policy |
가져오기, 나열, 감시 | 생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
pods |
가져오기, 나열, 감시 | 생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
만들기, 삭제, deletecollection , 가져오기, 목록, top , 패치, 업데이트, 보기 |
pods/attach |
|
생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
pods/exec |
|
생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
pods/log |
가져오기, 나열, 감시 | 가져오기, 나열, 감시 | 가져오기, 나열, 감시 |
pods/portforward |
|
생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
pods/proxy |
|
생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
pods/status |
가져오기, 나열, 감시 | 가져오기, 나열, 감시 | 가져오기, 나열, 감시 |
replicasets.apps |
가져오기, 나열, 감시 | 생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
replicasets.apps/scale |
가져오기, 나열, 감시 | 생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
replicasets.extensions |
가져오기, 나열, 감시 | 생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
replicasets.extensions/scale |
가져오기, 나열, 감시 | 생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
replicationcontrollers |
가져오기, 나열, 감시 | 생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
replicationcontrollers/scale |
가져오기, 나열, 감시 | cr}eate, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
replicationcontrollers/status |
가져오기, 나열, 감시 | 가져오기, 나열, 감시 | 가져오기, 나열, 감시 |
replicationcontrollers.extensions/scale |
가져오기, 나열, 감시 | 생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
resourcequotas |
가져오기, 나열, 감시 | 가져오기, 나열, 감시 | 가져오기, 나열, 감시 |
resourcequotas/status |
가져오기, 나열, 감시 | 가져오기, 나열, 감시 | 가져오기, 나열, 감시 |
rolebindings |
|
|
생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
roles |
|
|
생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
secrets |
|
생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
serviceaccounts |
가져오기, 나열, 감시 | 만들기, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기, impersonate |
만들기, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기, impersonate |
services |
가져오기, 나열, 감시 | 생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
services/proxy |
|
생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
statefulsets.apps |
가져오기, 나열, 감시 | 생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
statefulsets.apps/scale |
가져오기, 나열, 감시 | 생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
생성, 삭제, deletecollection , 가져오기, 목록, 패치, 업데이트, 보기 |
RBAC 사용자에 대한 IBM Cloud IAM 발행자 세부사항
IAM에서 IBM Cloud Kubernetes Service에 대한 서비스 액세스 역할이 있는 사용자에게는 RBAC의 해당 사용자 역할이 제공됩니다. RBAC 사용자 세부사항에는 고유한 발행자 ID, 주제 ID 클레임 및 Kubernetes 사용자 이름이 포함됩니다. 이 세부사항은 클러스터의 Kubernetes 버전에 따라 달라집니다. 이전 버전에서 클러스터를 업데이트하면 세부사항이
자동으로 업데이트됩니다. RBAC 사용자 이름의 접두부는 IAM#
입니다. OpenID 인증의 작동 방식에 대한 자세한 내용은 Kubernetes 문서를 참조하세요.
Kubernetes API 서버를 인증하기 위해 사용자 세부사항에 의존하는 클러스터 내에서 자동화 도구를 빌드하는 경우 이 정보를 사용할 수 있습니다.
버전 | 발행자 | 청구 | 케이싱* |
---|---|---|---|
Kubernetes | https://iam.cloud.ibm.com/identity |
realmed_sub_<account_ID> |
소문자 |
*
: 소문자의 예는 user.name@company.com
입니다. 대소문자 구분의 예는 User.Name@company.com
입니다.