【k8s应用管理】kubernetes 安全机制

Kubernetes 安全机制

安全机制概述

Kubernetes 的安全机制围绕掩护 API Server 设计，所有请求需通过 认证（Authentication）、鉴权（Authorization）、准入控制（Admission Control） 三关才气创建资源。
认证（Authentication）

认证方式

认证方式机制分析实用场景HTTP Token 认证通过 Token 字符串辨认用户，Token 存储在 API Server 可访问的文件中。客户端单向认证（服务端验证客户端）。HTTP Base 认证使用 用户名:暗码 的 Base64 编码字符串，通过 HTTP Header 发送。简单场景，安全性较低。HTTPS 证书认证基于 CA 根证书签名的双向认证，客户端和服务端互相验证证书正当性。生产环境，安全性最高。 注意：

• Token 和 Base 认证仅支持单向认证（服务端验证客户端）。
  
• HTTPS 证书认证支持双向认证，是 Kubernetes 推荐的安全方式。
  

必要认证的访问类型

• Kubernetes 组件访问 API Server
  kubectl、kubelet、kube-proxy 等组件需通过 HTTPS 证书认证（端口 6443）。
  
• Pod 访问 API Server
  Pod（如 CoreDNS、Dashboard）需通过 Service Account（SA）的 Token 认证。
  

安全性分析

• Controller Manager 和 Scheduler
  与 API Server 在同一台机器，直接使用非安全端口（如 8080）访问。
  
• 其他组件（kubectl、kubelet）
  必须使用 HTTPS 双向认证（端口 6443）。
  

证书颁发

• 手动签发
  二进制部署时，需手动生成 CA 根证书并签发组件证书。
  
• 自动签发
  
  
  
  • kubelet 首次访问 API Server 时使用 Token 认证。
    
  • 认证通事后，Controller Manager 自动为 kubelet 生成证书，后续访问使用证书认证。
    
  
  

kubeconfig 文件

• 作用：描述集群参数（CA 证书、API Server 地点）、客户端参数（证书、私钥）及上下文（集群名称、用户）。
  
• 默认路径：~/.kube/config
  
• 多集群管理：通过指定差别的 kubeconfig 文件切换集群。
  

示例结构：

1. apiVersion: v1
2. clusters:
3. - cluster:
4.     certificate-authority-data: <CA证书>
5.     server: https://api-server:6443
6.   name: my-cluster
7. contexts:
8. - context:
9.     cluster: my-cluster
10.     user: admin
11.   name: my-context
12. current-context: my-context
13. users:
14. - name: admin
15.   user:
16.     client-certificate-data: <客户端证书>
17.     client-key-data: <客户端私钥>

复制代码

---

Service Account（SA）

1. 核心概念

• 目的：为 Pod 提供动态身份认证，解决 Pod 访问 API Server 的认证题目。
  
• 默认行为：每个 Namespace 自动创建名为 default 的 SA，Pod 未指定 SA 时使用默认 SA。
  

2. SA 组成

组件分析TokenAPI Server 私钥签名的 JWT 令牌，用于身份认证。ca.crtCA 根证书，用于验证 API Server 的证书正当性。namespace标识 SA 所属的 Namespace。 3. Pod 挂载 SA

每个 Pod 自动挂载所属 SA 的 Token、CA 证书和 Namespace 到以下路径：

1. /var/run/secrets/kubernetes.io/serviceaccount/

复制代码

示例查察：

1. kubectl exec -it <pod-name> -- ls /var/run/secrets/kubernetes.io/serviceaccount/
2. # 输出：ca.crt  namespace  token

复制代码

---

Secret 与 SA 的关系

1. Secret 类型

• service-account-token：存储 SA 的认证信息（Token、CA 证书、Namespace）。
  
• Opaque：用户自定义的敏感信息（如暗码、密钥）。
  

2. 查察默认 SA

1. kubectl get sa
2. # 输出示例：
3. NAME      SECRETS   AGE
4. default   1         22d

复制代码

---

示例

查察 Pod 挂载的 SA 信息

1. kubectl exec -it kube-proxy-prdjp -n kube-system shls /var/run/secrets/kubernetes.io/serviceaccount/
2. # 输出：ca.crt  namespace  token

复制代码

创建自定义 SA

1. apiVersion: v1
2. kind: ServiceAccount
3. metadata:
4.   name: my-sa
5.   namespace: default

复制代码

在 Pod 中指定 SA

1. apiVersion: v1
2. kind: Pod
3. metadata:
4.   name: my-pod
5. spec:
6.   serviceAccountName: my-sa  # 指定自定义 SA
7.   containers:
8.   - name: nginx
9.     image: nginx

复制代码

---

• 认证机制：HTTPS 证书认证是 Kubernetes 最安全的认证方式，支持双向验证。
  
• kubeconfig：管理多集群访问的核心配置文件，包罗集群、用户和上下文信息。
  
• Service Account：为 Pod 提供动态身份认证，通过挂载 Token 和 CA 证书实现安全访问 API Server。
  
• Secret：存储敏感信息，分为 service-account-token 和用户自定义的 Opaque 类型。
  

---

Kubernetes 鉴权机制（RBAC）

概述

• 目的：确定请求方对资源的访问权限。
  
• 鉴权策略：
  
  
  
  • AlwaysDeny：拒绝所有请求（用于测试）。
    
  • AlwaysAllow：答应所有请求（用于测试或无需鉴权的场景）。
    
  • ABAC：基于属性的访问控制，配置复杂，需重启 API Server。
    
  • Webhook：通过外部 REST 服务进行鉴权。
    
  • RBAC：基于角色的访问控制，Kubernetes 1.6 起默认使用。
    
  
  

RBAC 的上风

• 全面覆盖：支持对资源（如 Pod、Deployment）和非资源（如元信息）的权限控制。
  
• 动态调整：无需重启 API Server，可及时修改权限。
  
• API 驱动：通过 API 资源对象（Role、ClusterRole、RoleBinding、ClusterRoleBinding）管理权限。
  

RBAC 核心概念

角色（Role 和 ClusterRole）

• Role：定义命名空间内的资源权限。
  
• ClusterRole：定义集群范围的资源权限。
  

Role 示例：

1. apiVersion: rbac.authorization.k8s.io/v1
2. kind: Role
3. metadata:
4.   namespace: default
5.   name: pod-reader
6. rules:
7. - apiGroups: [""]  # 核心 API 组
8.   resources: ["pods"]  # 资源类型
9.   verbs: ["get", "watch", "list"]  # 操作权限

复制代码

• 授予 default 命名空间中对 Pod 的 get、watch、list 权限。
  

ClusterRole 示例：

1. apiVersion: rbac.authorization.k8s.io/v1
2. kind: ClusterRole
3. metadata:
4.   name: secret-reader
5. rules:
6. - apiGroups: [""]
7.   resources: ["secrets"]  # 资源类型
8.   verbs: ["get", "watch", "list"]  # 操作权限

复制代码

• 授予集群范围内对 Secret 的 get、watch、list 权限。
  

角色绑定（RoleBinding 和 ClusterRoleBinding）

• RoleBinding：将角色绑定到主体（User、Group、ServiceAccount），作用范围限于命名空间。
  
• ClusterRoleBinding：将集群角色绑定到主体，作用范围为整个集群。
  

RoleBinding 示例 1：

1. apiVersion: rbac.authorization.k8s.io/v1
2. kind: RoleBinding
3. metadata:
4.   name: read-pods
5.   namespace: default
6. subjects:
7. - kind: User
8.   name: zhangsan
9.   apiGroup: rbac.authorization.k8s.io
10. roleRef:
11.   kind: Role
12.   name: pod-reader
13.   apiGroup: rbac.authorization.k8s.io

复制代码

• 分析：将 default 命名空间的 pod-reader Role 授予用户 zhangsan。
  

RoleBinding 示例 2：

1. apiVersion: rbac.authorization.k8s.io/v1
2. kind: RoleBinding
3. metadata:
4.   name: read-secrets
5.   namespace: kube-public
6. subjects:
7. - kind: User
8.   name: lisi
9.   apiGroup: rbac.authorization.k8s.io
10. roleRef:
11.   kind: ClusterRole
12.   name: secret-reader
13.   apiGroup: rbac.authorization.k8s.io

复制代码

• 分析：将集群范围的 secret-reader ClusterRole 授予用户 lisi，但仅限 kube-public 命名空间。
  

ClusterRoleBinding 示例：

1. apiVersion: rbac.authorization.k8s.io/v1
2. kind: ClusterRoleBinding
3. metadata:
4.   name: read-secrets-global
5. subjects:
6. - kind: Group
7.   name: manager
8.   apiGroup: rbac.authorization.k8s.io
9. roleRef:
10.   kind: ClusterRole
11.   name: secret-reader
12.   apiGroup: rbac.authorization.k8s.io

复制代码

• 分析：将集群范围的 secret-reader ClusterRole 授予 manager 组，作用范围为整个集群。
  

主体（Subject）

• User：用户，字符串表示，前缀 system: 为体系保存。
  
• Group：用户组，格式与 User 类似。
  
• ServiceAccount：服务账号，用于 Pod 认证。
  

RBAC 实例

1. 创建 Role 和 RoleBinding

1. # 创建 RoleapiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata:  namespace: default  name: pod-readerrules:- apiGroups: [""]  resources: ["pods"]  verbs: ["get", "watch", "list"]# 创建 RoleBindingapiVersion: rbac.authorization.k8s.io/v1
2. kind: RoleBinding
3. metadata:
4.   name: read-pods
5.   namespace: default
6. subjects:
7. - kind: User
8.   name: zhangsan
9.   apiGroup: rbac.authorization.k8s.io
10. roleRef:
11.   kind: Role
12.   name: pod-reader
13.   apiGroup: rbac.authorization.k8s.io

复制代码

2. 创建 ClusterRole 和 ClusterRoleBinding

1. # 创建 ClusterRoleapiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata:  name: secret-readerrules:- apiGroups: [""]  resources: ["secrets"]  verbs: ["get", "watch", "list"]# 创建 ClusterRoleBindingapiVersion: rbac.authorization.k8s.io/v1
2. kind: ClusterRoleBinding
3. metadata:
4.   name: read-secrets-global
5. subjects:
6. - kind: Group
7.   name: manager
8.   apiGroup: rbac.authorization.k8s.io
9. roleRef:
10.   kind: ClusterRole
11.   name: secret-reader
12.   apiGroup: rbac.authorization.k8s.io

复制代码

总结

• RBAC 是 Kubernetes 默认的鉴权机制，通过 Role、ClusterRole、RoleBinding、ClusterRoleBinding 实现灵活的权限管理。
  
• Role 和 RoleBinding 用于命名空间内的权限控制。
  
• ClusterRole 和 ClusterRoleBinding 用于集群范围的权限控制。
  
• 主体 可以是 User、Group 或 ServiceAccount，用于绑定角色。
  

参考文档：Kubernetes RBAC 官方文档

---

Kubernetes RBAC 实例

创建一个用户 zhangsan，并限制其只能管理 kgc 命名空间中的资源。
创建用户

• 添加用户：
  
  1. useradd zhangsan
  2. passwd zhangsan

  复制代码
• 测试用户权限：
  
  1. su - zhangsan
  3. kubectl get pods

  复制代码
  
  
  • 结果：用户 zhangsan 没有权限访问 API Server。
    
  
  

生成用户证书和 kubeconfig 文件

1. 创建证书签名请求（CSR）

1. mkdir /opt/zhangsan
2. cd /opt/zhangsan
4. cat > zhangsan-csr.json <<EOF
5. {
6.   "CN": "zhangsan",
7.   "hosts": [],
8.   "key": {
9.     "algo": "rsa",
10.     "size": 2048
11.   },
12.   "names": [
13.     {
14.       "C": "CN",
15.       "ST": "BeiJing",
16.       "L": "BeiJing",
17.       "O": "k8s",
18.       "OU": "System"
19.     }
20.   ]
21. }
22. EOF

复制代码

2. 生成证书

1. cd /etc/kubernetes/pki/
2. cfssl gencert -ca=ca.crt -ca-key=ca.key -profile=kubernetes /opt/zhangsan/zhangsan-csr.json | cfssljson -bare zhangsan

复制代码

• 生成文件：zhangsan-key.pem（私钥）、zhangsan.pem（证书）、zhangsan.csr（证书签名请求）。
  

创建 kubeconfig 文件

1. 编写脚本

1. vim /opt/zhangsan/rbac-kubeconfig.sh

复制代码

1. APISERVER=$1
2. # 设置集群参数
3. export KUBE_APISERVER="https://$APISERVER:6443"
4. kubectl config set-cluster kubernetes \
5.   --certificate-authority=/etc/kubernetes/pki/ca.crt \
6.   --embed-certs=true \
7.   --server=${KUBE_APISERVER} \
8.   --kubeconfig=zhangsan.kubeconfig
10. # 设置客户端认证参数
11. kubectl config set-credentials zhangsan \
12.   --client-key=/etc/kubernetes/pki/zhangsan-key.pem \
13.   --client-certificate=/etc/kubernetes/pki/zhangsan.pem \
14.   --embed-certs=true \
15.   --kubeconfig=zhangsan.kubeconfig
17. # 设置上下文参数
18. kubectl config set-context kubernetes \
19.   --cluster=kubernetes \
20.   --user=zhangsan \
21.   --namespace=kgc \
22.   --kubeconfig=zhangsan.kubeconfig
24. # 使用上下文参数生成 zhangsan.kubeconfig 文件
25. kubectl config use-context kubernetes --kubeconfig=zhangsan.kubeconfig

复制代码

2. 执行脚本

1. chmod +x rbac-kubeconfig.sh
2. ./rbac-kubeconfig.sh 192.168.80.10

复制代码

3. 配置用户 kubeconfig

1. mkdir /home/zhangsan/.kube
2. cp zhangsan.kubeconfig /home/zhangsan/.kube/config
3. chown -R zhangsan:zhangsan /home/zhangsan/.kube/

复制代码

---

RBAC 授权

1. 创建 Role 和 RoleBinding

1. # rbac.yaml
2. apiVersion: rbac.authorization.k8s.io/v1
3. kind: Role
4. metadata:
5.   namespace: kgc
6.   name: pod-reader
7. rules:
8. - apiGroups: [""]
9.   resources: ["pods"]
10.   verbs: ["get", "watch", "list", "create"]
12. ---
13. apiVersion: rbac.authorization.k8s.io/v1
14. kind: RoleBinding
15. metadata:
16.   name: read-pods
17.   namespace: kgc
18. subjects:
19. - kind: User
20.   name: zhangsan
21.   apiGroup: rbac.authorization.k8s.io
22. roleRef:
23.   kind: Role
24.   name: pod-reader
25.   apiGroup: rbac.authorization.k8s.io

复制代码

2. 应用 RBAC 配置

1. kubectl apply -f rbac.yaml

复制代码

3. 验证 Role 和 RoleBinding

1. kubectl get role,rolebinding -n kgc

复制代码

• 输出示例：
  1. NAME                                        AGE
  2. role.rbac.authorization.k8s.io/pod-reader   32s
  4. NAME                                              AGE
  5. rolebinding.rbac.authorization.k8s.io/read-pods   32s

  复制代码

测试用户权限

1. 切换用户

1. su - zhangsan

复制代码

2. 创建 Pod

1. # pod-test.yaml
2. apiVersion: v1
3. kind: Pod
4. metadata:
5.   name: pod-test
6. spec:
7.   containers:
8.     - name: nginx
9.       image: nginx

复制代码

1. kubectl create -f pod-test.yaml

复制代码

3. 查察 Pod

1. kubectl get pods -o wide

复制代码

• 输出示例：
  1. NAME       READY   STATUS    RESTARTS   AGE    IP           NODE     NOMINATED NODE   READINESS GATES
  2. pod-test   1/1     Running   0          114s   10.244.2.2   node02   <none>           <none>

  复制代码

4. 测试其他权限

• 访问 Service：
  
  1. kubectl get svc

  复制代码
  
  
  • 结果：被拒绝，由于未授权。
    
  
  
• 访问默认命名空间：
  
  1. kubectl get pods -n default

  复制代码
  
  
  • 结果：被拒绝，由于权限仅限于 kgc 命名空间。
    
  
  

授予管理员权限（可选）

假如必要用户 zhangsan 在 kgc 命名空间中拥有管理员权限，可以绑定 cluster-admin 角色：

1. kubectl create rolebinding zhangsan-admin-binding --clusterrole=cluster-admin --user=zhangsan --namespace=kgc

复制代码

总结

• RBAC 是 Kubernetes 中灵活的权限管理机制，通过 Role 和 RoleBinding 实现细粒度的权限控制。
  
• 用户证书和 kubeconfig：用于用户身份认证和访问集群。
  
• 命名空隔断离：通过 RoleBinding 将权限限制在特定命名空间内。
  

参考文档：Kubernetes RBAC 官方文档

---

Kubernetes 准入控制与资源限制指南

准入控制（Admission Control）

准入控制是 Kubernetes API Server 的核心机制，通过一系列插件对请求进行拦截和校验。所有发送到 API Server 的请求需通过准入控制器插件的查抄，若任意插件拒绝，则请求被驳回。
1. 官方默认准入控制器插件

推荐使用以下默认插件（版本间可能有差异）：

1. NamespaceLifecycle, LimitRanger, ServiceAccount, DefaultStorageClass,
2. DefaultTolerationSeconds, MutatingAdmissionWebhook, ValidatingAdmissionWebhook,
3. ResourceQuota, NodeRestriction

复制代码

2. 关键插件功能

• NamespaceLifecycle
  管理命名空间生命周期：禁止在已删除或不存在的命名空间创建资源，制止删除体系保存命名空间，并清理命名空间下的所有资源。
  
• LimitRanger
  资源配额管理：确保 Pod 请求的资源不高出命名空间的 LimitRange 限制。
  
• ResourceQuota
  命名空间级资源配额：限制命名空间内资源总量（如 CPU、内存、对象数目等）。
  
• NodeRestriction
  节点最小权限控制：限制 kubelet 仅能操作自身节点资源。
  

官方文档：准入控制器参考
资源限制 - Pod 级别

通过 resources 字段定义容器的资源请求（requests）和上限（limits），由 cgroups 实现底层控制。
核心规则：

• requests：Pod 启动时需分配的资源量，影响调度。
  
• limits：Pod 运行时的资源使用上限，超限时触发 OOM（内存）或 CPU 节流。
  

示例配置

1. spec:
2.   containers:
3.   - name: auth
4.     resources:
5.       requests:
6.         cpu: 250m    # 初始请求 0.25 核 CPU
7.         memory: 250Mi # 初始请求 250MB 内存
8.       limits:
9.         cpu: "2"     # 最大使用 2 核 CPU
10.         memory: 1Gi   # 最大使用 1GB 内存

复制代码

  注意：未设置 requests/limits 时，默认使用命名空间的 LimitRange；若命名空间也未定义，则 Pod 可能无限制占用资源。
  资源限制 - 命名空间级别

通过 ResourceQuota 和 LimitRange 管理命名空间资源。
1. ResourceQuota（全局配额）

限制命名空间内资源总量（计算资源或对象数目）。
示例 1：计算资源配额

1. apiVersion: v1
2. kind: ResourceQuota
3. metadata:
4.   name: compute-resources
5.   namespace: spark-cluster
6. spec:
7.   hard:
8.     pods: "20"             # 最大 Pod 数量
9.     requests.cpu: "2"      # 总 CPU 请求不超过 2 核
10.     requests.memory: 1Gi   # 总内存请求不超过 1GB
11.     limits.cpu: "4"        # 总 CPU 上限不超过 4 核
12.     limits.memory: 2Gi     # 总内存上限不超过 2GB

复制代码

示例 2：对象数目配额

1. apiVersion: v1
2. kind: ResourceQuota
3. metadata:
4.   name: object-counts
5.   namespace: spark-cluster
6. spec:
7.   hard:
8.     configmaps: "10"               # 最大 ConfigMap 数量
9.     persistentvolumeclaims: "4"    # 最大 PVC 数量
10.     services.loadbalancers: "2"    # 最大 LoadBalancer 服务数量

复制代码

2. LimitRange（默认值束缚）

为未指定资源限制的 Pod 或容器设置默认 requests/limits。
示例

1. apiVersion: v1
2. kind: LimitRange
3. metadata:
4.   name: mem-limit-range
5.   namespace: test
6. spec:
7.   limits:
8.   - type: Container
9.     default:           # 默认 limits
10.       cpu: 500m
11.       memory: 512Mi
12.     defaultRequest:    # 默认 requests
13.       cpu: 100m
14.       memory: 256Mi

复制代码

总结

机制作用范围核心功能准入控制插件集群/请求级别拦截非法请求（如资源超限、非法命名空间操作）ResourceQuota命名空间限制命名空间内资源总量和对象数目LimitRange命名空间定义 Pod/容器的默认资源请求和上限   最佳实践：生产环境应结合 ResourceQuota 和 LimitRange，制止资源竞争和过度消耗。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。