十一.K8s安全管理:认证,授权,准入控制
11.1RBAC概述
11.1.1安全管理概述
k8s 对我们整个系统的认证,授权,访问控制做了精密的设置;对于 k8s 集群来说,apiserver 是整 个集群访问控制的唯一入口,我们在 k8s 集群之上部署应用程序的时候,也可以通过宿主机的 NodePort 暴露的端口访问里面的程序,用户访问 kubernetes 集群需要经历如下认证过程:认证 ->授权->准入控制(adminationcontroller)
1.认证(Authenticating)是对客户端的认证,通俗点就是用户名密码验证
2.授权(Authorization)是对资源的授权,k8s 中的资源无非是容器,最终其实就是容器的计算,网 络,存储资源,当一个请求经过认证后,需要访问某一个资源(比如创建一个 pod),授权检查会根 据授权规则判定该资源(比如某 namespace 下的 pod)是否是该客户可访问的。
3.准入控制器(Admission Controller)位于 API Server 中,在对象被持久化之前,准入控制器拦 截对 API Server 的请求,一般用来做身份验证和授权。其中包含webhook两个特殊的控制器:
变更(Mutating)准入控制:修改请求的对象
验证(Validating)准入控制:验证请求的对
准入控制器是在 API Server 的启动参数配置的。一个准入控制器可能属于以上两者中的一种,也 可能两者都属于。当请求到达 API Server 的时候首先执行变更准入控制,然后再执行验证准入控 制。
k8s 的整体架构也是一个微服务的架构,所有的请求都是通过一个 GateWay,也就是 kubeapiserver 这个组件(对外提供 REST 服务),k8s 中客户端有两类,一种是普通用户,一种是集群 内的 Pod,这两种客户端的认证机制略有不同,但无论是哪一种,都需要依次经过认证,授权,准 入这三个机制。
Kubernetes 的授权是基于插件形成的,其常用的授权插件有以下几种:
1)Node(节点认证)
2)ABAC(基于属性的访问控制)
3)RBAC(基于角色的访问控制)***
4)Webhook(基于 http 回调机制的访问控制)
什么是RBAC
让一个用户(Users)扮演一个角色(Role),角色拥有权限,从而让用户拥有这样的权限,随后在 授权机制当中,只需要将权限授予某个角色,此时用户将获取对应角色的权限,从而实现角色的访问 控制。
在 k8s 的授权机制当中,采用 RBAC 的方式进行授权,其工作逻辑是,把对对象的操作权限定义到 一个角色当中,再将用户绑定到该角色,从而使用户得到对应角色的权限。如果通过 rolebinding 绑定 role,只能对 rolebingding 所在的名称空间的资源有权限,上图 user1 这个用户绑定到 role1 上,只对 role1 这个名称空间的资源有权限,对其他名称空间资源没有权限,属于名称空间级 别的;
另外,k8s 为此还有一种集群级别的授权机制,就是定义一个集群角色(ClusterRole),对集群内 的所有资源都有可操作的权限,从而将 User2 通过 ClusterRoleBinding 到 ClusterRole,从而使 User2 拥有集群的操作权限。
1.用户通过 rolebinding 绑定 role
2.用户通过 clusterrolebinding 绑定 clusterrole
3.用户通过rolebinding 绑定 clusterrole:
假如有 6 个名称空间,每个名称空间的用户都需要对自己的名称空间有管理员权限,那么需要定义 6 个 role 和 rolebinding,然后依次绑定,如果名称空间更多,我们需要定义更多的 role,这个是很 麻烦的,所以我们引入 clusterrole,定义一个 clusterrole,对 clusterrole 授予所有权限,然后用 户通过 rolebinding 绑定到 clusterrole,就会拥有自己名称空间的管理员权限了 注:RoleBinding 仅仅对当前名称空间有对应的权限。
11.1.2ServiceAccount 介绍
kubernetes 中账户区分为:User Accounts(用户账户) 和 Service Accounts(服务账户) 两种:
UserAccount 是给 kubernetes 集群外部用户使用的,例如运维或者集群管理人员,,kubeadm 安装的 k8s,默认用户账号是 kubernetes-admin;
k8s 客户端(一般用:kubectl) ------>API Server
APIServer 需要对客户端做认证,使用 kubeadm 安装的 K8s,会在用户家目录下创建一个认 证配置文件 .kube/config 这里面保存了客户端访问 API Server 的密钥相关信息,这样当用 kubectl 访问 k8s 时,它就会自动读取该配置文件,向 API Server 发起认证,然后完成操作请求。#默认cd ~/.kube/config
ServiceAccount 是 Pod 使用的账号,Pod 容器的进程需要访问 API Server 时用的就是 ServiceAccount 账户;ServiceAccount 仅局限它所在的 namespace,每个 namespace 创建时都会 自动创建一个 default service account;创建 Pod 时,如果没有指定 Service Account,Pod 则会使 用 default Service Account。
11.2Role和ClusterRole
RBAC 介绍
在 Kubernetes 中,所有资源对象都是通过 API 进行操作,他们保存在 etcd 里。而对 etcd 的操作 我们需要通过访问 kube-apiserver 来实现,上面的 Service Account 其实就是 APIServer 的认证过 程,而授权的机制是通过 RBAC:基于角色的访问控制实现。
Role 总是用来在某个名字空间内设置访问权限; 在你创建 Role 时,你必须指定该 Role 所属的名字空间。
ClusterRole 则是一个集群作用域的资源。这两种资源的名字不同(Role 和 ClusterRole) 是因为 Kubernetes 对象要么是名字空间作用域的,要么是集群作用域的,不可两者兼具。
如果你希望在名字空间内定义角色,应该使用 Role; 如果你希望定义集群范围的角色,应该使用 ClusterRole。
11.2.1Role的使用
作用于命令空间的权限
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: default
name: pod-reader
rules:
- apiGroups: [""] # "" 标明 core API 组
resources: ["pods"]
verbs: ["get", "watch", "list"]
11.2.2ClusterRole
ClusterRole可以用于授予Role的权限,也可以用于:
集群范围资源(比如节点(Node))
非资源端点(比如
/healthz
)[root@master2 secret]# curl https://localhost:6443/healthz -k
ok跨名字空间访问的名字空间作用域的资源(如 Pod)
比如,你可以使用 ClusterRole 来允许某特定用户执行
kubectl get pods --all-namespaces
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
# "namespace" 被忽略,因为 ClusterRoles 不受名字空间限制
name: secret-reader
rules:
- apiGroups: [""]
# 在 HTTP 层面,用来访问 Secret 资源的名称为 "secrets"
resources: ["secrets"]
verbs: ["get", "watch", "list"]
11.3RoleBinding 和 ClusterRoleBinding
角色绑定(Role Binding)是将角色中定义的权限赋予一个或者一组用户。 它包含若干 主体(用户、组或服务账户)的列表和对这些主体所获得的角色的引用。
RoleBinding 在指定的名字空间中执行授权,而 ClusterRoleBinding 在集群范围执行授权。
11.3.1RoleBinding
下面的例子中的 RoleBinding 将 “pod-reader” Role 授予在 “default” 名字空间中的用户 “jane”。 这样,用户 “jane” 就具有了读取 “default” 名字空间中所有 Pod 的权限。
apiVersion: rbac.authorization.k8s.io/v1
# 此角色绑定允许 "jane" 读取 "default" 名字空间中的 Pod
# 你需要在该命名空间中有一个名为 “pod-reader” 的 Role
kind: RoleBinding
metadata:
name: read-pods
namespace: default
subjects:
# 你可以指定不止一个“subject(主体)”
- kind: User
name: jane # "name" 是区分大小写的
apiGroup: rbac.authorization.k8s.io
roleRef:
# "roleRef" 指定与某 Role 或 ClusterRole 的绑定关系
kind: Role # 此字段必须是 Role 或 ClusterRole
name: pod-reader # 此字段必须与你要绑定的 Role 或 ClusterRole 的名称匹配
apiGroup: rbac.authorization.k8s.io
RoleBinding 也可以引用 ClusterRole,以将对应 ClusterRole 中定义的访问权限授予 RoleBinding 所在名字空间的资源。这种引用使得你可以跨整个集群定义一组通用的角色, 之后在多个名字空间中复用。
例如,尽管下面的 RoleBinding 引用的是一个 ClusterRole,“dave”(这里的主体, 区分大小写)只能访问 “development” 名字空间中的 Secrets 对象,因为 RoleBinding 所在的名字空间(由其 metadata 决定)是 “development”。
apiVersion: rbac.authorization.k8s.io/v1
# 此角色绑定使得用户 "dave" 能够读取 "development" 名字空间中的 Secrets
# 你需要一个名为 "secret-reader" 的 ClusterRole
kind: RoleBinding
metadata:
name: read-secrets
# RoleBinding 的名字空间决定了访问权限的授予范围。
# 这里隐含授权仅在 "development" 名字空间内的访问权限。
namespace: development
subjects:
- kind: User
name: dave # 'name' 是区分大小写的
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: secret-reader
apiGroup: rbac.authorization.k8s.io
11.3.2ClusterRoleBinding
集群角色绑定的角色只能是集群角色,用于进行集群级别或对所有命名空间都生效的授权
apiVersion: rabc.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: read-secret-global
subjects:
- kind: Group
name: manager
apiGroup: rabc.authorization.k8s.io
ruleRef:
- kind: ClusterRole
name: secret-read
apiGroup: rabc.authorization.k8s.io
11.3.3资源的引用
多数资源可以用其名称的字符串表示,也就是 Endpoint 中的 URL 相对路径,例如 pod 中的日志是 GET /api/v1/namaspaces/{namespace}/pods/{podname}/log 如果需要在一个 RBAC 对象中体现上下级资源,就需要使用“/”分割资源和下级资源。
例如:若想授权让某个主体同时能够读取 Pod 和 Pod log,则可以配置 resources 为一个数组
apiVersion: rabc.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: rabc.authorization.k8s.io/v1
kind: Role
metadata:
namaspace: default
name: configmap-update
rules:
- apiGroups: [""]
resources: ["configmap"]
resourceNames: ["my-configmap"]
verbs: ["get","update"]
11.4常见角色示例
(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"]、
- apiVersion: ["batch","extensions"]
resources: ["jobs"]
verbs: ["get","list","watch","create","update","patch","delete"]
(4)允许读取一个名为 my-config 的 ConfigMap(必须绑定到一个 RoleBinding 来限制到一个 Namespace 下的 ConfigMap):
rules:
- 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 和 ClusterRoleBinding):
rules:
- nonResourceURLs: ["/healthz","/healthz/*"]
verbs: ["get","post"]
11.5常见的角色绑定示例
(1)用户名 alice
subjects:
- kind: User
name: alice
apiGroup: rbac.authorization.k8s.io
(2)组名 alice
subjects:
- kind: Group
name: alice
apiGroup: rbac.authorization.k8s.io
(3)kube-system 命名空间中默认 Service Account
subjects:
- kind: ServiceAccount
name: default
namespace: kube-system
(4)qa 命名空间中的所有 Service Account:
subjects:
- kind: Group
name: system:serviceaccounts:qa
apiGroup: rbac.authorization.k8s.io
(5)所有 Service Account
subjects:
- kind: Group
name: system:serviceaccounts
apiGroup: rbac.authorization.k8s.io
(6)所有认证用户
subjects:
- kind: Group
name: system:authenticated
apiGroup: rbac.authorization.k8s.io
(7)所有未认证用户
subjects:
- kind: Group
name: system:unauthenticated
apiGroup: rbac.authorization.k8s.io
(8)全部用户
subjects:
- kind: Group
name: system:authenticated
apiGroup: rbac.authorization.k8s.io
- kind: Group
name: system:unauthenticated
apiGroup: rbac.authorization.k8s.io
11.6对 Service Account 的授权管理
Service Account 也是一种账号,是给运行在 Pod 里的进程提供了必要的身份证明。需要在 Pod 定义中指明引用的 Service Account,这样就可以对 Pod 的进行赋权操作。例如: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 --clusterrole=view --serviceaccount=mynamespace:my-sa --namespace=my-namespace
#(2)为一个命名空间中名为 default 的 Service Account 授权如果一个应用没有指定 serviceAccountName,则会使用名为 default 的 Service Account。注意,赋予 Service Account “default”的权限会让所有没有指定 serviceAccountName 的 Pod都具有这些权限
#例如,在 my-namespace 命名空间中为 Service Account“default”授予只读权限:
kubectl create rolebinding default-view --clusterrole=view --serviceaccount=mynamespace:default --namespace=my-namespace
#另外,许多系统级 Add-Ons 都需要在 kube-system 命名空间中运行,要让这些 Add-Ons 能够使用超级用户权限,则可以把 cluster-admin 权限赋予 kube-system 命名空间中名为 default 的Service Account,这一操作意味着 kube-system 命名空间包含了通向 API 超级用户的捷径。
kubectl create clusterrolebinding add-ons-add-admin --clusterrole=cluster-admin --serviceaccount=kube-system:default
#(3)为命名空间中所有 Service Account 都授予一个角色如果希望在一个命名空间中,任何 Service Account 应用都具有一个角色,则可以为这一命名空间的 Service Account 群组进行授权
kubectl create rolebinding serviceaccounts-view --clusterrole=view --group=system:serviceaccounts:my-namespace --namespace=my-namespace
#(4)为集群范围内所有 Service Account 都授予一个低权限角色如果不想为每个命名空间管理授权,则可以把一个集群级别的角色赋给所有 Service Account。
kubectl create clusterrolebinding serviceaccounts-view --clusterrole=view --group=system:serviceaccounts
#(5)为所有 Service Account 授予超级用户权限
kubectl create clusterrolebinding serviceaccounts-view --clusterrole=cluster-admin --group=system:serviceaccounts
11.7用kubectl创建资源对象
#(1)在命名空间 rbac 中为用户 es 授权 admin ClusterRole:
kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=es --namespace=rbac
#(2)在命名空间 rbac 中为名为 myapp 的 Service Account 授予 view ClusterRole:
kubctl create rolebinding myapp-role-binding --clusterrole=view --serviceaccount=rbac:myapp --namespace=rbac
#(3)在全集群范围内为用户 root 授予 cluster-admin ClusterRole:
kubectl create clusterrolebinding cluster-binding --clusterrole=cluster-admin --user=root
#(4)在全集群范围内为名为 myapp 的 Service Account 授予 view ClusterRole:
kubectl create clusterrolebinding service-account-binding --clusterrole=view --serviceaccount=myapp
yaml 文件进行 rbac 授权:https://kubernetes.io/zh/docs/reference/access-authn-authz/rbac/
11.8限制不同的用户操控k8s集群
#(1)生成一个私钥
cd /etc/kubernetes/pki/
(umask 077; openssl genrsa -out lucky.key 2048)
#(2)生成一个证书请求
openssl req -new -key lucky.key -out lucky.csr -subj "/CN=lucky"
#(3)生成一个证书
openssl x509 -req -in lucky.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out lucky.crt -days 3650
#在 kubeconfig 下新增加一个 lucky 这个用户
#(1)把 lucky 这个用户添加到 kubernetes 集群中,可以用来认证 apiserver 的连接
kubectl config set-credentials lucky --clientcertificate=./lucky.crt --client-key=./lucky.key --embed-certs=true
#(2)在 kubeconfig 下新增加一个 lucky 这个账号
kubectl config set-context lucky@kubernetes --cluster=kubernetes --user=lucky
#(3)切换账号到 lucky,默认没有任何权限
kubectl config use-context lucky@kubernetes
kubectl config use-context kubernetes-admin@kubernetes #这个是集群用户,有任何权限
#把 user 这个用户通过 rolebinding 绑定到 clusterrole 上,授予权限,权限只是在 lucky 这个名称空间有效
#(1)把 lucky 这个用户通过 rolebinding 绑定到 clusterrole 上
kubectl create ns lucky
kubectl create rolebinding lucky -n lucky --clusterrole=cluster-admin --user=lucky
#(2)切换到 lucky 这个用户
kubectl config use-context lucky@kubernetes
#(3)测试是否有权限
kubectl get pods -n lucky
#有权限操作这个名称空间
kubectl get pods
#没有权限操作其他名称空间
#添加一个 lucky 的普通用户
useradd lucky
cp -ar /root/.kube/ /home/lucky/
chown -R lucky.lucky /home/lucky/
su - lucky
kubectl get pods -n lucky