佛山市网站建设企业,科技公司建设网站,天猫商家入驻需要什么条件,登陆工伤保险网站 提示未授权 怎么做开头语
写在前面#xff1a;如有问题#xff0c;以你为准#xff0c;
目前24年应届生#xff0c;各位大佬轻喷#xff0c;部分资料与图片来自网络
内容较长#xff0c;页面右上角目录方便跳转
Kubernetes 安全架构 K8S安全控制框架主要由下面3个阶段进行控制#xf… 开头语
写在前面如有问题以你为准
目前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
使用kubeconfig
Kubernetes管理的Pod对容器的访问Pod(dashborad也是以Pod形式运行)
使用ServiceAccount
安全性说明
Controller Manager、Scheduler与API Server在同一台机器所以直接使用API Server的非安全端口
访问--insecure-.bind-address-127.0.0.1
kubectl、kubelet、kube-proxy访间API Server就都需要证书进行HTTPS双向认证
证书颁发
手动签发通过k8s集群的限cā进行签发HTTPS证书
自动签发kubelet首次访问API Server时使用token做认证通过后Controller Manager会为kubelet生成一个证书以后的访问都是用证书做认证了 kubeconfig
kubeconfig文件包含集群参数(CAi证书、API Serveri地址)客户端参数上面生成的证书和私钥集群context信息集群名称、用户名。
Kubenetes组件通过启动时指定不同的kubeconfig文件可以切换到不同的集群
[rootmaster 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 --assystem: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。
2、HTTP Base认证通过用户名密码的方式认证
用户名:密码 用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 动态配置策略可以接入第三方
优势
1、对集群中的资源和非资源均拥有完整的覆盖
2、整个RBAC完全由几个API对象完成同其他API对象一样可以用kubectl或API进行操作
3、可以在运行时进行操作无需重启API Server
资源 架构
角色 • Role授权特定命名空间的访问权限 • ClusterRole授权 所有命名空间 的访问权限
角色绑定这个才是决定作用域 即命名空间 • RoleBinding将角色绑定到主体即subject • ClusterRoleBinding将 集群角色绑定到主体
主体subject • User用户 • Group用户组 • ServiceAccount服务账号 Role、ClusterRole、RoleBinding 和 ClusterRoleBinding |--- Role --- RoleBinding ServiceAccount ---| # 只在指定namespace中生效|--- ClusterRole --- ClusterRoleBinding | # 不受namespace限制在整个K8s集群中生效# 真正限制的是作用域命名空间的是bingding连接
ClusterRole:和Role的区别Role是只作用于命名空间内作用于整个集群
RoleBinding作用于命令空间内
将ClusterRole或者Role绑定到User、Group、ServiceAccount。
ClusterRoleBinding作用于整个集群。 ServiceAccount RoleBinding Role 资源都可以指定命名空间但是作用域是看RoleBinding的metadata中的命名空间
ClusterRoleBinding / ClusterRole 是不指定命名空间的 此时有一个场景有很多的用户每个都访问不同的命名空间但是他们要求的权限是一样的
使用ClusterRole权限集合模板 可以绑定在不同命名空间上通过RoleBinding来指定每个用户的作用域
这种操作允许集群管理员在整个集群内定义一些通用的ClusterRole,然后在不同的namespace中使用RoleBinding来引用* 也可以将主体设置为Group 来实现但是只能是同一个命名空间 k8s内置的集群角色
cluster-admin 超级管理员对集群所有权限在部署dashboard的时候先创建sa然后将sa绑定到角色cluster-admin最后获取到token这就使用了内置的cluster-admin
admin 主要用于授权命名空间所有读写权限
edit 允许对命名空间大多数对象读写操作不允许查看或者修改角色、角色绑定。
view 允许对命名空间大多数对象只读权限不允许查看角色、角色绑定和Secret
[rootmaster 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进行作用域的限制 管理员权限
管理员权限配置所在位置如下图
[rootmaster k8s]# ll ~/.kube/config-rw-------. 1 root root 5638 Feb 2 07:13 /root/.kube/config[rootmaster 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和subjectkubectl 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 --clusterroleadmin --userbob --namespaceacmeb) 在名为”acme”的名字空间中将view ClusterRole授予服务账户”myapp”kubectl create rolebinding myapp-view-binding --clusterroleview --serviceaccountacme:myapp --namespaceacmekubectl create clusterrolebinding# 在整个集群中授予ClusterRole包括所有名字空间。示例如下a) 在整个集群范围内将cluster-admin ClusterRole授予用户”root”kubectl create clusterrolebinding root-cluster-admin-binding --clusterrolecluster-admin --userrootb) 在整个集群范围内将system:node ClusterRole授予用户”kubelet”kubectl create clusterrolebinding kubelet-node-binding --clusterrolesystem:node --userkubeletc) 在整个集群范围内将view ClusterRole授予名字空间”acme”内的服务账户”myapp”kubectl create clusterrolebinding myapp-view-binding --clusterroleview --serviceaccountacme:myapp# 创建 sakubectl create serviceaccount --namespace kube-system tiller 示例
# 创建 clusterrole# 查看帮助kubectl create clusterrole -h# 创建kubectl create clusterrole deployment-clusterrole --verbcreate --resourcedeployments,statefulsets,daemonsets# 检查candidatenode01:~$ kubectl describe clusterrole deployment-clusterroleName: deployment-clusterroleLabels: noneAnnotations: nonePolicyRule:Resources Non-Resource URLs Resource Names Verbs--------- ----------------- -------------- -----daemonsets.apps [] [] [create]deployments.apps [] [] [create]statefulsets.apps [] [] [create]
# 创建sa# 查看帮助candidatenode01:~$ kubectl create sa -h# 创建kubectl create sa -n app-team1 cicd-token# 检查candidatenode01:~$ kubectl get sa -n app-team1NAME SECRETS AGEcicd-token 0 5m2sdefault 0 116d
# 创建 rolebinding# 查看帮助candidatenode01:~$ kubectl create rolebinding -h# 创建candidatenode01:~$ kubectl create rolebinding -n app-team1 test --clusterroledeployment-clusterrole --serviceaccountapp-team1:cicd-tokenrolebinding.rbac.authorization.k8s.io/test created# 检查candidatenode01:~$ kubectl describe -n app-team1 rolebindings.rbac.authorization.k8s.ioName: testLabels: noneAnnotations: noneRole:Kind: ClusterRoleName: deployment-clusterroleSubjects:Kind Name Namespace---- ---- ---------ServiceAccount cicd-token app-team1# 检查不了rolebindings 所在区域
测试
kubectl --assystem: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 groupdeployments属于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 组详细列表请参阅 Kubernetes API reference。 ClusterRole
大体上跟role差不多主要是没有命名空间其作用域是整个集群
apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata:# namespace 被忽略因为 ClusterRoles 不受名字空间限制name: secret-readerlabelssnj:test #用于其他role聚合rules:- apiGroups: [] # 标明 core API 组默认留空即可# 在 HTTP 层面用来访问 Secret 资源的名称为 secretsresources: [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
命名空间问题
role和rolebinding一般是一个命名空间
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 [rootmaster 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[rootmaster k8s]# kubectl get role -n studyNAME CREATED ATsnj-role 2023-02-21T08:24:41Z[rootmaster k8s]# kubectl get rolebindings.rbac.authorization.k8s.io -n studyNAME ROLE AGEsnj-rolebinding Role/snj-role 14s[rootmaster k8s]# kubectl get saNAME SECRETS AGEdefault 0 18dsnj 0 70s[rootmaster k8s]# kubectl get clusterrole | grep snjsnj-clusterrole 2023-02-21T08:24:41Z[rootmaster 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通过之前给大家讲解的一个较为完整的服务可能会存在deploymentserviceconfigmapsecretingress等资源来组合使用大家在用的过程中可能会觉得配置使用较为麻烦这时候helm就出现了它把这些资源都打包封装成它自己能识别的内容我们在安装一个服务的时候就只需要作下简单的配置一条命令即可完成上述众多资源的配置安装titller相当于helm的服务端它是需要有权限在K8s中创建各类资源的在初始安装使用时如果没有配置RBAC权限我们会看到如下报错 rootnode1:~# helm install stable/mysql Error: no available release name found 更改使用权限
这时我们可以来快速解决这个问题创建sa关联K8s自带的最高权限的ClusterRole生产中建议不要这样做权限太高有安全隐患这个就和linux的root管理帐号一样一般都是建议通过sudo来控制帐号权限
kubectl create serviceaccount --namespace kube-system tillerkubectl create clusterrolebinding tiller-cluster-rule --clusterrolecluster-admin --serviceaccountkube-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
配置 cfssl
# 注意只需要在一台机器下载即可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
创建申请证书的json
O组织信息CN用户名 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
创建证书和公私钥
CN: 用户名
O: 用户组
cfssl gencert -ca/etc/kubernetes/pki/ca.crt -ca-key/etc/kubernetes/pki/ca.key -profilekubernetes /root/k8s/cert/devuser.json | cfssljson -bare devuser[rootmaster pki]# ls | grep userdevuser.csrdevuser-key.pemdevuser.pem 所属命名空间和权限
示例1
[rootnode-01 rbac]# vim role-pods-reader.yamlapiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata:name: devuser-rolenamespace: devrules:- apiGroups:- resources:- podsverbs:- get- list- watch
[rootmaster cert]# kubectl apply -f pods-reader.yamlrole.rbac.authorization.k8s.io/pods-reader created[rootmaster cert]# kubectl describe role -n dev pods-readerName: pods-readerLabels: noneAnnotations: nonePolicyRule:Resources Non-Resource URLs Resource Names Verbs--------- ----------------- -------------- -----pods [] [] [get list watch]
[rootmaster 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 # 可写可不写
[rootmaster cert]# kubectl apply -f devuser-pods-reader.yamlrolebinding.rbac.authorization.k8s.io/devuser-pods-reader created[rootmaster cert]# kubectl describe rolebindings.rbac.authorization.k8s.io -n devName: devuser-role-bindingLabels: noneAnnotations: noneRole:Kind: RoleName: devuser-roleSubjects:Kind Name Namespace---- ---- ---------User devuser
示例2
给devuser最大权限作用空间在dev下kubectl create ns dev
kubectl create ns devkubectl create rolebinding devuser-admin-binding --clusterroleadmin --userdevuser --namespacedev
创建配置文件
创建配置文件主要有以下几个步骤
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_APISERVERhttps://192.168.100.53:6443kubectl config set-cluster kubernetes \--certificate-authority/etc/kubernetes/pki/ca.crt \--embed-certstrue \--serverhttps://192.168.100.53:6443 \--kubeconfig/root/k8s/cert/devuser.kubeconfig# /etc/kubernetes/pki/ca.crt 集群ca证书自带#/root/k8s/cert/devuser.kubeconfig 生成的kubeconfig文件名和路径
[rootmaster cert]# lsdevuser.json devuser.kubeconfig [rootmaster 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-certstrue \--kubeconfig/root/k8s/cert/devuser.kubeconfig# User devuser set.# --client 使用上面创建证书时候pem文件# /root/k8s/cert/devuser.kubeconfig 要设置的kubeconfig文件
[rootmaster cert]# kubectl config view --kubeconfig/root/k8s/cert/devuser.kubeconfigapiVersion: v1clusters:- cluster:certificate-authority-data: DATAOMITTEDserver: https://192.168.100.53:6443name: kubernetescontexts:- context:cluster: kubernetesnamespace: devuser: devusername: kubernetescurrent-context: kind: Configpreferences: {}users: #设置的是这一部分- name: devuseruser:client-certificate-data: DATAOMITTEDclient-key-data: DATAOMITTED
创建上下文配置
#设置上下文参数kubectl config set-context devuserkubernetes \--clusterkubernetes \--userdevuser \--namespacedev \--kubeconfig/root/k8s/cert/devuser.kubeconfig# Context kubernetes created. [rootmaster cert]# kubectl config view --kubeconfig/root/k8s/cert/devuser.kubeconfigapiVersion: v1clusters:- cluster:certificate-authority-data: DATAOMITTEDserver: https://192.168.100.53:6443name: kubernetescontexts: #设置的是这一部分- context:cluster: kubernetesnamespace: devuser: devusername: devuserkubernetescurrent-context: kind: Configpreferences: {}users:- name: devuseruser:client-certificate-data: DATAOMITTEDclient-key-data: DATAOMITTED
切换上下文
[rootmaster cert]# kubectl config use-context devuserkubernetes --kubeconfig/root/k8s/cert/devuser.kubeconfigSwitched to context devuserkubernetes.
创建系统用户及k8s验证文件
useradd devuser #创建什么用户名都可以mkdir /home/devuser/.kubecp devuser.kubeconfig /home/devuser/.kube/configchown devuser.devuser -R /home/devuser/.kube/su - devuser
测试 # 访问测试[devusermaster ~]$ kubectl get podNo resources found in dev namespace.[devusermaster ~]$ 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[devusermaster ~]$ kubectl get podNAME READY STATUS RESTARTS AGEnginx 1/1 Running 0 12m[devusermaster ~]$ kubectl delete pod nginxError from server (Forbidden): pods nginx is forbidden: User devuser cannot delete resource pods in API group in the namespace dev[devusermaster ~]$ 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[devusermaster ~]$ kubectl run pod nginx --imagenginx: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-pluginsNamespaceLifecycle,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-pluginsNamespaceLifecycle,LimitRanger...关闭一个准入控制器kube-apiserver --disable-admission-pluginsPodNodeSelector,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 的安全策略进行控制
kubernetes 证书体系 在 Kubernetes 中私钥就是证书的 key 公钥就是证书当然也会存在 CA 机构的
