【云原生--Kubernetes】安全机制

一. 安全机制

Kubernetes 作为一个分布式集群的管理工具，保证集群的安全性是其一个重要的任务。API Server 是集群内部各个组件通信的中介， 也是外部控制的入口。所以 Kubernetes 的安全机制基本就是围绕保护 API Server 来设计的。

api server是k8s集群的入口，默认有两个端口:

• 本地端口8080: 用于接收HTTP请求, 不对外服务, 非认证或授权的HTTP请求通过该端口访问API Server
• 安全端口6443: 用于接收认证授权的HTTPS请求，对外服务。

用户通过安全端口访问k8s的api server需要过三关：认证、授权、准入控制

• Authentication认证: 用于识别用户身份
• Authorization授权: 确认是否对资源具有相关的权限
• Admission Control准入控制: 判断操作是否符合集群的要求
  

二. 认证（Authentication）

2.1 认证方式

• HTTP Token 认证：通过一个 Token 来识别合法用户
  HTTP Token 的认证是用一个很长的特殊编码方式的并且难以被模仿的 Token 字符串来表达客户的一种方式。Token 是一个很长的很复杂的字符串，每一个 Token 对应一个用户名存储在 API Server 能访问的文件中。当客户端发起 API 调用请求时，需要在 HTTP Header 里放入 Token。

• HTTP Base 认证：通过用户名+密码的方式认证
  用户名:密码 用 BASE64 算法进行编码后的字符串放在 HTTP Request 中的 Heather Authorization 域里发送给服务端， 服务端收到后进行解码，获取用户名及密码。

• HTTPS 证书认证（最严格）：基于 CA 根证书签名的客户端身份认证方式。

注：Token 认证和 Base 认证方式只能进行服务端对客户端的单向认证，而客户端不知道服务端是否合法；而 HTTPS 证书认证方式 则可以实现双向认证。

1. 需要被认证的访问类型：

• Kubernetes 组件对 API Server 的访问：kubectl、kubelet、kube-proxy
• Kubernetes 管理的 Pod 对 API Server 的访问：Pod（coredns,dashborad 也是以 Pod 形式运行）

2. 安全性说明：

• Controller Manager、Scheduler 与 API Server 在同一台机器，所以直接使用 API Server 的非安全端口访问（比如 8080 端口）
• kubectl、kubelet、kube-proxy 访问 API Server 就都需要证书进行 HTTPS 双向认证，端口号使用 6443

3. 证书颁发：

• 手动签发：使用二进制部署时，需要先手动跟 CA 进行签发 HTTPS 证书
• 自动签发：kubelet 首次访问 API Server 时，使用 token 做认证，通过后，Controller Manager 会为 kubelet 生成一个证书， 以后的访问都是用证书做认证了

4. kubeconfig
   kubeconfig 文件包含集群参数（CA 证书、API Server 地址），客户端参数（上面生成的证书和私钥），集群 context 上下文参数 （集群名称、用户名）。Kubenetes 组件（如 kubelet、kube-proxy）通过启动时指定不同的 kubeconfig 文件可以切换到不同的集群 ，连接到 apiserver。
   也就是说 kubeconfig 文件既是一个集群的描述，也是集群认证信息的填充。包含了集群的访问方式和认证信息。kubectl 文件默认位于 ~/.kube/config
5. Service Account
   Service Account是为了方便 Pod 中的容器访问API Server。因为 Pod 的创建、销毁是动态的，所以要为每一个 Pod 手动生成证书就不可行了。 Kubenetes 使用了 Service Account 来循环认证，从而解决了 Pod 访问API Server的认证问题。
6. Secret 与 SA 的关系
   Kubernetes 设计了一种资源对象叫做 Secret，分为两类：

• 用于保存 ServiceAccount 的 service-account-token
• 用于保存用户自定义保密信息的 Opaque

2.2 Service Account（SA）

Service Account 中包含三个部分：

• Token：是使用 API Server 私钥签名的 Token 字符串序列号，用于访问 API Server 时，Server 端认证
• ca.crt：ca 根证书，用于 Client 端验证 API Server 发送来的证书
• namespace：标识这个 service-account-token 的作用域名空间

默认情况下，每个 namespace 都会有一个 Service Account，如果 Pod 在创建时没有指定 Service Account，就会使用 Pod 所属的 namespace 的 Service Account。每个 Pod 在创建后都会自动设置 spec.serviceAccount 为 default（除非指定了其他 Service Accout）。

kubectl get sa -A

每个 Pod 启动后都会挂载该 ServiceAccount 的 Token、ca.crt、namespace 到 /var/run/secrets/kubernetes.io/serviceaccount/

kubectl get pod -n kube-system

kubectl exec -it kube-proxy-556vt -n kube-system sh

三. 鉴权（Authorization）

认证（Authentication）过程，只是确认通信的双方都确认了对方是可信的，可以相互通信。而鉴权是确定请求方有哪些资源的权限。
API Server 目前支持以下几种授权策略：

1. AlwaysDeny：表示拒绝所有的请求，一般用于测试
2. AlwaysAllow：允许接收所有请求，如果集群不需要授权流程，则可以采用该策略，一般用于测试
3. ABAC（Attribute-Based Access Control）：基于属性的访问控制，表示使用用户配置的授权规则对用户请求进行匹配和控制。也就是说定义一个访问类型的属性，用户可以使用这个属性访问对应的资源。此方式设置较为繁琐，每次设置需要定义一长串的属性才可以。
4. Webhook：通过调用外部 REST 服务对用户进行授权，即可在集群外部对K8S进行鉴权
5. RBAC（Role-Based Access Control）：基于角色的访问控制，K8S自1.6版本起默认使用规则

3.1 RBAC

• RBAC 相对其它访问控制方式，拥有以下优势：

1. 对集群中的资源（Pod,Deployment,Service）和非资源（元信息或者资源状态）均拥有完整的覆盖
2. 整个 RBAC 完全由几个 API 资源对象完成，同其它 API 资源对象一样，可以用 kubectl 或 API 进行操作
3. 可以在运行时进行调整，无需重启 API Server，而 ABAC 则需要重启 API Server

• RBAC 的 API 资源对象说明
  RBAC 引入了 4 个新的顶级资源对象：Role、ClusterRole、RoleBinding、ClusterRoleBinding，4 种对象类型均可以通过 kubectl 与 API Server 操作。

官方文档：https://kubernetes.io/docs/reference/access-authn-authz/rbac/

• 角色
  Role：授权指定命名空间的资源控制权限
  ClusterRole：可以授权所有命名空间的资源控制权限
  如果使用 RoleBinding 绑定 ClusterRole，仍会受到命名空间的影响；如果使用 ClusterRoleBinding 绑定 ClusterRole， 将会作用于整个 K8S 集群。

• 角色绑定
  RoleBinding：将角色绑定到主体（即subject）
  ClusterRoleBinding：将集群角色绑定到主体

• 主体（subject）
  User：用户
  Group：用户组
  ServiceAccount：服务账号

User 使用字符串表示，它的前缀 system: 是系统保留的，集群管理员应该确保普通用户不会使用这个前缀格式；
Group 书写格式与 User 相同，同样 system: 前缀也为系统保留。
Pod使用 ServiceAccount 认证时，service-account-token 中的 JWT 会保存用户信息。 有了用户信息，再创建一对角色/角色绑定（集群角色/集群角色绑定）资源对象，就可以完成权限绑定了。

• Role and ClusterRole
  在 RBAC API 中，Role 表示一组规则权限，权限只能增加（累加权限），不存在一个资源一开始就有很多权限而通过 RBAC 对其进行减少的操作。也就是说只有白名单权限，而没有黑名单权限的概念。

小结：
Role 只能定义在一个 namespace 中，如果想要跨 namespace 则可以创建 ClusterRole，也就是说定义 ClusterRole 不需要绑定 namespace。

3.2 示例

• Role 示例：

apiVersion: rbac.authorization.k8s.io/v1  #指定 core API 组和版本
kind: Role   #指定类型为 Role
metadata:
  namespace: default   #使用默认命名空间
  name: pod-reader     #Role 的名称
rules:   #定义规则
- apiGroups: [""]   #""表示 apiGroups 和 apiVersion 使用相同的 core API 组，即 rbac.authorization.k8s.io
  resources: ["pods"]  #资源对象为 Pod 类型
  verbs: ["get", "watch", "list"]  #被授予的操作权限

把 pod-reader 这个 Role 赋予给一个用户，那么这个用户将在 default 命名空间中具有对 Pod 资源对象 进行 get（获取）、watch（监听）、list（列出）这三个操作权限。

• ClusterRole 示例：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  # "namespace" 被忽略，因为 ClusterRoles 不受名称空间限制
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]  #资源对象为 Secret 类型
  verbs: ["get", "watch", "list"]

cluseterole不受名称空间印象，其作用在所有名称空间上，所以无需指定namespace

• RoleBinding示例

1. 引用Role角色绑定

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: zhangsan
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

将 default 命名空间的 pod-reader Role 授予 zhangsan 用户，此后 zhangsan 用户在 default 命名空间中将具有 pod-reader 的权限。

2. 使用ClusterRole角色绑定
   RoleBinding 同样可以引用 ClusterRole 来对当前 namespace 内 User、Group 或 ServiceAccount 进行授权， 这种操作允许集群管理员在整个集群内定义一些通用的 ClusterRole，然后在不同的 namespace 中使用 RoleBinding 来引用。

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-secrets
  namespace: kube-public
subjects:
- kind: User
  name: lisi
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

注：因为RoleBinding绑定是受名称空间限制，所以即使ClusterRole角色拥有名称空间权限，也会被限制作用在RoleBingding设置的名称空间内
所以以上的lisi用户对secrets的访问权限只能在kube-public空间中使用

• ClusterRoleBinding 示例：
  使用 ClusterRoleBinding 可以对整个集群中的所有命名空间资源权限进行授权

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-secrets-global
subjects:
- kind: Group
  name: manager
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

ClusterRoleBinding 授权 manager 组内所有用户在全部命名空间中对 secrets 进行访问。

3.3 Resources

Kubernetes 集群内一些资源一般以其名称字符串来表示，这些字符串一般会在 API 的 URL 地址中出现； 同时某些资源也会包含子资源，例如 log 资源就属于 pods 的子资源，API 中对 Pod 日志的请求 URL 样例如下：
GET /api/v1/namespaces/{namespace}/pods/{name}/log

在 RBAC 授权模型中控制这些子资源的访问权限，可以通过 / 分隔符来分隔资源和子资源实现。
例：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-and-pod-logs-reader
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list"]

rules内的资源定义有如下类型：

1. rules.verbs有：“get”, “list”, “watch”, “create”, “update”, “patch”, “delete”, “exec”
2. rules.resources有：“services”, “endpoints”, “pods”, “secrets”, “configmaps”, “crontabs”, “deployments”, “jobs”, “nodes”, “rolebindings”, “clusterroles”, “daemonsets”, “replicasets”, “statefulsets”, “horizontalpodautoscalers”, “replicationcontrollers”, “cronjobs”
3. rules.apiGroups有：“”,“apps”, “autoscaling”, “batch”

四. 准入控制（Admission Control）

通过认证和鉴权之后，客户端并不能得到API Server的真正响应，这个请求还需通过Admission Control所控制的一个准入控制插件列表的层层考验。

Admission Control配备有一个“准入控制器”的插件列表，发送给API Server的任何请求都需要通过列表中每一个准入控制器的检查，检查不通过API Server拒绝此调用请求。
此外，准入控制器还能够修改请求参数以完成一些自动化的任务，比如Service Account这个控制器。
当前可配置的Admission Control准入控制如下：

• AlwaysAdmit：允许所有请求；
• AlwaysPullmages：在启动容器之前总去下载镜像，相当于在每个容器的配置项imagePullPolicy=Always
• AlwaysDeny：禁止所有请求，一般用于测试；
• DenyExecOnPrivileged：它会拦截所有想在Privileged Container上执行命令的请求，如果你的集群支持Privileged Container，你又希望限制用户在这些Privileged Container上执行命令，强烈推荐你使用它，其功能已经合并到DenyEscalatingExec中。
• ImagePolicyWebhook：这个插件将允许后端的一个Webhook程序来完成admission controller的功能。ImagePolicyWebhook需要使用一个配置文件（通过kube-apiserver的启动参数–admission-control-config-file设置）定义后端Webhook的参数。目前该插件还处在Alpha版本。
• Service Account：这个plug-in将ServiceAccount实现了自动化，默认启用，如果你想使用ServiceAccount对象，那么强烈推荐使用它。
• SecurityContextDeny：这个插件将使用SecurityContext的Pod中的定义全部失效。SecurityContext在Container中定义了操作系统级别的安全设定（uid，gid，capabilityes，SELinux等）。在未启用PodSecurityPolicy的集群中建议启用该插件，以禁用容器设置的非安全访问权限。
• ResourceQuota：用于资源配额管理目的，作用于namespace上，它会观察所有请求，确保在namespace上的配额不会超标。推荐在Admission Control参数列表中将这个插件安排在最后一个，以免可能被其他插件拒绝的Pod被过早分配资源。
• LimitRanger：用于资源限制管理，作用于namespace上，确保对Pod进行资源限制。启用该插件还会为未设置资源限制的Pod进行默认设置，例如为namespace "default"中所有的Pod设置0.1CPU的资源请求。
• InitialResources：是一个实验特性，旨在为未设置资源请求与限制的Pod，根据其镜像的历史资源的使用情况进行初始化的资源请求、限制设置。
• NamespaceLifecycle：如果尝试在一个不存在的namespace中创建资源对象，则该创建请求将被拒绝。当删除一个namespace时，系统将会删除该namespace中所有对象，保存Pod，Service等。
• DefaultStorageClass：为了实现共享存储的动态供应，为未指定StorageClass或PV的PVC尝试匹配默认的StorageClass，尽可能减少用户在申请PVC时所需了解的后端存储细节。
• DefaultTolerationSeconds：这个插件为那些没有设置forgiveness tolerations并具有notready:NoExecute和unreachable:NoExecute两种taints的Pod设置默认的“容忍”时间，为5min。
• PodSecurityPolicy：这个插件用于在创建或修改Pod时决定是否根据Pod的security context和可用的PodSecurityPolicy对Pod的安全策略进行控制。

五. ServiceAccount访问案例

5.1 创建namespace

kubectl create namespace sa

创建namespace默认会创建一个serviceaccount和一个secret

#查看sa名称空间的sa证书
kubectl get sa -n sa
#查看sa名称空间的secret
kubectl get secret -n sa

#查看sa证书
kubectl describe sa default -n sa

#查看token
kubectl describe secret default-token-4mp4g -n sa

5.2 创建pod验证其sa与secret

#创建一个pod
kubectl run nginx --image=nginx:1.15 -n sa
#查看pod详细信息
kubectl get pod nginx -n sa -o yaml |grep serviceAccount

创建pod不指定serviceaccount则默认使用default

5.3 创建一个sa

#在sn名称空间中创建一个sa
kubectl create sa daniel -n sa
#查询sa
kubectl get sa -n sa
#查询secret
kubectl get secret -n sa

5.4 创建pod并自定义sa

vim sa-pod.yml

apiVersion: v1
kind: Pod
metadata:
  name: nginx2
  namespace: sa
spec:
  containers:
  - name: c1
    image: nginx:1.15-alpine
    ports:
    - name: httpd
      containerPort: 80
  serviceAccountName: daniel				# 指定sa为daniel

创建pod

kubectl apply -f sa-pod.yml
#查看pod的sa
kubectl get pod nginx2 -n sa -o yaml |grep serviceAccount