인증 및 권한 부여
Authentication 탭을 클릭하여 ServiceAccounts 섹션으로 드릴다운하면 네임스페이스별로 Kubernetes service account 리소스를 볼 수 있습니다.
추가 예제는 보안 모듈을 확인하세요.
ServiceAccount는 Pod에서 실행되는 프로세스에 대한 ID를 제공합니다. Pod를 생성할 때 service account를 지정하지 않으면 동일한 네임스페이스의 기본 service account가 자동으로 할당됩니다.
특정 service account에 대한 추가 세부 정보를 보려면 네임스페이스로 드릴다운하고 보려는 service account를 클릭하면 labels, annotations, events와 같은 추가 정보를 볼 수 있습니다. 아래는 catalog service account의 세부 보기입니다.
EKS에서는 요청이 권한 부여(액세스 권한 부여)되기 전에 인 증(로그인)되어야 합니다. Kubernetes는 REST API 요청에 공통적인 속성을 기대합니다. 이는 EKS 권한 부여가 액세스 제어를 위해 AWS Identity and Access Management와 함께 작동한다는 것을 의미합니다.
이 실습에서는 Kubernetes Role Based Access Control (RBAC) 리소스인 Cluster Roles, Roles, ClusterRoleBindings 및 RoleBindings를 살펴보겠습니다. RBAC는 EKS 클러스터 사용자에 매핑된 IAM role에 따라 EKS 클러스터와 그 객체에 대한 제한된 최소 권한 액세스를 제공하는 프로세스입니다. 다음 다이어그램은 사용자 또는 service account가 Kubernetes 클라이언트 및 API를 통해 EKS 클러스터의 객체에 액세스하려고 할 때 액세스 제어가 어떻게 흐르는지 보여줍니다.
추가 예제는 보안 모듈을 확인하세요.
**Role**은 사용자에게 적용할 권한 집합을 정의합니다. Role-based access control (RBAC)은 조직 내 개별 사용자의 역할에 따라 컴퓨터 또는 네트워크 리소스에 대한 액 세스를 규제하는 방법입니다. Role은 항상 특정 네임스페이스 내에서 권한을 설정하며, Role을 생성할 때 속할 네임스페이스를 지정해야 합니다.
Resource Type - Authorization 섹션에서 클러스터의 ClusterRoles 및 Roles 리소스를 네임스페이스별로 나열하여 볼 수 있습니다.
cluster-autoscaler-aws-cluster-autoscaler role을 클릭하면 해당 role에 대한 자세한 내용을 볼 수 있습니다. 아래 스크린샷은 네임스페이스 kube-system 아래에 생성된 cluster-autoscaler-aws-cluster-autoscaler role을 보여주며, 이 role은 configmaps 리소스에 대해 delete, get, update 권한을 가지고 있습니다.
**ClusterRoles**는 네임스페이스가 아닌 클러스터 범위의 규칙 집합이며, 이것이 Role과 다른 점입니다. ClusterRoles는 추가적이며 "거부" 규칙을 설정할 수 없습니다. 일반적으로 ClusterRoles는 클러스터 전체 권한을 정의하는 데 사용됩니다.
**Role binding**은 사용자 또는 사용자 집합에게 role 권한을 부여합니다. Rolebindings는 생성 중에 특정 네임스페이스에 할당됩니다. Rolebinding 리소스는 subjects(사용자, 그룹 또는 service accounts) 목록과 부여되는 role에 대한 참조를 보유합니다. RoleBinding은 pods, replicasets, jobs, deployments와 같은 특정 네임스페이스 내에서 권한을 부여합니다. 반면 ClusterRoleBinding은 nodes와 같은 클러스터 범위 리소스를 부여합니다.
**ClusterRoleBinding**은 ClusterRoles를 사용자 집합에 연결합니다. 클러스터 범위이며 Roles 및 RoleBindings처럼 네임스페이스에 바인딩되지 않습니다.
