Oracle Cloud Native Environment에서 역할 기반 접근 제어 사용
소개
Kubernetes 클러스터에 대한 배치 수가 증가하면 이를 관리하는 데 도움이 필요할 수 있습니다. Kubernetes API는 사용자를 추가하고 클러스터에 대한 권한을 정의하는 기능을 제공합니다.
사용자가 인증되면 Kubernetes는 사용자에게 수행 권한이 부여된 작업을 확인합니다. 역할 기반 액세스 제어(RBAC)는 Kubernetes에서 기본적으로 지원되며 Oracle Cloud Native Environment(Oracle CNE)에서 기본적으로 사용으로 설정됩니다. 일반적으로 사용되는 액세스 제어 방법 중 하나로 설정합니다. RBAC를 사용하면 클러스터 리소스에 대한 사용자 액세스를 제한하는 규칙을 적용하여 Kubernetes 환경에 배치된 리소스에 대한 액세스를 관리할 수 있습니다. 이러한 규칙은 역할을 사용하여 이름 공간 제한 또는 ClusterRole를 사용하여 클러스터 전체일 수 있습니다.
다음과 같은 Kubernetes에서 RBAC(역할 기반 액세스 제어)의 주요 구성 요소를 이해하는 것이 도움이 됩니다.
- 역할: 네임스페이스 내에서 허용되는 작업을 정의하는 정의된 권한 집합입니다.
- RoleBindings: 네임스페이스 내의 사용자 또는 서비스 계정에 롤을 바인드하는 데 사용됩니다.
- ClusterRole: 클러스터의 모든 네임스페이스에서 허용되는 작업을 정의하는 정의된 권한 집합입니다.
- ClusterRoleBindings: 클러스터의 모든 네임스페이스에서 ClusterRole을 사용자 또는 서비스 계정에 바인드하는 데 사용됩니다.
- 제목: 역할 또는 ClusterRoles에 바인드된 사용자, 그룹 또는 서비스 계정입니다.
- 권한: 롤 또는 ClusterRole이 지정된 리소스에 대해 수행할 수 있는 허용된 작업을 정의합니다. 사용자 또는 서비스 계정이 아닌 역할 및 클러스터 역할과 연관됩니다.
Kubernetes 클러스터에 대한 액세스를 관리하는 또 다른 방법은 Attribute-Based Access Control (ABAC)로, RBAC에 비해 보다 미세한 정책 튜닝이 가능합니다. 그러나 이것은이 튜토리얼의 범위를 벗어납니다.
이 사용지침서에서는 RBAC를 사용하여 Kubernetes 클러스터에 대한 액세스를 관리하는 방법에 대해 설명하고 간단한 사용 사례를 설명합니다.
Oracle Cloud Native Environment 2에 대한 자세한 내용은 현재 릴리스 설명서 사이트를 참조하십시오.
목표
이 자습서에서는 다음 내용을 학습합니다.
- 이름 공간별 사용자 권한 제한을 보여주는 역할을 만듭니다.
- 클러스터 전체에서 사용자 권한 부여를 보여주는 ClusterRole를 생성합니다.
필요 조건
- Oracle Cloud Native Environment(Oracle CNE) 설치
- 단일 제어 노드 및 하나의 워커 노드
Oracle Cloud Native Environment 구성
주: 고유 테넌시에서 실행 중인 경우 linux-virt-labs GitHub 프로젝트 README.md를 읽고 실습 환경을 배치하기 전에 필요 조건을 완료하십시오.
-
루나 데스크탑에서 터미널을 엽니다.
-
linux-virt-labsGitHub 프로젝트를 복제합니다.git clone https://github.com/oracle-devrel/linux-virt-labs.git -
작업 디렉토리로 변경합니다.
cd linux-virt-labs/ocne2 -
필요한 모음을 설치합니다.
ansible-galaxy collection install -r requirements.yml -
lab 환경을 배치합니다.
ansible-playbook create_instance.yml -e localhost_python_interpreter="/usr/bin/python3.6" -e install_ocne_rpm=true -e create_ocne_cluster=true -e "ocne_cluster_node_options='-n 1 -w 1'"무료 실습 환경에는 localhost에서 실행되는 재생에 대해
ansible_python_interpreter를 설정하는 추가 변수local_python_interpreter이 필요합니다. 이 변수는 환경이 python3.6 모듈 아래에 있는 Oracle Cloud Infrastructure SDK for Python용 RPM 패키지를 설치하기 때문에 필요합니다.기본 배치 구성은 AMD CPU 및 Oracle Linux 8을 사용합니다. Intel CPU 또는 Oracle Linux 9를 사용하려면 배치 명령에
-e instance_shape="VM.Standard3.Flex"또는-e os_version="9"를 추가합니다.중요: 플레이북이 성공적으로 실행될 때까지 기다렸다가 일시 중지 작업에 도달합니다. 플레이북의 이 단계에서 Oracle CNE 설치가 완료되고 인스턴스가 준비됩니다. 이전 플레이에서 배치하는 노드의 공용(public) 및 전용(private) IP 주소와 실습을 실행하는 동안 필요한 기타 배치 정보를 출력합니다.
Kubernetes 클러스터 액세스
-
터미널을 열고 SSH를 통해 ocne 인스턴스에 연결합니다.
ssh oracle@<ip_address_of_instance> -
클러스터가 안정화되고 모든 포드가 실행 중 상태로 보고될 때까지 기다립니다.
watch kubectl get pods -A모든 포드가 Running의 STATUS를 표시하면
Ctrl-C를 입력하여watch명령을 종료합니다. -
노드가 몇 개 있는지 확인합니다.
kubectl get nodes
현재 RBAC 구성 확인
RBAC는 Kubernetes 클러스터에 배포된 리소스에 대해 수행하는 작업에 대한 권한을 관리합니다. RBAC가 사용으로 설정되었는지 확인하고 클러스터의 기본 역할을 검토합니다.
-
RBAC가 사용으로 설정되었는지 확인합니다.
rbac.authorization.k8s.ioAPI가 표시되는 경우 RBAC가 구성되고 사용자 또는 서비스 계정이 클러스터 리소스에서 수행할 수 있는 작업을 제어하는 데 사용됩니다.kubectl api-versions | grep rbac출력 예:
[oracle@ocne ~]$ kubectl api-versions | grep rbac rbac.authorization.k8s.io/v1 -
내장 클러스터 역할을 표시합니다.
kubectl get clusterroles | grep admin출력 예:
[oracle@ocne ~]$ kubectl get clusterroles | grep admin admin 2025-07-23T10:21:55Z cluster-admin 2025-07-23T10:21:55Z system:aggregate-to-admin 2025-07-23T10:21:55Z system:kubelet-api-admin 2025-07-23T10:21:55Z일반 사용자는
admin및cluster-admin역할을 사용하고 RBAC API는 내부 구성 요소에 대해system:역할을 예약합니다. -
cluster-admin에 대한 권한을 나열합니다.kubectl describe clusterrole cluster-admin출력 예:
[oracle@ocne ~]$ kubectl describe clusterrole cluster-admin Name: cluster-admin Labels: kubernetes.io/bootstrapping=rbac-defaults Annotations: rbac.authorization.kubernetes.io/autoupdate: true PolicyRule: Resources Non-Resource URLs Resource Names Verbs --------- ----------------- -------------- ----- *.* [] [] [*] [*] [] [*]동사 및 리소스 열의 별표는
cluster-admin역할이 모든 작업을 수행할 수 있음을 의미합니다. 각 Kubernetes 릴리스에 사용 가능한 작업(동사)의 상위 레벨 목록은 해당 릴리스의 API 개요에서 확인할 수 있습니다. 예를 들어 Kubernetes v1.33.0에서 확인할 수 있습니다. 각 Resource 유형에 사용 가능한 유효한 작업(Verbs)의 세부 목록은 명령줄에서kubectl api-resources -o wide를 실행하여 확인할 수 있습니다.그러나
kubectl에 로그인하지 않았기 때문에 Kubernetes는 명령을 실행하는 사용자가 누구인지 어떻게 알 수 있습니까? 운용 시스템은 일반적으로 인증에 LDAP 서버를 사용합니다. 외부 인증 시스템을 사용할 수 없는 경우 ServiceAccount를 사용할 수 있습니다.주: ServiceAccounts는 CI/CD 파이프라인과 같은 자동화된 워크로드에서 사용되지만 테스트에도 사용할 수 있습니다.
역할 생성
롤은 단일 네임스페이스 내에서 Kubernetes 리소스에 액세스하기 위한 권한을 정의하는 네임스페이스 제한 리소스입니다.
네임스페이스 및 롤 생성
-
네임스페이스를 생성합니다.
이 예제에 대해 새 네임스페이스를 생성합니다.
kubectl create namespace rbac-example -
롤 생성.
rbac-example 이름 공간 내에서 pods 및 deployments에 대한 읽기 전용 액세스('get' 및 'list' 권한)를 부여하는 역할을 만듭니다.
cat << EOF | tee pod-reader-role.yaml > /dev/null apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: pod-reader namespace: rbac-example rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "list"] - apiGroups: ["apps"] resources: ["deployments"] verbs: ["get", "list"] EOF설명:
rules:- 롤에 부여된 권한을 정의합니다. 이 예에서는 두 가지 규칙을 정의합니다(아래 참조).apiGroups: [""]- 이 규칙에 바인드된 사용자 또는 서비스 계정이rbac-example네임스페이스에서 POD를 검색하고 나열하도록 허용합니다.apiGroups: ["apps"]- 이 규칙에 바인드된 사용자 또는 서비스 계정이rbac-example네임스페이스에서 배치를 검색하고 나열하도록 허용합니다.
-
파일을 적용합니다.
kubectl apply -f pod-reader-role.yaml -
새로 생성된 pod-reader 역할에 대한 권한을 확인합니다.
kubectl describe role/pod-reader -n rbac-example출력 예:
[oracle@ocne ~]$ kubectl describe role/pod-reader -n rbac-example Name: pod-reader Labels: <none> Annotations: <none> PolicyRule: Resources Non-Resource URLs Resource Names Verbs --------- ----------------- -------------- ----- pods [] [] [get list] deployments.apps [] [] [get list]
사용자 만들기 및 역할에 바인드
-
pod-reader-user라는 새 ServiceAccount 사용자를 만들고 이를 pod-reader 역할에 바인딩합니다.
cat << EOF | tee pod-reader-user.yaml > /dev/null apiVersion: v1 kind: ServiceAccount metadata: name: pod-reader-user namespace: rbac-example --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: pod-reader-binding namespace: rbac-example roleRef: name: pod-reader kind: Role subjects: - kind: ServiceAccount name: pod-reader-user namespace: rbac-example EOF설명:
- ServiceAccount는 서비스 계정을 만듭니다.
name:- 서비스 계정 사용자의 이름(pod-reader-user)입니다.namespace- 생성된 네임스페이스(rbac-example)입니다.
- RoleBinding는 이름 공간 관련 권한을 서비스 계정에 부여합니다.
roleRef:- 바인딩 롤을 지정합니다. 이 예에서는pod-reader이라는 롤을 참조합니다.subjects:- 권한을 부여할 엔티티를 지정합니다. 이 예에서는pod-reader-user이라는 서비스 계정을 사용합니다.
- ServiceAccount는 서비스 계정을 만듭니다.
-
파일을 적용합니다.
kubectl apply -f pod-reader-user.yaml
RoleBinding 테스트
그런 다음 새 Pod를 생성하고 새로 생성된 pod-reader-user 서비스 계정을 사용하여 액세스하여 RoleBinding를 테스트합니다.
-
새 테스트 배치를 생성합니다.
cat << EOF | tee testpod.yaml > /dev/null apiVersion: v1 kind: Pod metadata: name: test-pod namespace: rbac-example spec: containers: - name: test-container image: ghcr.io/oracle/oraclelinux9-nginx:1.20 ports: - containerPort: 80 serviceAccountName: pod-reader-user EOF설명:
spec:는 포드의 원하는 상태를 정의합니다.containers:- POD에서 실행할 컨테이너 목록을 지정합니다. 이 예에서는 컨테이너가 하나만 있습니다.name:- 컨테이너의 이름입니다(test-container).image:- 사용할 이미지입니다(ghcr.io/oracle/oraclelinux9-nginx:1.20).ports:- 컨테이너에 의해 노출되는 포트를 지정합니다. 이 예에서는 포트 80(containerPort: 80)입니다.
serviceAccountName:- Pod에 사용할 서비스 계정을 지정합니다. 이 구성에서 Pod는pod-reader-user서비스 계정에 지정된 권한과 자격 증명을 사용합니다.
-
파일을 적용합니다.
kubectl apply -f testpod.yaml -
이제 pod-reader-user ServiceAccount를 사용하여 Pod에 액세스해 보십시오.
kubectl auth can-i get pod/test-pod --as=system:serviceaccount:rbac-example:pod-reader-user -n rbac-examplepod-reader-user가 Pod에 액세스할 수 있는 권한을 가지고 있음을 나타내는 출력으로
yes가 표시되어야 합니다.주:
kubectl auth can-i기능을 사용하여 새로 생성된 ServiceAccount 사용자 계정으로 명령을 실행하여 작업이 허용되는지 확인합니다. -
ServiceAccount가 예상대로 작동하는지 확인합니다.
kubectl --as=system:serviceaccount:rbac-example:pod-reader-user get pods -n rbac-example출력 예:
[oracle@ocne ~]$ kubectl --as=system:serviceaccount:rbac-example:pod-reader-user get pods -n rbac-example NAME READY STATUS RESTARTS AGE test-pod 1/1 Running 0 109s -
pod-reader-user롤을 사용하여 Pod를 삭제해 보십시오.kubectl --as=system:serviceaccount:rbac-example:pod-reader-user delete pod test-pod -n rbac-example출력 예:
[oracle@ocne ~]$ kubectl --as=system:serviceaccount:rbac-example:pod-reader-user delete pod test-pod -n rbac-example Error from server (Forbidden): pods "test-pod" is forbidden: User "system:serviceaccount:rbac-example:pod-reader-user" cannot delete resource "pods" in API group "" in the namespace "rbac-example"pod-reader-user롤은rbac-example에서 POD를 삭제할 수 없습니다. 새로운 포드를 시작할 수 있습니까? -
pod-reader-role롤을 사용하여 Pod를 실행해 보십시오.kubectl run nginx1 --image=ghcr.io/oracle/oraclelinux9-nginx:1.20 --as=system:serviceaccount:default:my-serviceaccount -n rbac-example출력 예:
[oracle@ocne ~]$ kubectl run nginx1 --image=ghcr.io/oracle/oraclelinux9-nginx:1.20 --as=system:serviceaccount:rbac-example:pod-reader-user -n rbac-example Error from server (Forbidden): pods is forbidden: User "system:serviceaccount:rbac-example:pod-reader-user" cannot create resource "pods" in API group "" in the namespace "rbac-example"이 오류는
pod-reader-user역할이 클러스터의 rbac-example 네임스페이스에 있는 Pod 리소스에 대해get및list작업을 수행할 수 있도록 허용되기 때문에 정확합니다. 다른 작업 delete 또는 create는 허용되지 않습니다.
ClusterRole 생성
ClusterRoles는 역할과 유사하지만 전체 클러스터에서 리소스에 대해 허용되는 권한을 정의합니다.
주: 너무 넓은 권한을 부여할 때는 주의해야 합니다. 대신 최소 '최소 권한의 원칙'을 사용하여 지정된 작업을 완료하는 데 필요한 권한만 사용자와 서비스 계정에 부여합니다.
ClusterRole 및 ClusterRoleBinding 생성
이전 예에서는 이름 공간 관련 사용자 및 역할을 만드는 방법을 보여주었습니다. 다음 단계에서는 ClusterRole를 만들고 이를 사용자에게 바인드하여 클러스터 전체 관리 액세스 권한을 부여하는 방법을 보여줍니다.
-
새 ClusterRole를 생성합니다.
이 ClusterRole를 사용하면 사용자가 클러스터의 모든 리소스에 대해 작업을 수행할 수 있습니다.
cat << EOF | tee cluster-admin-clusterrole.yaml > /dev/null apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: cluster-admin-cr rules: - apiGroups: ["*"] resources: ["*"] verbs: ["*"] EOF설명:
rules:- ClusterRole에 부여된 권한을 정의합니다. 이 예에는 하나의 규칙만 있습니다.apiGroups: ["*"]- 모든 API 그룹에 적용되는 규칙을 지정합니다.resources: ["*"]- 규칙이 API 그룹의 모든 리소스에 적용되도록 지정합니다.verbs: ["*"]- 규칙이get,list,create,delete등 리소스에 대해 가능한 모든 동사를 부여하도록 지정합니다.
-
파일을 적용합니다.
kubectl apply -f cluster-admin-clusterrole.yaml -
ClusterRole를 새 유저에 바인드하는 ClusterRoleBinding를 생성합니다.
ClusterRoleBinding는 이전에 생성한 RoleBinding와 유사하지만 클러스터 범위입니다.
cat << EOF | tee cluster-admin-user.yaml > /dev/null apiVersion: v1 kind: ServiceAccount metadata: name: cluster-admin-user namespace: rbac-example --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: cluster-admin-crb roleRef: name: cluster-admin-cr kind: ClusterRole subjects: - kind: ServiceAccount name: cluster-admin-user namespace: rbac-example EOF설명:
subjects:- ClusterRole에서 권한을 부여할 엔티티를 정의합니다. 이 예에서는cluster-admin-user서비스 계정입니다.
-
파일을 적용합니다.
kubectl apply -f cluster-admin-user.yaml
ClusterRoleBinding 테스트
-
다른 네임스페이스의 리소스에 액세스하려고 시도하여 클러스터 롤을 테스트합니다. 예를 들어, default 이름 공간입니다.
kubectl auth can-i list pods --as=system:serviceaccount:rbac-example:cluster-admin-user -n defaultcluster-admin-user에 cluster-admin 액세스 권한이 있음을 나타내는 출력으로
yes가 표시되어야 합니다. -
새로 생성된 ClusterRole가 예상대로 작동하는지 확인합니다.
kubectl --as=system:serviceaccount:rbac-example:cluster-admin-user get pods -A출력 예:
[oracle@ocne ~]$ kubectl --as=system:serviceaccount:rbac-example:cluster-admin-user get pods -A NAMESPACE NAME READY STATUS RESTARTS AGE kube-flannel kube-flannel-ds-ptwkz 1/1 Running 0 6h58m kube-flannel kube-flannel-ds-wn2g6 1/1 Running 0 6h58m kube-system coredns-7cbdbfd99c-7xqkl 1/1 Running 0 6h59m kube-system coredns-7cbdbfd99c-k2ssb 1/1 Running 0 6h59m kube-system etcd-ocne-control-plane-1 1/1 Running 0 6h59m kube-system kube-apiserver-ocne-control-plane-1 1/1 Running 0 6h59m kube-system kube-controller-manager-ocne-control-plane-1 1/1 Running 0 6h59m kube-system kube-proxy-48rm5 1/1 Running 0 6h59m kube-system kube-proxy-h4kd2 1/1 Running 0 6h58m kube-system kube-scheduler-ocne-control-plane-1 1/1 Running 0 6h59m ocne-system ocne-catalog-577b7cd5f9-bnvtm 1/1 Running 0 6h58m ocne-system ui-846bddd4b-lnrwm 1/1 Running 0 6h58m rbac-example test-pod 1/1 Running 0 6h34m이 출력은 새로 생성된 ClusterRole가 클러스터에 정의된 모든 이름 공간에 액세스할 수 있음을 확인합니다.
ClusterRole 사용자가 새 배치를 생성할 수 있는지 확인
ClusterRole를 테스트하여 할당된 유저가 새 배치를 생성할 수 있는지 확인합니다. 그런 다음 새로 생성된 ClusterRole를 사용하여 액세스해 봅니다.
-
새 테스트 배치를 생성합니다.
cat << EOF | tee testpod2.yaml > /dev/null apiVersion: v1 kind: Pod metadata: name: test-pod2 namespace: default spec: containers: - name: test-container image: ghcr.io/oracle/oraclelinux9-nginx:1.20 ports: - containerPort: 8080 EOF이 배치는 이전에 사용된 rbac-example 네임스페이스가 아닌 'default' 네임스페이스에 배치됩니다.
-
파일을 적용합니다.
kubectl apply -f testpod2.yaml -
배치가 성공적으로 완료되었는지 확인합니다.
kubectl --as=system:serviceaccount:rbac-example:cluster-admin-user get pods -A출력 예:
[oracle@ocne ~]$ kubectl --as=system:serviceaccount:rbac-example:cluster-admin-user get pods -A NAMESPACE NAME READY STATUS RESTARTS AGE default test-pod2 1/1 Running 0 28s kube-flannel kube-flannel-ds-shgh7 1/1 Running 0 38m kube-flannel kube-flannel-ds-zzrgh 1/1 Running 0 38m kube-system coredns-7cbdbfd99c-jg6lz 1/1 Running 0 38m kube-system coredns-7cbdbfd99c-wh5g4 1/1 Running 0 38m kube-system etcd-ocne-control-plane-1 1/1 Running 0 38m kube-system kube-apiserver-ocne-control-plane-1 1/1 Running 0 38m kube-system kube-controller-manager-ocne-control-plane-1 1/1 Running 0 38m kube-system kube-proxy-5qngx 1/1 Running 0 38m kube-system kube-proxy-6fz2q 1/1 Running 0 38m kube-system kube-scheduler-ocne-control-plane-1 1/1 Running 0 38m ocne-system ocne-catalog-577b7cd5f9-vz782 1/1 Running 0 38m ocne-system ui-846bddd4b-bbhtj 1/1 Running 0 38m rbac-example test-pod 1/1 Running 0 21m새 ClusterRole가 다른 네임스페이스에 대한 새 배치를 허용하는지 확인합니다.
다음 단계
이 사용지침서에서는 Kubernetes 리소스에 대한 액세스를 관리할 롤을 생성하여 Kubernetes와 함께 역할 기반 액세스 제어(RBAC)를 설정하고 사용하는 방법을 보여줍니다. 이렇게 하려면 역할과 바인딩을 정의하여 이름 공간 내 리소스 또는 클러스터 전체에서 허용된 작업을 제어해야 합니다. 이러한 방식으로 RBAC가 제공하는 세분화된 제어는 특히 대규모 배포의 경우 Kubernetes 환경을 보호하는 데 필수적입니다. 추가 튜토리얼과 내용은 Oracle Linux Training Station을 확인하십시오.
관련 링크
추가 학습 자원
docs.oracle.com/learn에서 다른 랩을 탐색하거나 Oracle Learning YouTube 채널에서 더 많은 무료 학습 콘텐츠에 액세스하세요. 또한 education.oracle.com/learning-explorer를 방문하여 Oracle Learning Explorer가 되십시오.
제품 설명서는 Oracle Help Center를 참조하십시오.
Use Role-Based Access Control with Oracle Cloud Native Environment
G40839-01