역할 기반 접근 제어(RBAC)
Kubernetes 클러스터에서 사용자 및 서비스 계정 권한을 안전하게 관리하도록 RBAC를 구성합니다.
역할 기반 접근 제어(RBAC)은(는) CoddyKit의 무료 Docker & Kubernetes for Developers 강의입니다. 이것은 4개 중 1번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 Docker & Kubernetes for Developers 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. Docker & Kubernetes for Developers 강의에는 총 4개의 강의가 포함되어 있습니다.
이 강의의 일부는 아직 번역되지 않았으며 영어로 표시됩니다.
What is Kubernetes RBAC?
Welcome to Role-Based Access Control (RBAC)! In Kubernetes, RBAC is a method for regulating access to computer or network resources based on the roles of individual users within your organization.
Think of it as the security guard for your cluster: it decides who can do what.
Why RBAC is Essential
RBAC is critical for cluster security and operational integrity. Without it, any user or process with access could potentially perform any action, leading to security vulnerabilities or accidental misconfigurations.
- Security: Prevents unauthorized access.
- Least Privilege: Ensures users/applications only have necessary permissions.
- Compliance: Helps meet regulatory requirements for access control.
RBAC Core Concepts: Subjects
In RBAC, a Subject is 'who' is performing an action. Kubernetes identifies three types of subjects:
- Users: Human users (often managed externally).
- Service Accounts: Identities for processes running in Pods. These are Kubernetes-native.
- Groups: Collections of Users or Service Accounts.
We'll focus on Service Accounts as they are central to application security within Kubernetes.
RBAC Core Concepts: Roles
A Role defines 'what' actions can be performed. Roles are always namespace-scoped, meaning the permissions they grant apply only within a specific namespace.
A Role contains rules, which are sets of permissions. Each rule specifies:
apiGroups: The API group the resource belongs to (e.g.,""for core,appsfor deployments).resources: The specific resource types (e.g.,pods,deployments).verbs: The actions allowed (e.g.,get,list,create,delete).
RBAC Core Concepts: ClusterRoles
Similar to Roles, a ClusterRole also defines 'what' actions can be performed, but it is cluster-scoped. This means its permissions apply across the entire cluster.
ClusterRoles are used for:
- Granting access to cluster-scoped resources (like nodes).
- Granting access to resources across all namespaces.
- Granting access to non-resource endpoints (like
/healthz).
RBAC Core Concepts: RoleBindings
A RoleBinding is 'how' permissions are granted. It links a Subject (User, ServiceAccount, or Group) to a Role.
Like Roles, RoleBindings are namespace-scoped. This means the binding grants the permissions defined in the Role to the Subject, but only within that specific namespace.
RBAC Core Concepts: ClusterRoleBindings
A ClusterRoleBinding links a Subject to a ClusterRole. Because ClusterRoles are cluster-scoped, a ClusterRoleBinding grants permissions across the entire cluster.
Use ClusterRoleBindings carefully, as they grant broad access. They are typically used for cluster administrators or system-level components.
Example: Creating a Service Account
Let's create a Service Account named my-app-sa in the default namespace. This Service Account will be the identity for a future application pod.
Run this command in your terminal:
kubectl create serviceaccount my-app-sa -n defaultExample: Defining a Pod Reader Role
Now, let's define a Role called pod-reader in the default namespace. This Role will allow subjects to get, list, and watch pods.
Save this YAML as pod-reader-role.yaml and apply it using kubectl apply -f pod-reader-role.yaml:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: pod-reader
namespace: default
rules:
- apiGroups: [""] # Core API group
resources: ["pods", "pods/log"]
verbs: ["get", "list", "watch"]Example: Binding the Role
Finally, let's create a RoleBinding named read-pods-binding that links our my-app-sa Service Account to the pod-reader Role in the default namespace.
Save this YAML as pod-reader-binding.yaml and apply it:
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: read-pods-binding
namespace: default
subjects:
- kind: ServiceAccount
name: my-app-sa
namespace: default
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.ioQuick Check: RBAC Resources
Which Kubernetes resource is used to grant cluster-wide permissions to a Service Account?
RBAC: Key Takeaways
You've learned the fundamentals of Kubernetes RBAC!
- Subjects: Who is acting (Users, Service Accounts, Groups).
- Roles/ClusterRoles: What actions are allowed (namespace-scoped vs. cluster-scoped).
- RoleBindings/ClusterRoleBindings: How subjects are linked to permissions (namespace-scoped vs. cluster-scoped).
Mastering RBAC is crucial for securing your Kubernetes applications and infrastructure. Keep practicing with different permission sets!
자주 묻는 질문
“역할 기반 접근 제어(RBAC)” 강의는 무료인가요?
네 — “역할 기반 접근 제어(RBAC)” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 Docker & Kubernetes for Developers 강의 전체를 잠금 해제할 수 있습니다. Docker & Kubernetes for Developers 강의에는 총 4개의 강의가 포함되어 있습니다.
“역할 기반 접근 제어(RBAC)”에서 뭘 배우나요?
Kubernetes 클러스터에서 사용자 및 서비스 계정 권한을 안전하게 관리하도록 RBAC를 구성합니다. 브라우저에서 직접 실행하는 실습 코드로 Docker & Kubernetes for Developers을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.
Docker & Kubernetes for Developers을(를) 시작하는 데 경험이 필요한가요?
사전 경험은 필요하지 않습니다. CoddyKit의 Docker & Kubernetes for Developers은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 1번째 강의입니다.
“역할 기반 접근 제어(RBAC)” 강의는 얼마나 걸리나요?
대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.
이 Docker & Kubernetes for Developers 강의에서 코드를 작성하고 실행할 수 있나요?
네. 모든 Docker & Kubernetes for Developers 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.
이 강의의 모든 강의
- 역할 기반 접근 제어(RBAC)
- 파드 보안 및 이미지 검사
- Kubernetes 네트워크 트래픽 보안
- 외부 Secret 저장소로 Secret을 안전하게 관리하기