0Pricing
Docker & Kubernetes for Developers · 课时

基于角色的访问控制(RBAC)

配置 RBAC,以安全地管理 Kubernetes 集群中的用户和服务账户权限。

基于角色的访问控制(RBAC) 是 CoddyKit 上的免费 Docker & Kubernetes for Developers 课时。 这是第 1 节课,共 4 节。 你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 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, apps for 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 default

Example: 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.io

Quick 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)」的完整文本可在网页上免费阅读。要进行交互式练习(内置代码编辑器和全天候 AI 导师)并解锁 Docker & Kubernetes for Developers 课程的其余内容,请升级到 CoddyKit PRO。 Docker & Kubernetes for Developers 课程共包含 4 节课。

「基于角色的访问控制(RBAC)」这节课中我会学到什么?

配置 RBAC,以安全地管理 Kubernetes 集群中的用户和服务账户权限。 你通过在浏览器中直接运行的动手代码来练习 Docker & Kubernetes for Developers,全天候 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 反馈 — 无需本地设置。

此课程中的所有课时

  1. 基于角色的访问控制(RBAC)
  2. Pod 安全与镜像扫描
  3. 保护 Kubernetes 网络流量
  4. 使用外部密钥存储安全管理 Secrets
← 返回 Docker & Kubernetes for Developers