如何评价网站是否做的好处,移动网站开发书籍,wordpress插件汉化工具,品牌创意网站建设目录
引言
一、Kubernetes安全机制概述
二、认证机制
#xff08;一#xff09;认证方式
1.HTTPS证书认证
1.1 证书颁发
1.2 config文件
1.3 认证类型
1.4 Service Account
1.4.1 作用
1.4.2 包含内容
1.4.3 与Secret的关系
2.Bearer Tokens
3.基本认证
三、鉴…目录
引言
一、Kubernetes安全机制概述
二、认证机制
一认证方式
1.HTTPS证书认证
1.1 证书颁发
1.2 config文件
1.3 认证类型
1.4 Service Account
1.4.1 作用
1.4.2 包含内容
1.4.3 与Secret的关系
2.Bearer Tokens
3.基本认证
三、鉴权
一鉴权机制
1.基于RBAC
2.其它鉴权机制
二RBAC的API资源对象
1.Role角色
2.ClusterRole集群角色
3.RoleBinding角色绑定
4.ClusterRoleBinding集群角色绑定
5. 主体subject类型
5.1 User
5.2 Group
5.3 ServiceAccount
三创建角色及绑定
1.创建服务账号
2.创建Role
3.创建RoleBinding
4.创建pod
5.示例总结
四、准入控制
一准入控制器的工作流程
二准入控制器的类型
五、对用户的权限设置
一创建证书
1.获取工具
2.创建生成证书的配置文件
3.生成证书
二生成config文件
三RBAC授权
1.创建Role资源
2.Role绑定
四切换用户使用
1.创建pod
2.其它权限
3.获取管理员权限 引言
随着云计算和容器技术的蓬勃发展KubernetesK8s作为容器编排的领头羊其安全性成为了众多企业和开发者关注的焦点。本文将详细解析Kubernetes的安全机制包括认证、鉴权和准入控制以确保集群的稳定性和数据的安全。
一、Kubernetes安全机制概述
Kubernetes的安全机制主要围绕三个核心组件认证、鉴权和准入控制。认证是安全机制的第一道防线负责确认请求者的身份鉴权则是根据用户的身份和权限策略确定其是否有权执行特定操作最后准入控制对API资源对象的修改和校验进行把关。
二、认证机制
一认证方式
1.HTTPS证书认证
HTTPS证书认证基于CA证书颁发机构证书签名的数字证书认证。
适用于kube-apiserver、etcd、kubelet等组件之间的连接确保通信的安全性。
当Pod在Kubernetes集群中启动时Service Account通常会使用客户端证书进行身份验证。
1.1 证书颁发
手动签发使用二进制部署时需要先手动跟 CA 进行签发 HTTPS 证书
自动签发kubelet 首次访问 API Server 时使用 token 做认证通过后Controller Manager 会为 kubelet 生成一个证书 以后的访问都是用证书做认证了
1.2 config文件
[rootmaster01 ~]#ll ~/.kube/config
-rw------- 1 root root 5565 5月 16 15:19 /root/.kube/config
#家目录下的.kube/config文件用于存储用户的认证信息
#kubectl通过该文件的令牌信息确定使用的用户以及对应的权限
1.3 认证类型 Kubernetes 组件对 API Server 的访问如kubelet、kubectl、kube-proxy由于这些组件是在node节点上所以需要证书进行HTTPS双向认证端口号使用6443端口 Kubernetes 管理的 Pod 对 API Server 的访问 注释访问安全性要求
kubernetes中API Server会启动8080端口非安全端口与6443端口安全端口
安全性8080端口没有认证和授权检查存在安全风险而6443端口有TLS保护更加安全。
用途8080端口主要用于调试或内部通信而6443端口是Kubernetes集群的官方通信端口用于与外部工具和组件进行交互。
配置两个端口的配置都可以通过apiserver的启动参数进行修改。在生产环境中通常建议只开启6443端口并确保其安全性。 1.4 Service Account
1.4.1 作用 Service Account是Kubernetes中的一种资源对象用于定义Pod中应用程序的身份。 主要作用是为Pod提供身份使得Pod可以在Kubernetes集群中被唯一标识并通过身份验证和授权机制获取访问API Server的权限 因为 Pod 的创建、销毁是动态的所以要为每一个 Pod 手动生成证书就不可行了。 Kubenetes 使用了 Service Account 来循环认证。Service Account提供了一个在Pod内部使用的身份令牌用于在Pod与Kubernetes API之间进行交互。 1.4.2 包含内容 ●Token是使用 API Server 私钥签名的 Token 字符串序列号用于访问 API Server 时Server 端认证 ●ca.crtca 根证书用于 Client 端验证 API Server 发送来的证书 ●namespace标识这个 service-account-token 的作用域名空间 每个命名空间都有一个默认的ServiceAccount如果用户不指定ServiceAccountPod将自动关联到该默认的ServiceAccount上。
1.4.3 与Secret的关系
当Service Account创建时Kubernetes会自动为每个ServiceAccount创建一个与之关联的Secret其中包含了ServiceAccount的身份令牌。 [rootmaster01 opt]#kubectl describe pod nginx
...... Mounts:/var/run/secrets/kubernetes.io/serviceaccount from default-token-vgx6f (ro)
......
2.Bearer Tokens
令牌认证用户或服务可以通过获取一个令牌Token并在请求中携带该令牌来进行身份验证。 HTTP Token 的认证是用一个很长的特殊编码方式的并且难以被模仿的 Token 字符串来表达客户的一种方式。Token 是一个很长的很复杂的字符串每一个 Token 对应一个用户名存储在 API Server 能访问的文件中。当客户端发起 API 调用请求时需要在 HTTP Header 里放入 Token。 在node节点加入master时就需要令牌来进行连接 3.基本认证
HTTP Basic Auth使用用户名和密码进行基本的HTTP认证。
在Kubernetes中这种认证方式相对较少使用因为它不如其他方式安全。
注释Token 认证和 Base 认证方式只能进行服务端对客户端的单向认证而客户端不知道服务端是否合法而 HTTPS 证书认证方式 则可以实现双向认证。
三、鉴权
一鉴权机制
1.基于RBAC
Kubernetes的鉴权机制主要基于Role-Based Access ControlRBAC实现。RBAC允许管理员定义角色Role和角色绑定RoleBinding以控制用户对资源的访问权限。角色定义了用户可以执行的操作和可以访问的资源而角色绑定则将角色与用户或用户组进行关联。通过这种方式管理员可以灵活地配置权限策略确保只有授权用户才能执行特定操作。
2.其它鉴权机制
●AlwaysDeny表示拒绝所有的请求一般用于测试 ●AlwaysAllow允许接收所有请求如果集群不需要授权流程则可以采用该策略一般用于测试 ●ABACAttribute-Based Access Control基于属性的访问控制表示使用用户配置的授权规则对用户请求进行匹配和控制。也就是说定义一个访问类型的属性用户可以使用这个属性访问对应的资源。此方式设置较为繁琐每次设置需要定义一长串的属性才可以。 ●Webhook通过调用外部 REST 服务对用户进行授权即可在集群外部对K8S进行鉴权
二RBAC的API资源对象
1.Role角色 定义Role 是一个针对单个命名空间的权限控制对象包含了若干的rules这些rules代表了一组的permissions准入、权限。这些准入是叠加起作用的并且RBAC在Kubernetes中是一种白名单机制即都是“允许干xxx”而不是“不允许干xxx”。 使用Role属于某个特定的namespace所以在创建Role时需要指定其所属的namespace。 2.ClusterRole集群角色 定义ClusterRole 是一个集群范围的概念用于定义对Kubernetes资源集群级别包含全部命名空间的访问规则。ClusterRole 不属于某个特定的namespace它可以定义跨所有命名空间的资源权限也可以定义集群级别的资源权限。 使用ClusterRole 可以像Role一样使用用于对cluster-scoped resources如nodes和非资源端点如/healthz进行权限的赋予。 3.RoleBinding角色绑定 定义RoleBinding 定义了“Role”和“Subject”如User、Group或ServiceAccount的绑定关系即将用户以及操作权限进行绑定。 使用使用RoleBinding可以将User和某个Role进行绑定这样User就拥有了Role所定义的权限但只能操作RoleBinding所在的命名空间。 4.ClusterRoleBinding集群角色绑定 定义ClusterRoleBinding 定义了用户和集群角色的关系即通过ClusterRoleBinding将User和ClusterRole进行绑定。 使用通过ClusterRoleBindingUser可以获得ClusterRole所定义的权限从而拥有操作所有命名空间的权限。 5. 主体subject类型
在Kubernetes中User、Group 和 ServiceAccount 都是安全认证和授权模型中的主体subject类型。这些主体代表了可以执行操作的实体并且与特定的权限相关联
5.1 User 用户通常代表一个真实的或虚拟的人。在Kubernetes中用户可能是一个集群外部的实体如一个开发者或管理员他们使用kubectl或其他客户端工具与集群交互。 用户的身份验证可以通过多种方式进行包括静态令牌、OAuth令牌、OpenID ConnectOIDC等。 一旦通过身份验证用户的身份会与一个或多个Group关联以进一步简化授权。 5.2 Group 用户组是用户的集合通常用于简化权限管理。例如你可能有一个名为developers的用户组并为该组分配特定的权限。 用户的组成员资格可以静态定义也可以通过身份验证机制如OIDC动态确定。 授权策略可以基于用户组进行定义从而允许或拒绝整个组的访问。 5.3 ServiceAccount 服务账号ServiceAccount是Kubernetes内部的一个实体用于给Pods中的进程提供访问集群API的凭据。 每个Pod都可以与一个ServiceAccount关联该ServiceAccount包含了一个API令牌该令牌允许Pod中的容器以Pod的身份对Kubernetes API发起请求。 ServiceAccount是Pod的安全上下文的一部分通常与特定的命名空间相关联。 与User和Group不同ServiceAccount是专为集群内部的服务和工作负载设计的。 三创建角色及绑定
1.创建服务账号
首先创建一个服务账号Service Account
[rootmaster01 rbac]#vim sa.yaml
[rootmaster01 rbac]#cat sa.yaml
apiVersion: v1
kind: Namespace #创建命名空间
metadata:name: web #指定命名空间名称
---
apiVersion: v1
kind: ServiceAccount
metadata:name: rbac-sa #服务账号名称namespace: web #所在命名空间
[rootmaster01 rbac]#kubectl apply -f sa.yaml
namespace/web created
serviceaccount/rbac-sa created
[rootmaster01 rbac]#kubectl get serviceaccounts rbac-sa -n web
NAME SECRETS AGE
rbac-sa 1 26s
2.创建Role
[rootmaster01 rbac]#cat role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:name: rbac-rolenamespace: web
rules:- apiGroups: []resources: [pods]verbs: [get, watch, list]
[rootmaster01 rbac]#kubectl apply -f role.yaml
role.rbac.authorization.k8s.io/rbac-role created
[rootmaster01 rbac]#kubectl get role rbac-role -n web
NAME CREATED AT
rbac-role 2024-06-05T16:07:54Z
------------------------------------------------------------------------------
apiGroups
apiGroups字段指定了资源所属的API群组。常用apiGroups的有空字符串核心API群组例如Pods、Services、Endpoints等。
apps包含Deployments、StatefulSets、DaemonSets等应用相关的资源。
batch包含Jobs、CronJobs等资源。
extensions在旧版Kubernetes中用于某些beta API但在新版中很多资源已经移至其他群组。
networking.k8s.io网络相关的资源如Ingress。
rbac.authorization.k8s.ioRBAC相关的资源如Role、RoleBinding等。
----------------------------------------------------------------------------------
resources
resources字段列出了该角色可以访问的具体资源类型。这些资源类型必须是Kubernetes API中定义的。
以下是一些常见的资源类型示例
pods
services
deployments
configmaps
secrets
ingresses
nodes对于ClusterRole
roles 或 rolebindings对于ClusterRole允许管理RBAC资源
-----------------------------------------------------------------------------------
verbs
verbs字段定义了可以对资源执行的操作。以下是一些常用的verbs示例get读取资源。
list列出所有资源。
watch观察资源的更改。
create创建资源。
update更新资源。
patch部分更新资源。
delete删除资源。
deletecollection删除资源集合。
exec在Pod中执行命令通常与Pod资源一起使用
------------------------------------------------------------------------------------3.创建RoleBinding
[rootmaster01 rbac]#cat rolebind.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata: name: rbac-rolebindnamespace: web #RoleBinding所属的命名空间(RoleBinding也是命名空间作用域的必须指定)
subjects: #定义主体类型
- kind: ServiceAccount #主体类型为ServiceAccountname: rbac-sa #ServiceAccount名称namespace: web #指定的ServiceAccount所在命名空间
roleRef: #引用Role或者ClusterRolekind: Role #引用的资源类型为Rolename: rbac-role #引用的Role的名称apiGroup: rbac.authorization.k8s.io #表示RBAC API群组
[rootmaster01 rbac]#kubectl apply -f rolebind.yaml
rolebinding.rbac.authorization.k8s.io/rbac-rolebind created
[rootmaster01 rbac]#kubectl get rolebindings rbac-rolebind -n web -owide
NAME ROLE AGE USERS GROUPS SERVICEACCOUNTS
rbac-rolebind Role/rbac-role 35s web/rbac-sa
4.创建pod
创建pod是为了验证角色绑定后的权限效果
[rootmaster01 rbac]#cat rbac-pod.yaml
apiVersion: v1
kind: Pod
metadata: name: rbac-centos namespace: web
spec: serviceAccountName: rbac-sacontainers: - name: centosimage: centos:7command: [/bin/sh,-c,sleep 36000]
[rootmaster01 rbac]#kubectl apply -f rbac-pod.yaml
pod/rbac-centos created在pod内部使用curl命令的方式获取到pod的信息类似于执行了get权限 curl -k -H Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token) https://API_SERVER_ADDRESS:API_SERVER_PORT/api/v1/namespaces/default/pods ------------------------------------------------------------------------------------------------------------------------ API_SERVER_ADDRESSAPIServer的地址也就是master的地址 API_SERVER_PORTAPIServer的监听端口也就是6443 default指定命名空间 创建一个不指定serviceaccount的pod它就不具备权限使用curl命令访问会出现403报错表示权限拒绝
[rootmaster01 rbac]#vim rbac-pod.yaml
[rootmaster01 rbac]#cat rbac-pod.yaml
apiVersion: v1
kind: Pod
metadata: name: rbac-centos-testnamespace: web
spec:
# serviceAccountName: rbac-sa #注释serviceAccountName字段信息containers: - name: centosimage: centos:7command: [/bin/sh,-c,sleep 36000]
[rootmaster01 rbac]#kubectl apply -f rbac-pod.yaml
pod/rbac-centos-test created
[rootmaster01 rbac]#kubectl get pod rbac-centos-test -n web
NAME READY STATUS RESTARTS AGE
rbac-centos-test 1/1 Running 0 25s 5.示例总结 通过上面的示例我们创建了一个名为rbac-sa的ServiceAccount一个名为rbac-role的Role允许在web命名空间中读取Pod资源以及一个名为rbac-rolebind的RoleBinding将rbac-role Role绑定到rbac-sa ServiceAccount上。 效果是任何使用rbac-sa ServiceAccount的Pod都将具有在web命名空间中读取Pod资源的权限。这允许Pod中的进程通过Kubernetes API获取Pod列表、读取Pod详细信息或监视Pod更改但不允许它们创建、更新或删除Pod除非Role中明确允许这些操作 四、准入控制
准入控制是Kubernetes安全机制的最后一道防线对API资源对象的修改和校验进行把关。Kubernetes提供了一个插件列表所有请求都需要经过这个列表中的每个准入控制插件进行处理。这些插件可以对请求进行各种检查和修改如检查请求是否符合特定的规范、限制请求的资源配额等。通过启用不同的准入控制插件管理员可以实现对集群的细粒度控制和管理。一般建议直接采用官方默认的准入控制器
一准入控制器的工作流程
当向Kubernetes API服务器提交一个请求如创建、更新或删除资源时API服务器会将请求传递给一系列注册的准入控制器进行检查。每个控制器都会根据其配置的规则来决定是否允许请求继续。如果任何一个控制器拒绝了请求那么整个操作将不会被执行。
二准入控制器的类型
Kubernetes提供了多种内置的准入控制器包括但不限于 NamespaceAutoProvision: 自动创建请求的命名空间如果它还不存在。 ResourceQuota: 检查资源配额确保请求的资源不会超过限定。 ServiceAccount: 确保Pod自动关联一个ServiceAccount。 NodeRestriction: 限制Node上可执行的操作。 PodSecurityPolicy: 应用Pod安全策略控制Pod的运行方式。 MutatingAdmissionWebhook: 执行自定义的HTTP请求允许修改请求体。 ValidatingAdmissionWebhook: 类似于MutatingAdmissionWebhook但仅用于验证不允许修改请求。 五、对用户的权限设置
平时我们都是默认的root用户进行操作因为在~/.kube/config的配置文件中进行了令牌认证它与k8s的admin用户进行了绑定所以它会有k8s的所有操作权限。如果使用其它用户进行操作就无法使用 [rootmaster01 ~]#useradd rbac #创建一个普通用户
[rootmaster01 pki]#passwd rbac
更改用户 rbac 的密码 。
新的 密码
无效的密码 密码少于 8 个字符
重新输入新的 密码
passwd所有的身份验证令牌已经成功更新。
[rootmaster01 ~]#su - rbac
[rbacmaster01 ~]$ kubectl get pod #以普通用户的身份执行kubectl命令
The connection to the server localhost:8080 was refused - did you specify the right host or port?
[rbacmaster01 ~]$ ls ~/.kube/config
ls: 无法访问/home/rbac/.kube/config: 没有那个文件或目录
#错误信息表示kubectl命令试图连接到默认的Kubernetes API服务器地址localhost:8080但连接被拒绝了
#因为APIServer的监听端口是6443而使用kubectl命令在没有kubeconfig文件的指定情况下
#连接的是8080端口(非安全端口)所以需要进行证书认证并访问644端口
比如现在的需求是创建一个用户只能管理指定的命名空间首先要做的就是创建用户用于连接到 API Server 所需的证书和 kubeconfig 文件
一创建证书
下载生成TSL证书工具并上传到系统当中
下载地址 https://pkg.cfssl.org/R1.2/cfssl_linux-amd64 https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64 https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64 1.获取工具
[rootmaster01 cfssl]#ls
cfssl cfssl-certinfo cfssljson
[rootmaster01 cfssl]#chmod x ./*
[rootmaster01 cfssl]#ll
总用量 18808
-rwxr-xr-x 1 root root 10376657 2月 17 2021 cfssl
-rwxr-xr-x 1 root root 6595195 2月 17 2021 cfssl-certinfo
-rwxr-xr-x 1 root root 2277873 2月 17 2021 cfssljson
[rootmaster01 cfssl]#mv * /usr/local/sbin/
2.创建生成证书的配置文件
以下JSON文件是一个CFSSLCloudflares PKI/TLS toolkit的配置文件用于生成一个TLS证书和私钥
[rootmaster01 cfssl]#mkdir -p /k8s/rbac
[rootmaster01 cfssl]#vim /k8s/rbac/rbac-csr.json
[rootmaster01 cfssl]#cat /k8s/rbac/rbac-csr.json
{CN: rbac,hosts: [],key: {algo: rsa,size: 2048},names: [{C: CN,ST: BeiJing,L: BeiJing,O: k8s,OU: System}]
} CN: rbac: 这指定了证书的Common NameCN即证书的主题名。在这里它被设置为“rbac”但在实际应用中这个值应该反映证书将被用于的服务或组件的实际名称。 hosts: []: 这定义了证书应该覆盖的主机名列表。在这个例子中列表是空的意味着证书不会为任何特定的主机名提供验证。在Kubernetes中这通常不是必需的因为证书验证通常是通过其他方式如证书颁发机构或内部CA进行的。 key: 这个部分定义了私钥的生成参数。 algo: rsa: 指定了密钥算法为RSA。 size: 2048: 指定了密钥的大小为2048位。 names: 这个部分定义了证书的主题Subject信息。 C: CN: 指定了国家代码Country Code这里是“CN”代表中国。 ST: BeiJing: 指定了州/省State/Province这里是“BeiJing”代表北京。 L: BeiJing: 指定了城市/地区Locality同样是“BeiJing”。 O: k8s: 指定了组织Organization这里是“k8s”代表Kubernetes。 OU: System: 指定了组织单位Organizational Unit这里是“System”。 #API Server 会把客户端证书的 CN 字段作为 User把 names.O 字段作为 Group 3.生成证书
[rootmaster01 pki]#cfssl gencert -caca.crt -ca-keyca.key -profilekubernetes /k8s/rbac/rbac-csr.json | cfssljson -bare rbac
2024/06/06 08:51:45 [INFO] generate received request
2024/06/06 08:51:45 [INFO] received CSR
2024/06/06 08:51:45 [INFO] generating key: rsa-2048
2024/06/06 08:51:45 [INFO] encoded CSR
2024/06/06 08:51:45 [INFO] signed certificate with serial number 6178924093556289309011739985572884710402992043
2024/06/06 08:51:45 [WARNING] This certificate lacks a hosts field. This makes it unsuitable for
websites. For more information see the Baseline Requirements for the Issuance and Management
of Publicly-Trusted Certificates, v.1.1.6, from the CA/Browser Forum (https://cabforum.org);
specifically, section 10.2.3 (Information Requirements).
[rootmaster01 pki]#ls rbac*
rbac.csr rbac-key.pem rbac.pem
----------------------------------------------------------------------------------------- cfssl gencert这是 CFSSL 的一个子命令用于生成证书。 -caca.crt指定了 CA证书颁发机构的证书文件。 -ca-keyca.key指定了 CA 的私钥文件。 -profilekubernetes指定了一个配置文件中的签名配置profile。这个配置文件通常定义了证书的签名算法、有效期等参数。 /k8s/rbac/rbac-csr.json这是 CSR证书签名请求文件的路径。这个文件包含了要生成的证书的请求信息如 CNCommon Name、hosts、密钥算法等。 cfssljson -bare rbac这是 CFSSL 的另一个子命令 cfssljson用于解析 CFSSL 生成的 JSON 格式的输出并将其转换为 PEM 格式的证书和私钥文件。 -bare rbac 表示输出的文件名将以 rbac 为前缀因此你会得到 rbac.pem证书文件和 rbac-key.pem私钥文件。 综上所述这条命令的作用是使用指定的 CA 证书和私钥以及 kubernetes profile根据/k8s/rbac/rbac-csr.json 文件中的请求信息来生成一个 TLS 证书和私钥并将结果保存为 rbac.pem和 rbac-key.pem 文件。 二生成config文件
[rootmaster01 pki]#cd /k8s/rbac/
[rootmaster01 rbac]#vim rbac-config.sh
[rootmaster01 rbac]#cat rbac-config.sh
#!/bin/bash
APISERVER$1
export KUBE_APISERVERhttps://$APISERVER:6443
kubectl config set-cluster kubernetes \--certificate-authority/etc/kubernetes/pki/ca.crt \--embed-certstrue \--server${KUBE_APISERVER} \--kubeconfigrbac.kubeconfig
kubectl config set-credentials rbac \--client-key/etc/kubernetes/pki/rbac-key.pem \--client-certificate/etc/kubernetes/pki/rbac.pem \--embed-certstrue \--kubeconfigrbac.kubeconfig
kubectl config set-context kubernetes \--clusterkubernetes \--userrbac \--namespacekgc \--kubeconfigrbac.kubeconfig
kubectl config use-context kubernetes --kubeconfigrbac.kubeconfig
-----------------------------------------------------------------------------------
#以脚本的形式创建或者以命令的方式分别执行 APISERVER$1 这是一个 Bash 脚本变量赋值语句它将脚本的第一个参数$1赋值给变量 APISERVER。这个参数是 Kubernetes API 服务器的地址。export KUBE_APISERVERhttps://$APISERVER:6443 设置环境变量引用$1的参数生成的变量 --------------------------------------------------------------------------------------------------------------------------设置集群参数 使用 kubectl config set-cluster 命令设置 kubeconfig 文件中的集群信息。 --certificate-authority/etc/kubernetes/pki/ca.crt: 指定 CA 证书的路径用于验证 API 服务器的 TLS 证书。 --embed-certstrue: 将 CA 证书嵌入到 kubeconfig 文件中而不是仅引用文件路径。 --server${KUBE_APISERVER}: 设置 API 服务器的 URL。${KUBE_APISERVER} 是之前通过 $1 设置的变量。 --kubeconfigrbac.kubeconfig: 指定要修改的 kubeconfig 文件的名称。 --------------------------------------------------------------------------------------------------------------------------设置客户端认证参数 使用 kubectl config set-credentials 命令设置 kubeconfig 文件中的用户认证信息。 --client-key/etc/kubernetes/pki/rbac-key.pem: 指定客户端私钥的路径。 --client-certificate/etc/kubernetes/pki/rbac.pem: 指定客户端证书的路径。 --embed-certstrue: 类似于集群设置这也会将证书嵌入到 kubeconfig 文件中。 --kubeconfigrbac.kubeconfig: 指定要修改的 kubeconfig 文件的名称。 --------------------------------------------------------------------------------------------------------------------------设置上下文参数 使用 kubectl config set-context 命令设置 kubeconfig 文件中的上下文信息。 --clusterkubernetes: 指定要使用的集群名称这必须与 kubectl config set-cluster 命令中使用的名称相匹配。 --userrbac: 指定要使用的用户名称这必须与 kubectl config set-credentials 命令中使用的名称相匹配。 --namespacerbac-ns: 设置默认的命名空间为rbac-ns。 --kubeconfigrbac.kubeconfig: 指定要修改的 kubeconfig 文件的名称。 使用上下文参数生成 rbac.kubeconfig 文件 使用 kubectl config use-context 命令将指定的上下文设置为 kubeconfig 文件中的当前上下文。 --kubeconfigrbac.kubeconfig: 指定要修改的 kubeconfig 文件的名称。 [rootmaster01 rbac]#kubectl create ns rbac-ns
namespace/rbac-ns created
#创建默认的命名空间与上述文件中指定命名空间一致
[rootmaster01 rbac]#chmod x rbac-config.sh
[rootmaster01 rbac]#./rbac-config.sh 192.168.83.30
Cluster kubernetes set.
User rbac set.
Context kubernetes created.
Switched to context kubernetes.
查看config文件 这样看起来是不是与~/.kube/config文件很相似而后将文件移动到用户的目录下改名为config
[rootmaster01 rbac]#mkdir -p /home/rbac/.kube
[rootmaster01 rbac]#mv rbac.kubeconfig /home/rbac/.kube/config
[rootmaster01 rbac]#chown -R rbac:rbac /home/rbac/.kube/
[rootmaster01 rbac]#ls /home/rbac/.kube/
config三RBAC授权
1.创建Role资源
[rootmaster01 rbac]#vim role.yaml
[rootmaster01 rbac]#cat role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role #创建Role资源
metadata:namespace: rbac-nsname: rbac-pod
rules: #定义授权的信息
- apiGroups: [] #指定资源核心组例如Pod、Service等resources: [pods] #指定对pod资源进行授权verbs: [get, watch, list, create]
#授与get(获取)、watch(监听)、list(列出)、create(创建)权限
[rootmaster01 rbac]#kubectl apply -f role.yaml
role.rbac.authorization.k8s.io/rbac-pod created
[rootmaster01 rbac]#kubectl get role -n rbac-ns
NAME CREATED AT
rbac-pod 2024-06-06T01:30:44Z
[rootmaster01 rbac]#kubectl describe role rbac-pod -n rbac-ns
Name: rbac-pod
Labels: none
Annotations: none
PolicyRule:Resources Non-Resource URLs Resource Names Verbs--------- ----------------- -------------- -----pods [] [] [get watch list create]2.Role绑定
[rootmaster01 rbac]#vim rolebind.yaml
[rootmaster01 rbac]#cat rolebind.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding #创建角色绑定资源
metadata:name: rolebind-podnamespace: rbac-ns
subjects: #定义了哪些用户、组或服务账户可以被这个RoleBinding授权
- kind: User #指定授权的主体类型是User(用户)name: rbac #指定用户的名称apiGroup: rbac.authorization.k8s.io #指定API组对于用户而言不需要指定可省略
roleRef: #引用Role或者ClusterRolekind: Role #定义了被引用的资源的类型为Rolename: rbac-pod #被引用的角色的名称apiGroup: rbac.authorization.k8s.io #表示它们来自RBAC API组
[rootmaster01 rbac]#kubectl apply -f rolebind.yaml
rolebinding.rbac.authorization.k8s.io/rolebind-pod created
[rootmaster01 rbac]#kubectl get rolebindings -n rbac-ns
NAME ROLE AGE
rolebind-pod Role/rbac-pod 9s
[rootmaster01 rbac]#kubectl describe rolebindings rolebind-pod -n rbac-ns
Name: rolebind-pod
Labels: none
Annotations: none
Role:Kind: RoleName: rbac-pod
Subjects:Kind Name Namespace---- ---- ---------User rbac
四切换用户使用
在rbac用户指定操作内容
1.创建pod
[rootmaster01 ~]#su - rbac
上一次登录四 6月 6 08:01:29 CST 2024pts/5 上
[rbacmaster01 ~]$ kubectl get pod
No resources found in rbac-ns namespace.
#默认的命名空间为rbac-ns
[rbacmaster01 ~]$ kubectl run nginx --imagenginx:1.18.0
pod/nginx created
[rbacmaster01 ~]$ kubectl get pod
NAME READY STATUS RESTARTS AGE
nginx 1/1 Running 0 6s
--------------------------------------------------------------------------------------
#可以看到rbac用于经过授权之后可以进行查看以及创建pod的操作
2.其它权限
[rbacmaster01 ~]$ kubectl get ns
Error from server (Forbidden): namespaces is forbidden: User rbac cannot list resource namespaces in API group at the cluster scope
#查看命名空间被权限拒绝
[rbacmaster01 ~]$ kubectl get svc
Error from server (Forbidden): services is forbidden: User rbac cannot list resource services in API group in the namespace rbac-ns
#查看service资源被权限拒绝
[rbacmaster01 ~]$ kubectl delete pod nginx
Error from server (Forbidden): pods nginx is forbidden: User rbac cannot delete resource pods in API group in the namespace rbac-ns
#同样的没有对pod资源授予删除权限所以无法删除
[rbacmaster01 ~]$ kubectl get pod nginx
NAME READY STATUS RESTARTS AGE
nginx 1/1 Running 0 4m-------------------------------------------------------------------------------------[rootmaster01 rbac]#kubectl get pod -n rbac-ns
NAME READY STATUS RESTARTS AGE
nginx 1/1 Running 0 5m40s
#在root用户同样可以查看到新建的pod
3.获取管理员权限
//在root用户中操作
[rootmaster01 rbac]#kubectl create rolebinding rbac-admin-binding --clusterroleadmin --userrbac -n rbac-ns
#将rbac用户与admin集群角色进行绑定并指定rbac-ns命名空间
#执行此命令后rbac用户会拥有rbac-ns命名空间中所有的资源的管理权限
rolebinding.rbac.authorization.k8s.io/rbac-admin-binding created
[rootmaster01 rbac]#kubectl get rolebindings rbac-admin-binding -n rbac-ns
NAME ROLE AGE
rbac-admin-binding ClusterRole/admin 20s//在rbac用户中操作
[rbacmaster01 ~]$ kubectl get service
No resources found in rbac-ns namespace.
[rbacmaster01 ~]$ kubectl expose pod nginx --port80 --target-port80 --namenginx-svc --typeNodePort
service/nginx-svc exposed
[rbacmaster01 ~]$ kubectl get service -owide
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
nginx-svc NodePort 10.96.211.179 none 80:30309/TCP 8s runnginx
#可以看到rbac用于拥有对其它资源的同样拥有操作权限 但是该管理员权限仅限于指定的命名空间无法所其它命名空间进行操作 在工作环境中对于不同的层次可以对指定的命令空间有不同的权限负责人或领导也可能需要一个命名空间的所有权限类似于一个项目每个人都有不同的职责一个人负责pod创建一个人负责对外发布各司其职所有需要不同的权限但是在赋权时一定要谨慎
声明式删除资源
[rbacmaster01 ~]$ kubectl delete svc nginx-svc
service nginx-svc deleted
[rbacmaster01 ~]$ kubectl delete pod nginx
pod nginx deleted
[rbacmaster01 ~]$ kubectl get svc,pod
No resources found in rbac-ns namespace.
