ロールベースアクセス制御(RBAC)
RBACを設定し、Kubernetesクラスター内のユーザーとサービスアカウントの権限を安全に管理します。
「ロールベースアクセス制御(RBAC)」はCoddyKit上の無料Docker & Kubernetes for Developersレッスンです。 これはレッスン1/4です。 下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応の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時間対応のAIチューター)、Docker & Kubernetes for Developersコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 Docker & Kubernetes for Developersコースには全4レッスンが含まれています。
「ロールベースアクセス制御(RBAC)」で何を学びますか?
RBACを設定し、Kubernetesクラスター内のユーザーとサービスアカウントの権限を安全に管理します。 ブラウザで直接実行するハンズオンコードでDocker & Kubernetes for Developersを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。
Docker & Kubernetes for Developersを始めるのに経験は必要ですか?
事前経験は必要ありません。CoddyKitのDocker & Kubernetes for Developersは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。 これはレッスン1/4です。
「ロールベースアクセス制御(RBAC)」レッスンにはどのくらい時間がかかりますか?
ほとんどのCoddyKitレッスンは約5~10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。
このDocker & Kubernetes for Developersレッスンでコードを書いて実行できますか?
はい。すべてのDocker & Kubernetes for Developersレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。
このコースのすべてのレッスン
- ロールベースアクセス制御(RBAC)
- Podセキュリティとイメージスキャン
- Kubernetesネットワークトラフィックの保護
- 外部Secretストアによる安全なSecret管理