企业官网建设流程全解析

孟州哪里可以做网站,天津网站建设定制,做gif的网站,工程信息平台有哪些前言 本文系统阐述Kubernetes安全机制的核心架构与实践方法#xff0c;详细解析API Server保护的三大关键环节#xff1a;认证、鉴权和准入控制#xff0c;以及如何通过RBAC实现细粒度权限管理。特别聚焦在实践中如何创建安全隔离的集群访问账号#xff0c;适用于Kubernet…前言本文系统阐述Kubernetes安全机制的核心架构与实践方法详细解析API Server保护的三大关键环节认证、鉴权和准入控制以及如何通过RBAC实现细粒度权限管理。特别聚焦在实践中如何创建安全隔离的集群访问账号适用于Kubernetes安全架构设计与运维人员。安全机制说明认证身份鉴权权限准入控制实践赋权普通用户操作k8s理论部分1_安全机制概述安全机制保护Kubernetes集群中API Server的三层防护体系防止未授权访问和操作。1.1_机制说明安全体系设计原因Kubernetes作为分布式集群管理工具API Server是内部组件通信中介与外部控制入口安全机制围绕保护API Server设计。安全三大环节认证Authentication验证你是谁确认请求主体身份 — 身份验证鉴权Authorization确定你能做什么判定权限范围 — 资源权限控制准入控制Admission Control决定是否允许该请求被接受请求进一步校验 — 二次验证工作流程客户端如kubectl向API Server发送请求请求通过三重安全关卡认证→鉴权→准入控制所有关卡通过后API Server才处理该请求2_认证Authentication2.1_认证方式认证方式API Server支持的三种主要认证方式。认证方式实现原理特点核心作用HTTP TokenHTTP Header携带难以仿冒的长TokenAPI Server维护Token与用户权限的映射。授权访问特定API或资源HTTP BasicBase64编码的用户名:密码放入Authorization字段简单但安全性极低密码明文传输必须配合HTTPS最基础的身份验证HTTPS证书基于CA根证书签名的双向TLS认证最严格实现客户端与服务器的双向身份验证建立通信双方的可信身份并加密通道重要说明Token与Basic认证仅支持服务端对客户端的单向认证HTTPS证书认证可实现双向认证客户端与服务端互相验证2.2_认证对象需要被认证的访问类型Kubernetes组件对API Server的访问kubectl、kubelet、kube-proxy由Kubernetes管理的Pod对API Server的访问coredns、dashboard等端口与证书安全性Controller Manager、Scheduler与API Server同机常走非安全端口如8080kubectl、kubelet、kube-proxy访问API Server需HTTPS双向认证端口使用64432.3_证书管理证书颁发方式手动签发二进制部署时需与CA手动签发HTTPS证书自动签发kubelet首次访问用token认证通过后由Controller Manager生成证书kubeconfig包含三类关键参数的配置文件集群参数CA证书、API Server地址客户端参数证书与私钥上下文参数集群名、用户名、命名空间kubectl默认位置~/.kube/configService Account (SA)用于Pod中容器访问API Server的身份标识自动应对Pod动态创建/销毁场景无需为每个Pod单独发证书默认每个命名空间都有一个SA2.4_Secret与SA的关系Secret对象类型service-account-token保存ServiceAccount的令牌Opaque保存用户自定义的保密信息Service Account组成TokenAPI Server私钥签名的Tokenca.crtCA根证书验证API Server证书namespaceservice-account-token的命名空间作用域默认行为若创建Pod时未指定SA将使用所属命名空间的defaultSA系统自动将以下内容挂载到容器/var/run/secrets/kubernetes.io/serviceaccount/ ├── ca.crt ├── namespace └── token小结k8s 安全机制 3关 认证 鉴权 准入控制 认证 token 使用很长复杂的token令牌字符串 来做认证通常是单向认证 basic 使用账号 密码的格式通过 base64编码和解码来做认证 通常是单向的认证 https 使用CA机构签发的证书进行https认证 可以实现双向认证 k8s 认证 组件 **Controller Manager、Scheduler** **kubectl、kubelet、kube-proxy** 等与apiserver通信是使用https证书认证默认使用6443进行通信 未知Scheduler Controller 使用内部端口 8080 使用kubeconfig配置文件就知道使用什么证书连接到那个K8s的集群的APIserver pod 形式 的组件 dashboad coredns 外置存储常插件 比如 NFS provsisnor与APIserver通信使用serviceaccount作为pod服务的账号来访问APIserver 每个pod都会有 一个 serviceaccouint服务账号可以创建pod资源时指定serviceaccouint字段3_鉴权Authorization 重点3.1_授权策略对比授权策略API Server通过--authorization-mode参数配置。策略特点适用场景AlwaysDeny拒绝所有请求测试环境AlwaysAllow允许所有请求无安全要求环境ABAC淘汰基于用户配置的属性的静态规则繁琐需重启ApiServer。简单权限需求Webhook外部REST服务鉴权触发器钩子统一外部认证系统RBAC基于角色的动态权限细粒度与资源模型一致。生产环境默认(≥v1.6)RBAC核心优势覆盖资源Pod/Deployment/Service与非资源元信息/状态由标准API资源对象构成可用kubectl/API管理运行时可调整无需重启API ServerABAC需重启3.2_RBAC资源对象① RBAC引入的四个顶级对象Role命名空间级权限定义定义特定命名空间的权限ClusterRole集群级权限跨命名空间。定义集体集群范围内的所有权限RoleBinding命名空间内将角色绑定到主体将Role或ClusterRole绑定到特定命名空间的主体ClusterRoleBinding集群级将角色绑定到主体将ClusterRole绑定到整个集群范围内的主体② 绑定规则RoleBinding可引用ClusterRole但仍受命名空间限制ClusterRoleBinding只能绑定ClusterRole作用于全集群③ 权限控制模型仅能累加白名单模型不存在先权限多再减少的黑名单机制Role仅限单一命名空间ClusterRole可跨命名空间3.3_角色与角色绑定① 角色定义Role只定义在一个命名空间内的权限ClusterRole可定义跨多个命名空间的权限Role示例在default命名空间读取PodapiVersion:rbac.authorization.k8s.io/v1kind:Rolemetadata:namespace:defaultname:pod-readerrules:-apiGroups:[]resources:[pods]verbs:[get,watch,list]ClusterRole示例读取所有命名空间SecretapiVersion:rbac.authorization.k8s.io/v1kind:ClusterRolemetadata:name:secret-readerrules:-apiGroups:[]resources:[secrets]verbs:[get,watch,list]② 角色绑定RoleBinding将Role/ClusterRole绑定到主体User/Group/SA限于命名空间ClusterRoleBinding在全集群范围绑定ClusterRole到主体RoleBinding示例将pod-reader绑定给jxc用户apiVersion:rbac.authorization.k8s.io/v1kind:RoleBindingmetadata:name:read-podsnamespace:defaultsubjects:-kind:Username:jxcapiGroup:rbac.authorization.k8s.ioroleRef:kind:Rolename:pod-readerapiGroup:rbac.authorization.k8s.io③ 主体Subject类型User用户Group用户组ServiceAccount服务账号系统保留前缀system:*管理员应避免普通用户使用④ 资源Resources定义K8s资源以名称字符串表示如pods, services子资源如pods/logAPI访问示例GET /api/v1/namespaces/{namespace}/pods/{name}/log在RBAC中使用资源/子资源控制访问④ 常见权限verbsget、list、watch、create、update、patch、delete、execresourcesservices、pods、secrets、configmaps等apiGroups“”core、apps、autoscaling等小结1、角色Role/clusterRole Role: 定义 特定的命名空间内的权限 clusterRole定义整体集群范围内的所有权限 2、角色绑定 RoleBinding/clusterRolebing RoleBinding: 将Role或clusterRole绑定到特定单的命名空间内的用户、组或服务账号 clusterRolebing将clusterRole绑定到整个集群范围内的用户、组或服务账号 主体subject 用户 User 组(Group) 服务账号SerivceAccount 权限管理 RBAC 基于 白名单 机制 只能增加权限 无法通过RBAC 直接减少权限 resource http 调用 一个方法 get pull put kubectl get pod 来获取 资源的信息 GET /api/v1/namespaces/pods4_准入控制AdmissionControl4.1_准入控制概述Admission ControlAPI Server处理请求前的最后一道关卡。工作机制一组插件链请求依次通过该列表若任意插件拒绝整个请求即被拒绝建议采用官方推荐的控制器组合官方默认插件链不同版本有所不同NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,NodeRestriction4.2_关键插件功能重点插件说明NamespaceLifecycle命名空间生命周期管理阻止在不存在的命名空间创建对象阻止删除系统命名空间删除命名空间时级联清理LimitRanger配额与限制管理确保请求不超过该命名空间的LimitRangeServiceAccount为Pod自动注入ServiceAccount便于Pod访问API ServerResourceQuota命名空间级高级配额确保不超过该命名空间的ResourceQuotaNodeRestriction限制Node加入集群后的权限遵循最小权限原则官方文档https://kubernetes.io/zh/docs/reference/access-authn-authz/admission-controllers/实验部分1_创建仅能管理指定命名空间的用户1.1_准备工作① 创建系统用户创建操作系统层用户useraddjxcechoqwer1234|passwd--stdin jxc# 切换用户验证su- jxc kubectl get podsThe connection to the server localhost:8080 was refused - did you specify the right host or port? 连接到服务器 localhost:8080 被拒绝 - 您是否指定了正确的主机或端口useradd创建系统用户passwd设置用户密码jxc用户还未配置kubeconfig所以访问失败为正常现象1.2_生成证书与kubeconfig① 上传证书工具从本地上传证书工具cfssl、cfssljson、cfssl-certinfo到 Master节点主机的/usr/local/bin目录下# userlocalhostscpcfssl cfssljson cfssl-certinfo rootk8s-master01:/usr/local/bin/CFSSL工具链是用于简单快速创建和管理TLS证书的命令行工具集。cfssl是核心生成器cfssljson负责拆分证书文件cfssl-certinfo用于查看证书信息RSA/ECC非对称加密工具注释RSA历史久远更常见ECC更小更安全更现代。类似TLS是SSL的迭代产品。工具特点适合场景OpenSSL老牌经典功能全面预装在多数系统单次手动操作、故障排查、学习原理CFSSL现代配置驱动易于自动化云平台、容器集群如K8s、需要批量签发证书并赋予执行权限# rootk8s-master chmod x /usr/local/bin/cfssl* mkdir -p /opt/jxc cd /opt/jxccfssl系列工具需提前安装并放置在PATH中② 创建证书请求文件# rootk8s-master01:/opt/jxcvimuser-cert.sh#!/bin/bashkube_userjxccat$kube_user-csr.jsonEOF { CN: $kube_user, hosts: [], key: { algo: rsa, size: 2048 }, names: [ { C: CN, ST: BeiJing, L: BeiJing, O: k8s, OU: System } ] } EOFcd/etc/kubernetes/pki/ cfssl gencert -caca.crt -ca-keyca.key -profilekubernetes /opt/$kube_user/$kube_user-csr.json|cfssljson -bare$kube_useralgoalgorithm算法的缩写CN作为User身份names.O作为Group身份k8sAPI Server会将CN作为Usernames.O作为Grouphosts: []用户认证不需要填写服务器/节点/Pod认证才需要补全hosts信息(IP/域名)。后面会warning警告不必理会。执行证书生成会在/etc/kubernetes/pki/生成证书jxc-key.pem、jxc.pem、jxc.csr# rootk8s-master01:/opt/jxcchmodx user-cert.sh ./user-cert.shls/opt/jxc /etc/kubernetes/pki/|grep^jxcjxc.csr jxc-key.pem jxc.pem jxc-csr.jsonjxc-csr.json生成证书的申请配置模板里面填写了你的身份信息和需求。jxc-key.pem你的私钥是绝不能泄露的核心秘密用来证明你的身份并对CSR签名。jxc.csr根据配置和私钥生成的证书请求文件包含你的公钥和信息并由私钥签名(数字签名)提交给CA机构用于申请证书。jxc.pemCA机构颁发给你的正式证书包含了你的公钥和CA的签名是公开的身份凭证。③ 生成kubeconfig创建kubeconfig生成脚本vimrbac-kubeconfig.sh#!/bin/bashAPISERVER192.168.100.13# 必须替换为实际API Server IPkube_userjxc# 替换为的kube用户kube_namespaceyjs1023# 替换为实际的命名空间# 设置集群参数exportKUBE_APISERVERhttps://$APISERVER:6443kubectl config set-cluster kubernetes\--certificate-authority/etc/kubernetes/pki/ca.crt\--embed-certstrue\--server${KUBE_APISERVER}\--kubeconfig$kube_user.kubeconfig# 设置客户端认证参数kubectl config set-credentials$kube_user\--client-key/etc/kubernetes/pki/$kube_user-key.pem\--client-certificate/etc/kubernetes/pki/$kube_user.pem\--embed-certstrue\--kubeconfig$kube_user.kubeconfig# 设置上下文参数kubectl config set-context kubernetes\--clusterkubernetes\--user$kube_user\--namespace$kube_namespace\--kubeconfig$kube_user.kubeconfig# 使用上下文参数生成 .kubeconfig 文件kubectl config use-context kubernetes --kubeconfig$kube_user.kubeconfig设置集群参数、客户端认证参数和上下文生成实际kubeconfigchmodx rbac-kubeconfig.sh ./rbac-kubeconfig.sh生成jxc.kubeconfig文件1.3_权限配置① 创建命名空间与应用配置创建测试命名空间kubectl create namespace yjs1023分发kubeconfig到用户目录mkdir-p /home/jxc/.kubecpjxc.kubeconfig /home/jxc/.kube/configchown-R jxc:jxc /home/jxc/.kube/使jxc用户能使用此配置文件② 创建RBAC规则创建rbac.yaml权限配置文件vimrbac.yamlapiVersion:rbac.authorization.k8s.io/v1kind:Rolemetadata:namespace:yjs1023name:pod-readerrules:-apiGroups:[]resources:[pods]verbs:[get,watch,list,create]---apiVersion:rbac.authorization.k8s.io/v1kind:RoleBindingmetadata:name:read-podsnamespace:yjs1023subjects:-kind:Username:jxcapiGroup:rbac.authorization.k8s.ioroleRef:kind:Rolename:pod-readerapiGroup:rbac.authorization.k8s.io定义jxc在yjs1023命名空间的权限get/watch/list/create Pod应用RBAC配置kubectl apply -f rbac.yaml kubectl get role,rolebinding -n yjs1023NAME CREATED AT role.rbac.authorization.k8s.io/pod-reader 2026-01-21T14:28:54Z NAME ROLE AGE rolebinding.rbac.authorization.k8s.io/read-pods Role/pod-reader 28s1.4_权限验证① 验证jxc各项权限切换用户并创建测试Podsu- jxccatrole-rolebinding-test.yamlYAML apiVersion: v1 kind: Pod metadata: name: role-rolebinding-test spec: containers: - name: nginx image: nginx YAMLkubectl create -f role-rolebinding-test.yaml kubectl get pods -o wide预期输出role-rolebinding-test成功创建并运行测试跨命名空间访问kubectl get pods -n defaultError from server (Forbidden): pods is forbidden: User jxc cannot list resource pods in API group in the namespace default访问其他命名空间失败权限受限测试其他资源访问kubectl get svcError from server (Forbidden): services is forbidden: User jxc cannot list resource services in API group in the namespace yjs1023无权限查看Service资源② 管理员视角验证root用户查看资源# rootk8s-masterkubectl get pods --all-namespaces -o wideNAMESPACE NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES yjs1023 role-rolebinding-test 1/1 Running 0 5m2s 10.244.1.17 k8s-node01 none none确认RoleBinding已生效查看所有角色和绑定kubectl get role,rolebinding -n yjs1023③ 可选授予管理员权限授予用户特定命名空间管理员权限kubectl create rolebinding jxc-admin-binding\--clusterroleadmin\--userjxc\--namespaceyjs1023将集群admin角色绑定到用户但限制在yjs1023命名空间结语如果想要有让一个pod 或者 Serivce secert configmap等 /普通用户 具有 接入 k8s 集群相关资源的操作权限 1、创建serviceaccount 或者 用户 2、做认证 token/证书认证 ​ ① serviceaccount 会自动 生成Serivceaccount token 的 secret 资源 ​ ② 用户需要创建证书使用cfssl等工具通过CA证书和私钥文件 生成 证书和 私钥文件 使用CA证书和私钥文件来去创建kubeconfig配置文件 把kubeconfig配置文件导入用户的家目录中 目录名.kube/config文件中 3、做RBAC鉴权 Role|clusterRole 创建角色赋予给资源的操作权限**resources**、verbs Rolebinding|cluster Rolebinding 把主体用户|组|服务账号和角色进行绑定 此时切换用户后pod 或者用户具有相关的命名空间的中对相关子资源有了操作权限API Server安全Kubernetes通过认证、鉴权和准入控制三道防线保护API Server6443端口是安全访问的关键门户。RBAC架构基于Role/ClusterRole定义权限通过RoleBinding/ClusterRoleBinding进行绑定实现命名空间级精细权限控制。安全最佳实践最小权限原则通过SA管理Pod访问权限RBAC结合NetworkPolicy实现纵深防御。[!question] 请问Kubernetes安全体系的三个环节分别是什么认证确认身份、鉴权确认权限、准入控制请求验证 请求必须经过这三道关卡才能被API Server处理[!question] 为什么说RBAC是生产环境的推荐选择RBAC支持运行时调整权限无需重启API Server通过标准API资源管理支持命名空间级和集群级权限控制[!question] ServiceAccount自动产生哪些内容自动挂载三个文件到容器token认证令牌、ca.crtAPI Server根证书、namespace命名空间信息[!question] 如何限制用户只能在特定命名空间操作通过RoleRoleBinding组合Role定义命名空间内权限RoleBinding将角色绑定到特定用户[!question] AlwaysAllow和AlwaysDeny策略适用于什么场景AlwaysAllow用于无安全要求或测试场景AlwaysDeny用于安全测试模拟拒绝所有请求环境