用jsp做的网站代码,长沙市住房和城乡建设部网站,网站建设装什么系统,房产交易网站开发目录 一、安全机制 三个主要安全机制 认证#xff08;Authentication#xff09;#xff1a; 鉴权#xff08;Authorization#xff09;#xff1a; 准入控制#xff08;Admission Control#xff09;#xff1a; 二、 认证 认证方式 对比总结 认证机制框架和相关组件… 目录 一、安全机制 三个主要安全机制 认证Authentication 鉴权Authorization 准入控制Admission Control 二、 认证 认证方式 对比总结 认证机制框架和相关组件 Service Account 访问权限机制 Service Account 通常包含以下三个部分 当 Pod 在 Kubernetes 集群中启动时 三、 鉴权 授权策略 RBAC 管理用户和组对资源访问权限机制 RBAC 的优势 RBAC 的 API 资源对象 RBAC基于角色的访问控制的核心概念和组件 Role 示例 ClusterRole 示例 RoleBinding and ClusterRoleBinding示例 RoleBinding 示例1 RoleBinding 示例2 ClusterRoleBinding 示例 Resources 资源 如何在 Role 中定义规则以控制对资源及其子资源的访问权限的示例 rules规则 四、准入控制 官方推荐的准入控制器 常用的控制器插件 完整示例 创建用户 生成证书和 kubeconfig 文件 配置 kubeconfig 文件 创建命名空间 RBAC 授权 测试操作权限 管理员权限 一、安全机制
Kubernetes 的安全机制非常关键因为它确保了集群的稳定性和数据的安全。
三个主要安全机制
是 Kubernetes 安全架构的核心组成部分
认证Authentication 这是安全机制的第一道防线。它负责确认请求者的身份。在 Kubernetes 中认证通常通过以下几种方式实现 客户端证书用户或服务可以通过客户端证书进行身份验证。 Bearer Tokens用户可以获取一个令牌Token并在请求中携带这个令牌。 基本认证使用用户名和密码进行基本的 HTTP 认证。 SSH 密钥对于某些操作如节点登录可以使用 SSH 密钥进行认证。
鉴权Authorization 一旦用户或服务通过认证下一步就是确定他们有哪些权限。Kubernetes 提供了几种鉴权机制 Role-Based Access Control (RBAC)这是 Kubernetes 最常用的鉴权方式它允许管理员定义角色Role和角色绑定RoleBinding以控制对资源的访问。 Attribute-Based Access Control (ABAC)这是一种更细粒度的鉴权方式它基于用户、资源和操作的属性来决定访问权限。 Webhook 鉴权允许调用外部服务来决定访问权限。
准入控制Admission Control 即使请求者通过了认证和鉴权准入控制还会在资源被创建或修改之前进行最后的检查。这是为了确保资源的创建符合集群的策略和规范。准入控制器可以包括 MutatingWebhook在资源被持久化之前可以修改资源对象。 ValidatingWebhook验证资源对象是否符合集群的策略和规范。 ResourceQuota限制资源的使用量如 CPU、内存和存储。 NamespaceLifecycle管理命名空间的生命周期。
这些机制共同工作确保了 Kubernetes 集群的安全性。管理员可以根据集群的需求和安全策略来配置这些机制。
二、 认证
这些认证方式确保了只有合法的用户和服务能够与 Kubernetes API Server 进行交互
认证方式 HTTP Token 认证 客户端需要获取一个 Token这个 Token 通常是由 Kubernetes API Server 生成并存储在一个安全的地方。 客户端在发起请求时将这个 Token 放在 HTTP 请求的头部Header中通常是 Authorization 字段。 API Server 会验证这个 Token 是否有效以及对应的用户是否有权进行请求的操作。 HTTP Basic 认证 用户名和密码组合使用 Base64 编码后形成一串编码字符串。 这串编码字符串被放在 HTTP 请求的 Authorization 头部中以 Basic 开头。 API Server 解码后验证用户名和密码的正确性。 HTTPS 证书认证 这是一种更为安全的认证方式通常用于服务之间的通信。 客户端和服务器都需要有由可信的证书颁发机构CA签发的 SSL/TLS 证书。 在建立 HTTPS 连接时双方会交换并验证对方的证书确保通信双方的身份。 这种方式不仅能够验证客户端的身份还能验证服务器的身份实现双向认证Mutual TLS, mTLS。
对比总结
Token 和 Basic 认证主要是单向的即只能验证客户端对服务器的身份。而 HTTPS 证书认证可以实现双向认证这对于需要确保通信双方身份的场景非常重要比如在 Kubernetes API Server 与 etcd 或其他组件之间的通信中。使用 HTTPS 证书认证可以防止中间人攻击确保数据传输的安全性。
认证机制框架和相关组件 需要被认证的访问类型 Kubernetes 组件如 kubectl、kubelet、kube-proxy需要与 API Server 通信这些通信需要通过认证。 Kubernetes 管理的 Pod如 coredns、dashboard也需要访问 API Server同样需要认证。 安全性说明 控制平面组件Controller Manager、Scheduler通常与 API Server 运行在同一台机器上因此它们可以直接使用非安全端口如 8080进行通信。 对于需要远程访问 API Server 的组件如 kubectl、kubelet、kube-proxy则需要使用 HTTPS 双向认证通常通过 6443 端口进行。 证书颁发 在二进制部署 Kubernetes 时可能需要手动签发 HTTPS 证书。 在 Kubernetes 自动化部署的环境中kubelet 首次访问 API Server 时使用 Token 进行认证之后 Controller Manager 会为 kubelet 生成证书kubelet 使用这个证书进行后续的认证。 kubeconfig kubeconfig 文件包含了集群的访问参数如 CA 证书、API Server 地址和客户端认证信息如证书和私钥。 kubeconfig 文件还包含了集群上下文参数允许用户在不同的集群之间切换。 kubectl 使用的 kubeconfig 文件通常位于用户的主目录下的 .kube/config。 Service Account Service Account 是 Kubernetes 中的一个资源对象用于代表 Pod 中的容器访问 API Server。 Service Account 允许 Pod 以一种安全的方式获取访问令牌Token而不需要为每个 Pod 单独生成证书。 Secret 与 Service Account 的关系 Kubernetes 中的 Secret 资源对象用于存储敏感信息如密码、OAuth 令牌和 ssh 密钥。 Service Account 相关的 Secret 包含了用于认证的 Token这些 Token 被 Pod 中的容器用来访问 API Server。 Opaque 类型的 Secret 用于存储任意的非结构化数据这些数据可以由用户自定义。
这些机制共同构成了 Kubernetes 的安全框架确保了集群的管理和操作都是安全可控的。通过这些机制Kubernetes 能够为不同的组件和服务提供适当的认证和授权同时保持操作的灵活性和便利性。
Service Account 访问权限机制
Service Account 是 Kubernetes 中用于提供对 API Server 的访问权限的机制。它允许 Pod 中的容器以该 Service Account 的身份进行操作而无需为每个 Pod 单独创建和管理认证凭据。
Service Account 通常包含以下三个部分 Token 这是一个由 API Server 的私钥签名的 Token 字符串序列号。 当 Pod 中的容器需要与 API Server 通信时可以使用这个 Token 进行认证。 API Server 会使用其私钥来验证这个 Token 的有效性。 ca.crt 这是 API Server 的 CA 根证书。 Pod 中的容器使用这个证书来验证 API Server 发送来的证书确保通信的安全性。 这是双向 TLSmTLS认证的一部分确保了通信双方的身份验证。 Namespace 这个字段标识了 Service Account 所属的命名空间。 Service Account 通常与特定的命名空间关联这限制了它的作用范围。
默认情况下每个命名空间都会自动创建一个名为 default 的 Service Account。如果 Pod 在创建时没有指定 Service Account它将默认使用其所属命名空间的 default Service Account。这允许 Pod 以该命名空间的权限进行操作。
kubectl get sa
NAME SECRETS AGE
default 1 7dkubectl get sa 命令输出显示了当前命名空间中的 Service Account 列表。在这个例子中default Service Account 已经存在了 7 天并且有一个与之关联的 Secret。这个 Secret 包含了上述提到的 Token 和 CA 证书。
Service Account 的使用简化了 Pod 的认证流程使得开发者和管理员可以更轻松地管理 Pod 的权限同时保持集群的安全性。通过 Service AccountKubernetes 能够为动态创建和销毁的 Pod 提供一种安全且灵活的认证机制。
当 Pod 在 Kubernetes 集群中启动时
它会从与它关联的 Service Account 获取必要的认证信息并将其挂载到特定的目录 /var/run/secrets/kubernetes.io/serviceaccount/。这个目录包含了三个关键文件 ca.crt这是 CA 根证书用于验证 API Server 的身份。Pod 中的容器在与 API Server 通信时会使用这个证书来确保它们正在与合法的 API Server 通信。 namespace这是一个文件包含了 Pod 所属的命名空间。这个信息对于 API Server 来说很重要因为它决定了 Pod 可以访问的资源范围。 token这是一个由 API Server 签发的 Token用于在 API Server 进行身份验证。当 Pod 中的容器需要访问 API Server 时它会使用这个 Token 来证明自己的身份。
kubectl get pod -n kube-system
NAME READY STATUS RESTARTS AGE
coredns-5c98db65d4-gmmrn 1/1 Running 0 7d
coredns-5c98db65d4-w24d7 1/1 Running 0 7d
etcd-master 1/1 Running 0 7d
kube-apiserver-master 1/1 Running 0 7d
kube-controller-manager-master 1/1 Running 0 7d
kube-flannel-ds-amd64-4dgcs 1/1 Running 0 7d
kube-flannel-ds-amd64-55xzq 1/1 Running 0 7d
kube-flannel-ds-amd64-l8r2b 1/1 Running 0 7d
kube-proxy-4hj92 1/1 Running 0 7d
kube-proxy-dcprb 1/1 Running 0 7d
kube-proxy-prdjp 1/1 Running 0 7d
kube-scheduler-master 1/1 Running 0 7dkubectl get pod -n kube-system 命令输出显示了 kube-system 命名空间中的 Pod 列表。这些 Pod 包括了 Kubernetes 控制平面组件和其他关键组件。每个 Pod 都会挂载其关联 Service Account 的认证信息。
kubectl exec -it kube-proxy-prdjp -n kube-system sh通过 kubectl exec -it kube-proxy-prdjp -n kube-system sh 命令进入了 kube-system 命名空间中名为 kube-proxy-prdjp 的 Pod 的 shell。
ls /var/run/secrets/kubernetes.io/serviceaccount/
ca.crt namespace token然后使用 ls /var/run/secrets/kubernetes.io/serviceaccount/ 命令列出了挂载的认证信息文件这证实了每个 Pod 都能够访问其 Service Account 的认证信息。
这种机制确保了 Pod 能够安全地与 API Server 通信同时也使得 Pod 的管理和认证过程更加自动化和透明。 三、 鉴权
鉴权Authorization是 Kubernetes 安全机制中的一个关键环节它决定了用户或系统组件在通过认证后能够执行哪些操作。鉴权策略定义了对资源的访问权限确保只有具有适当权限的用户或服务可以访问或修改资源。
授权策略 AlwaysDeny 这种策略会拒绝所有的请求无论请求的内容是什么。 通常用于测试环境以确保在开发或调试过程中不会有意外的资源访问。 AlwaysAllow 这种策略允许所有的请求不对请求进行任何权限检查。 这同样通常用于测试环境或者在不需要进行权限控制的情况下。 ABACAttribute-Based Access Control ABAC 是一种细粒度的访问控制策略它基于用户、资源和操作的属性来决定访问权限。 管理员可以定义复杂的规则这些规则考虑了用户的属性如角色、部门和资源的属性如标签、注解。 ABAC 提供了高度的灵活性但配置起来可能比较复杂。 Webhook Webhook 鉴权策略允许 API Server 调用外部的 RESTful 服务来决定是否允许请求。 这种方式可以与现有的身份管理系统如 LDAP、OAuth 服务器集成实现集中化的鉴权管理。 Webhook 鉴权策略提供了一种灵活的方式来扩展 Kubernetes 的鉴权能力。 RBACRole-Based Access Control RBAC 是 Kubernetes 自 1.6 版本起默认的鉴权模式。 在 RBAC 中管理员可以定义角色Role和角色绑定RoleBinding。 角色定义了一组权限而角色绑定则将角色分配给用户或用户组。 RBAC 提供了一种结构化的方式来管理权限使得权限的分配和审计更加清晰和容易。
在实际部署中RBAC 是最常用的鉴权策略因为它提供了一种既灵活又易于管理的方式来控制对 Kubernetes 资源的访问。通过定义角色和角色绑定管理员可以精确地控制不同用户和组件的权限从而保护集群的安全。
RBAC 管理用户和组对资源访问权限机制
RBACRole-Based Access Control是 Kubernetes 中用于管理用户和组对资源访问权限的一种机制。与其他访问控制方式相比RBAC 提供了更细粒度的权限控制并且更加灵活和易于管理。
官方文档https://kubernetes.io/docs/reference/access-authn-authz/rbac/
RBAC 的优势 全面覆盖RBAC 可以对集群中的资源如 Pods、Deployments、Services和非资源如元信息或资源状态进行访问控制。 动态管理RBAC 的策略可以通过 Kubernetes API 动态配置和管理无需重启 API Server。这与 ABACAttribute-Based Access Control不同ABAC 通常需要重启 API Server 来更新策略。 易于操作RBAC 的配置完全通过 Kubernetes API 资源对象实现可以使用 kubectl 或直接通过 API 与 API Server 交互。
RBAC 的 API 资源对象 Role定义了一组权限这些权限适用于特定命名空间内的资源。Role 通常用于在单个命名空间内定义访问策略。 ClusterRole与 Role 类似但 ClusterRole 是集群级别的资源其定义的权限适用于整个集群范围内的资源。 RoleBinding将 Role 与用户、组或服务账户ServiceAccount绑定从而授予这些主体Subjects在特定命名空间内的权限。 ClusterRoleBinding与 RoleBinding 类似但 ClusterRoleBinding 将 ClusterRole 与主体绑定授予主体在整个集群范围内的权限。
这些资源对象使得管理员可以灵活地定义和分配权限以满足不同的安全需求。通过 Role 和 RoleBinding可以在命名空间级别进行细粒度的访问控制而通过 ClusterRole 和 ClusterRoleBinding则可以实现跨命名空间的访问控制。
官方文档提供了关于 RBAC 的详细信息包括如何创建和管理这些资源对象以及如何使用它们来保护 Kubernetes 集群的资源。通过提供的链接可以访问官方文档以获取更多关于 RBAC 的指导和最佳实践。
RBAC基于角色的访问控制的核心概念和组件
角色Role和集群角色ClusterRole Role定义了在特定命名空间内对资源的一组操作权限。Role 通常用于限制对单个命名空间内资源的访问。 ClusterRole与 Role 类似但 ClusterRole 提供了跨命名空间的权限。它允许定义一组在整个集群范围内适用的权限。 如果使用 RoleBinding 绑定 ClusterRole仍会受到命名空间的影响如果使用 ClusterRoleBinding 绑定 ClusterRole 将会作用于整个 K8S 集群。
角色绑定RoleBinding和集群角色绑定ClusterRoleBinding RoleBinding将 Role 与一个或多个用户、组或服务账户ServiceAccount绑定从而授予这些主体在特定命名空间内的权限。 ClusterRoleBinding与 RoleBinding 类似但 ClusterRoleBinding 将 ClusterRole 与主体绑定授予主体在整个集群范围内的权限。
主体Subject User代表一个用户可以是集群外部的用户或集群内部的服务账户。 Group代表一组用户可以是系统定义的组或自定义组。 ServiceAccount代表一个服务账户它是 Kubernetes 内部的一个账户通常用于 Pod 身份认证。 User 使用字符串表示它的前缀 system: 是系统保留的集群管理员应该确保普通用户不会使用这个前缀格式Group 书写格式与 User 相同同样 system: 前缀也为系统保留。 Pod使用 ServiceAccount 认证时service-account-token 中的 JWT 会保存用户信息。 有了用户信息再创建一对角色/角色绑定集群角色/集群角色绑定资源对象就可以完成权限绑定了。
权限规则Rules
在 Role 或 ClusterRole 中定义的规则指定了哪些资源如 Pods、Deployments和哪些操作如 get、watch、list被允许。这些规则是累加的意味着只有白名单权限没有黑名单权限。
Role 示例
#Role 示例
apiVersion: rbac.authorization.k8s.io/v1 #指定 core API 组和版本
kind: Role #指定类型为 Role
metadata:namespace: default #使用默认命名空间 name: pod-reader #Role 的名称
rules: #定义规则
- apiGroups: [] #表示 apiGroups 和 apiVersion 使用相同的 core API 组即 rbac.authorization.k8s.ioresources: [pods] #资源对象为 Pod 类型verbs: [get, watch, list] #被授予的操作权限Role 示例定义了一个名为 pod-reader 的角色它允许用户在 default 命名空间中对 Pods 执行获取get、监听watch和列出list操作。
通过这些组件Kubernetes 管理员可以精细地控制用户和系统组件对资源的访问从而确保集群的安全性。RBAC 提供了一种声明式的权限管理方式使得权限的分配和审计变得更加清晰和容易。
ClusterRole 示例
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:# namespace 被忽略因为 ClusterRoles 不受名字空间限制name: secret-reader
rules:
- apiGroups: []resources: [secrets] #资源对象为 Secret 类型verbs: [get, watch, list]提供的 ClusterRole 示例定义了一个名为 secret-reader 的集群角色这个角色授予了对 Kubernetes Secret 资源的读取get、观察watch和列出list权限。由于这是一个 ClusterRole这些权限将适用于整个 Kubernetes 集群中的所有命名空间而不仅仅是单个命名空间。
这里是对 ClusterRole 示例的详细解释 apiVersion指定了 Kubernetes API 的版本这里使用的是 rbac.authorization.k8s.io/v1这是 RBAC API 的稳定版本。 kind指定了资源类型这里是 ClusterRole。 metadata包含了资源的元数据如名称name。对于 ClusterRolenamespace 字段被忽略因为它不适用于集群级别的资源。 rules定义了角色的权限规则。每个规则包含以下部分 apiGroups指定了 API 组 表示核心 API 组。 resources指定了资源类型这里为 secrets即 Secret 资源。 verbs指定了允许的操作这里是 get、watch 和 list。
创建了 ClusterRole 之后需要创建一个 ClusterRoleBinding 来将这个角色绑定到一个或多个主体如用户、组或服务账户从而授予它们相应的权限。例如
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:name: read-secrets-global
subjects:
- kind: Username: janeexample.comapiGroup: rbac.authorization.k8s.io
roleRef:kind: ClusterRolename: secret-readerapiGroup: rbac.authorization.k8s.io这个 ClusterRoleBinding 将 secret-reader 角色授予了用户 janeexample.com使其能够在整个集群中读取 Secret 资源。
RoleBinding and ClusterRoleBinding示例 RoloBinding 可以将角色中定义的权限授予用户或用户组RoleBinding 包含一组主体subjectsubject 中包含有不同形式的待授予权限资源类型User、Group、ServiceAccount RoloBinding 同样包含对被绑定的 Role 引用 RoleBinding 适用于某个命名空间内授权而 ClusterRoleBinding 适用于集群范围内的授权
RoleBinding 示例1
#RoleBinding 示例1
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:name: read-podsnamespace: default
subjects:
- kind: Username: zhangsanapiGroup: rbac.authorization.k8s.io
roleRef:kind: Rolename: pod-readerapiGroup: rbac.authorization.k8s.io这个 RoleBinding 将 pod-reader 角色授予了用户 zhangsan。 由于 RoleBinding 在 default 命名空间中定义因此 zhangsan 用户在 default 命名空间中具有 pod-reader 角色的权限。
RoleBinding 示例2
RoleBinding 同样可以引用 ClusterRole 来对当前 namespace 内 User、Group 或 ServiceAccount 进行授权 这种操作允许集群管理员在整个集群内定义一些通用的 ClusterRole然后在不同的 namespace 中使用 RoleBinding 来引用。#RoleBinding 示例2
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:name: read-secretsnamespace: kube-public
subjects:
- kind: Username: lisiapiGroup: rbac.authorization.k8s.io
roleRef:kind: ClusterRolename: secret-readerapiGroup: rbac.authorization.k8s.io这个 RoleBinding 引用了一个 ClusterRolesecret-reader这意味着它授予的权限是集群范围内的。 尽管如此由于 RoleBinding 在 kube-public 命名空间中定义用户 lisi 只能访问 kube-public 命名空间中的 Secrets。
ClusterRoleBinding 示例
#ClusterRoleBinding 示例
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:name: read-secrets-global
subjects:
- kind: Groupname: managerapiGroup: rbac.authorization.k8s.io
roleRef:kind: ClusterRolename: secret-readerapiGroup: rbac.authorization.k8s.io这个 ClusterRoleBinding 授予了 manager 组内的所有用户在整个集群范围内对 Secrets 的访问权限。 由于是 ClusterRoleBinding它不受命名空间的限制适用于所有命名空间。
这些绑定的创建和管理可以通过 kubectl 命令行工具或直接通过 Kubernetes API 进行。例如要创建 RoleBinding 或 ClusterRoleBinding可以使用以下 kubectl 命令
kubectl create rolebinding binding-name --rolerole-name --useruser-or-group --namespacenamespace或者对于 ClusterRoleBinding
kubectl create clusterrolebinding binding-name --clusterroleclusterrole-name --groupgroup-name通过这种方式Kubernetes 提供了灵活的权限管理机制使得管理员可以根据需要精细地控制用户和系统组件对资源的访问。
Resources 资源
在 Kubernetes 中资源Resources是 API 对象的集合它们代表了集群中的对象如 Pods、Services、Secrets 等。资源可以是命名空间作用域的例如 Pods、Services也可以是集群作用域的例如 Nodes、ClusterRoles。此外某些资源还可能包含子资源Subresources这些子资源提供了对资源的特定操作例如 Pod 的日志/pods/{name}/log。
在 RBAC基于角色的访问控制模型中可以通过定义 Role 或 ClusterRole 来控制对这些资源及其子资源的访问权限。
如何在 Role 中定义规则以控制对资源及其子资源的访问权限的示例
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:namespace: defaultname: pod-and-pod-logs-reader
rules:
- apiGroups: [] # 空字符串表示核心 API 组resources: [pods, pods/log] # pods 是资源pods/log 是子资源verbs: [get, list] # 允许的操作在这个例子中pod-and-pod-logs-reader Role 授予了对 default 命名空间中 Pods 的获取get和列出list权限同时也允许对这些 Pods 的日志子资源执行相同的操作。
RBAC 中的 verbs 字段定义了可以对资源执行的操作常见的 verbs 包括 get获取单个资源的详细信息。 list列出资源。 watch监视资源的变化。 create创建新资源。 update更新现有资源。 patch部分更新资源。 delete删除资源。 exec在 Pod 中执行命令。
resources 字段定义了 Role 适用的资源类型而 apiGroups 字段定义了资源所属的 API 组。在 Kubernetes 中资源和 API 组的概念允许对不同类型的资源进行细粒度的访问控制。
rules规则
在 Kubernetes RBAC基于角色的访问控制中rules 字段定义了一组规则这些规则指定了哪些操作verbs可以对哪些资源resources执行。rules 字段中的 verbs、resources 和 apiGroups 是关键的部分它们共同决定了角色的权限范围。
verbs get读取单个资源的详细信息。 list列出资源集合。 watch监视资源集合的实时更新。 create创建新资源。 update修改现有资源。 patch对资源进行部分更新。 delete删除资源。 exec在容器内执行命令通常用于调试或执行特定任务。
resources services、endpoints、pods 等这些是 Kubernetes 中的核心资源类型。 secrets、configmaps这些是用于存储敏感信息和配置数据的资源类型。 deployments、jobs、daemonsets 等这些是应用部署和管理相关的资源类型。 nodes、rolebindings、clusterroles 等这些是集群管理和权限控制相关的资源类型。
apiGroups 表示核心 API 组也就是 Kubernetes 最初的 API 组。 apps、autoscaling、batch这些是 Kubernetes 扩展的 API 组包含了额外的资源类型和功能。
在定义 Role 或 ClusterRole 时可以根据需要组合这些 verbs、resources 和 apiGroups 来精确控制对资源的访问权限。例如如果你想允许用户查看和列出 Pods但不允许创建、修改或删除它们你可以在 rules 中设置 verbs 为 [get, list]resources 为 [pods]。
通过这种方式Kubernetes 提供了一种细粒度的权限管理机制使得管理员可以根据实际需求为不同的用户和组件分配合适的权限。 四、准入控制
准入控制Admission Control是 Kubernetes 中的一个关键特性它在资源对象被持久化到 etcd 之前对 API Server 接收到的请求进行检查和验证。准入控制器Admission Controllers是一组插件它们可以拦截和修改请求或者根据特定的策略拒绝请求。这些控制器有助于维护集群的稳定性和安全性。
Kubernetes 提供了一系列的准入控制器它们可以按需启用或禁用。
官方推荐的准入控制器
官方文档参考https://kubernetes.io/zh/docs/reference/access-authn-authz/admission-controllers/
它们在不同版本的 Kubernetes 中会有所不同 NamespaceLifecycle管理命名空间的生命周期例如防止删除包含活动资源的命名空间。 LimitRanger检查资源请求是否超出了集群设置的限制范围如 CPU 和内存请求。 ServiceAccount确保 Pod 能够正确地使用服务账户进行身份认证。 DefaultStorageClass为没有指定存储类的 PersistentVolumes 选择默认的存储类。 DefaultTolerationSeconds为没有指定容忍度Toleration的 Pods 添加默认的容忍度设置。 MutatingAdmissionWebhook允许外部服务通过 webhook 修改请求对象。 ValidatingAdmissionWebhook允许外部服务通过 webhook 验证请求对象。 ResourceQuota限制命名空间内资源的使用量如 Pods、CPU 和内存。 NodeRestriction限制 Pods 可以在哪些节点上运行。
管理员可以根据集群的具体需求和安全策略来启用或禁用这些准入控制器。例如如果集群需要严格的资源限制那么 LimitRanger 和 ResourceQuota 就非常重要。如果集群需要与外部鉴权服务集成那么 MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook 就非常有用。
在 Kubernetes 的配置文件中可以通过 --admission-control 参数来指定启用哪些准入控制器。例如
kube-apiserver --admission-controlNamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,NodeRestriction这个参数的值是一个逗号分隔的准入控制器列表。通过这种方式Kubernetes 确保只有符合集群策略的资源对象才能被创建或修改。
常用的控制器插件 NamespaceLifecycle 这个控制器管理命名空间的生命周期确保只有存在的对象才能在命名空间中创建。 它防止删除系统预置的命名空间如 kube-system。 当删除命名空间时它会确保命名空间中的所有资源对象也被删除。 LimitRanger LimitRanger 用于配额管理它检查资源请求是否符合命名空间的 LimitRange 限制。 这有助于防止资源过度分配确保集群资源的合理使用。 ServiceAccount 这个控制器在创建 Pod 时自动为其添加 ServiceAccount。 它确保 Pod 能够使用 ServiceAccount 的身份访问 API Server这对于 Pod 的认证和授权至关重要。 ResourceQuota ResourceQuota 控制器用于基于命名空间的配额管理它确保资源请求不会超过预设的配额限制。 这有助于防止单个用户或应用占用过多资源从而影响集群中其他用户或应用。 NodeRestriction NodeRestriction 控制器用于限制节点加入集群时的权限。 它确保节点以最小权限运行从而减少潜在的安全风险。
完整示例
如何在 Kubernetes 集群中创建一个用户并限制该用户只能管理指定命名空间的资源。这个过程涉及到用户创建、证书生成、RBAC 授权和 kubeconfig 文件的配置。
创建用户
useradd zhangsan
passwd zhangsan使用 useradd 和 passwd 命令创建一个名为 zhangsan 的用户并设置密码。
生成证书和 kubeconfig 文件
#使用这个用户进行资源操作会发现连接 API Server 时被拒绝访问请求
su - zhangsankubectl get pods
The connection to the server localhost:8080 was refused - did you specify the right host or port?#创建用于用户连接到 API Server 所需的证书和 kubeconfig 文件
#先上传证书生成工具 cfssl、cfssljson、cfssl-certinfo 到 /usr/local/bin 目录中
chmod x /usr/local/bin/cfssl*mkdir /opt/zhangsan
cd /opt/zhangsanvim user-cert.sh
#######################
cat zhangsan-csr.json EOF
{CN: zhangsan,hosts: [],key: {algo: rsa,size: 2048},names: [{C: CN,ST: BeiJing,L: BeiJing,O: k8s,OU: System}]
}
EOF
#API Server 会把客户端证书的 CN 字段作为 User把 names.O 字段作为 Groupcd /etc/kubernetes/pki/
cfssl gencert -caca.crt -ca-keyca.key -profilekubernetes /opt/zhangsan/zhangsan-csr.json | cfssljson -bare zhangsan chmod x user-cert.sh
./user-cert.sh
#/etc/kubernetes/pki/ 目录中会生成 zhangsan-key.pem、zhangsan.pem、zhangsan.csr使用 CFSSL 工具生成用户 zhangsan 的证书和私钥。 创建一个 user-cert.sh 脚本用于自动化证书生成过程。 运行脚本生成证书文件。
配置 kubeconfig 文件
cd /opt/zhangsanvim rbac-kubeconfig.sh
APISERVER$1
# 设置集群参数
export KUBE_APISERVERhttps://$APISERVER:6443
kubectl config set-cluster kubernetes \--certificate-authority/etc/kubernetes/pki/ca.crt \--embed-certstrue \--server${KUBE_APISERVER} \--kubeconfigzhangsan.kubeconfig# 设置客户端认证参数
kubectl config set-credentials zhangsan \--client-key/etc/kubernetes/pki/zhangsan-key.pem \--client-certificate/etc/kubernetes/pki/zhangsan.pem \--embed-certstrue \--kubeconfigzhangsan.kubeconfig# 设置上下文参数
kubectl config set-context kubernetes \--clusterkubernetes \--userzhangsan \--namespacegzb \--kubeconfigzhangsan.kubeconfig# 使用上下文参数生成 zhangsan.kubeconfig 文件
kubectl config use-context kubernetes --kubeconfigzhangsan.kubeconfig使用 rbac-kubeconfig.sh 脚本设置 kubeconfig 文件包括集群参数、客户端认证参数和上下文参数。 将生成的 kubeconfig 文件复制到用户的家目录并设置正确的权限。
创建命名空间
kubectl create namespace gzb
chmod x rbac-kubeconfig.sh
./rbac-kubeconfig.sh 192.168.41.31#查看证书
cat zhangsan-kubeconfigmkdir /home/zhangsan/.kube
cp zhangsan.kubeconfig /home/zhangsan/.kube/config
chown -R zhangsan:zhangsan /home/zhangsan/.kube/使用 kubectl 创建一个名为 gzb 的命名空间。
RBAC 授权
vim rbac.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:namespace: gzbname: pod-reader
rules:
- apiGroups: []resources: [pods]verbs: [get, watch, list, create]---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:name: read-podsnamespace: gzb
subjects:
- kind: Username: zhangsanapiGroup: rbac.authorization.k8s.io
roleRef:kind: Rolename: pod-readerapiGroup: rbac.authorization.k8s.iokubectl apply -f rbac.yamlkubectl get role,rolebinding -n gzb
NAME AGE
role.rbac.authorization.k8s.io/pod-reader 32sNAME AGE
rolebinding.rbac.authorization.k8s.io/read-pods 32s创建一个名为 pod-reader 的 Role允许在 gzb 命名空间中读取 Pods。 创建一个 RoleBinding将 pod-reader Role 绑定到用户 zhangsan。
测试操作权限
//切换用户测试操作权限
su - zhangsanvim pod-test.yaml
apiVersion: v1
kind: Pod
metadata:name: pod-test
spec:containers:- name: nginximage: nginxkubectl create -f pod-test.yamlkubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod-test 1/1 Running 0 114s 10.244.2.2 node02 none none//访问 svc 资源就会被拒绝
kubectl get svc
Error from server (Forbidden): services is forbidden: User zhangsan cannot list resource services in API group in the namespace gzb//也无法访问 default 命名空间
kubectl get pods -n default
Error from server (Forbidden): pods is forbidden: User zhangsan cannot list resource pods in API group in the namespace default//使用 root 用户查看
kubectl get pods --all-namespaces -o wide
NAMESPACE NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
gzb pod-test 1/1 Running 0 107s 10.244.2.2 node02 none none
......
#由此可以看出 RoleBinding 的用户只能管理指定的命名空间中的资源切换到 zhangsan 用户尝试创建 Pod。 尝试访问其他命名空间或资源如 Services以验证权限限制。
管理员权限
#也可以通过绑定 admin 角色来获得管理员权限
kubectl create rolebinding zhangsan-admin-binding --clusterroleadmin --userzhangsan --namespacegzb如果需要可以创建一个新的 RoleBinding将 admin 角色绑定到用户 zhangsan从而授予其管理员权限。
这个过程展示了如何通过 RBAC 和证书管理来控制用户对 Kubernetes 集群资源的访问。通过这种方式可以确保用户只能访问和操作他们被授权的资源从而提高集群的安全性。
