Kubernetes 的授权和审计

Kubernetes 中的账号和认证，除了基础的双向证书认证之外，还有 OIDC 等方式的第三方集成能力，这里暂且不提。这里主要想谈谈授权和审计方面的内容。

很多 Kubernetes 集群，都是一个 cluster-admin 走天下的，这和 Linux 里面只使用一个 root 账号一样，因此要完成授权和审计任务，首先需要创建的东西就是一个新用户。

在使用本地证书进行用户管理的情况下，创建新用户通常有这样几种方法：

1. 创建一个新的 ServiceAccount，使用 SA 的 Token 进行认证。
2. 使用 Kubernetes 所使用的 CA，签发新的客户端证书。
3. 创建 CSR，提交到 Kubernetes 上，通过后，获取客户端证书。

上面几个方法，完成后生成 kubeconfig 文件，并使用 RBAC 为新用户进行最小化授权，就可以用这些新用户的身份来完成“普通”用户的操作了。

在 Kubeadm 中启用审计

Kubeadm 的配置文件中加入如下内容：

apiServer:
  extraArgs:
    audit-log-path: /var/log/k8s/audit.log
    audit-policy-file: /etc/kubernetes/audit.yaml
    audit-log-maxage: "1"
    audit-log-maxsize: "100"
    audit-log-maxbackup: "1"
  extraVolumes:
  - name: audit-config
    hostPath: /etc/k8s/audit.yaml
    mountPath: /etc/kubernetes/audit.yaml
    readOnly: true
    pathType: File
  - name: audit-log
    hostPath: /var/log/k8s
    mountPath: /var/log/k8s

这个文件中指定了两个加载卷，分别用于存储配置文件和审计日志。API Server 会据此进行审计配置并输出日志。官方提供了审计策略的配置样例：

apiVersion: audit.k8s.io/v1 # This is required.
kind: Policy
# Don't generate audit events for all requests in RequestReceived stage.
omitStages:
  - "RequestReceived"
rules:
  - level: None
    verbs: ["get", "list", "watch"]
  # Log pod changes at RequestResponse level
  - level: RequestResponse
    resources:
    - group: ""
      # Resource "pods" doesn't match requests to any subresource of pods,
      # which is consistent with the RBAC policy.
      resources: ["pods"]
  # Log "pods/log", "pods/status" at Metadata level

有了 RBAC + 审计，结合专人专用的操作账户，我们就能够对用户在集群上的操作有个初步的了解，例如如下记录：

...
  "requestURI": "/apis/apps/v1/namespaces/default/deployments",
  "verb": "create",
  "user": {
    "username": "commonuser",
    "groups": [
      "dev",
      "system:authenticated"
    ]
  }
...

就代表用户 commonuser 新建了一个 Deployment。审计信息中还包括了事件发生的时间、IP、当时的 RBAC 角色等。

把审计日志汇总到 Elasticsearch 或者 Loki 之中，就能够获得集群范围内的所有我们关注的记录的操作了。

为 Kubeadm 集群启动 PSP

RBAC 决定一个用户能够操作什么资源（例如 Pod、Deployment、Service、SA 等），能够如何操作（例如创建、删除），而 PSP 则确定了 Pod 自身所能完成的任务：例如加载主机卷、使用 sysctl 等。

启动 PSP 是个相对来说较危险的操作。首先要做的就是获取现在运行之中的应用所使用的策略，并将策略涉及的权限和当前使用的 ServiceAccount 对应起来，简单说来步骤如下：

1. 遍历运行中的 Pod，获取其中的特权情况，以及当前使用的 ServiceAccount。
2. 根据特权情况编写 PodSecurityPolicy 策略。
3. 为策略设置 Role 或者 ClusterRole，绑定到 ServiceAccount。

Krew 有个 psp-advice 插件，能完成上面的前两个步骤——形成单一的 PSP 对象，相对来说有些粗放。例如使用这个插件在一个启动了 Calico 的 Kubeadm 集群上生成的 PSP（kubectl advise-psp inspect）：

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  creationTimestamp: null
spec:
  allowedHostPaths:
  - pathPrefix: /lib/modules
    readOnly: true
  - pathPrefix: /var/lib/calico
    readOnly: true
  - pathPrefix: /opt/cni/bin
    readOnly: true
  - pathPrefix: /var/run/nodeagent
    readOnly: true
  - pathPrefix: /var/lib/cni/networks
    readOnly: true
  - pathPrefix: /usr/libexec/kubernetes/kubelet-plugins/volume/exec/nodeagent~uds
    readOnly: true
  - pathPrefix: /run/xtables.lock
    readOnly: true
  - pathPrefix: /etc/cni/net.d
    readOnly: true
  - pathPrefix: /var/run/calico
    readOnly: true
  fsGroup:
    rule: RunAsAny
  hostNetwork: true
  hostPorts:
  hostPorts:
  - max: 0
    min: 0
  privileged: true
  runAsUser:
    rule: RunAsAny
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  volumes:
  - hostPath
  - secret
  - configMap

我们可以简单的为这个 PSP 生成一个 Role，并绑定到当前运行的 SA 上：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: kube-system-psp
  namespace: kube-system
rules:
- apiGroups:
  - extensions
  resourceNames:
  - kube-system
  resources:
  - podsecuritypolicies
  verbs:
  - use
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: kube-system-psp
  namespace: kube-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: kube-system-psp
subjects:
- kind: ServiceAccount
  name: default
  namespace: kube-system
- kind: ServiceAccount
...

完成所有步骤之后，在 API Server 的 --enable-admission-plugins 参数里面加入 PodSecurityPolicy，重新启动服务即可。

接下来就可以使用 PSP 为各个不同的 SA、用户创建角色，确定各种情况下创建 Pod 的安全策略，例如绝大多数业务 Pod 是无需使用特权模式、HostNetwork 的。

结论

各司其职是个基础，在 RBAC/PSP 支持下，能够比较容易的针对用户、ServiceAccount、Namespace 进行细粒度的权限控制，例如对各种资源的操作权限、对 Pod 的日志、Exec 等操作、以及 Pod 自身的卷加载、特权申请等都可以进行控制，并且还可以通过审计功能进行事后追溯。