开头语
写在前面:如有问题,以你为准,
目前24年应届生,各位大佬轻喷,部分资料与图片来自网络
内容较长,页面右上角目录方便跳转
Kubernetes 安全架构
K8S安全控制框架主要由下面3个阶段进行控制,每一个阶段都支持插件方式,通过API Server配置来启用插件。
① Authentication(认证):身份鉴别,只有正确的账号才能通过认证。
② Authorization(授权):判断用户是否有权限对访问的资源执行特定的动作。
③ Admission Control(准入控制):用于补充授权机制以实现更加精细的访问控制功能
- 用户携带令牌或者证书给 Kubernetes 的 api-server 发送请求,要求修改集群资源。
- Kubernetes 开始认证。
- Kubernetes 认证通过之后,会查询用户的授权(有哪些权限)。
- 用户执行操作的过程中(操作 CPU、内存、硬盘、网络……),利用准入控制来判断是否可以执行这样的操作。
两种类型
Kubenetes组件对API Server的i访i问:kubectl、.Controller Manager、Scheduler、kubelet,kube-proxy
Kubernetes管理的Pod对容器的访问:Pod(dashborad也是以Pod形式运行)
安全性说明
Controller Manager、Scheduler与API Server在同一台机器,所以直接使用API Server的非安全端口
访问,--insecure-.bind-address-127.0.0.1
kubectl、kubelet、kube-proxy访间API Server就都需要证书进行HTTPS双向认证
证书颁发
自动签发:kubelet首次访问API Server时,使用token做认证,通过后,Controller Manager会为kubelet生成一个证书,以后的访问都是用证书做认证了
kubeconfig
kubeconfig文件包含集群参数(CAi证书、API Serveri地址),客户端参数(上面生成的证书和私钥),集群context信息(集群名称、用户名)。
Kubenetes组件通过启动时指定不同的kubeconfig文件可以切换到不同的集群
[root@master cks]# ls /root/.kube/cache config
ServiceAccount
Pod中的容器访问API Server。因为Pod的创建、销毁是动态的,所以要为它手动生成i证书就不可行了。Kubenetes使用了Service Account解决Pod访问API Server的认证问题
default SA
- 当创建naamespacel时,会自动创建一个名为default的SA,这个SA没有绑定任何权限
- 当default SA创建时,会自动创建一个default-token-xxx的secret,并自动关联到SA
- 当创建Pod时,如果没有指定SA,会自动为pod以volume方式挂载这个default SA,在容器目录:var/run/secrets/kubernetes.io/serviceaccount
- 验证默认SA权限:kubectl --as=system:serviceaccount:default:default get pods
Secret 与 SA 的关系
Kubernetes 设计了一种资源对象叫做Secret,分为两类,
一种是用于ServiceAccount的service-account-token
一种是用于保存用户自定义保密信息的Opaque,.ServiceAccount中用到包含三个部分:Token、ca.crt、namespace
token 是使用API Server私钥签名的JWT。用于访问API Server时,Server端认证
ca.crt 根证书。用于Client端验证API Server发送的证书
namespace 标识这个service-account-token的作用l域名空间
默认情况下,每个namespace都会有一个default SA,如果Pod在创建时没有指定ServiceAccount,
就会使用Pod所属的namespace的ServiceAccount
<!--默认挂载目录:/run/secrets./kubernetes,io/serviceaccount/-->
Authentication 认证(鉴权)
上面认证过程,只是确认通信的双方都确认了对方是可信的,可以相互通信。而鉴权是确定请求方有那些资源的权限。
API Server目前支持以下几种授权第路(通过API Server的启动参数”--authorization-mode"设置)
1、HTTP Token认证:通过一个Token来识别合法用户。
HTTP Token的认证是用一个很长的特殊编码方式的并且难以被模仿的字符串来表达客户的一种方式。每一个Token对应一个用户名,存储在API Server能访问的文件中。当客户端发起API调用请求时,需要在HTTP Header里放入Token。
用户名:密码 用base64算法进行编码后的字符串放在HTTP Request中的Heather Authorization 域里发送给服务端,服务端收到后进行解码,获取用户名和密码。
3、最严格的HTTPS证书认证:基于CA根证书签名的客户端身份认证方式,但是同时也是操作起来最麻烦的一种方式(企业使用)
认证只是确认通信的双方都是可信的,可以相互通信。而授权是确定请求方有哪些资源的权限
API Server目前支持的几种授权策略
API Server目前支持如下几种授权策略(通过API Server的启动参数 --authorization-mode 设置)
- AlwaysDeny:表示拒绝所有请求。仅用于测试
- AlwaysAllow:表示允许所有请求。如果有集群不需要授权流程,则可以采用该策略
- Node:节点授权是一种特殊用途的授权模式,专门授权由 kubelet 发出的 API 请求
- Webhook:是一种 HTTP 回调模式,允许使用远程 REST 端点管理授权
- ABAC:基于属性的访问控制,表示使用用户配置的授权规则对用户请求进行匹配和控制
- RBAC:基于角色的访问控制,默认使用该规则
- AlwaysDeny:表示拒绝所有请求,一般用于测试。
- AlwaysAllow:允许接收所有的请求,相当于集群不需要授权流程(Kubernetes 默认的策略)。
- ABAC:基于属性的访问控制,表示使用用户配置的授权规则对用户请求进行匹配和控制。
- Webhook:通过调用外部REST服务对用户进行授权。
- Node:是一种专用模式,用于对 kubelet 发出的请求进行访问控制。
- RBAC:基于角色的访问控制( kubeadm 安装方式下的默认选项)。
cat /etc/kubernetes/manifests/kube-apiserver.yaml | grep -i rbac
RBAC
k8s 通过Role-based access control (RBAC) 管理权限,基于角色(Role)的访问控制(类似于AWS role)
(RBAC)是一种基于组织中用户的角色来调节控制对 计算机或网络资源的访问的方法
在早期的K8s版本,RBAC还未出现的时候,整个K8s的安全是较为薄弱的,有了RBAC后,我们可以对K8s集群的访问人员作非常明细化的控制,控制他们能访问什么资源,以只读还是可以读写的形式来访问,目前RBAC是K8s默认的安全授权标准
RBAC 权限机制使用 rbac.authorization.k8s.io API 组来驱动鉴权决定, 允许你通过 Kubernetes API 动态配置策略,可以接入第三方
2、整个RBAC完全由几个API对象完成,同其他API对象一样,可以用kubectl或API进行操作
资源 架构
• RoleBinding:将角色绑定到主体(即subject)
• ClusterRoleBinding:将 集群角色绑定到主体
Role、ClusterRole、RoleBinding 和 ClusterRoleBinding
|--- Role --- RoleBinding ServiceAccount ---| # 只在指定namespace中生效|--- ClusterRole --- ClusterRoleBinding | # 不受namespace限制,在整个K8s集群中生效# 真正限制的是作用域(命名空间)的是bingding连接
ClusterRole:和Role的区别,Role是只作用于命名空间内,作用于整个集群
将ClusterRole或者Role绑定到User、Group、ServiceAccount。
ServiceAccount RoleBinding Role 资源都可以指定命名空间,但是作用域是看RoleBinding的metadata中的命名空间
ClusterRoleBinding / ClusterRole 是不指定命名空间的
此时有一个场景,有很多的用户,每个都访问不同的命名空间,但是他们要求的权限是一样的
使用ClusterRole(权限集合,模板) 可以绑定在不同命名空间上,通过RoleBinding来指定每个用户的作用域
这种操作允许集群管理员在整个集群内定义一些通用的ClusterRole,然后在不同的namespace中使用RoleBinding来引用*
也可以将主体设置为Group 来实现,但是只能是同一个命名空间
k8s内置的集群角色
cluster-admin 超级管理员,对集群所有权限(在部署dashboard的时候,先创建sa,然后将sa绑定到角色cluster-admin,最后获取到token,这就使用了内置的cluster-admin )
edit 允许对命名空间大多数对象读写操作,不允许查看或者修改角色、角色绑定。
view 允许对命名空间大多数对象只读权限,不允许查看角色、角色绑定和Secret
[root@master default]# kubectl get clusterroleNAME CREATED ATadmin 2021-05-20T07:04:01Zedit 2021-05-20T07:04:01Zcluster-admin 2021-05-20T07:04:01Zview 2021-05-20T07:04:01Z
带system: 开头的,不要去动,因为这是集群运行所需的clusterrole
role 和 clusterrole 和binding之间的关系
role 和 clusterrole 通过创建对应的 rolebinding 和 clusterrolebinding
在 role 和 clusterrole 创建中,role指定命令空间(导致role也被限制了命名空间),clusterrole不需要命名空间
rolebinding 和 clusterrolebinding 真正决定了role和clusterrole 的作用域
clusterrole 结合 rolebinding ,哪就只能在该命名空间内使用
role 和 clusterrole 与 rolebinding 和 clusterrolebinding可以混搭
如果有多个命名空间,但是使用同一个权限,如果使用role要创建多个相同的role,指定不同的命名空间,这就要使用 clusterrole 来实现,因为不用指定命名空间,作用域是整个集群,可以给不同的命名空间,通过rolebinding进行作用域的限制
管理员权限
[root@master k8s]# ll ~/.kube/config-rw-------. 1 root root 5638 Feb 2 07:13 /root/.kube/config[root@master k8s]# cat !$cat ~/.kube/configapiVersion: v1clusters:- cluster:certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUMvakNDQWVhZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcm...
实操
命令行
# 查看kube-system namespace下的所有rolekubectl get role -n kube-system# 查看某个role定义的资源权限kubectl get role <role-name> -n kube-system -o yaml# 查看kube-system namespace下所有的rolebindingkubectl get rolebinding -n kube-system# 查看kube-system namespace下的某个rolebinding详细信息(绑定的Role和subject)kubectl get rolebinding <rolebind-name> -n kube-system -o yaml# 查看集群所有的clusterrolekubectl get clusterrole# 查看某个clusterrole定义的资源权限详细信息kubectl get clusterrole <clusterrole-name> -o yaml# 查看所有的clusterrolebindingkubectl get clusterrolebinding
# 在某一特定名字空间内授予Role或者ClusterRole。示例如下:a) 在名为”acme”的名字空间中将admin ClusterRole授予用户”bob”:kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=acmeb) 在名为”acme”的名字空间中将view ClusterRole授予服务账户”myapp”:kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=acmekubectl create clusterrolebinding# 在整个集群中授予ClusterRole,包括所有名字空间。示例如下:a) 在整个集群范围内将cluster-admin ClusterRole授予用户”root”:kubectl create clusterrolebinding root-cluster-admin-binding --clusterrole=cluster-admin --user=rootb) 在整个集群范围内将system:node ClusterRole授予用户”kubelet”:kubectl create clusterrolebinding kubelet-node-binding --clusterrole=system:node --user=kubeletc) 在整个集群范围内将view ClusterRole授予名字空间”acme”内的服务账户”myapp”:kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp# 创建 sakubectl create serviceaccount --namespace kube-system tiller
示例
# 创建 clusterrole# 查看帮助kubectl create clusterrole -h# 创建kubectl create clusterrole deployment-clusterrole --verb=create --resource=deployments,statefulsets,daemonsets# 检查candidate@node01:~$ kubectl describe clusterrole deployment-clusterroleName: deployment-clusterroleLabels: <none>Annotations: <none>PolicyRule:Resources Non-Resource URLs Resource Names Verbs--------- ----------------- -------------- -----daemonsets.apps [] [] [create]deployments.apps [] [] [create]statefulsets.apps [] [] [create]
# 创建sa# 查看帮助candidate@node01:~$ kubectl create sa -h# 创建kubectl create sa -n app-team1 cicd-token# 检查candidate@node01:~$ kubectl get sa -n app-team1NAME SECRETS AGEcicd-token 0 5m2sdefault 0 116d
# 创建 rolebinding# 查看帮助candidate@node01:~$ kubectl create rolebinding -h# 创建candidate@node01:~$ kubectl create rolebinding -n app-team1 test --clusterrole=deployment-clusterrole --serviceaccount=app-team1:cicd-tokenrolebinding.rbac.authorization.k8s.io/test created# 检查candidate@node01:~$ kubectl describe -n app-team1 rolebindings.rbac.authorization.k8s.ioName: testLabels: <none>Annotations: <none>Role:Kind: ClusterRoleName: deployment-clusterroleSubjects:Kind Name Namespace---- ---- ---------ServiceAccount cicd-token app-team1# 检查不了rolebindings 所在区域
测试
kubectl --as=system:serviceaccount:app-team1:cicd-token get deployments -n app-team1
yaml 解析
资源和动作查询
# 查询资源kubectl api-resources# 查询资源和动作kubectl api-resources -o wide
Role / ClusterRole
Role
定义到名称为 “study” 的命名空间,可以用来授予对该命名空间中的 Pods 的读取权限
apiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata:name: pod-readernamespace: study #指定所属命名空间rules:- apiGroups: [""] # "" 指定核心 API 组# "*" represents all API groups 空字符串""表明使用core API group# (如pods属于core api group,deployments属于apps api group)# 通过 kubectl api-resources | grep deployment 查看api 组# 例如 aaps/v1 写为["","apps"]resources: ["pods"] # 资源,'*' represents allresourcesresourceNames: ["nginx"] # 指定某资源下的具体某个资源,不写即为全部verbs: ["get", "watch", "list"] # 对资源的操作动作,'*' represents all verbs# 包括操作(get、create、list、delete、update、edit、watch、exec)资源# 指定多组权限# - apiGroups: [""]# resources: [""]# verbs: [""]
Core Groups (核心组),也可以称为Legacy Groups,该组的REST路径位于/api/v1, 作为 Kubernetes 最核心的 API,
它是没有“组”的概念,例如 ”v1“,在资源对象的定义中表示为”apiVersion: v1“
具有分组信息的API,以/apis/$GROUP_NAME/$VERSIONURL路径进行标识,在资源对象的定义中表示为
apiVersion: $GROUP_NAME/$VERSION(例如,apiVersion: batch/v1)。已支持的 API 组详细列表请参阅
ClusterRole
大体上跟role差不多,主要是没有命名空间,其作用域是整个集群
apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata:# "namespace" 被忽略,因为 ClusterRoles 不受名字空间限制name: secret-readerlabelssnj:"test" #用于其他role聚合rules:- apiGroups: [""] # "" 标明 core API 组,默认留空即可# 在 HTTP 层面,用来访问 Secret 资源的名称为 "secrets"resources: ["secrets"]verbs: ["get", "watch", "list"]
聚合ClusterRole
就是将rbac.example.com/aggregate-to-monitoring标签的ClusterRole所有权限添加到该ClusterRole中
apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata:name: monitoringaggregationRule:clusterRoleSelectors:- matchLabels:snj:"test" # 此时 monitoring就有了上面secret-reader的所有的权限rules: [] # 控制面自动填充这里的规则
RoleBinding / ClusterRoleBinding
角色绑定用来把一个角色绑定到一个目标对象上,绑定目标可以是 User、Group 或者 ServiceAccount
RoleBinding
apiVersion: rbac.authorization.k8s.io/v1# 此角色绑定允许 "jane" 读取 "default" 名字空间中的 Pod# 你需要在该命名空间中有一个名为 “pod-reader” 的 Rolekind: RoleBindingmetadata:name: read-podsnamespace: default #一般和role是一个命名空间,这里的这个参数也实现了role的作用域roleRef:# "roleRef" 指定与某 Role 或 ClusterRole 的绑定关系kind: Role # 此字段必须是 Role 或 ClusterRolename: pod-reader # 此字段必须与你要绑定的 Role 或 ClusterRole 的名称匹配 subjects:# 你可以指定不止一个“subject(主体)”- kind: ServiceAccountname: test # "name" 是区分大小写的
ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1# 此集群角色绑定允许 “manager” 组中的任何人访问任何名字空间中的 Secret 资源kind: ClusterRoleBindingmetadata:name: read-secrets-global# 作用域是整个Cluster,不是单个namespace所以不写namespace# 如果资源是某个 namespace 下的,也就resourceNames指定了,那么就需要设置 namespace# 因为不同命名空间中可能会有重名roleRef:kind: ClusterRolename: secret-readersubjects:- kind: Groupname: manager # 'name' 是区分大小写的
ServiceAccout
apiVersion: v1kind: ServiceAccountmetadata:name: admin-usernamespace: kube-system
命名空间问题
sa 和 rolebinding / role 不在同一个命名空间
yaml 实操
# 名称空间角色apiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata:name: snj-rolenamespace: study # 所属的名称空间rules: # 当前角色的规则- apiGroups: [""] # "" 标明 core API 组,默认留空即可。resources: ["pods"] # 指定能操作的资源 ,通过 kubectl api-resources 查看即可。# resourceNames: [""] # 指定只能操作某个名字的资源verbs: ["get", "watch", "list"] # 操作动作,通过 kubectl api-resources -o wide 查看即可。---# 集群角色apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata:name: snj-clusterrolerules:- apiGroups: [""] # "" 标明 core API 组,默认留空即可。resources: ["namespaces"]verbs: ["get", "watch", "list"]---# ServiceAccountapiVersion: v1kind: ServiceAccountmetadata:name: snj # ServiceAccount 的名称namespace: default---# 账号和角色绑定apiVersion: rbac.authorization.k8s.io/v1kind: RoleBindingmetadata:name: snj-rolebindingnamespace: studysubjects:- kind: ServiceAccountname: snj # "name" 是区分大小写的roleRef:kind: Rolename: snj-roleapiGroup: rbac.authorization.k8s.io---# 账号和集群角色绑定apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata:name: snj-clusterrolebindingsubjects:- kind: ServiceAccountname: snj # "name" 是区分大小写的namespace: default # 如果资源是某个 namespace 下的,那么就需要设置 namespaceroleRef:kind: ClusterRolename: snj-clusterroleapiGroup: rbac.authorization.k8s.io
---# pod 使用 saapiVersion: v1kind: Podmetadata:name: web-seccompnamespace: studyspec:serviceAcccountName: snjcontainers:- image: busybox:1.30name: hellocommand:- sleep- 24h
[root@master k8s]# kubectl apply -f role-test.yamlrole.rbac.authorization.k8s.io/snj-role createdclusterrole.rbac.authorization.k8s.io/snj-clusterrole createdserviceaccount/snj createdrolebinding.rbac.authorization.k8s.io/snj-rolebinding createdclusterrolebinding.rbac.authorization.k8s.io/xudaxian-clusterrolebinding created[root@master k8s]# kubectl get role -n studyNAME CREATED ATsnj-role 2023-02-21T08:24:41Z[root@master k8s]# kubectl get rolebindings.rbac.authorization.k8s.io -n studyNAME ROLE AGEsnj-rolebinding Role/snj-role 14s[root@master k8s]# kubectl get saNAME SECRETS AGEdefault 0 18dsnj 0 70s[root@master k8s]# kubectl get clusterrole | grep snjsnj-clusterrole 2023-02-21T08:24:41Z[root@master k8s]# kubectl get clusterrolebindings.rbac.authorization.k8s.io | grep snjsnj-clusterrolebinding ClusterRole/snj-clusterrole 72s
用途
(1)第一类是保证在K8s上运行的pod服务具有相应的集群权限,如gitlab的CI/CD,它需要能访问除自身以外其他pod,比如gitlab-runner的pod的权限,再比如gitlab-runner的pod需要拥有创建新的临时pod的权限,用以来构建CI/CD自动化流水线
(2)第二类是创建能访问K8s相应资源、拥有对应权限的kube-config配置给到使用K8s的人员,来作为连接K8s的授权凭证
helm是一个快捷安装K8s各类资源的管理工具(类似于linux yaml),通过之前给大家讲解的,一个较为完整的服务可能会存在deployment,service,configmap,secret,ingress等资源来组合使用,大家在用的过程中可能会觉得配置使用较为麻烦,这时候helm就出现了,它把这些资源都打包封装成它自己能识别的内容,我们在安装一个服务的时候,就只需要作下简单的配置,一条命令即可完成上述众多资源的配置安装,titller相当于helm的服务端,它是需要有权限在K8s中创建各类资源的,在初始安装使用时,如果没有配置RBAC权限,我们会看到如下报错:
root@node1:~# helm install stable/mysql
更改使用权限
这时,我们可以来快速解决这个问题,创建sa关联K8s自带的最高权限的ClusterRole(生产中建议不要这样做,权限太高有安全隐患,这个就和linux的root管理帐号一样,一般都是建议通过sudo来控制帐号权限)
kubectl create serviceaccount --namespace kube-system tillerkubectl create clusterrolebinding tiller-cluster-rule --clusterrole=cluster-admin --serviceaccount=kube-system:tillerkubectl patch deploy --namespace kube-system tiller-deploy -p '{"spec":{"template":{"spec":{"serviceAccount":"tiller"}}}}'
提供查看日志权限
apiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata:namespace: defaultname: pod-and-pod-logs-readerrules:- apiGroups: [""]resources: ["pods", "pods/log"] # log 是 pods 的子资源 用斜线(/)来分隔资源和子资源verbs: ["get", "list"]
配置一个能访问集群的特定用户( master主机内 )
创建证书(master)
# 注意:只需要在一台机器下载即可wget https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl-certinfo_1.5.0_linux_amd64wget https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl_1.5.0_linux_amd64wget https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssljson_1.5.0_linux_amd64chmod +x cfssl*for name in `ls cfssl*`; do mv $name ${name%_1.5.0_linux_amd64}; donemv cfssl* /usr/bin
sudo tee /root/k8s/cert/devuser.json <<-'EOF'{"CN": "devuser","hosts": [],"key": {"algo": "rsa","size": 2048},"names": [{"C": "CN","ST": "Shenzhen","L": "Shenzhen","O": "k8s","OU": "system"}]}EOF
cfssl gencert -ca=/etc/kubernetes/pki/ca.crt -ca-key=/etc/kubernetes/pki/ca.key -profile=kubernetes /root/k8s/cert/devuser.json | cfssljson -bare devuser[root@master pki]# ls | grep userdevuser.csrdevuser-key.pemdevuser.pem
所属命名空间和权限
[root@node-01 rbac]# vim role-pods-reader.yamlapiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata:name: devuser-rolenamespace: devrules:- apiGroups:- ""resources:- podsverbs:- get- list- watch
[root@master cert]# kubectl apply -f pods-reader.yamlrole.rbac.authorization.k8s.io/pods-reader created[root@master cert]# kubectl describe role -n dev pods-readerName: pods-readerLabels: <none>Annotations: <none>PolicyRule:Resources Non-Resource URLs Resource Names Verbs--------- ----------------- -------------- -----pods [] [] [get list watch]
[root@master cert]# cat devuser-pods-reader.yamlapiVersion: rbac.authorization.k8s.io/v1kind: RoleBindingmetadata:name: devuser-role-bindingnamespace: dev # 定义作用域roleRef:apiGroup: rbac.authorization.k8s.iokind: Rolename: devuser-rolesubjects:- apiGroup: rbac.authorization.k8s.iokind: Username: devusernamespace: dev # 可写可不写
[root@master cert]# kubectl apply -f devuser-pods-reader.yamlrolebinding.rbac.authorization.k8s.io/devuser-pods-reader created[root@master cert]# kubectl describe rolebindings.rbac.authorization.k8s.io -n devName: devuser-role-bindingLabels: <none>Annotations: <none>Role:Kind: RoleName: devuser-roleSubjects:Kind Name Namespace---- ---- ---------User devuser
给devuser最大权限,作用空间在dev下kubectl create ns dev
kubectl create ns devkubectl create rolebinding devuser-admin-binding --clusterrole=admin --user=devuser --namespace=dev
创建配置文件
kubectl config set-cluster --kubeconfig=/PATH/TO/SOMEFILE #集群配置kubectl config set-credentials NAME --kubeconfig=/PATH/TO/SOMEFILE #用户配置kubectl config set-context #context配置kubectl config use-context #切换context–embed-certs =true的作用是不在配置文件中显示证书信息。–kubeconfig =/root/jenkins.conf 用于创建新的配置文件,如果不加此选项,则内容会添加到家目录下.kube/config文件中,可以使用use-context来切换不同的用户管理k8s集群。可以不加context简单的理解就是用什么用户来管理哪个集群,即用户和集群的结合。
创建集群配置
--certificate-authority # 指定ca证书,pki下自带--embed-certs # 是否进行加密--server # 服务器信息--kubeconfig 根据信息创建 kubeconfig 配置文件,给访问机子使用export KUBE_APISERVER="https://192.168.100.53:6443"kubectl config set-cluster kubernetes \--certificate-authority=/etc/kubernetes/pki/ca.crt \--embed-certs=true \--server="https://192.168.100.53:6443" \--kubeconfig=/root/k8s/cert/devuser.kubeconfig# /etc/kubernetes/pki/ca.crt 集群ca证书,自带#/root/k8s/cert/devuser.kubeconfig 生成的kubeconfig文件名和路径
[root@master cert]# lsdevuser.json devuser.kubeconfig
[root@master cert]# cat devuser.kubeconfigapiVersion: v1clusters:- cluster: #设置的是这一部分certificate-authority-data: ...server: https://192.168.100.53:6443name: kubernetescontexts: nullcurrent-context: ""kind: Configpreferences: {}users: null
创建用户配置
kubectl config set-credentials devuser \--client-certificate=/root/k8s/cert/devuser.pem \--client-key=/root/k8s/cert/devuser-key.pem \--embed-certs=true \--kubeconfig=/root/k8s/cert/devuser.kubeconfig# User "devuser" set.# --client 使用上面创建证书时候pem文件# /root/k8s/cert/devuser.kubeconfig 要设置的kubeconfig文件
[root@master cert]# kubectl config view --kubeconfig=/root/k8s/cert/devuser.kubeconfigapiVersion: v1clusters:- cluster:certificate-authority-data: DATA+OMITTEDserver: https://192.168.100.53:6443name: kubernetescontexts:- context:cluster: kubernetesnamespace: devuser: devusername: kubernetescurrent-context: ""kind: Configpreferences: {}users: #设置的是这一部分- name: devuseruser:client-certificate-data: DATA+OMITTEDclient-key-data: DATA+OMITTED
创建上下文配置
#设置上下文参数kubectl config set-context devuser@kubernetes \--cluster=kubernetes \--user=devuser \--namespace=dev \--kubeconfig=/root/k8s/cert/devuser.kubeconfig# Context "kubernetes" created.
[root@master cert]# kubectl config view --kubeconfig=/root/k8s/cert/devuser.kubeconfigapiVersion: v1clusters:- cluster:certificate-authority-data: DATA+OMITTEDserver: https://192.168.100.53:6443name: kubernetescontexts: #设置的是这一部分- context:cluster: kubernetesnamespace: devuser: devusername: devuser@kubernetescurrent-context: ""kind: Configpreferences: {}users:- name: devuseruser:client-certificate-data: DATA+OMITTEDclient-key-data: DATA+OMITTED
切换上下文
[root@master cert]# kubectl config use-context devuser@kubernetes --kubeconfig=/root/k8s/cert/devuser.kubeconfigSwitched to context "devuser@kubernetes".
创建系统用户及k8s验证文件
useradd devuser #创建什么用户名都可以mkdir /home/devuser/.kubecp devuser.kubeconfig /home/devuser/.kube/configchown devuser.devuser -R /home/devuser/.kube/su - devuser
测试
# 访问测试[devuser@master ~]$ kubectl get podNo resources found in dev namespace.[devuser@master ~]$ kubectl get pod -n defaultError from server (Forbidden): pods is forbidden: User "devuser" cannot list resource "pods" in API group "" in the namespace "default"# 该用户默认就直接是dev namespace# 对于其他命名空间没有权限
在role只给了get list watch[devuser@master ~]$ kubectl get podNAME READY STATUS RESTARTS AGEnginx 1/1 Running 0 12m[devuser@master ~]$ kubectl delete pod nginxError from server (Forbidden): pods "nginx" is forbidden: User "devuser" cannot delete resource "pods" in API group "" in the namespace "dev"[devuser@master ~]$ kubectl get rolebindings.rbac.authorization.k8s.ioError from server (Forbidden): rolebindings.rbac.authorization.k8s.io is forbidden: User "devuser" cannot list resource "rolebindings" in API group "rbac.authorization.k8s.io" in the namespace "dev"[devuser@master ~]$ kubectl run pod nginx --image=nginx:1.17.1Error from server (Forbidden): pods is forbidden: User "devuser" cannot create resource "pods" in API group "" in the namespace "dev"
准入控制
- 通过了前面的认证和授权之后,还需要经过准入控制通过之后,API Server 才会处理这个请求。
- 准入控制是一个可配置的控制器列表,可以通过在 API Server 上通过命令行设置选择执行哪些注入控制器。
- 通过添加不同的插件,实现额外的准入控制规则
--enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,PersistentVolumeLabel,DefaultStorageClass,ResourceQuota,DefaultTolerationSeconds
只有当所有的注入控制器都检查通过之后,API Server 才会执行该请求,否则返回拒绝
kube-apiserver 容器内部可以使用kube-apiserver进行查看启动关闭
# 查看启动插件kubectl exec kube-apiserver-k8s-master-n kube-system --kube-apiserver -h | grep enable-admission-plugins--enable-admission-plugins strings admission plugins that should be enabled in addition to default enabled ones (NamespaceLifecycle, LimitRanger, ServiceAccount, TaintNodesByCondition, PodSecurity, Priority, DefaultTolerationSeconds, DefaultStorageClass, StorageObjectInUseProtection, PersistentVolumeClaimResize, RuntimeClass, CertificateApproval, CertificateSigning, ClusterTrustBundleAttest, CertificateSubjectRestriction, DefaultIngressClass, MutatingAdmissionWebhook, ValidatingAdmissionPolicy, ValidatingAdmissionWebhook, ResourceQuota)上面这些是默认启用的,用括号括起来. Comma-delimited list of admission plugins: AlwaysAdmit, AlwaysDeny, AlwaysPullImages, CertificateApproval, CertificateSigning, CertificateSubjectRestriction, ClusterTrustBundleAttest, DefaultIngressClass, DefaultStorageClass, DefaultTolerationSeconds, DenyServiceExternalIPs, EventRateLimit, ExtendedResourceToleration, ImagePolicyWebhook, LimitPodHardAntiAffinityTopology, LimitRanger, MutatingAdmissionWebhook, NamespaceAutoProvision, NamespaceExists, NamespaceLifecycle, NodeRestriction, OwnerReferencesPermissionEnforcement, PersistentVolumeClaimResize, PersistentVolumeLabel, PodNodeSelector, PodSecurity, PodTolerationRestriction, Priority, ResourceQuota, RuntimeClass, SecurityContextDeny, ServiceAccount, StorageObjectInUseProtection, TaintNodesByCondition, ValidatingAdmissionPolicy, ValidatingAdmissionWebhook. The order of plugins in this flag does not matter.
启用一个准入控制器:kube-apiserver --enable-admission-plugins=NamespaceLifecycle,LimitRanger...关闭一个准入控制器:kube-apiserver --disable-admission-plugins=PodNodeSelector,AlwaysDeny ..
当前可配置的 Admission Control
NamespaceLifecycle: 防止在不存在的namespace上创建对像,防止删除系统预置namespace,别除namespace时,连带删除它的所有资源对象。LimitRanger: 确保情求的资源不会超过资源所在Namespace的LimitRange的限制:ServiceAccount: 实现了自动化添加ServiceAccount。ResourceQuota: 确保请求的资源不会超过资源的ResourceQuota限制。AlwaysAdmit:允许所有请求。AlwaysDeny:禁止所有请求,一般用于测试。AlwaysPullImages:在启动容器之前总去下载镜像。DenyExecOnPrivileged:它会拦截所有想在 Privileged Container 上执行命令的请求。ImagePolicyWebhook:这个插件将允许后端的一个 Webhook 程序来完成 admission control 的功能。Service Account:实现 ServiceAccount 实现了自动化。SecurityContextDeny:这个插件将使用 SecurityContext 的 Pod 中的定义全部失效。ResourceQuota:用于资源配额管理目的,观察所有请求,确保在 namespace 上的配额不会超标。LimitRanger:用于资源限制管理,作用于 namespace 上,确保对 Pod 进行资源限制。InitialResources:为未设置资源请求与限制的 Pod,根据其镜像的历史资源的使用情况进行设置。NamespaceLifecycle:如果尝试在一个不存在的 namespace 中创建资源对象,则该创建请求将被拒绝。当删除一个 namespace 时,系统将会删除该 namespace 中所有对象。DefaultStorageClass:为了实现共享存储的动态供应,为未指定 StorageClass 或 PV 的 PVC 尝试匹配默认 StorageClass,尽可能减少用户在申请 PVC 时所需了解的后端存储细节。DefaultTolerationSeconds:这个插件为那些没有设置 forgiveness tolerations 并具有 notready:NoExecute 和 unreachable:NoExecute 两种taints的Pod设置默认的容忍时间,为 5min 。PodSecurityPolicy:这个插件用于在创建或修改 Pod 时决定是否根据 Pod 的 security context 和可用的 PodSecurityPolicy 对 Pod 的安全策略进行控制