成都php网站开发,网站备案号代码,网站设计的公司设计,个人网站经营 合法么K8S安全实战篇之RBAC认证授权-v1 k8s安全管理#xff1a;认证、授权、准入控制概述认证k8s客户端访问apiserver的几种认证方式客户端认证#xff1a;BearertokenServiceaccountkubeconfig文件 授权Kubernetes的授权是基于插件形成的#xff0c;其常用的授权插件有以下几种认证、授权、准入控制概述认证k8s客户端访问apiserver的几种认证方式客户端认证BearertokenServiceaccountkubeconfig文件 授权Kubernetes的授权是基于插件形成的其常用的授权插件有以下几种什么是RBAC基于角色的授权Role、RoleBinding、ClusterRole和ClusterRoleBinding的关系用户基于rolebinding绑定到clusterrolerolebinding绑定clusterrole的优点用户基于clusterrolebinding绑定到clusterrole 准入控制 Useraccount和ServiceAccount介绍ServiceAccount使用案例介绍创建sa并绑定到pod创建sa创建pod对sa做授权再次请求 k8s安全管理认证、授权、准入控制概述
认证
认证基本介绍kubernetes主要通过APIserver对外提供服务那么就需要对访问apiserver的用户做认证如果任何人都能访问apiserver那么就可以随意在k8s集群部署资源这是非常危险的也容易被黑客攻击渗透所以需要我们对访问k8s系统的apiserver的用户进行认证确保是合法的符合要求的用户。授权基本介绍认证通过后仅代表它是一个被apiserver信任的用户能访问apiserver但是用户是否拥有删除资源的权限 需要进行授权操作常见的授权方式有rbac授权。准入控制基本介绍当用户经过认证和授权之后最后一步就是准入控制了k8s提供了多种准入控制机制它有点类似插件为apiserver提供了很好的可扩展性。请求apiserver时通过认证、鉴权后、持久化(“api对象保存到etcd)前会经过准入控制器”让它可以做变更和验证 为什么需要准入控制器如果我们创建pod时定义了资源上下限但不满足LimitRange规则中定义的资源上下限此时LimitRanger就会拒绝我们创建此pod 假如我们定义了一个名称空间叫做test-aa这个名称空间做下资源限制限制最多可以使用10vCPU、10Gi内存在这个名称空间test-aa下创建的所有pod定义limit的时候所有pod的limit值不能超过test-aa这个名称空间设置的limit上线。 k8s客户端访问apiserver的几种认证方式
客户端认证 客户端认证也称为双向TLS认证 kubectl在访问apiserver的时候apiserver也要认证kubectl是否是合法的他们都会通过ca根证书来进行验证如下图 Bearertoken Bearertoken的方式可以理解为apiserver将一个密码通过了非对称加密的方式告诉了kubectl然后通过该密码进行相互访问如下图 Kubectl访问k8s集群要找一个kubeconfig文件基于kubeconfig文件里的用户访问apiserver Serviceaccount 上面客户端证书认证和Bearertoken的两种认证方式都是外部访问apiserver的时候使用的方式那么我们这次说的Serviceaccount是内部访问pod和apiserver交互时候采用的一种方式。Serviceaccount包括了namespace、token、ca且通过目录挂载的方式给予pod当pod运行起来的时候就会读取到这些信息从而使用该方式和apiserver进行通信。如下图 kubeconfig文件 官方地址 https://kubernetes.io/zh-cn/docs/concepts/configuration/organize-cluster-access-kubeconfig/ 在K8S集群当中当我们使用kubectl操作k8s资源时候需要确定我们用哪个用户访问哪个k8s集群kubectl操作k8s集群资源会去/root/.kube目录下找config文件可以通过kubectl config查看config文件配置如下 kubectl config view
apiVersion: v1
clusters:
- cluster:certificate-authority-data: DATAOMITTEDserver: https://192.168.40.180:6443 #apiserver的地址name: kubernetes #集群的名字
contexts:
- context:cluster: kubernetes user: kubernetes-admin name: kubernetes-adminkubernetes #上下文的名字
current-context: kubernetes-adminkubernetes #当前上下文的名字
kind: Config
preferences: {}
users:
- name: kubernetes-adminuser:client-certificate-data: REDACTEDclient-key-data: REDACTED在上面的配置文件当中定义了集群、上下文以及用户。其中Config也是K8S的标准资源之一在该配置文件当中定义了一个集群列表指定的集群可以有多个用户列表也可以有多个指明集群中的用户而在上下文列表当中是进行定义可以使用哪个用户对哪个集群进行访问以及当前使用的上下文是什么。 kubectl get pods --kubeconfig/root/.kube/config授权 用户通过认证之后什么权限都没有需要一些后续的授权操作如对资源的增删该查等kubernetes1.6之后开始有RBAC基于角色的访问控制机制授权检查机制。 Kubernetes的授权是基于插件形成的其常用的授权插件有以下几种
Node节点认证ABAC(基于属性的访问控制)RBAC基于角色的访问控制Webhook基于http回调机制的访问控制
什么是RBAC基于角色的授权 让一个用户Users扮演一个角色Role角色拥有权限从而让用户拥有这样的权限随后在授权机制当中只需要将权限授予某个角色此时用户将获取对应角色的权限从而实现角色的访问控制。如图 在k8s的授权机制当中采用RBAC的方式进行授权其工作逻辑是把对对象的操作权限定义到一个角色当中再将用户绑定到该角色从而使用户得到对应角色的权限。如果通过rolebinding绑定role只能对rolebingding所在的名称空间的资源有权限上图user1这个用户绑定到role1上只对role1这个名称空间的资源有权限对其他名称空间资源没有权限属于名称空间级别的 另外k8s为此还有一种集群级别的授权机制就是定义一个集群角色ClusterRole对集群内的所有资源都有可操作的权限从而将User2通过ClusterRoleBinding到ClusterRole从而使User2拥有集群的操作权限。 Role、RoleBinding、ClusterRole和ClusterRoleBinding的关系 用户基于rolebinding绑定到role 限定在rolebinding所在的名称空间 用户基于rolebinding绑定到clusterrole 上面我们说了两个角色绑定 1用户通过rolebinding绑定role 2用户通过rolebinding绑定clusterrole rolebinding绑定clusterrole的优点 假如有6个名称空间每个名称空间的用户都需要对自己的名称空间有管理员权限那么需要定义6个role和rolebinding然后依次绑定如果名称空间更多我们需要定义更多的role这个是很麻烦的所以我们引入clusterrole定义一个clusterrole对clusterrole授予所有权限然后用户通过rolebinding绑定到clusterrole就会拥有自己名称空间的管理员权限了 注RoleBinding仅仅对当前名称空间有对应的权限。
用户基于clusterrolebinding绑定到clusterrole 用户基于rbac授权有几种方案
基于rolebinding绑定到role上基于rolebinding绑定到clusterrole上基于clusterrolebinding绑定到clusterrole上
准入控制 在k8s上准入控制器的模块有很多其中比较常用的有LimitRanger、ResourceQuota、ServiceAccount、PodSecurityPolicy(k8s1.25废弃了)等等对于前面三种准入控制器系统默认是启用的我们只需要定义对应的规则即可对于PodSecurityPolicy(k8s1.25废弃了)这种准入控制器系统默认没有启用如果我们要使用就必需启用以后对应规则才会正常生效这里需要注意一点对应psp准入控制器一定要先写好对应的规则把规则和权限绑定好以后在启用对应的准入控制器否则先启用准入控制器没有对应的规则默认情况它是拒绝操作这可能导致现有的k8s系统跑的系统级pod无法正常工作所以对于psp准入控制器要慎用如果规则和权限做的足够精细它会给我们的k8s系统安全带来大幅度的提升反之可能导致整个k8s系统不可用。 查看apiserver启用的准入控制器有哪些 cat /etc/kubernetes/manifests/kube-apiserver.yaml
apiVersion: v1
kind: Pod
metadata:annotations:kubeadm.kubernetes.io/kube-apiserver.advertise-address.endpoint: 192.168.40.63:6443creationTimestamp: nulllabels:component: kube-apiservertier: control-planename: kube-apiservernamespace: kube-system
spec:containers:- command:- kube-apiserver- --advertise-address192.168.40.180…
- --enable-admission-pluginsNodeRestrictionapiserver启用准入控制插件需要使用–enable-admission-plugins选项来指定该选项可以使用多个值用逗号隔开表示启用指定的准入控制插件这里配置文件中显式启用了NodeRestrication这个插件默认没有写在这上面的内置准入控制器它也是启用了的比如LimitRanger、ResourceQuota、ServiceAccount等等对于不同的k8s版本内置的准入控制器和启用与否请查看相关版本的官方文档对于那些没有启动的准入控制器我们可以在上面选项中直接启用分别用逗号隔开即可。 Useraccount和ServiceAccount介绍
kubernetes中账户分为UserAccounts用户账户 和 ServiceAccounts服务账户 两种
UserAccount是给kubernetes集群外部用户使用的如kubectl访问k8s集群要用useraccount用户 kubeadm安装的k8s默认的useraccount用户是kubernetes-admink8s客户端(一般用:kubectl) ------API ServerAPIServer需要对客户端做认证使用kubeadm安装的K8s会在用户家目录下创建一个认证配置文件 .kube/config 这里面保存了客户端访问API Server的密钥相关信息这样当用kubectl访问k8s时它就会自动读取该配置文件向API Server发起认证然后完成操作请求。 用户名称可以在kubeconfig中查看 cd ~/.kube/
ls
cache config http-cache
cat configusers:
- name: kubernetes-adminServiceAccount是Pod使用的账号Pod容器的进程需要访问API Server时用的就是ServiceAccount账户ServiceAccount仅局限它所在的namespace每个namespace创建时都会自动创建一个default service account创建Pod时如果没有指定Service AccountPod则会使用default Service Account。 ServiceAccount使用案例介绍
创建sa并绑定到pod
创建sa
kubectl create sa sa-test创建pod
cat pod.yamlapiVersion: v1
kind: Pod
metadata:name: sa-testnamespace: defaultlabels:app: sa
spec:serviceAccountName: sa-testcontainers:- name: sa-tomcatports:- containerPort: 80image: nginximagePullPolicy: IfNotPresentkubectl apply -f pod.yamlkubectl exec -it sa-test -- /bin/bash
rootsa-test:/# cd /var/run/secrets/kubernetes.io/serviceaccount/
rootsa-test:/var/run/secrets/kubernetes.io/serviceaccount# curl --cacert ./ca.crt -H Authorization: Bearer $(cat ./token)显示如下 {kind: Status,apiVersion: v1,metadata: {},status: Failure,message: namespaces \kube-system\ is forbidden: User \system:serviceaccount:default:sa-test\ cannot get resource \namespaces\ in API group \\ in the namespace \kube-system\,reason: Forbidden,details: {name: kube-system,kind: namespaces},code: 403
}上面结果能看到sa能通过https方式成功认证API但是没有权限访问k8s资源所以code状态码是403表示没有权限操作k8s资源 对sa做授权
kubectl create clusterrolebinding sa-test-admin --clusterrolecluster-admin --serviceaccountdefault:sa-test再次请求
kubectl exec -it sa-test -- /bin/bash
rootsa-test:/# cd /var/run/secrets/kubernetes.io/serviceaccount/
rootsa-test:/var/run/secrets/kubernetes.io/serviceaccount# curl --cacert ./ca.crt -H Authorization: Bearer $(cat ./token)显示如下 {kind: Namespace,apiVersion: v1,metadata: {name: kube-system,uid: c392fcb2-12da-4419-b5de-6e2fe2ca626a,resourceVersion: 28,creationTimestamp: 2022-09-18T06:19:42Z,labels: {kubernetes.io/metadata.name: kube-system},managedFields: [{manager: kube-apiserver,operation: Update,apiVersion: v1,time: 2022-09-18T06:19:42Z,fieldsType: FieldsV1,fieldsV1: {f:metadata: {f:labels: {.: {},f:kubernetes.io/metadata.name: {}}}}}]},spec: {finalizers: [kubernetes]},status: {phase: Active}
}通过上面可以看到对sa做授权之后就有权限访问k8s资源了
