通过 Oracle Cloud Native Environment 使用基于角色的访问控制

简介

随着 Kubernetes 集群部署数量的增加，您可能需要帮助来管理它。Kubernetes API 支持添加用户并定义其对集群的权限。

用户通过验证后，Kubernetes 将验证用户有权执行的操作。基于角色的访问控制 (Role-Based Access Control，RBAC) 由 Kubernetes 原生支持，默认情况下在 Oracle Cloud Native Environment (Oracle CNE) 中启用。使之成为常用的访问控制方法之一。通过 RBAC，您可以通过应用限制用户访问集群资源的规则来管理对部署到 Kubernetes 环境的资源访问。这些规则可以使用 Role 限制名称空间，也可以使用 ClusterRole 限制群集范围。

您会发现了解 Kubernetes 中基于角色的访问控制 (Role-Based Access Control，RBAC) 的关键组件很有帮助，这些组件包括：

角色：定义一组在名称空间中定义允许操作的权限。
RoleBindings：用于将角色绑定到名称空间中的用户或服务帐户。
ClusterRole：定义一组允许在群集中的所有名称空间中执行的操作的权限。
ClusterRoleBindings：用于将 ClusterRole 绑定到群集内所有名称空间中的用户或服务帐户。
主题：这些是绑定到 Roles 或 ClusterRoles 的用户、组或服务帐户。
权限：这些权限定义角色（或 ClusterRole）可以对指定资源执行的允许操作。它们与角色和群集角色关联，而不是与用户或服务帐户关联。

另一种管理 Kubernetes 集群访问的方法是 Attribute-Based Access Control (ABAC) ，与 RBAC 相比，它可以更精细地优化策略。但这超出了本教程的范围。

本教程介绍了使用 RBAC 管理对 Kubernetes 集群的访问的基础知识，并演示了一个简单的用例。

有关 Oracle Cloud Native Environment 2 的更多信息，请参阅当前 Release Documentation 站点。

目标

在本教程中，您将学习：

创建一个角色以演示如何按名称空间限制用户权限。
创建 ClusterRole 以演示在集群范围内授予用户权限。

先决条件

安装 Oracle Cloud Native Environment (Oracle CNE)
单个控制节点和一个 Worker 节点

配置 Oracle Cloud Native Environment

注：如果在您自己的租户中运行，请在部署实验环境之前阅读 linux-virt-labs GitHub 项目 README.md 并完成先决条件。

在 Luna Desktop 上打开一个终端。

克隆 linux-virt-labs GitHub 项目。

git clone https://github.com/oracle-devrel/linux-virt-labs.git

转到工作目录。
```
cd linux-virt-labs/ocne2
```

安装所需集合。

ansible-galaxy collection install -r requirements.yml

部署实验室环境。
```
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'"
```
免费的实验环境需要额外的变量 local_python_interpreter，该变量为在 localhost 上运行的播放设置 ansible_python_interpreter。此变量是必需的，因为环境安装了适用于 Python 的 Oracle Cloud Infrastructure SDK 的 RPM 程序包，该程序包位于 python3.6 模块下。

默认部署配置使用 AMD CPU 和 Oracle Linux 8。要使用 Intel CPU 或 Oracle Linux 9，请将 -e instance_shape="VM.Standard3.Flex" 或 -e os_version="9" 添加到部署命令。

重要提示：等待手册成功运行并到达暂停任务。在手册的这一阶段，Oracle CNE 安装已完成，实例已准备就绪。记下之前的剧集，其中输出其部署的节点的公共和专用 IP 地址，以及运行实验时所需的任何其他部署信息。

访问 Kubernetes 集群

打开终端并通过 SSH 连接到 ocne 实例。
```
ssh oracle@<ip_address_of_instance>
```
等待群集稳定下来，并且所有 pod 都报告为正在运行状态。
```
watch kubectl get pods -A
```
当所有 pod 显示 STATUS 为 Running 时，键入 Ctrl-C 以退出 watch 命令。
确认存在多少个节点。
```
kubectl get nodes
```

确认当前 RBAC 配置

RBAC 管理您对部署到 Kubernetes 集群上的资源执行的操作的权限。您将检查是否已启用 RBAC，并查看集群中的默认角色。

确认已启用 RBAC。

如果 rbac.authorization.k8s.io API 可见，则表示已配置 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 角色可以执行任何操作。该发行版的 API 概述中提供了每个 Kubernetes 发行版可用的操作（动词）的概括列表。例如，在 Kubernetes v1.33.0 中。通过从命令行执行 kubectl api-resources -o wide，可以获得适用于每个 Resource 类型的有效操作 ( Verbs ) 的详细列表。

但是，由于您未登录到 kubectl，Kubernetes 如何知道执行命令的用户是谁？生产系统通常使用 LDAP 服务器进行验证。如果外部验证系统不可用，则可以使用 ServiceAccount 。

注：ServiceAccounts 由自动化工作负荷（例如 CI/CD 管道）使用，但也可以用于测试。

创建角色

角色是受名称空间限制的资源，用于定义在单个名称空间内访问 Kubernetes 资源的权限。

创建名称空间和角色

创建名称空间。

为此示例创建新名称空间。
```
kubectl create namespace rbac-example
```
创建角色。

创建一个角色，授予对 rbac-example 名称空间中的 pods 和 deployments 的只读访问权限（“获取”和“列出”权限）。
```
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 名称空间中的云池。
- 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 的服务帐户。
应用该文件。
```
kubectl apply -f pod-reader-user.yaml
```

测试 RoleBinding

接下来，通过创建新 Pod 并使用新创建的 pod-reader-user 服务帐户访问 RoleBinding 来测试该 Pod。

创建新的测试部署。
```
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: 定义 pod 的所需状态。
  - containers:- 指定要在云池中运行的容器列表。在此示例中，只有一个容器。
    - 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-example
```
您应将 yes 视为输出，指示 pod-reader-user 具有访问 pod 的权限。

注：使用 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 与 Roles 类似，但它们为整个群集中的资源定义允许的权限。

注：授予过于宽泛的权限时，请务必谨慎。而是使用最少的“最小权限原则”仅向用户和服务帐户授予完成其分配任务所需的权限。

创建 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

创建 ClusterRoleBinding 以将 ClusterRole 绑定到新用户。

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 default
```
您应将 yes 视为输出，指示 cluster-admin-user 具有群集管理员访问权限。

确认新创建的 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

请注意，此部署将部署到 ‘ default ’ 名称空间，而不是之前使用的 rbac-example 名称空间。

应用该文件。
```
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 中设置和使用基于角色的访问控制 (Role-Based Access Control，RBAC)。可以通过定义角色和绑定来控制允许对名称空间内的资源执行哪些操作，或者在群集范围内执行哪些操作来实现此目的。通过这种方式，RBAC 提供的细粒度控制对于保护 Kubernetes 环境（尤其是对于大型部署）至关重要。有关其他教程和内容，请查看 Oracle Linux 培训站。

通过 Oracle Cloud Native Environment 使用基于角色的访问控制

简介

目标

先决条件

配置 Oracle Cloud Native Environment

访问 Kubernetes 集群

确认当前 RBAC 配置

创建角色

创建名称空间和角色

创建用户并绑定到角色

测试 RoleBinding

创建 ClusterRole

创建 ClusterRole 和 ClusterRoleBinding

测试 ClusterRoleBinding

确认 ClusterRole 用户可以创建新部署

后续步骤

相关链接

更多学习资源