企业官网建设流程全解析

杭州专业网站建设,wordpress 获取表单数据,优化seo是什么意思,企业网络采购平台一、k8s安全管理#xff1a;认证、授权、准入控制概述 k8s对我们整个系统的认证#xff0c;授权#xff0c;访问控制做了精密的设置#xff1b;对于k8s集群来说#xff0c;apiserver是整个集群访问控制的唯一入口#xff0c;我们在k8s集群之上部署应用程序的时候#x…一、k8s安全管理认证、授权、准入控制概述k8s对我们整个系统的认证授权访问控制做了精密的设置对于k8s集群来说apiserver是整个集群访问控制的唯一入口我们在k8s集群之上部署应用程序的时候也可以通过宿主机的NodePort暴露的端口访问里面的程序用户访问kubernetes集群需要经历如下认证过程认证-授权-准入控制admination controller1.认证(Authenticating)是对客户端的认证通俗点就是用户名密码验证2.授权(Authorization)是对资源的授权k8s中的资源无非是容器最终其实就是容器的计算网络存储资源当一个请求经过认证后需要访问某一个资源比如创建一个pod授权检查会根据授权规则判定该资源比如某namespace下的pod是否是该客户可访问的。3.准入(Admission Control)机制准入控制器Admission Controller位于 API Server中在对象被持久化之前准入控制器拦截对 API Server 的请求一般用来做身份验证和授权。其中包含两个特殊的控制器Mutating Admission Webhook 和 Validating Admission Webhook。分别作为配置的变更和验证准入控制 webhook。变更Mutating准入控制修改请求的对象验证Validating准入控制验证请求的对象准入控制器是在 API Server 的启动参数配置的。一个准入控制器可能属于以上两者中的一种也可能两者都属于。当请求到达 API Server 的时候首先执行变更准入控制然后再执行验证准入控制。我们在部署 Kubernetes 集群的时候都会默认开启一系列准入控制器如果没有设置这些准入控制器的话可以说你的 Kubernetes 集群就是在裸奔应该只有集群管理员可以修改集群的准入控制器。例如:会默认开启如下的准入控制器。--admission-controlServiceAccount,NamespaceLifecycle,NamespaceExists,LimitRanger,ResourceQuota,MutatingAdmissionWebhook,ValidatingAdmissionWebhookk8s的整体架构也是一个微服务的架构所有的请求都是通过一个GateWay也就是kube-apiserver这个组件对外提供REST服务k8s中客户端有两类一种是普通用户一种是集群内的Pod这两种客户端的认证机制略有不同但无论是哪一种都需要依次经过认证授权准入这三个机制。1.1 认证1、认证支持多种插件1令牌token认证双方有一个共享密钥服务器上来先创建一个密码下来客户端登陆的时候拿这个密码登陆即可这个就是对称密钥认证方式k8s提供了一个restful风格的接口它的所有服务都是通过http协议提供的因此认证信息只能经由http协议的认证首部进行传递这种认证首部进行传递通常叫做令牌2ssl认证TLS对于k8s访问来讲ssl认证能让客户端确认服务器的认证身份我们在跟服务器通信的时候需要服务器发过来一个证书我们需要确认这个证书是不是ca签署的如果是我们认可的ca签署的里面的subj信息与我们访问的目标主机信息保持一致没有问题那么我们就认为服务器的身份得到认证了k8s中最重要的是服务器还需要认证客户端的信息kubectl也应该有一个证书这个证书也是server所认可的ca签署的证书双方需要互相认证实现加密通信这就是ssl认证。2、kubernetes上的账号客户端对apiserver发起请求apiserver要识别这个用户是否有请求的权限要识别用户本身能否通过apiserver执行相应的操作那么需要哪些信息才能识别用户信息来完成对用户的相关的访问控制呢kubectl explain pods.spec可以看到有一个字段serviceAccountName服务账号名称这个就是我们pod连接apiserver时使用的账号因此整个kubernetes集群中的账号有两类ServiceAccount服务账号User account用户账号User account实实在在现实中的人人可以登陆的账号客户端想要对apiserver发起请求apiserver要识别这个客户端是否有请求的权限那么不同的用户就会有不同的权限靠用户账号表示叫做usernameServiceAccount方便Pod里面的进程调用Kubernetes API或其他外部服务而设计的是kubernetes中的一种资源sa账号登陆dashboard使用的账号user account这个是登陆k8s物理机器的用户系统用户1.ServiceAccountService account是为了方便Pod里面的进程调用Kubernetes API或其他外部服务而设计的。它与User account不同User account是为人设计的而service account则是为Pod中的进程调用Kubernetes API而设计User account是跨namespace的而service account则是仅局限它所在的namespace每个namespace都会自动创建一个defaultservice account开启ServiceAccount Admission Controller后1每个Pod在创建后都会自动设置spec.serviceAccount为default除非指定了其他ServiceAccout2验证Pod引用的service account已经存在否则拒绝创建当创建 pod 的时候如果没有指定一个 serviceaccount系统会自动在与该pod 相同的 namespace 下为其指派一个default service account。这是pod和apiserver之间进行通信的账号如下[rootk8s-master01 ~]# kubectl get pods NAME READY STATUS RESTARTS AGE mysql-pod-volume 1/1 Running 0 43m nfs-provisioner-cd5589cfc-c8vc5 1/1 Running 0 13h pod-secret 1/1 Running 0 18m web-0 1/1 Running 0 13h web-1 1/1 Running 0 13h[rootk8s-master01 ~]# kubectl get pods web-0 -o yaml | grep serviceAccountName serviceAccountName: default[rootk8s-master01 ~]# kubectl get sa NAME SECRETS AGE default 0 12d默认的service account 仅仅只能获取当前Pod自身的相关属性无法观察到其他名称空间Pod的相关属性信息。创建一个serviceaccount[rootk8s-master ~]# kubectl create serviceaccount test [rootk8s-master ~]# kubectl describe sa test #查看test这个账号的详细信息 [rootk8s-master ~]# kubectl describe sa test Name: test Namespace: default Labels: none Annotations: none Image pull secrets: none Mountable secrets: none Tokens: none Events: none2、kubeconfig文件在K8S集群当中每一个用户对资源的访问都是需要通过apiserver进行通信认证才能进行访问的那么在此机制当中对资源的访问可以是token也可以是通过配置文件的方式进行保存和使用认证信息可以通过kubectl config进行查看配置如下[rootk8s-master ~]# kubectl config view apiVersion: v1 clusters: - cluster: certificate-authority-data: DATAOMITTED server: https://192.168.40.199:6443 #apiserver的地址 name: kubernetes #集群的名字 contexts: - context: cluster: kubernetes user: kubernetes-admin name: kubernetes-adminkubernetes #上下文的名字 current-context: kubernetes-adminkubernetes #当前上下文的名字 kind: Config preferences: {} users: - name: kubernetes-admin user: client-certificate-data: REDACTED client-key-data: REDACTED查看当前管理集群的账户kubectl auth whoami在上面的配置文件当中定义了集群、上下文以及用户。其中Config也是K8S的标准资源之一在该配置文件当中定义了一个集群列表指定的集群可以有多个用户列表也可以有多个指明集群中的用户而在上下文列表当中是进行定义可以使用哪个用户对哪个集群进行访问以及当前使用的上下文是什么。1.2 授权如果用户通过认证什么权限都没有需要一些后续的授权操作如对资源的增删该查等kubernetes1.6之后开始有RBAC基于角色的访问控制机制授权检查机制。role basic access controlKubernetes的授权是基于插件形成的其常用的授权插件有以下几种Node节点认证ABAC(基于属性的访问控制)RBAC基于角色的访问控制Role Basic Access ControlWebhook基于http回调机制的访问控制什么是RBAC基于角色的访问控制让一个用户Users扮演一个角色Role角色拥有权限从而让用户拥有这样的权限随后在授权机制当中只需要将权限授予某个角色此时用户将获取对应角色的权限从而实现角色的访问控制。如图在k8s的授权机制当中采用RBAC的方式进行授权其工作逻辑是把对对象的操作权限定义到一个角色当中再将用户绑定到该角色从而使用户得到对应角色的权限。如果通过rolebinding绑定role只能对rolebingding所在的名称空间的资源有权限上图user1这个用户绑定到role1上只对role1这个名称空间的资源有权限对其他名称空间资源没有权限属于名称空间级别的另外k8s为此还有一种集群级别的授权机制就是定义一个集群角色ClusterRole对集群内的所有资源都有可操作的权限从而将User2通过ClusterRoleBinding到ClusterRole从而使User2拥有集群的操作权限。Role、RoleBinding、ClusterRole和ClusterRoleBinding的关系如下图通过上图可以看到可以通过rolebinding绑定rolerolebinding绑定clusterroleclusterrolebinding绑定clusterrole。上面我们说了两个角色绑定1用户通过rolebinding绑定role2用户通过clusterrolebinding绑定clusterrole还有一种rolebinding绑定clusterrolerolebinding绑定clusterrole的好处假如有6个名称空间每个名称空间的用户都需要对自己的名称空间有管理员权限那么需要定义6个role和rolebinding然后依次绑定如果名称空间更多我们需要定义更多的role这个是很麻烦的所以我们引入clusterrole定义一个clusterrole对clusterrole授予所有权限然后用户通过Clusterrolebinding绑定到clusterrole就会拥有自己名称空间的管理员权限了注RoleBinding仅仅对当前名称空间有对应的权限。二、RBAC认证授权策略RBAC介绍在Kubernetes中所有资源对象都是通过API进行操作他们保存在etcd里。而对etcd的操作我们需要通过访问 kube-apiserver 来实现上面的Service Account其实就是APIServer的认证过程而授权的机制是通过RBAC基于角色的访问控制实现。RBAC有四个资源对象分别是Role、ClusterRole、RoleBinding、ClusterRoleBinding3.1 Role角色一组权限的集合在一个命名空间中可以用其来定义一个角色只能对命名空间内的资源进行授权。如果是集群级别的资源则需要使用ClusterRole。例如定义一个角色用来读取Pod的权限apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: rbac name: pod-read rules: - apiGroups: [] resources: [pods] resourceNames: [] verbs: [get,watch,list]rules中的参数说明apiGroups支持的API组列表例如apiVersion: batch/v1等resources支持的资源对象列表例如pods、deplayments、jobs等resourceNames: 指定resource的名称verbs对资源对象的操作方法列表。3.2 ClusterRole集群角色具有和角色一致的命名空间资源的管理能力还可用于以下特殊元素的授权集群范围的资源例如Node非资源型的路径例如/healthz包含全部命名空间的资源例如Pods例如定义一个集群角色可让用户访问任意secretsapiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: secrets-clusterrole rules: - apiGroups: [] resources: [secrets] verbs: [get,watch,list]3.3 RoleBinding角色绑定、ClusterRolebinding集群角色绑定角色绑定和集群角色绑定用于把一个角色绑定在一个目标上可以是UserGroupService Account使用RoleBinding为某个命名空间授权使用ClusterRoleBinding为集群范围内授权。例如将在rbac命名空间中把pod-read角色授予用户esapiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: pod-read-bind namespace: rbac subjects: - kind: User name: es apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: pod-read apiGroup: rbac.authorization.k8s.ioRoleBinding也可以引用ClusterRole对属于同一命名空间内的ClusterRole定义的资源主体进行授权 例如es能获取到集群中所有的资源信息apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: es-allresource namespace: rbac subjects: - kind: User name: es apiGroup: rbac.authorization.k8s.io roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-admin集群角色绑定的角色只能是集群角色用于进行集群级别或对所有命名空间都生效的授权例如允许manager组的用户读取所有namaspace的secretsapiVersion: rabc.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: read-secret-global subjects: - kind: Group name: manager apiGroup: rabc.authorization.k8s.io roleRef: kind: ClusterRole name: secret-read apiGroup: rabc.authorization.k8s.io四、资源的引用方式多数资源可以用其名称的字符串表示也就是Endpoint中的URL相对路径例如pod中的日志是GET /api/v1/namaspaces/{namespace}/pods/{podname}/log如果需要在一个RBAC对象中体现上下级资源就需要使用“/”分割资源和下级资源。例如若想授权让某个主体同时能够读取Pod和Pod log则可以配置 resources为一个数组apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: logs-reader namespace: default rules: - apiGroups: [] resources: [pods,pods/log] verbs: [get,list]资源还可以通过名称ResourceName进行引用在指定ResourceName后使用get、delete、update、patch请求就会被限制在这个资源实例范围内。例如下面的声明让一个主体只能对名为my-configmap的Configmap进行get和update操作apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: default name: configmap-update rules: - apiGroups: [] resources: [configmap] resourceNames: [my-configmap] verbs: [get,update]查看资源信息的命令[rootk8s-master01 ~]# kubectl api-resources五、常见角色示例1允许读取核心API组的Pod资源rules: - apiGroups: [] resources: [pods] verbs: [get,list,watch]2允许读写extensions和apps两个API组中的deployment资源rules: - apiGroups: [extensions,apps] resources: [deployments] verbs: [get,list,watch,create,update,patch,delete]3允许读取Pod以及读写job信息rules: - apiGroups: [] resources: [pods] verbs: [get,list,watch]、 - apiGroups: [batch,extensions] resources: [jobs] verbs: [get,list,watch,create,update,patch,delete]4允许读取一个名为my-config的ConfigMap必须绑定到一个RoleBinding来限制到一个Namespace下的ConfigMaprules: apiGroups: [] resources: [configmap] resourceNames: [my-configmap] verbs: [get]5读取核心组的Node资源Node属于集群级的资源所以必须存在于ClusterRole中并使用ClusterRoleBinding进行绑定rules: apiGroups: [] resources: [nodes] verbs: [get,list,watch]6允许对非资源端点“/healthz”及其所有子路径进行GET和POST操作必须使用ClusterRole和ClusterRoleBindingrules: nonResourceURLs: [/healthz,/healthz/*] verbs: [get,post]六、常见的角色绑定示例1用户名alicesubjects: - kind: User name: alice apiGroup: rbac.authorization.k8s.io2组名alicesubjects: - kind: Group name: alice apiGroup: rbac.authorization.k8s.io3kube-system命名空间中默认Service Accountsubjects: kind: ServiceAccount name: default namespace: kube-system4qa命名空间中的所有Service Accountsubjects: kind: Group name: system:serviceaccounts:qa apiGroup: rbac.authorization.k8s.io5所有Service Accountsubjects: kind: Group name: system:serviceaccounts apiGroup: rbac.authorization.k8s.io6所有认证用户subjects: kind: Group name: system:authenticated apiGroup: rbac.authorization.k8s.io7所有未认证用户subjects: kind: Group name: system:unauthenticated apiGroup: rbac.authorization.k8s.io8全部用户subjects: kind: Group name: system:authenticated apiGroup: rbac.authorization.k8s.io kind: Group name: system:unauthenticated apiGroup: rbac.authorization.k8s.io七、对Service Account的授权管理pod内可获取rbac命名空间的所有Pod资源pod-reader-sc的Service Account是绑定了名为pod-read的Role。apiVersion: v1 kind: Pod metadata: name: nginx namespace: rbac spec: serviceAccountName: pod-reader-sc containers: name: nginx image: nginx imagePullPolicy: IfNotPresent ports: containerPort: 80默认的RBAC策略为控制平台组件、节点和控制器授予有限范围的权限但是除kube-system外的Service Account是没有任何权限的。1为一个应用专属的Service Account赋权此应用需要在Pod的spec中指定一个serviceAccountName用于API、Application Manifest、kubectl create serviceaccount等创建Service Account的命令。例如为my-namespace中的my-sa Service Account授予只读权限kubectl create rolebinding my-sa-view --clusterroleview --serviceaccountmy-namespace:my-sa --namespacemy-namespace2为一个命名空间中名为default的Service Account授权如果一个应用没有指定 serviceAccountName则会使用名为default的Service Account。注意赋予Service Account “default”的权限会让所有没有指定serviceAccountName的Pod都具有这些权限例如在my-namespace命名空间中为Service Account“default”授予只读权限kubectl create rolebinding default-view --clusterroleview --serviceaccountmy-namespace:default --namespacemy-namespace另外许多系统级Add-Ons都需要在kube-system命名空间中运行要让这些Add-Ons能够使用超级用户权限则可以把cluster-admin权限赋予kube-system命名空间中名为default的Service Account这一操作意味着kube-system命名空间包含了通向API超级用户的捷径。kubectl create clusterrolebinding add-ons-add-admin --clusterrolecluster-admin --serviceaccountkube-system:default3为命名空间中所有Service Account都授予一个角色如果希望在一个命名空间中任何Service Account应用都具有一个角色则可以为这一命名空间的Service Account群组进行授权kubectl create rolebinding serviceaccounts-view --clusterroleview --groupsystem:serviceaccounts:my-namespace --namespacemy-namespace4为集群范围内所有Service Account都授予一个低权限角色如果不想为每个命名空间管理授权则可以把一个集群级别的角色赋给所有Service Account。kubectl create clusterrolebinding serviceaccounts-view --clusterroleview --groupsystem:serviceaccounts5为所有Service Account授予超级用户权限kubectl create clusterrolebinding serviceaccounts-view --clusterrolecluster-admin --groupsystem:serviceaccounts八、使用kubectl命令行工具创建资源对象1在命名空间rbac中为用户es授权admin ClusterRolekubectl create rolebinding bob-admin-binding --clusterroleadmin --useres --namespacerbac2在命名空间rbac中为名为myapp的Service Account授予view ClusterRolekubctl create rolebinding myapp-role-binding --clusterroleview --serviceaccountrbac:myapp --namespacerbac3在全集群范围内为用户root授予cluster-admin ClusterRolekubectl create clusterrolebinding cluster-binding --clusterrolecluster-admin --userroot4在全集群范围内为名为myapp的Service Account授予view ClusterRolekubectl create clusterrolebinding service-account-binding --clusterroleview --serviceaccountmyappyaml文件进行rbac授权https://kubernetes.io/zh/docs/reference/access-authn-authz/rbac/九、限制不同的用户操作k8s集群(重点)ssl认证生成一个证书1生成一个私钥cd /etc/kubernetes/pki/ umask 077; openssl genrsa -out lucky.key 20482生成一个证书请求openssl req -new -key lucky.key -out lucky.csr -subj /CNlucky3生成一个证书openssl x509 -req -in lucky.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out lucky.crt -days 3650在kubeconfig下新增加一个lucky这个用户1把lucky这个用户添加到kubernetes集群中可以用来认证apiserver的连接[rootxianchaomaster1 pki]# kubectl config set-credentials lucky --client-certificate./lucky.crt --client-key./lucky.key --embed-certstrue2在kubeconfig下新增加一个lucky这个账号kubectl config set-context luckykubernetes --clusterkubernetes --userlucky3切换账号到lucky默认没有任何权限[rootk8s-master01 pki]# kubectl config use-context luckykubernetes [rootk8s-master01 pki]# kubectl get pod Error from server (Forbidden): pods is forbidden: User lucky cannot list resource pods in API group in the namespace default ###切换到有权限的管理账户 [rootk8s-master01 pki]# kubectl config use-context kubernetes-adminkubernetes这个是集群用户有任何权限把lucky这个用户通过rolebinding绑定到clusterrole上授予权限,权限只是在lucky这个名称空间有效1把lucky这个用户通过rolebinding绑定到clusterrole上[rootk8s-master01 pki]# kubectl create ns lucky [rootk8s-master01 pki]# kubectl create rolebinding lucky -n lucky --clusterrolecluster-admin --userlucky2切换到lucky这个用户[rootk8s-master01 pki]# kubectl config use-context luckykubernetes3测试是否有权限kubectl get pods -n lucky [rootk8s-master01 pki]# kubectl get pod -n lucky No resources found in lucky namespace. [rootk8s-master01 pki]# kubectl get sa -n lucky NAME SECRETS AGE default 0 2m10s #有权限操作这个名称空间 kubectl get pods ​ [rootk8s-master01 pki]# kubectl get pod Error from server (Forbidden): pods is forbidden: User lucky cannot list resource pods in API group in the namespace default ​ #没有权限操作其他名称空间添加一个lucky的普通用户useradd lucky cp -ar /root/.kube/ /home/lucky/ chown -R lucky.lucky /home/lucky/ su - lucky vim .kube/config ....... server: https://192.168.158.15:6443 name: kubernetes contexts: - context: cluster: kubernetes user: lucky name: luckykubernetes current-context: luckykubernetes .... su - root chattr i /home/lucky/.kube/config exit kubectl get pods -n lucky验证创建pod[luckyk8s-master ~]$ cat nginx.txt apiVersion: v1 kind: Pod metadata: name: nginx-pod spec: containers: - name: nginx image: nginx imagePullPolicy: IfNotPresent [luckyk8s-master ~]$ kubectl apply -f nginx.txt ##发现报错 Error from server (Forbidden): error when retrieving current configuration of: Resource: /v1, Resourcepods, GroupVersionKind: /v1, KindPod Name: nginx-pod, Namespace: default from server for: nginx.txt: pods nginx-pod is forbidden: User lucky cannot get resource pods in API group in the namespace default ​ [luckyk8s-master ~]$ cat nginx.txt apiVersion: v1 kind: Pod metadata: name: nginx-pod namespace: lucky spec: containers: - name: nginx image: nginx imagePullPolicy: IfNotPresent [luckyk8s-master ~]$ kubectl apply -f nginx.txt ##发现成功创建 pod/nginx-pod created [luckyk8s-master ~]$ kubectl -n lucky get po NAME READY STATUS RESTARTS AGE nginx-pod 1/1 Running 0 28s ​