역할 기반 접근 제어

역할 기반 접근 제어 (RBAC)

Kubernetes에서 사용자나 애플리케이션 특정 서비스 계정에 역할을 부여하는 것은 애플리케이션이 지정한 범위 안에서 동작하도록 하는 모범 사례예요. 서비스 계정 권한에 대한 자세한 내용은 공식 Kubernetes 문서에서 읽어 보세요.

Kubernetes 1.6부터 Role-based Access Control(RBAC)은 기본적으로 활성화돼요. RBAC를 사용하면 사용자와 조직 내 역할에 따라 어떤 종류의 액션을 허용할지 지정할 수 있어요.

출처: 문서

본문

사용자 계정 관리

모든 Kubernetes 클러스터에는 두 가지 범주의 사용자가 있어요: Kubernetes가 관리하는 서비스 계정과 일반 사용자.

일반 사용자는 외부의 독립 서비스가 관리한다고 가정돼요. 관리자가 개인 키를 배포하거나, Keystone이나 Google Accounts 같은 사용자 저장소, 심지어 사용자 이름과 비밀번호 목록이 담긴 파일일 수도 있어요. 이런 점에서 Kubernetes에는 일반 사용자 계정을 나타내는 객체가 없어요. 일반 사용자는 API 호출로 클러스터에 추가될 수 없어요.

반대로 서비스 계정은 Kubernetes API가 관리하는 사용자예요. 특정 네임스페이스에 바인딩되며, API 서버가 자동으로 만들거나 API 호출로 수동으로 만들어요. 서비스 계정은 Secrets로 저장된 자격 증명 집합에 연결되며, 파드에 마운트되어 클러스터 내 프로세스가 Kubernetes API와 통신할 수 있게 해 줘요.

API 요청은 일반 사용자나 서비스 계정에 연결되거나 익명 요청으로 처리돼요. 즉, 워크스테이션에서 kubectl을 입력하는 인간 사용자부터 노드의 kubelet, 컨트롤 플레인 구성원까지 클러스터 안팎의 모든 프로세스는 API 서버에 요청할 때 인증하거나 익명 사용자로 처리되어야 해요.

Roles, ClusterRoles, RoleBindings, ClusterRoleBindings

Kubernetes에서 사용자 계정과 서비스 계정은 접근 권한이 부여된 리소스만 보고 편집할 수 있어요. 이 접근 권한은 Roles와 RoleBindings를 통해 부여돼요. Roles와 RoleBindings는 특정 네임스페이스에 바인딩되며, Role이 접근을 제공하는 해당 네임스페이스 내 리소스를 보고/편집할 수 있는 능력을 사용자에게 부여해요.

클러스터 범위에서는 이것들이 ClusterRoles와 ClusterRoleBindings라고 불러요. 사용자에게 ClusterRole을 부여하면 클러스터 전체의 리소스를 보고/편집할 수 있는 접근 권한이 부여돼요. 클러스터 범위(네임스페이스, 리소스 쿼터, 노드)의 리소스를 보고/편집하는 데도 필요해요.

ClusterRoles는 RoleBinding의 참조를 통해 특정 네임스페이스에 바인딩될 수 있어요. 기본 ClusterRole인 admin, edit, view가 이런 방식으로 흔히 사용돼요.

이것들은 Kubernetes에서 기본으로 제공하는 몇 가지 ClusterRole이에요. 사용자 대상 역할로 의도됐어요. 최고 권한 역할(cluster-admin)과 더 세분화된 접근 권한을 가진 역할(admin, edit, view)을 포함해요.

RBAC로 사용자 계정 접근 제한

Role-based Access Control의 기본을 이해했으니, 관리자가 사용자의 접근 범위를 어떻게 제한할 수 있는지 논의해 볼게요.

예제: 특정 네임스페이스에 사용자에게 읽기/쓰기 접근 부여

사용자의 특정 네임스페이스 접근을 제한하려면 edit 또는 admin 역할을 사용할 수 있어요. 차트가 Roles와 Rolebindings를 만들거나 상호작용한다면 admin ClusterRole을 사용하고 싶을 거예요.

또한 cluster-admin 접근 권한이 있는 RoleBinding을 만들 수도 있어요. 네임스페이스 범위에서 사용자에게 cluster-admin 접근을 부여하면 네임스페이스 자체를 포함해 네임스페이스의 모든 리소스를 완전히 제어할 수 있어요.

이 예제에서는 edit Role을 가진 사용자를 만들 거예요. 먼저 네임스페이스를 만들어요:

$ kubectl create namespace foo

이제 그 네임스페이스에 RoleBinding을 만들어 사용자에게 edit 역할을 부여해요.

$ kubectl create rolebinding sam-edit
    --clusterrole edit \
    --user sam \
    --namespace foo

예제: 클러스터 범위에서 사용자에게 읽기/쓰기 접근 부여

사용자가 클러스터 범위 리소스(네임스페이스, roles, 커스텀 리소스 정의 등)를 설치하는 차트를 설치하려 한다면 클러스터 범위 쓰기 접근이 필요해요.

그렇게 하려면 사용자에게 admin 또는 cluster-admin 접근을 부여해요.

사용자에게 cluster-admin 접근을 부여하면 kubectl drain을 사용한 노드 접근과 다른 관리 작업을 포함해 Kubernetes에서 사용 가능한 절대적으로 모든 리소스에 접근할 수 있게 해 줘요. 대신 사용자에게 admin 접근을 제공하거나 사용자 요구에 맞는 커스텀 ClusterRole을 만드는 것을 강력히 권장해요.

$ kubectl create clusterrolebinding sam-view
    --clusterrole view \
    --user sam

$ kubectl create clusterrolebinding sam-secret-reader
    --clusterrole secret-reader \
    --user sam

예제: 특정 네임스페이스에 사용자에게 읽기 전용 접근 부여

secrets를 보는 데 사용할 수 있는 ClusterRole이 없다는 것을 눈치챘을 거예요. view ClusterRole은 escalate 우려 때문에 사용자에게 Secrets 읽기 접근을 부여하지 않아요. Helm은 기본적으로 릴리스 메타데이터를 Secrets로 저장해요.

사용자가 helm list를 실행하려면 이 secrets를 읽을 수 있어야 해요. 그래서 특별한 secret-reader ClusterRole을 만들 거예요.

cluster-role-secret-reader.yaml 파일을 만들고 다음 내용을 작성해요:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

그런 다음 ClusterRole을 만들어요:

$ kubectl create -f cluster-role-secret-reader.yaml

완료되면 사용자에게 대부분 리소스에 대한 읽기 접근을 부여한 후 secrets에 대한 읽기 접근을 부여할 수 있어요:

$ kubectl create namespace foo

$ kubectl create rolebinding sam-view
    --clusterrole view \
    --user sam \
    --namespace foo

$ kubectl create rolebinding sam-secret-reader
    --clusterrole secret-reader \
    --user sam \
    --namespace foo

예제: 클러스터 범위에서 사용자에게 읽기 전용 접근 부여

특정 시나리오에서는 사용자에게 클러스터 범위 접근을 부여하는 것이 유리할 수 있어요. 예를 들어 사용자가 helm list --all-namespaces 명령을 실행하려면 API가 사용자에게 클러스터 범위 읽기 접근을 요구해요.

그렇게 하려면 위에서 설명한 대로 view와 secret-reader 접근을 모두 부여하되 ClusterRoleBinding으로 해요.

$ kubectl create clusterrolebinding sam-view
    --clusterrole view \
    --user sam

$ kubectl create clusterrolebinding sam-secret-reader
    --clusterrole secret-reader \
    --user sam

추가 고려 사항

위에 보여 준 예제는 Kubernetes와 함께 제공되는 기본 ClusterRoles를 활용해요. 사용자에게 부여되는 리소스에 대한 더 세밀한 제어를 원한다면, 자신만의 커스텀 Roles와 ClusterRoles를 만드는 방법에 대한 Kubernetes 문서를 참고하세요.

더 알아보기 (Learn more)

• Kubernetes RBAC 문서
• 라이브러리 차트